🏖️ Почему я впервые отдохнул только в 26 лет

Продолжаю рассказывать про свои отношения с отдыхом – на этот раз о том, почему мой первый отпуск случился в 26 лет

🙄 Поиск себя

Получив магистра по робототехнике, в 23 года я вернулся в родной город в заснеженной Якутии 🥶. Там из роботов - максимум микроволновка

Но работать надо было, поэтому устроился инженером по связи в Мегафон. Я не шарил за связь, но у меня был напарник, благодаря которому я продержался полгода 😏. Поняв, что это не мое, уволился - хотя через полгода я уже мог получить отпуск в 1 месяц

Дальше был сумбур – поработал в родном городе 2 недели в другом месте, понял, что нужно ехать в Москву. После переезда удалось найти работу инженером-программистом. Но предприятие оказалось в антураже СССР с тестировщиками, которым уже за 70. Чувствовал себя некомфортно, поэтому снова уволился через 2 недели 😧

В итоге прыгал между работами и нифига не отдыхал

👨‍💻 Поиск себя… в IT

Однако в Москве довольно быстро получилось войти в IT. Причем не абы где, а в Москва-Сити 💎. Правда, формат был очным, поэтому приходилось 5 дней в неделю кататься туда-сюда и тратить по 3 часа на дорогу. Однако новая сфера и молодой коллектив перекрывали эти минусы

И вот через полгода я ждал, что наконец-то наступит мой первый заслуженный отпуск, но и тут не повезло – на работе перестали платить зарплату, и я уволился 🤯

Отдыхать не стал, устроился в другое место. Но это оказался аутстафф, тогда мне, новичку в сфере, этот формат не пришелся по вкусу, и я уволился через 2 месяца 🥴. И тут же устроился на место, где работаю сейчас

🌴 Первый отпуск

И только тут случился мой долгожданный отпуск длиной в 1 неделю. Мы с женой отправились на Красную Поляну – замечательное место, чтобы отдохнуть от всего 🏔

Однако мой мозг отличника переживал за работу и проекты – поэтому я заходил в рабочие чаты, отвечал на сообщение и в целом был включен в работу. Классическая ошибка: в итоге в отпуске не скажу, что отдыхал 😫

Правда, в следующий отпуск уже учел эти нюансы, да и стал относиться ко всему проще. Выключил уведомления, о работе не переживал и вообще забыл о ней. И только тогда я наконец-то полноценно отдохнул две недели, и это было прекрасно 🔠🔠🔠🔠

📌 Какие уроки вынес

Что я понял из своего опыта:

➡️ Херня случается. Если вынуждены уволиться и есть подушка безопасности – лучше взять перерыв в одну-две недели и постараться отдохнуть
➡️ В отпуске забываем про чаты и работу. Поверьте, и без вас справятся
➡️ Если есть возможность – делать отпуск насыщенным. Посетить другую страну, начать что-то новое, съездить на природу
➡️ Не работать без отпусков. Выгорание гарантировано – см. предыдущий пост

—————

⬇ А как вы отдыхаете от работы и проводите отпуск? Пишите в комментариях

#истории_системный_анализ

Помните, я вписался в конкурс тг-каналов?

Я выбрал трек «Карьера», и меня добавили в уютный чатик. Там я увидел других интересных авторов, которые тоже пишут про свой карьерный путь

Кто-то только начинает его и рассказывает о первых достижениях, а кто-то уже занимает (или занимал) руководящую должность и делится неочевидным опытом управленца. HR-менеджеры, Data-аналитики, Карьерные коучи, Продакты, Маркетологи – пишут специалисты из разных предметных областей, но в основном IT

💡 Мы объединили наши каналы в папку, чтобы не потеряться. Делюсь этой находкой с вами - возможно, тоже найдете для себя интересных авторов

💎 Папка карьерных каналов

Как понять, что сбор требований завершен? Чек-лист для СА

Все зависит от методологии

➡ Сбор требований в Agile

В Agile сбор требований происходит в рамках отдельной фичи. Вот как понять, где финиш:

✅ Не можете придумать новые use case или user story для этой фичи
✅ На встречах обсуждается одно и то же
✅ Заказчик уже говорит о фичах на будущее, а не о текущей
✅ Новые требования выходят за рамки фичи
✅ Новые требования имеют низкий приоритет
✅ У разработки после груминга нет или крайне мало вопросов

Если выполнены все эти пункты, можно говорить, что требования собраны 🎉

Требования могут измениться уже на этапе аналитики/разработки, но это тема для отдельной дискуссии. Могу рассказать о своем опыте - ставь 👍, если интересно

➡ Сбор требований в Waterfall

В Waterfall, в отличие от Agile, сбор требований покрывает весь продукт

Критерии завершенности сбора такие же, но нужно декомпозировать ТЗ на отдельные фичи

У меня был проект в госсекторе. Сначала встречи очень частые, каждую неделю или несколько раз в неделю. Ближе к середине проекта раз в 2 недели. После уже сбор требований не проводится

