Системный анализ | Ольга Пономарева

📌 НФТ в архитектуре: измеримые требования «Система должна быть быстрой» — не НФТ. Без цифр и сценариев архитектурные решения не защитить ни перед техлидом, ни перед бизнесом. 👉 Что такое НФТ для аналитика: Не список технологий, а критерии успеха системы в цифрах и сценариях. Минимальный набор для архитектурного ТЗ: ▫️ Нагрузка — запросов в секунду, заказов в час, одновременных пользователей, рост на год ▫️ Задержка ответа — 95-й и 99-й перцентиль (не «среднее») ▫️ Доступность — 99,9% ≈ 8,7 ч простоя в год; что допустимо ▫️ Время восстановления / допустимая потеря данных — сколько можно быть недоступными и что потерять ▫️ Безопасность — платёжные данные, персональные данные, аудит 👉 Как переводить бизнес-фразы в НФТ: Схема: Бизнес говорит → Аналитик фиксирует «Быстро» → 95-й перцентиль < 300 мс на оформлении при 500 запр/с «Не должно падать» → 99,95% доступности, плавное снижение функций при отказе каталога «Чёрная пятница» → Пик в 10 раз от среднего, 2 ч, автомасштабирование за 5 мин 👉 Зачем это влияет на архитектуру: ▫️ 99-й перцентиль 300 мс при 5 синхронных вызовах → нужна прослойка для фронта или параллельные запросы ▫️ Нулевая потеря заказов → синхронная репликация или исходящая таблица со строгим порядком ▫️ Пик в 10 раз → горизонтальное масштабирование слоя без состояния + кэш, не «больше процессора на монолите» 💡 На собеседовании: после условия задачи спроси «какие НФТ?» — это отделяет тех, кто рисует схемы, от тех, кто проектирует систему.

Озон Доставка меня разочаровала 🫠

В конце мая — начале июня мы проводили активности и разыгрывали мерч: футболки, настольные игры и всякие приятные штуки для участников Победителей получилось около 10 человек. Я всё собрала, подписала открытки, разложила по пакетам и пошла отправлять через ПВЗ, потому что мне сказали: "Оля, сейчас так все делают, это удобно и дешевле, чем Почтой"

Спойлер: удобно не получилось На ПВЗ сотрудник устроил очередь минут на 20, я потом ещё записывала друзьям гневные голосовые, потому что всё происходило максимально странно. Но ладно, думаю, главное — отправила Спустя пару дней получила сообщение, что приехал не тот подарок 🤬 Начинаем разбираться — и выясняется, что на ПВЗ перепутали отправления. То есть часть подарков уехала не тем людям. Кому-то вместо своего мерча приехал чужой, кто-то вообще получил не то, что должен был. ПЕРВЫЙ РАЗ С ТАКИМ СТОЛКНУЛАСЬ! Даже на Почте такого у меня не было)) Хотя я отправляю много посылок и из других стран! Я понимаю, что ошибки бывают. Но в этой ситуации неприятно не только то, что сотрудник накосячил, а то, как это потом решается. По сути, ответ сводится к "проведём инструктаж". Инструктаж — это прекрасно, но посылки сами обратно не поменяются, а доставку и переотправку теперь снова нужно оплачивать нам 🥲

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

🪿У вас были похожие истории с ПВЗ или доставками?

Почему даже хорошие курсы иногда закрываются? Все очень просто, время не стоит на месте, да и навыки у всех разные. Кто-то еще путается в базовых понятиях, а кто-то готов обсуждать Highload, шардирование и сложные архитектурные решения. Поэтому мы сделали то, что давно нужно было сделать. Распилили монолит. И теперь вместо одного курса появились два направления 👇 🟨 Архитектура систем. База Для тех, кто хочет перестать плавать в терминах, разобраться в НФТ, API, очередях, вебхуках и научиться проектировать систему с нуля. 🗓 Старт 6 июля ⬛️ Архитектура систем. Хард Для тех, кто уже знает базу и хочет глубже понимать C4, репликацию, шардирование, кэширование, NoSQL и проектирование сложных систем. 🗓 Старт 27 июля До 30 июня действует скидка 15% по промокоду:JUNE15

Могучая кучка, 2026 г 😁 Именно так мы себя называем, потому что впятером организовали аналитический клуб для системных аналитиков Очень горжусь, что являюсь организатором этого клуба 🤩

