Системный анализ на максималках

Не забывайте надевать футболку перед созвоном 🙈

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

А пока держите кринжовую историю о том, как мы вели демо с элементами легкой эротики 🔞

Итак, история

Жаркое лето, очередное демо на проекте 👨‍💻. Вели его в паре с разработчиком на удаленке. На созвонах со своими сидим без камеры, но перед заказчиком обязательно включаем ее для хорошего тона

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

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

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

Что в итоге?

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

———

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

⬇ А какие у вас были кринжовые ситуации на работе, связанные с камерой?

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

Я – Senior. Что дальше? 🤔

Рассказываю свое видение дальнейших тропинок ведущего системного аналитика

🤍 Team Lead/Руководитель СА

Меньше hard skills, больше soft skill. Меньше работы с задачами, больше с людьми: найм и увольнение, контроль состояния, принятие различных решений и ответственности за них

Рекомендую:
🤍Попробовать менторство (от 2 и более людей)
🤍Прокачать теорию управления людьми – через литературу или курсы
🤍Просить руководителя делегировать часть своих задач

Заметил, что чаще стали появляться курсы для тимлидов – знаю, такие есть на Отусе и Стратоплан. Из книг советую начать с «Пять пороков команды: притчи о лидерстве»

🤍 Архитектор

Если развивать hard skills, то со временем можно попробовать стать архитектором. Они бывают разные:

🤍Системный архитектор (Software Architect)
🤍Архитектор решений (Solution Architect)
🤍Корпоративный архитектор (Enterprise Architect)

Их обязанности отличаются, но, как мне пояснил архитектор с опытом, на практике их не всегда разделяют, особенно в небольших и средних компаниях

Что делать, если хочешь уйти в архитектуру (общие рекомендации):
🤍Изучать теорию по архитектуре – через литературу или курсы
🤍Найти проект с микросервисной архитектурой, где СА вовлечен в задачи архитекторов и разработчиков
🤍Брать сложные задачки, которые требуют проработки архитектуры
🤍Осваивать технологии (OpenShift, Docker и др)
🤍(необязательно) Освоить язык программирования и написать pet-проект

➡️ Подробности – в следующем посте

🤍 Tech Lead

Организует техническую работу команды, принимает ключевые архитектурные решения, менторит разработчиков, а также может писать код и закрывать сложные задачи. В отличие от Team Lead, фокус в техническую сторону. В отличие от Архитектора, больше вовлечен в код.

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

🤍Разработка/QA/DevOps/иная смежная роль

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

Правда, придется доучиться и откатиться по ЗП и грейду 💸 – но опыт СА определенно будет плюсом

Шаги по смене профессии очевидны: обучаемся через курсы или книги, дорабатываем резюме и пробуем устроиться на работу

🤍Фриланс/подработки

Можно остаться Senior и укреплять свои hard и soft skills без смены рода деятельности, и направить внимание на:

🤍Фриланс – проекты вне основной работы
🤍Менторинг – персональное обучение
🤍Преподавание в онлайн-школах – тоже обучение, но на широкую аудиторию
🤍Личный бренд – выступление на конференциях, участие в активностях сообщества, развитие своего блога
🤍Открытие своего дела – онлайн-школа, компания по разработке

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

————————————

💡 В следующем посте поделюсь своим планом по переходу в архитекторы – что уже сделал, что предстоит, возможно ли это вообще и что я думаю по этому поводу

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

Как я НЕ стал техническим писателем 🙅‍♂️

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

🥵 Войти в айти

Из навыков тогда – инженерное образование и годы копирайтинга (помните, писал уже о них ранее?). Складываем два плюс два, получаем наиболее вероятную точку входа – технический писатель

Прошел экспресс-курс на технического писателя за 2 недели и 7000 руб. Полностью переписал резюме под тех писателя, а в качестве опыта работы взял 6 лет копирайтинга 😏. Начал откликаться, и буквально через пару дней меня пригласили на собес в Москва Сити 🌈

Подготовился за день, на самом собесе отвечал неуверенно – я тогда не знал ни про API, ни про БД, ни еще что-то. Но как-то рассказал, думал, что провалился – но меня приняли

Но не все так просто

🤔 В чем подвох?