➡ Можно ли собрать все-все требования?

Перфекционисты захотят собрать все-все требования и будут раз за разом пересматривать их, особенно в случае малейших изменений. Это сильно затянет разработку

Все требования собрать невозможно (особенно в Agile) – заказчику что-то приснилось, или прочитал новости о какой-то трендовой фиче. Или во время разговора с коллегой родились новые идеи. Даже если все-все требования собраны, высок риск, что уже завтра они поменяются

На одном из моих проектов так и было - 3 месяца на разработку, а сбор требований происходил вплоть до последней недели. Заказчик постоянно накидывал свои хотелки, а мы их не отбивали. В итоге проект вышел тяп-ляп

Правильнее и проще собрать необходимые требования для реализации фичи, а уже потом улучшать ее

⬇ Итог

Изменение требований – это норма. Главное тут – вовремя остановиться. Не собрать все-все требования, а собрать и согласовать столько, сколько необходимо для релиза. А оценить достаточность требований можно по чек-листу выше

—————

💬 А как у вас со сбором требований на проекте? Часто ли меняются? Пишите в комментариях

#полезное_системный_анализ

Как увидеть запросы в режиме онлайн? Используем Charles

Не знаете, как смотреть API-запросы в режиме реального времени? Держите классный инструмент - Charles

➡ Принцип работы

Charles – сниффер (sniffer – перехватчик) HTTP/HTTPS трафика. Работает как прокси-сервер: вклинивается в цепочку «Клиент - Сервер», перехватывает все запросы и отображает их в интерфейсе программы

Работает для веб и мобилки, но наиболее эффективно для мобильных приложений, т.к. для веб проще посмотреть запросы через WebTools. Однако для работы нужна будет дебаг-сборка приложения, а не прод – там запросы закрыты

Есть еще другие снифферы: Proxyman, Fiddler, Wireshark. Суть одна, отличаются интерфейсом, набором функций и платформами

➕ В Charles мне понравились следующие фишки:

• Можно увидеть порядок вызова запросов
• Отображается полная информация о запросе и ответе
• Можно подменить запрос и посмотреть, что будет

⚠ Однако есть и некоторые трудности
• Сложно настраивать. У меня Charles работает только на Android, на iOS трудности с сертификатами
• Громоздкий интерфейс – легко потеряться
• Бесплатная версия на 30 дней, а потом ограничение по времени работы

➡ Когда Charles пригодится СА
• При онбординге на проект
• При изучении задачи на доработку/улучшение фичи
• При выявлении багов и изучении проблемы

➡ Мой опыт
Использовал Charles на трех проектах, все мобильные приложения. На двух из них восстанавливал документацию, на третьем нужно было понимать, как дорабатывать существующую функциональность – что нужно изменить в запросе, в каком порядке вызывать новый

Благодаря прокси наглядно видел, в каком порядке вызываются запросы, какие из доки уже устаревшие, какой реальный ответ от сервера приходит

⬇ Итог
Если вы работаете с мобильным приложением, и вам непонятно, как оно работает с технической стороны – качайте дебаг-сборку и установите Charles или любой другой proxy

Также делюсь статьей с Хабра про установку на все платформы и обзор функциональности Charles

————

Как думаете, пригодится в работе?

👍 Да, нужно попробовать
🤷‍♂️ Нет, не потребуется

#инструменты_системный_анализ

💡 Паттерны микросервисной архитектуры для СА

Сохраняйте список паттернов микросервисной архитектуры (МСА), который пригодится системному аналитику при:

– Распиле монолита на микросервисы
– Проектировании МСА
– Подготовке к собеседованию
– Изучении принципов МСА

Okay, let’s gooo

🔹 Паттерны проектирования

1. Разбиение по бизнес-возможностям – на каждую хотелку бизнеса по одному микросервису. Пример: сервис управления доставкой
2. Разбиение по поддоменам – отдельный микросервис для каждой сущности. Пример: сервис заказов (сущность заказ)

🔹 Паттерны декомпозиции

1. «Душитель» (Strangler) – постепенный переход с монолита на МСА, по завершении монолит отключается
2. «Слой антикоррупции» (Anti-Corruption Layer) – когда полностью отказаться от монолита невозможно. В этом случае добавляется сервис-прослойка для связи с новыми микросервисами

🔹 Паттерны коммуникации микросервисов

1. API-шлюз (API Gateway) – единая точка входа для клиентов. Для маршрутизации запросов и не только
2. Бэкенды для фронтендов (Backend for Frontends, BFF) – отдельные API-шлюзы под разные платформы (Web, Mobile, Desktop) или роли (Клиент, Ресторан, Курьер)

🔹 Паттерн управления данными

1. База данных на сервис – у каждого микросервиса своя БД
2. Сага (Saga) – про управления транзакциями в микросервисной архитектуре с откатом при ошибках
3. API-композиция – сервис для агрегации данных из нескольких источников