Каждый из нас - активен в медийке системного анализа, с большим багажем знаний, опыта и достижений. Кто-то силен в сложных интеграциях, архитектуре высоконагруженных систем, миграции данных или даже банально легко умеет докапаться до сути. Мы как пазлы смогли усилить друг друга - кто-то проводит воркшоп, а кто-то пишет анонс или предлагает новые идеи

Проводим офлайн митапы в Москве. Если вы еще не видели, то ссылка клуба тут: @analystclubru Так что, кто в Москве - будем рады:)

Выбираем тему следующего бесплатного вебинара

Нужна ваша помощь. С командой зашел небольшой спор над "актуальной темой" для вебинара по архитектуре! Разрулите нас, и за одно выберем как раз ту, которая вам наиболее интересна 🙌 Опрос сделаем ниже 👇

Пошла спросить ИИ про C4. Он отправил меня к нам же 😂 Сейчас мы активно обновляем курсы по архитектуре систем и вот я пошла к ИИ быстро свериться по C4 — а он в ответе взял и сослался на сайт нашей школы 🤩 Получилось забавно: спрашиваю у ИИ про архитектуру, а он такой: "Вот, почитайте у вас же" С одной стороны, смешно. С другой — приятно. Значит, материалы, которые мы собираем и структурируем, уже живут не только на сайте, но и попадают в источники, на которые опираются ИИ-ответы 🔥 Кстати, уже можно посмотреть обновлённые программы и даты стартов: — «Архитектура систем. База» — старт 6 июля — «Архитектура систем. Хард» — старт 27 июля А есть среди подписчиков те, кто пришел к нам "через поиск"?

📊 Опрос: Интеграции и согласованность 4 вопроса про согласованную запись в БД и брокер, идемпотентность, поэтапный вынос из монолита и версии интерфейса. Отвечай в комментариях — разбор сразу после вопроса. Ну что, погнали?

Теперь не монолит: обновили курс по архитектуре систем Мы распилили 😬монолит: теперь у курса по архитектуре систем 2 уровня

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

1️⃣ Архитектура систем. База Для тех, кто хочет собрать фундамент и перестать плавать в архитектурных темах На курсе разберём свойства системы, декомпозицию, интеграции, REST API, очереди, вебхуки, callbacks, балансировщик и базовую документацию архитектурного решения Старт воркшопов — 6 июля 2️⃣Архитектура систем. Хард Для тех, кто уже знает базу и хочет глубже разбираться в сложных архитектурных решениях На курсе будут highload, C4, архитектурные слои, модульность, индексы, репликация, шардирование, кэширование, NoSQL, антипаттерны и trade-off Старт воркшопов — 27 июля

Если коротко: — если архитектура пока не складывается в единую картину — начинайте с Базы; — если фундамент уже есть и хочется расти в сторону senior/архитектора — смотрите Хард; — если хотите пройти путь последовательно — можно взять комбо База + Хард

А что на счет подарков? 🎁 До 30 июня действует скидка 15% по промокоду JUNE15 Напоминаем, что курсы можно оплатить от работодателя:

Для этого: Отправьте карточку компании (название компании, ИНН, юр.адрес), название курса, тариф, дату старта, ФИО ученика и его на почту на адрес: companysystemanalyst@gmail.com. Стоимость для юр.лиц дороже на 10%. Скидки не применяются (для покрытия издержек на документооборот), если вы хотите обучить сразу несколько сотрудников - сообщите нам об этом, подготовим выгодное предложение!

📂 Кейс: Saga вместо распределённой транзакции — когда "откатить всё" невозможно 🏢 Контекст: B2B-портал закупок. Заказ проходит: резерв на складе → списание лимита бюджета → создание счёта в ERP → уведомление поставщику. Четыре разных системы, у ERP нет двухфазного commit. Команда 12 человек, монолит режут на сервисы. 😬 Проблема: После выноса "Склад" и "Бюджет" в отдельные сервисы поймали баг: лимит списали, ERP вернула 500 — заказ завис "в полупути". Ручные откаты в саппорте — 2–3 раза в неделю. Бизнес: "Нужна атомарность как в старом монолите". 🔍 Что сделал аналитик: 1. Нарисовал happy path и точки отказа — где уже нельзя просто DELETE 2. Выбрал оркестрацию Saga (центральный Order Orchestrator), а не хореографию: процесс линейный, мало автономных реакций, нужна видимость статуса для саппорта 3. Описал компенсирующие транзакции: — Отмена резерва на складе — Возврат лимита бюджета — Аннулирование черновика счёта в ERP (отдельный API) 4. Зафиксировал идемпотентность шагов по order_id + step_id — повтор после таймаута не дублирует списание 5. В ТЗ добавил статусы заказа: PENDING_BUDGET → PENDING_ERP → CONFIRMED / COMPENSATING / FAILED ✅ Результат: За 6 недель — orchestrator на state machine, дашборд "застрявших" саг. Ручных откатов — 0 за два месяца. Бизнес принял, что при падении ERP заказ может минуту быть в COMPENSATING, но не «зависнуть навсегда». 💡 Выводы: ▫️ Распределённая транзакция 2PC в микросервисах — редкость; Saga + компенсации — рабочая модель ▫️ Оркестрация vs хореография — не религия, а наблюдаемость и сложность процесса ▫️ Аналитик обязан описать что откатываем и в каком порядке, иначе разработчики напишут "retry" и забудут