И вот я начал работать техническим писателем. Документации на проекте не было, поэтому я изучал код, чтобы восстановить архитектуру, описывал API, макеты интерфейса, функциональные требования, базу данных, затем ставил задачи на разработку… Что-то тут не так

Через четыре месяца осознал, что выполняю работу системного аналитика, а не технического писателя. ГОСТ, docs as code, инструкции, мануалы – всего этого тут не было. Максимум писал release note, и все. Все остальное подходило под описание работы СА

А по записи в трудовой книжке я вообще был программистом 😁

🏃‍♂️‍➡️ Что я сделал

Осознав это, в январе 2023 поступил на четырехмесячный курс СА. Знания сразу применял – дорабатывал то, что уже написал, и старался внедрить практику СА в команде, т.к. в процессах творился хаос

И уже через 2 месяца стало даже получаться, но на работе произошел лютый треш, из-за чего пришлось срочно увольняться. Это достойно отдельного поста

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

Там немного набрал опыта, структурировал знания и уже через пару месяцев устроился в хорошую компанию сразу на Middle+

———————

Вот такой у меня путь в IT. В итоге техническим писателем я не проработал ни дня, получилось «перепрыгнуть» эту ступень, что и так было в планах. Работодатель просто не знал, кто такие СА, и думал, тех писатели от слова «писать», а писать доку надо было срочно

⬇ А как вы начинали свой путь в IT?

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

Рецензия на пост «Размывание целей» Марии Серёгиной 📝

Итак, я еще участвую в конкурсе «Продолжи мысль» от @systems_education и успешно прошел во второй тур 🎉

В этом туре нужно оставить рецензию на пост другого участника. Наиболее интересным мне показался пост «Тенденция к снижению производительности» или «Размывание целей» на примере чашечки кофе Марии Серёгиной

📌 О чем пост?

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

Мария разбирает архетип «Тенденция к снижению производительности» на уровне организации, используя пример с кофейней ☕

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

👍 Что понравилось

🤍Четкая структура поста – понятно, от чего и к чему идем
🤍Приятное оформление, ничего не отвлекает от темы
🤍Сама тема нестандартная и интересная
🤍Разбор архетипа на простом примере
🤍Оставлены ссылки на предыдущие посты – в итоге легко найти первоисточник и прочитать про другие архетипы
🤍Есть аналогия с IT-областью
🤍Не просто объяснение концепции, но и вывод, что с этим делать – в посте есть практическая ценность

💡 Что бы я улучшил

🤍Вторую часть поста читать сложнее, чем первую. Информации много, а абзацы к концу становятся длиннее и «тяжелее». Я бы разделил на два или сократил бы
🤍Было бы интересно прочитать о примерах из других сфер

🤔 Какие мысли вызвал пост

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

Например, когда работал копирайтером, ставил себе цель писать не менее 20000 символов в день. Но за этот день у меня могла быть учеба в вузе, я мог съездить за продуктами, потратить время на готовку – в итоге цель чаще всего не была достигнута 🥲

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

Думаю, это и есть описанный Марией архетип. Теперь я могу распознать его, но получится ли бороться с ним – вопрос времени и силы воли

—————

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

#продолжи_мысль_SE

Что такое 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-секунд

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

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

Лучшее лекарство от стресса – спорт

Согласно исследованиям, спорт – один из лучших способов снизить стресс. И я с этим согласен

К спорту я пристрастился еще в школе, и многое перепробовал. Баскетбол, волейбол, бальные танцы (не совсем спорт, но ладно), киокушинкай каратэ… Но все не нравилось. Но однажды с другом решили пойти в качалку, и понеслось 💪

У меня не получилось обрасти горой мышц, но обнаружил другое: мне легко давался жим лежа при собственном низком весе

Эта особенность не осталась незамеченной: тренер предложил поучаствовать в соревнованиях. И да, это было моим – занимал призовые места, часто участвовал в соревах, чувствовал себя на высоте 🏆

После школы стабильность исчезла – начался универ, сессии, работа, взрослая жизнь🥲. В душе я хотел вернуться, но ходил в зал с большими перерывами

А в 2022-2023 годах у меня был сложный период со множеством стрессов и переездов. И тут на помощь неожиданно пришел спорт: помог мне восстановиться как физически, так и психологически 💊

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

—————

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

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