🔹 Паттерны мониторинга микросервисов

1. Проверка работоспособности (Health Check) – эндпоинт /health для проверки статуса сервиса
2. Трассировка запросов – каждому внешнему запросу назначается уникальный ид (traceId) для отслеживания в цепочке вызовов
3. Агрегация логов – централизованный сбор логов со всех сервисов

🔹 Паттерны построения UI

1. Сборка интерфейса на стороне клиента – фронт запрашивает данные и формирует интерфейс самостоятельно
2. Или на стороне сервера – сервак отдает готовые страницу, фронт просто отображает

—————

Паттернов больше, но остальные чаще нужны разработчикам. Подробнее про все эти шаблоны я читал в книге «Паттерны проектирования микросервисной архитектуры», о которой рассказывал ранее

⬇ Хотите разбор некоторых паттернов?

🤩 Естественно
🗿 Нет, списка достаточно

#полезное_системный_анализ

Проект провалился, я виноват? 🌧

Однажды я вел сразу два проекта, и оба считаю неудачными

Первый фейл

Заказчик хотел автоматизировать работу своих менеджеров, чтобы у них все было в одном месте. Срок был сильно сжатый

Что пошло не так:
🔴 Заказчик накидывал свои хотелки как только мог, мы их не отбивали
🔴 В основе решения иностранный сервис, который в итоге ушел из РФ
🔴 Как СА я не поспевал за темпом разработки, поэтому ребята делали не так, как хотел заказчик
🔴 Тут случился мой конфликт с разрабом с последующим его увольнением. Это затормозило разработку важнейшей фичи

В итоге мы не успели в срок и дорабатывали решение за счет компании, а результатом заказчик остался недоволен (да и мы тоже)

Второй фейл

Второй проект – из гос. сектора. Несложный, но дико непонятный из-за специфичной сферы деятельности компании

Что пошло не так:
🔴 Работали по дырявому ТЗ с противоречивыми требованиями, поэтому возник сильный разрыв ожиданий
🔴 Из-за сферы деятельности не понимали, правильно ли делали или нет
🔴 Выяснилось, что наш заказчик и не заказчик вовсе, а есть другой заказчик, но об этом узнали на финальном демо

Итог: успели в срок и сделали все по ТЗ, но из-за разрыва ожиданий и неопределенности со стороны заказчика дорабатывали систему за свой счет

✍️ Какие уроки извлек

После этих проектов у меня было чувство вины – где-то я мог лучше, где-то из-за моих ошибок замедлили разработку, где-то нужно было лучше защищать технические решения

Но спустя время понял, что моя вина минимальна. Вот почему не стоит винить себя в провале

🟢 Не все мы можем контролировать и предугадать. Бюджеты урезают, кто-то халтурит, у кого-то другой темп работы, санкции прилетают, что там в голове у заказчика - никто не знает
🟢 Виноват не конкретный человек, а вся команда. Если ты часто косячишь, тебя просто уволят. Если тебе тычут на ошибки, этот человек не умеет общаться. Если команда ищет виноватых вместо решения – стоит найти компанию получше. Во всей моей практике удар принимала вся команда, и мы вместе решали проблему
🟢 Иногда твоей квалификации просто не хватает. Это нормально что-то не знать. Одно дело, когда ты соврал на собеседовании, другое – когда от тебя хотят большего, чем ты можешь

Что можно сделать, чтобы минимизировать вероятность провала:

1 Делиться своими переживаниями с командой и руководителем
2. Защищать свои решения и конструктивно обсуждать их с командой
3. Принимать, что ошибки – часть работы
4. Учиться на ошибках, выписать их и провести саморефлексию
5. Делать свою работу честно и добросовестно, чтобы не винить себя
6. Если не справляешься, попросить помощи – коллеги, в чате аналитиков, у ментора, у ChatGPT

Провал проекта — это почти всегда системная проблема, а не вина одного человека. Если ты честно выполнил свою работу, но проект всё равно сорвался — значит, были другие факторы. Анализируй, учись и двигайся дальше

———————
⬇️ А у вас были неудачные проекты? Пишите, что чувствовали и какие уроки извлекли

#истории_системный_анализ

Собес на 20 минут – red флаг при трудоустройстве? 🚩

Вас тоже бесят супер короткие собесы, после которых сидишь и думаешь: это ты так круто себя показал, или после твоего отключения они там сидят и ржут?

🔹 Мой опыт

У меня было два таких собеса, оба в известные банки. На первом человек просто не был подготовлен к собесу – вероятно его попросили подменить коллегу. Поэтому это был короткий и лайтовый разговор, с которым бы справился и джун (а я собеседовался на senior), а после мне прилетел оффер. Но подобный собес меня смутил, непонятно, что там делают и чем занимаются, поэтому отказал

