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

У меня сегодня День Рождения, а подарки дарю ВАМ🎁

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

ОООЧЕНЬ ЩЕДРЫЕ СКИДКИ:

• до 30 000 ₽ — скидка 20%
• от 30 001 до 100 000 ₽ — скидка 30%
• от 100 001 до 120 000 ₽ — скидка 40%
• от 120 001 ₽ — скидка 50%

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

Например, сегодня можно:

• полностью прокачаться в ИИ примерно за 42 000 ₽ вместо 60 000 ₽;
• пройти сразу две программы по архитектуре за 55 860 ₽ вместо 79 800 ₽.

И да, в распродаже участвуют именно тарифы с обратной связью: с проверкой заданий, поддержкой и возможностью задавать вопросы экспертам (а в случае с архитектурой, где идут "потоки", вы можете выбрать подходящий, в течение срока доступа)

Доступ ко всем материалам останется у вас на целый год. Оплатить можно сразу или оформить рассрочку на 3, 5, 6, 9 или 12 месяцев

Праздничные условия будут действовать до 12 августа

Поэтому, если давно хотели пойти к нам на обучение, сегодня тот самый день 💛

👉 Выбрать программы

Финальный урок записан. Мы готовы к ученикам!

Сегодня записала последний урок для курса «Архитектура. База» и наконец-то могу выдохнуть: курс собран и получилось просто бомба! Как обычно объясняю просто даже сложные вещи, такие как балансировщик, вебхуки, вебсоекты и другие страшные слова!

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

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

1 поток стартует уже 6 июля, в понедельник!
До конца июня можно попасть со скидкой 15% по промокоду JUNE15

👉Подробнее о курсе

Успевайте попасть в первый поток😎

📂 Кейс: кэш спас скорость — и чуть не убил согласованность цен

🏢 Контекст:

Онлайн-аптека, 1,5 млн артикулов. Сервис каталога отдаёт карточку товара. После кэша в Redis 95-й перцентиль упал с 420 мс до 40 мс. Бизнес доволен. Через две недели — жалобы: в корзине одна цена, на оплате другая.


😬 Проблема:

Аналитик в ТЗ написал: «Кэшировать ответ карточки товара на 24 часа». Разработчики закэшировали весь ответ, включая поле «цена». Маркетинг обновил цены в БД в 09:00, пользователи до следующего дня видели старую цену в каталоге; при оформлении цена бралась из актуальной таблицы заказа — расхождение.


🔍 Что сделали:

1. Разделили кэшируемые поля: статика (название, фото) — долгое время жизни; цена — короткое (60 сек) или отдельный ключ по артикулу
2. Добавили сброс кэша по событию «цена изменилась» из админки
3. В контракт прослойки для фронта: на шаге оформления пересчёт цены с сервера, интерфейс показывает «цена обновлена» при расхождении
4. В ТЗ явно: «источник правды цены при оплате — сервис ценообразования, не кэш каталога»


✅ Результат:

Жалобы исчезли. 95-й перцентиль каталога — 55 мс (чуть выше, но в рамках НФТ). Аналитик добавил в шаблон ТЗ секцию «политика кэширования по полям».


💡 Выводы:

▫️ Кэш — архитектурное решение с бизнес-последствиями, не только про скорость
▫️ В ТЗ указывай: что кэшируем, срок жизни, сброс, что нельзя кэшировать на критичном пути
▫️ «Согласованность цены» — НФТ, которое ломается тихо

«Пошаговый гайд по System Design»

30 июня в 19:00 мск проведем бесплатный вебинар

System Design часто воспринимают как страшную секцию на собеседовании: нужно быстро придумать архитектуру, нарисовать схему, объяснить решения и не посыпаться на вопросах.

Но на самом деле System Design — это не
только про собеседования

Это навык, который помогает системному аналитику:

— понимать, как требования превращаются в архитектуру;
— увереннее общаться с разработчиками, архитекторами и техлидами;
— видеть ограничения, риски и trade-off’ы;
— не теряться в интеграциях, брокерах, очередях, НФТ и микросервисах;
— расти внутри компании, в зарплате и своей ценности на рынке

На вебинаре разберём:

— что такое System Design и из каких этапов он состоит;
— как подойти к проектированию системы пошагово;
— зачем System Design спрашивают на собеседованиях и как пройти эту секцию;
— какие ошибки можно допустить на каждом этапе и завалить решение;
— где и как дальше изучать System Design, чтобы прокачаться системно.

🎁 Бонус за регистрацию:
После регистрации вы получите полезные материалы по System Design:

— подборку статей;
— книги по архитектуре и проектированию систем;
— конференции и митапы;
— подкасты и блоги;
— презентацию с вебинара

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

Дата: 30 июня 19:00 (мск)
Формат: онлайн, бесплатно
Участие: по регистрации

Регистрируйтесь по ссылке: https://school.systemanalyst.life/abkhi

Команда 💛👩‍👩‍👦

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

А школа начинается там, где появляются люди, которым тоже не всё равно. Кто проверяет домашки не для галочки, разруливает сложные ситуации, видит косяки, предлагает идеи и может честно сказать: «Оль, тут надо переделать»

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

🪿Вчера был год, как со мной работает моя ассистентка/менеджер. Я отправила ей тортик с кофе, а она написала, что у нас самая лучшая команда. И я такая: ну всё, можно немного всплакнуть и дальше работать 😄

Наверное, один из главных выводов за годы школы: качество делают не только программы курсов. Качество делают люди

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


❤️ - если хочется больше узнавать о нашей команде и кто стоит за "школой"