⬇ А как у вас со спортом? Занимаетесь профессионально, или тоже для себя? Пишите в комментах

#мысли

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

————————

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

—————

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

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

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

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

————

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

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

Польза и вред той самой книги Вигерса 📖

Наверняка вы слышали о «Библии» или настольной книге аналитика (БА/СА) – «Разработка требований к программному обеспечению» Карла Вигерса и Джой Битти

Прочитал ее и делюсь мнением

🔹 Что узнал полезного

– Группы нефункциональных требований (глава 14) – тут они очень подробно расписаны с обилием примеров
– Методика расчета приоритетов (глава 16) по множеству критериев
– Признаки, по которым понятно, что сбор требований завершен (глава 7, ст 159-160) – коротко и ясно
– Правила для составления «идеальных требований» (глава 11) – полезная формула «Система/пользователь должен» «активный глагол» «наблюдаемый результат»
– Утверждение требований (глава 17) – для лидов и старших аналитиков
– Про документирование требований и шаблоны SRS (глава 10) – приведенную структуру можно доработать под свой проект

В остальных главах тоже встречается что-то полезное, но по мелочи

⚠️ Что же не так с этой книгой

– Главная проблема – книга морально устарела. Описанный процесс сбора требований был актуален лет 20 назад. Тогда люди готовились месяцами, сидели с пользователями в одной комнате – в общем, целый ритуал. Сейчас сбор требований не такая грандиозная история, а скорее итеративный подход (исключением может быть гос сектор)
– Отсюда идут устаревшие техники и советы. В главе 12 описаны диаграммы UML, но там нет Sequence. В главе 13 пишут про структуру данных в БД, но нет JSON
– Некоторые главы вообще можно смело пропускать – например, глава 9 про составление Бизнес-правил (вы их когда-нибудь писали?), глава 18 про Повторное использование требований (в моей практике не встречалось таких случаев)
– Вода, из-за которой тут аж 700 страниц. Не все осилят такой объем – признаюсь, что последние несколько глав и я не дочитал

🤔 Стоит ли читать?

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

Прочитать ее полностью стоит начинающим аналитикам, когда многое в голове не структурировано (но помните об устаревших методиках)

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

🙈 Альтернативы?

Несмотря на возраст, книга остается одной из немногих, где системно разобран весь цикл разработки ПО. Более современные книги освещают узкие темы («Пользовательские истории» Джеффа Паттона, «UML. Основы» Мартина Фаулера)

Есть труды англоязычных авторов, типа «Agile Software Requirements» от Дина Леффингвела, но перевод мне не удалось найти

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

——

А вы читали эту книгу? Что думаете? Пишите в комментах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

————

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

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

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

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

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

🟧🟧🟧🟧🟧🟧🟧🟧🟧

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

🔹 О личном
– Кто я и зачем пишу
– Лучшее лекарство от стресса – спорт

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

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

🔹 Про карьеру СА
– Я – Senior. Что дальше?
– Путь до архитектора. Часть 1 – Чек-лист по темам архитектуры
– Путь до архитектора. Часть 2 – Книги по архитектуре
– Путь до архитектора. Часть 3 – Какие бывают архитекторы в IT

🔹 Про собеседования:
– Цвет настроения желтый: как я проходил собеседование в Т-Банк
– Как я сходил на собес в Магнит Tech
– Собес на 20 минут – red флаг при трудоустройстве?
– Собеседование в Samokat.tech (бывший) – или как вызвать аналитика на ковер
– Собесы раньше vs Собесы теперь
– Реально ли найти работу в 2025? Мой опыт
– Что спрашивают на собесах в 2025? + Практические кейсы

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

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

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

🔹 Промты для ИИ:
– Промт для генерации User Story и Use Case

🔹 Разбор кейсов:
– Управление пуш-уведомлениями в мобильном приложении

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

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

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

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

Проанализировал вакансии на 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-диаграммы

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

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

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

—————

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

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

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

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

Что такое 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

—————

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

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

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

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

🔹 Мой опыт

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

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

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

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

🔹 Другой опыт

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

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

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

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

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

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

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

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

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

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

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

——————

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

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

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

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

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

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

Первый фейл

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

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

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

Второй фейл

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Или на стороне сервера – сервак отдает готовые страницу, фронт просто отображает

—————

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

————

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

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

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