Второй собес поинтереснее. 30 минут, из них первые 15 минут про проект и поверхностные вопросы СА, остальные 15 нерелевантные должности вопросы (деплоил ли проект, мигрировал ли БД) и бесполезная болтовня про жизнь. Я понял, что что-то не так

Прилетел отрицательный фидбек – сказали, что очень слабый специалист ❓

Потом прочитал подробнее и понял, что интервьюеры сделали ошибочный вывод о некоторых скилах: они просто не задали правильные вопросы. Наверное, стоило спрашивать меня не о сериалах, а о моей работе, а еще можно было поработать на 10 минут дольше

🔹 Другой опыт

Иной опыт у моей супруги – при трудоустройстве в IT-компанию, где она сейчас работает, у нее был сухой и короткий технический собес, после которого она сильно расстроилась. Не было понятно ничего, она думала, что провалила

Но уже через час ей прилетел положительный фидбек и приглашение на следующий этап

🔹 Почему так получается

Такие собеседования сильно зависят от интервьюера:

1. Он – очень скиловый человек, с завязанными глазами определяет компетенции кандидата и найдет человека в багажнике на парковке
2. У него плохое настроение или «таких как вы у меня 10 человек в день»
3. Он оказался тут случайно, попросили подменить – приходится выкручиваться
4. У него не развиты софт-скиллы
5. Проводит собес и параллельно работает
6. Не умеет проводить собес, поэтому это сухой и быстрый опрос с вопросами из статьи с Хабра «Топ 100 вопросов системному аналитику на собесе»

Но в любом случае кандидат остается в смятении. Даже если придет положительный фидбек, осадок скорее всего останется. Исключение – если мастерски попал в ожидания

Есть и обратная сторона – когда кандидат действительно очень слабый. Но в посте подразумеваю, что с кандидатом все норм

🔹 Что делать после отрицательного фидбека

Чтобы сухой отказ не расстраивал, поинтересуйтесь, что было не так:

1. Запросите подробный фидбек
2. Запросите критерии оценки
3. Проанализируйте свои ответы и сделайте выводы

Так можно понять, это вы где-то не так ответили, или интервьюер не успел раскрыть ваши навыки

——————

⚠️ Короткие собесы – не всегда red flag, но часто сигнализируют о слабом интервьюере или неорганизованности. Если после такого общения остается осадок – стоит насторожиться

На мой взгляд собес нужно уметь проводить: готовиться к нему, уметь сбавлять напряжение, выдерживать темп, в идеале – сделать из этого целостную историю (разобрать все скиллы на одном сквозном примере). Такой подход требует опыта – и времени больше, чем 20-30 минут

⬇ А у вас были подобные собесы? Какой результат, что чувствовали? Пишите в комментариях

#собеседования_системный_анализ

Частые вопросы про паттерны МСА на собесе СА 📌

Тут рассказал про основные паттерны МСА, а сейчас – про вопросы по этой теме, которые мне задавали на собесе

Что такое BFF?

Тут важно понимать, что такое API Gateway и зачем он в системе. BFF – Backend for Frontend (Бэкенды для Фронтендов) – подход, при котором используется несколько API Gateway под разные платформы (мобильные девайсы, десктоп, веб) или роли (клиент, курьер, ресторан). BFF используется, например, в Uber.

Это снижает нагрузку, разграничивает API и позволяет отдать разные Gateway на поддержку разных команд. Но если в системе роли плюс-минус похожи, а функциональность платформ одинаковая, в шаблоне нет смысла

Задача – разделить монолит на микросервисы. Что будешь делать?

В ответе говорим про два шаблона из группы «Паттерны декомпозиции» – Strangler или Anti-Corruption Layer. Аналитику сначала нужно изучить функциональность, а затем спроектировать будущие сервисы на основе этих паттернов

О чем паттерн CQRS?

О нем я не писал, но на собеседовании меня однажды спросили. CQRS (Command Query Responsibility Segregation) – паттерн, разделяющий операции чтения (запросы, queries) и записи (commands). При этом под чтение и запись создаются разные модели данных.

Шаблон применяется, когда в системе есть дисбаланс по операциям (например, чтение чаще чем запись), и он помогает масштабировать систему. Не стоит применять, если у вас простое CRUD-приложение или нет требований к масштабируемости

Как решается проблема согласованности данных в микросервисах?

Когда в одной операции задействовано несколько микросервисов, и один может не обновить/записать данные – возникает несогласованность

Тут на помощь придет паттерн Saga – бизнес-транзакция разбивается на цепочку локальных транзакций. Если хотя бы одна не выполнится – запускаются компенсирующие транзакции (откат). Подробнее разберем в следующем посте

Как определяются границы микросервисов? / С чего начать проектирование?

Обращаемся к группе «Паттерны проектирования». Каждый сервис должен отвечать за отдельную бизнес-область (домен, сущность): базу данных, бизнес-логику и API мы проектируем в пределах этой области.

Тут может возникнуть проблема с «Божественными классами», когда одна сущность включает несколько других – в этом случае ее нужно декомпозировать