Пошла спросить ИИ про C4. Он отправил меня к нам же 😂

Сейчас мы активно обновляем курсы по архитектуре систем и вот я пошла к ИИ быстро свериться по C4 — а он в ответе взял и сослался на сайт нашей школы 🤩

Получилось забавно: спрашиваю у ИИ про архитектуру, а он такой: "Вот, почитайте у вас же"

С одной стороны, смешно. С другой — приятно. Значит, материалы, которые мы собираем и структурируем, уже живут не только на сайте, но и попадают в источники, на которые опираются ИИ-ответы 🔥

Кстати, уже можно посмотреть обновлённые программы и даты стартов:

— «Архитектура систем. База» — старт 6 июля
— «Архитектура систем. Хард» — старт 27 июля

📰 Новости | Роль аналитика в эпоху ИИ, как пересобрать архитектуру

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»

Вчера провели первую встречу воркшопа по Postman

По отзывам участников, главная цель была достигнута💛:

«Цель про то, чтобы пощупать сам Postman, была выполнена»

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

Сейчас участникам выдали домашнее задание. Следующая встреча — 16 июня, там будем разбирать решения, отвечать на вопросы и смотреть, где чаще всего возникают ошибки!

И вот это, на мой взгляд, самое ценное в формате воркшопа: это не "посмотрел вебинар и забыл", а практика → домашка → разбор → вопросы


⭐️Если вдруг, по какой то причине, вы не смогли попасть, то сообщаем, что осталось несколько мест (14), и вы можете приобрести тариф с записями, чтобы пересмотреть первую встречу и подготовиться ко второй: https://systemanalyst.life/apiworkshop

📂 Кейс: «Почему вы не взяли Kafka?» — вопрос с собеседования, который стал реальным проектом

🏢 Контекст:

Маркетплейс доставки еды, ~200 заказов в минуту в пик. Команда из 8 разработчиков, монолит на Python, один PostgreSQL. Собеседование на Middle SA — тестовое: предложить целевую архитектуру на 12 месяцев.


😬 Проблема:

Кандидат на схеме нарисовал 6 микросервисов, Kafka и Redis "как в статьях". На защите тестового техлид спросил: "Зачем Kafka при 200 заказах и команде из 8 человек? Как будете дебажить?"

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


🔍 Что сделал аналитик (уже на проекте, тот же вопрос от бизнеса):

1. Собрал НФТ: пик 200 зак/мин, рост до 500 за год, RTO 30 мин
2. Выделил узкое место: не заказы, а расчёт времени доставки из трёх внешних сервисов (карты, курьеры, кухня)
3. Предложил поэтапно:
— Сейчас: вынести расчёт ETA в отдельный сервис + кэш Redis (синхронный REST для заказа остаётся)
— Через 6 мес.: события «заказ создан» в RabbitMQ для уведомлений и аналитики
— Kafka — только при выходе на 500+ и появлении event streaming для отчётов
4. Зафиксировал в ADR: почему не Kafka на старте (операционная сложность, нет consumer-групп на объёме)


✅ Результат:

Архитектурный комитет принял roadmap без "микросервисов ради микросервисов". Через 4 месяца ETA-сервис снизил таймауты на 40%. RabbitMQ добавили точечно — под уведомления.


💡 Выводы:

▫️ На собеседовании и на проекте побеждает не самая модная схема, а обоснованная под контекст
▫️ Вопрос "почему не X?" важнее, чем "мы взяли X"
▫️ Аналитик связывает НФТ, команду и этап продукта — не только рисует блоки


Кстати, у нас идет обновление курса "Архитектура для аналитика", скоро вернется в новом формате. Мы делим большой курс на два уровня:
База — чтобы перестать плавать в архитектуре
Hard — для сложных архитектурных решений
Подробности на сайте. Оставь заявку, чтобы первым получить уведомление о запуске!

✅ Решение | Архитектура · Запись к врачу

Краткий ответ:

Компоненты: Web/Mobile → API Gateway → Сервис записи → CRM (REST) + Брокер → Сервис уведомлений → Email/Push-провайдер. БД записи — у сервиса записи.


📖 Разбор:

1️⃣ Компоненты

▫️ API Gateway — единая точка входа для веба и мобилки
▫️ Сервис записи — бизнес-логика: проверка слота, создание записи, своя БД
▫️ CRM клиники — внешняя система с расписанием (REST)
▫️ Брокер сообщений — очередь событий «запись создана»
▫️ Сервис уведомлений — читает из брокера, шлёт email и push


2️⃣ Поток

Пользователь выбирает слот → Gateway → Сервис записи синхронно проверяет слот в CRM → создаёт запись у себя в БД → кладёт событие в брокер → сразу отвечает пользователю «Запись создана».

Сервис уведомлений асинхронно забирает событие и отправляет письмо и push. Если CRM упала после успешного создания записи — пользователь уже получил ответ, уведомление уйдёт позже из очереди.


3️⃣ Синхрон vs асинхрон

Синхронно (REST к CRM) — проверка и бронирование слота. Пользователь должен сразу узнать: слот свободен или занят.

Асинхронно (брокер) — уведомления. Не блокируем ответ пользователю, переживаем временные сбои email/push за счёт повторной обработки из очереди.


❌ Типичные ошибки:

▫️ Всё через синхронные вызовы — при падении push-сервиса пользователь не получит ответ о записи
▫️ CRM как единственная БД записей — потеря контроля над своими данными и зависимость от чужого SLA
▫️ Брокер для проверки слота — лишняя сложность, пользователь ждёт мгновенный результат


💡 На собеседовании важно: назвать почему граница между sync и async проходит именно здесь.