📰 Новости | Роль аналитика в эпоху ИИ, как пересобрать архитектуру Forrester выпустил отчёт «Rearchitecting Applications For The Age Of AI» — исследование о том, как ИИ меняет логику построения корпоративных систем. Раньше архитектура строилась вокруг жёстких BPM-схем и предсказуемых цепочек вызовов. ИИ добавляли как очередной микросервис. Forrester пишет: это не работает. ИИ требует пересмотреть сам подход к проектированию: от пошаговых процессов — к границам и целям. 👉 Что нового важно для системного аналитика: ▫️ Адаптивная оркестрация вместо BPM — ИИ-агенты принимают решения в рантайме. Аналитику нужно описывать не "шаг 1 → шаг 2 → шаг 3", а границы, цели и контекст, внутри которых ИИ сам выстроит траекторию. ▫️ Приложения генерируются по описанию — пользователи или агенты создают временные приложения под задачу естественным языком. Фокус смещается с проектирования статичных систем на проектирование многократно используемых бизнес-сервисов. ▫️ Контекст становится архитектурным слоем — ИИ-агентам нужны не просто данные, а их семантическое значение в реальном времени. Появляется слой управления контекстом (стандарты вроде MCP указывают, как он может развиваться). 👉 Что это значит на проекте: - Уходит слой Experience API — теперь ИИ-агент будет адаптировать бизнес-логику под интерфейс (мобилка/веб/чат) напрямую, обращаясь к Business API. - Новые требования к API — ИИ плохо работает с низкоуровневыми техническими API. Нужны чёткие бизнес-сервисы, которые инкапсулируют намерение, правила и результат. - Меняются НФТ — вместо контроля каждого пути проектируем безопасные границы (guardrails), внутри которых ИИ-агент действует автономно. 💡 Для собеседования: если спрашивают «как изменится роль аналитика через 2–3 года», уверенный ответ уровня Senior — смещение фокуса с линейных UX-потоков на проектирование бизнес-возможностей, границ оркестрации и семантического слоя данных. Источник: Forrester «Rearchitecting Applications For The Age Of AI»

📌 Границы сервисов Без чётких границ микросервисы быстро превращаются в распределённый монолит. Аналитику важно понимать, как резать систему на части и как связывать их без хаоса. 👉 Зачем думать о границах: Не "нарисовать 12 блоков", а ответить: какой сервис за что отвечает и какие данные ему принадлежат. Хорошая граница: ▫️ Совпадает с бизнес-возможностью (заказ, оплата, доставка) ▫️ Имеет свой жизненный цикл данных — другие сервисы не лезут в чужую БД ▫️ Меняется относительно независимо: можно выкатить оплату, не трогая каталог 👉 Как искать границы на практике: 1️⃣ По процессу — шаги бизнес-процесса → кандидаты в сервисы (но не каждый шаг = сервис) 2️⃣ По данным — у кого «источник правды» для сущности? Заказ живёт в Order Service, не в Payment 3️⃣ По нагрузке и НФТ — если расчёт ETA тормозит всё, его можно вынести, не дробя монолит на 20 частей 4️⃣ По команде — Conway's law: структура системы повторяет структуру коммуникации команд 👉 Красные флаги плохого разбиения: ▫️ Два сервиса пишут в одну таблицу ▫️ Синхронная цепочка из 5+ вызовов на каждый клик пользователя ▫️ "Общая" БД с JOIN-ами между доменами — признак того, что граница проведена на схеме, а не в голове 💡 На Middle от аналитика ждут не определение DDD, а умение объяснить: "Мы выделили сервис оплаты, потому что у него отдельный SLA, PCI-ограничения и свой релизный цикл".