Как организовать мониторинг и логирование микросервисов?

Тут поможет шаблон «Агрегация логов» – то есть централизованный сбор логов со всех сервисов для возможности мониторинга

Конечно, каждый сервис может локально собирать логи, но так их будет сложнее анализировать, а рано или поздно их объем повлияет на производительность сервиса

Как повысить отказоустойчивость микросервиса?

Еще один неочевидный паттерн для СА – «Предохранитель» (Circuit Breaker). Шаблон основан на отслеживании количества неудачных запросов к сервису

Если мы отправили 50 запросов сервису, а он не ответил, то Circuit Breaker временно блокирует вызовы к нему, переключаясь на fallback-логику (например, кэш или заглушу). За это время сервис восстановится и продолжит свою работу

➡ Итог

Перед собеседованием на проект, где есть МСА, нужно повторить:

🔹 API Gateway vs BFF
🔹 Saga
🔹 Strangler vs Anti-Corruption Layer
🔹 Паттерны проектирования
🔹 (вряд ли попадется, но вдруг) Circuit Breaker, CQRS

—————

⬇ Сохраняйте эти вопросы – пригодятся на собеседовании. В следующем посте расскажу простыми словами про самый важный паттерн микросервисной архитектуры

#полезное_системный_анализ

Нужно ли СА знать программирование? + Краткий анализ рынка

Все чаще слышу, что на собесах спрашивают навыки программирования у системных аналитиков, причем даже у джунов

Давайте разбираться, нужно или нет

🔹 Что там на рынке?

Проанализировал вакансии на HH. Из 2685 вакансий в 74 встречаются ключевые слова «код» и «язык». Это всего 2.75%. Если пройтись по каждой, то можно убрать еще несколько вакансий, т.к. в выдаче попадаются «английский язык» и «дресс-код»

В 15% из отобранных вакансий это обязательное требование, в 45% это «желательно» или «будет плюсом», в 40% это «большой плюс»

😄 Самое интересное – вакансии, в которых это требование обязательное:

– Системный аналитик (middle) (еще ок)
– Младший системный аналитик/Технический писатель
– Младший системный аналитик

А для мидлов и сеньоров это опционально ❓

🔹 Зачем нужен этот навык?

Когда это действительно нужно:

1. Специфичный стек, или сам проект специфичен (блокчейн, анализаторы кода, информационная безопасность) – тогда придется разбираться в сложных процессах, завязанных на коде и железе
2. Активно анализируют логи, а в них встречаются фрагменты кода – навык поможет быстрее установить проблему и точнее поставить задачу
3. Нет документации, держатели знаний уволились – придется копаться в дебрях кода и восстанавливать доку
4. СА работает в паре с архитектором и в перспективе может вырасти до этой должности

Когда непонятно, зачем спрашивают:

1. Работодатель не понимает, кто такой СА
2. Собеседующий "просто" интересуется кругозором кандидата

🔹 На каком уровне нужно понимание?

На самом деле вы не должны быть убер-прогером. Достаточно знать:

1. Базовые механики (циклы, условия, алгоритмы)
2. Структуры данных (в идеале – как они хранятся на компьютере)
3. ООП (классы, методы)

Все это частично встречается в других артефактах СА – циклы и условия в UML Sequence, структуры данных в JSON и БД, а ООП можно увидеть в UML Class Diagram (агрегация, наследование)

🔹 А что на деле?

Я программировал в универе на Python и C++, знаю ООП – можно сказать, умею читать и писать код. И на удивление это пригодилось на моей первой работе, где не было документации, и ее пришлось восстанавливать по коду в Gitlab. Код был на Golang, но не составило труда прочитать его – если выучишь один язык, другие изучить проще 💡 В итоге я восстановил документацию по API, базе данных и архитектуре, что помогло быстро погрузиться в проект.

Также знания пригодились при обучении СА, было проще освоить БД и UML-диаграммы

Однако после этого я работаю три года СА на разных проектах, от ноунейм-компаний до крупных игроков, и нигде повторно этот навык пока не пригодился

🔹 Так нужно или не нужно знать?

По моему мнению это не обязательный навык для СА: его отсутствие не должно быть блокером при трудоустройстве. Однако если изучить хотя бы базу, это станет ощутимым плюсом при трудоустройстве, а еще неожиданным образом может помочь в работе

—————

⬇ А что вы думаете на эту тему? Если умеете читать код, пригодилось ли в работе СА? Пишите в комментах

#вопросы_системный_анализ

🟧🟧🟧🟧🟧🟧🟧🟧🟧

Для удобства подготовил навигацию по постам, разбил по темам. Всем вновь прибывшим – добро пожаловать!

– Кто я и зачем пишу

🔹 Мысли и про бытовуху на работе:
– Я поругался с разработчиком и его уволили
– 2 навыка, которые помогли мне стать middl SA за 9 месяцев
– Проект провалился, я виноват?
– Нужно ли СА знать программирование? + Краткий анализ рынка
– Так ли плох аутстафф?
– Поработал на двух работах в IT и сгорел
– Почему я впервые отдохнул только в 26 лет

🔹 Просто о сложном:
– Просто о кэшировании
– Реплицирование vs Партиционирование vs Шардирование
– Просто о репликации
– Просто о партиционировании
– Просто о шардировании
– Паттерны микросервисной архитектуры для СА
– Как понять, что сбор требований завершен? Чек-лист для СА

🔹 Про собеседования:
– Цвет настроения желтый: как я проходил собеседование в Т-Банк
– Как я сходил на собес в Магнит Tech
– Собес на 20 минут – red флаг при трудоустройстве?

🔹 Обзоры книг:
– System Design: как выжить на собеседовании? Обзор книги Алекса Сюя
– Прочитал книгу «Микросервисы. Паттерны разработки и рефакторинга» и делюсь мнением

🔹 Обзоры курсов:
– Отзыв на воркшопы System Education

🔹 Инструменты для работы:
– Как увидеть запросы в режиме онлайн? Используем Charles

Самый важный паттерн МСА на примере неудавшегося отпуска

Представь, ты собрался в отпуск – забронировал авиабилеты, отель и даже экскурсию. Ты молодец - все спланировал заранее и теперь не нужно париться🌴

Но что-то пошло не так, и ты вынужден все отменить, то есть вернуть деньги за авиабилеты, отель и экскурсию. В идеале баланс на банковском счете не изменится, а в отпуск в следующий раз

Шаблон «Saga» (или «Повествование») – шаблон, обеспечивающий согласованность данных в микросервисной архитектуре в конечном счете. То есть, если бизнес-процесс затрагивает три сервиса, то после его выполнения данные должны быть актуальными и правильными

🔹 Локальные транзакции

В примере оформление отпуска, авиабилеты, отель и экскурсии – это локальные транзакции. Каждая завершенная локальная транзакция инициирует запуск следующей. Их последовательность образует бизнес-процесс, т.е. весь отпуск

В системах несколько сервисов могут участвовать в одном бизнес-процессе, и под локальной транзакцией понимают изменение в БД или публикацию события

Например, в Uber 🚕 нужно создать заказ, назначить водителя, запустить поездку и обработать оплату

🔹 Компенсирующие транзакции

В нашем примере отпуск сорвался, но мы еще можем спасти деньги. То есть вернуться к состоянию до начала планирования, компенсировать затраты. В нашем примере это возврат денег за авиабилет и отель

В Saga это действие называется компенсирующими транзакциями – операции, которые отменяют или корректируют эффект предыдущих шагов, чтобы система осталась согласованной

Например, в Uber Saga координирует цепочку: принятие заказа → назначение водителя → поездка → оплата. Если водитель отменит заказ, система компенсирует изменения (вернет заказ в очередь)

🔹 Поворотные транзакции

А теперь представим, что с отпуском все хорошо. Какое самое важное действие? Прилететь и пройти таможню. Отель можно поменять, а экскурсии отменить – однако деньги за билет уже не вернешь

В системах подобные транзакции называются поворотными. После поворотной транзакции полная компенсация невозможна (только частичная)

В примере с Uber поворотная транзакции – начало поездки. До этого момента заказ можно отменить без штрафа, после компенсация будет частичная (например, пассажир получит штраф 🤑)

🔹 Координация транзакций

Два способа координации транзакциями в системах:

1. Хореография
2. Оркестровка

При хореографии сервисы обмениваются событиями (например, через Kafka), и каждый решает, как реагировать. Это как если бы самостоятельно планировали отпуск – забронировали авиабилеты, получили событие в мозг, пошли бронировать отель (не обязательно сразу)

При оркестровке есть некий участник-оркестратор, который говорит сервисам, какие транзакции должны быть запущены. Он же, в случае сигнала «Галя, отмена», запускает компенсирующие транзакции. Это как если бы мы планировали отпуск через тур-оператора, который сам бронирует авиабилеты, отели и экскурсии

📌 Кратко о важном

– Saga – шаблон для обеспечения согласованности в рамках одного бизнес-процесса
– Локальная транзакция – действия в рамках одного сервиса
– Компенсирующая транзакция – операция для отката изменений
– Поворотная транзакция – операция, после которой полный откат невозможен (только частичный)
– Два способа координации транзакция: хореография и оркестровка

В итоге Saga – это не про идеальный сценарий, а про то, как грамотно откатиться при ошибках и поддержать данные в целостности

————

Теперь яснее, как мы обеспечиваем согласованность данных в микросервисах?

👍 Да, гораздо
🤔 Нужно разобраться

P.S. Пока писал пост, увидел новый конкурс авторских ТГ-каналов. На этот раз от ребят из System Education, куда мой канал вписывается куда лучше, чем в предыдущем конкурсе

В этом конкурсе несколько номинаций. Думаю, этот пост отлично вписывается в «Ясное объяснение». Оставлю пометку, что участвую в конкурсе от @systems_education.

#полезное_системный_анализ
#продолжи_мысль_SE

Аналитиков куда больше, чем мы думаем

Иногда ко мне приходят с таким запросом: «На работе я мастер Excel, в основном работаю с данными, даже строю дашборды – хочу стать системным аналитиком» ❓

Несмотря на то, что суть моей магистерской в универе – получение, обработка и представление данных в виде 3D-графиков, работа СА вовсе не про это

Аналитиков в IT можно разделить на две большие группы:

🔹 Аналитики данных
🔹 Аналитики требований

Еще есть финансовые и маркетинговые аналитики, но это уже за рамками IT

Аналитики требований делятся на:

1. UX-аналитики
2. Бизнес-аналатики
3. Системные аналитики (хей, это же я)
4. Аналитики 1С

При этом аналитики данных:

1. Продуктовый аналитик
2. Web/mobile аналитик
3. BI-аналитик
4. Аналитик Big Data

Возможно, я бы тоже поработал аналитиком данных, но уже не в этой жизни – однако заглянуть в этот дивный мир мне помогает бывший юрист и нынешний middle дата аналитик с ВТБ Арина на своем канале IT’s Арина 💡

Арина в основном рассказывает о своем непростом пути в карьере: причем он настолько длинный, что разбит на множество частей, которые читаешь, как сериал 🍿. Рекомендую начать с первой части.

В каждой истории она дополнительно раскрывает какую-нибудь тему: например, Как не работать с мудаками 🤯

Также не забывает делиться интересными находками:

🔹 Метрики, которые стоит знать, если вы работаете в финтехе
🔹 Вопросы с собеседовании на junior

И не прочь поделиться личными мыслями и о том, что у нее происходит в жизни: как она взяла ипотеку в нынешних непростых условиях, как выгорела и про веру в себя. Благодаря откровенности канал читать только интереснее 🤩

➡ Подписывайтесь, впереди немало интересного!

Фронт раньше бэка – это вообще законно? 🤔

История о том, как делать не нужно – а именно выкатывать фронт раньше бэка. И что делать, если это неизбежно

Немного контекста

Работал с продуктом одного банка, где было четкое разделение фронтенд и бэкенд-команд. Я был во фронтенд-команде. По идее аналитики обеих сторон связывают эти части, т.к. высок риск рассинхрона

Однако был один нюанс – бэкенд-команды не было. Ну как, сам бэк с сервисами есть, но его не развивают. Максимум, на что мы могли рассчитывать – один фантомный разраб со стороны банка

Что произошло? 🔥

В работе была огромная фича на весь квартал – новый продукт на фронте со своим отображением. А это новый JSON на 100+ полей со сложными структурами – без бэка не обойтись

Однако бэк делать не торопились, поэтому я писал моки (примеры JSON) на основе дизайна и отдавал своим разработчикам, чтобы им было с чем работать

Подходит конец квартала, в преддверии премии внутренние сотрудники активизировались – появился обещанный бэк-разработчик и сделал свою работу за две недели. Результат: JSON приходит с null полями и ошибками, фронт сломан. На проде 🌾

Исправляли все это еще месяц, пришлось плотно поработать с бэк-разрабом – хотя это нужно было делать до релиза

Можно ли было избежать? 🤔

Спустя время, проанализировал ситуацию, я понял, что нет. Мы не могли предусмотреть, что:

🔴 Команды бэка нет вовсе
🔴 Человек, который в итоге дорабатывал бэк, изначально не должен был этим заниматься

Виной всему политика компании и желание сэкономить на человеческих ресурсах – ничего бы не случилось, если бы разработчика выделили раньше

Но всегда можно свести риск к минимуму

Со своей стороны мы сделали все что смогли (и вам советую):

🟢 Сами разработали моки, работали с ними и их же скидывали бэк-разрабу для понимания итогового результата
🟢 Написали ТЗ для этого разработчика (хотя не должны были)
🟢 Были всегда на связи, отвечали на все вопросы и были открыты к предложениям
🟢 Постоянно подсвечивали разные проблемы и риски заказчику

—————

В таких непредсказуемых ситуациях самое главное – работать честно и на совесть. Отнестись с пониманием и постараться помочь. Тот бэк-разраб тоже стал жертвой ситуации, и винить его было бы глупостью

Поэтому если мы сделали, что могли, но в итоге случился фейл, то знайте – наша вина в этом минимальна. Не стоит зацикливаться – сделали выводы, получили уроки и потом вспоминаем об этом с улыбкой (как и делает моя команда) 😁

По моему мнению, такого процесса быть не должно – бэк нужно готовить раньше фронта или идти параллельно, но не наоборот. Однако IT-мир жесток

⬇ А вы сталкивались с похожими ситуациями? Делитесь в комментариях

————

P.S. Данный пост отправляю на конкурс «Продолжи мысль» от @systems_education в номинацию «Полевой опыт»

#истории_системный_анализ
#продолжи_мысль_SE

Шаблоны документации – пустая трата времени или действительно полезно?

Рассказываю, почему шаблоны важны

🥲 Что если их нет

Недавно работал на проекте крупной компании, где было замечательно все – большая команда, интересный продукт, слаженные процессы, команда СА. Документация в виде SRS на каждую часть системы на первый выглядела классной и исчерпывающей

Но потом я вчитался и понял, что документация несколько хаотичная 🫠. Cтруктура страниц, содержимое, используемые макросы, стиль написания переменных и прочие детали отличались у каждого аналитика

Поинтересовался, есть ли шаблон доки – сказали нет. Может, сделаем? Да, как-нибудь потом ❌

К чему это привело за почти год работы:
🤍 Непонятно, что брать за референс при создании своей доки
🤍 Постоянные недоумения при кросс-ревью: не на что опираться
🤍 Старший аналитик часто отходил от своих же требований и требовал следовать им: а ничего и не предъявишь
🤍 Разработчики возмущались, почему у нас написано по-разному

Какой-то катастрофы не случилось, но мелкие моменты триггерили, потому что их легко можно избежать

🙌 Что если шаблоны есть

То к тебе минимум претензий по части оформления и структуре. Ты больше сосредоточен на сути задачи, а не тратишь время на то, каким шрифтом выделить названия переменных и прятать ли под спойлером use case, иначе не пройдешь ревью

Подобный опыт тоже был в другой крупной компании – шаблон стандартизирован, все изменения обсуждаются на весь отдел СА, никаких вопросов

📌 Когда применять?

Несмотря на очевидную пользу, шаблоны нужны не везде:

🤍Если проект с нуля и он еще не запущен
🤍Какое-то небольшое решение (например, корпоративное), которое поддерживают, но не развивают
🤍Начинающий стартап
🤍Если вы один аналитик на проекте

То есть если нет команды, проект новый, не развивается и не масштабируется – то на шаблонах вы потеряете время, и никто кроме вас на них не взглянет

————————

В итоге шаблоны – полезная вещь, но нужны не везде. Если сталкиваетесь с проблемами, описанными выше, стоит внедрить шаблоны или предложить это старшему аналитику

⬇ А вы пользуетесь шаблонами в своей работе?

💯 Да, использую
😐 Нет, не вижу смысла

#полезное_системный_анализ

Что такое Polling и причем тут Шрек 🐸

Помните, как во второй части Осел постоянно спрашивал Шрека, приехали они или нет? Делал он это чуть ли не каждую секунду, несмотря на отрицательный ответ

Этой узнаваемой сценой можно легко объяснить «асинхронный» механизм Polling, который встречается в системах

📌 Polling простыми словами

Polling (он же опрос) – периодическая отправка запросов от клиента к серверу с целью обновления информации. Если данные есть, сервер сразу отдает их. Цикл повторяется бесконечно, вне зависимости от ответа

Механизм создает иллюзию асинхронности путем периодической фоновой отправки синхронных HTTP-запросов: например, отправка GET-запроса каждые 5 секунд с клиента на сервер. Никакой магии!

Пример работы с Ослом и Шреком в комментах ⬇

💡Где используется?

Там, где нужно обновлять данные в а-ля реалтайм: чаты, новостные ленты, системы мониторинга

🔹 Пример из жизни

🤍В приложении для вызова такси polling можно использовать для обновления геопозиции клиента и водителя
🤍Сайт с новостями может раз в 10 секунд опрашивать сервер на предмет новостей
🤍В ненагруженном чате мы можем проверять статус пользователя (в сети или оффлайн)

👍 Плюсы

1. Просто реализовать
2. Из «асинхронных» механизмов наиболее понятный и простой
3. Можно контролировать частоту запросов

👎 Минусы

1. Холостые запросы создают бесполезную нагрузку на сервер
2. Под капотом это все же синхронный механизм, а значит есть задержки при получении данных
3. Не подойдет, если система нагруженная – если много пользователей, сервер от такого пинга приляжет поспать

💪 Старший брат Long Polling

У Polling есть «продвинутая версия» – Long Polling. Почему длинный? Когда клиент отправляет запрос на сервер, тот открывает соединение на какое-то время. Если данные будут, отправит их, если нет, не отправит

Так вместо 5 запросов за 5 секунд мы отправляем 1 запрос и держим соединение 5 секунд. Плюсы и минусы почти такие же, как выше

➡ Итог

Если вдруг спросят на собесе про эти штуки, или попадутся на проекте – не пугайтесь, все просто:

🤍Polling – раз в n-секунд опрашиваем сервер для обновления данных через HTTP-запросы
🤍Long Polling – при аналогичном опросе открывается соединение и держится n-секунд

Было полезно? Ставь лайк 👍

#полезное_системный_анализ