☀Объяснение:

Severity (серьёзность) – техническая характеристика дефекта, показывающая, насколько сильно он ломает функциональность системы. Определяется без учёта бизнес-влияния.
High – критическая функция не работает (например, оформление заказа).
Medium – функция работает с ограничениями.
Low – косметический дефект, не мешающий основной работе.
Priority (приоритет) – бизнес-характеристика, показывающая, как срочно нужно исправить дефект. Зависит от количества затронутых пользователей, потери выручки, репутационных рисков.
High – нужно исправить как можно быстрее (влияет на ключевой бизнес-процесс).
Medium – исправить в ближайший спринт.
Low – исправить при следующей возможности.

Применение к задаче:
Severity = High, потому что критическая функция (оформление заказа) недоступна для затронутых пользователей. Даже если процент мал, сам сценарий критичен.
Priority = High, потому что любой сбой в оформлении заказа ведёт к потере выручки и негативному опыту. Бизнес не станет ждать следующего релиза, чтобы исправить такое.
Ошибка, которую часто допускают:
Путают «малое количество пользователей» с низким приоритетом. Например, если баг затрагивает только VIP-клиентов (но их мало), приоритет всё равно высок, потому что бизнес теряет самых ценных клиентов.

Реальный кейс:
В интернет-магазине баг с отображением корзины возникал у 2% пользователей. Команда хотела отложить исправление на следующий релиз из-за низкого процента. Аналитик аргументировал, что для затронутых пользователей оформление заказа невозможно (Severity High), и эти пользователи могут уйти к конкурентам (Priority High). Баг исправили в течение дня.

Что должен зафиксировать аналитик:
В регламенте тестирования и приёмки: «Severity определяется по степени нарушения функциональности, Priority – по влиянию на бизнес».
Примеры классификации для разных типов дефектов.

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

Как на таком рынке вообще можно устроиться?!

В 2026-м этим вопросом задается почти каждый, перед кем стоит проблема поиска работы.

Булат — солюшен-архитектор, выросший из системного аналитика. Практикующий ментор. В прошлом году он сам трижды (!) попадал под сокращения, но в итоге смог устроиться на еще большую ЗП, чем была до всех сокращений.

Впечатляющий маневр? Думаю, да. А ведь вся нужная инфа для таких же камбэков уже лежит у него в канале:

🔹Где искать работу в РФ и как искать работу аналитиком вне РФ?
🔹Что спрашивают на собеседованиях и что на них отвечать?
🔹Как выбить себе офер посолиднее?

🔥 Топ постов на канале:

🔸Извините, вы оверквалифайд кандидат
🔸Где искать работу? + полезные ресурсы в комментах
🔸System Design интервью на архитектора с вилкой 550к на руки
🔸Собес в СберЗдоровье с решением задачи по архитектуре
🔸Интервью в AEON Payment — финтех на Кипре
🔸Провальное собеседование в банк на solution архитектора


Подписывайся — @na_sobese, если хотите найти работу быстрее.

☀Объяснение:

Что такое Event Storming?
Это метод фасилитации, разработанный Альберто Брандолини. Он проводится в формате интенсивной сессии (1–2 дня), где все участники (аналитики, разработчики, бизнес-эксперты) наклеивают на большую стену стикеры разных цветов:

Оранжевые – события (доменные события), которые происходят в бизнесе («Заказ создан», «Платёж подтверждён»).
Синие – команды (действия), которые инициируют события («Создать заказ», «Подтвердить платёж»).
Жёлтые – агрегаты (сущности, над которыми выполняются команды, например «Заказ», «Клиент»).
Розовые – акторы (пользователи, системы).
Фиолетовые – внешние системы.
Красные молнии – проблемные зоны (hot spots).
Почему это эффективно для непонятного процесса:
Эксперты вместе выстраивают временную линию событий, выявляя нестыковки и пробелы.
Метод не требует предварительной подготовки и нотации.
Результат – общая картина домена (bounded contexts), которую можно превратить в архитектуру микросервисов или user stories.

Почему не другие варианты:
A (Use Case Mapping) – требует предварительного знания сценариев, менее интерактивен.
C (BPMN-воркшоп) – требует знания нотации BPMN, что мешает бизнес-экспертам.
D (Impact Mapping) – скорее для стратегии и целей, а не для моделирования процессов.

Реальный пример:
В стартапе по доставке еды никто не знал, как происходит возврат денег при отмене заказа. За 4 часа Event Storming выявили 15 событий, 3 спорные зоны и договорились о новой логике.

Вывод: Event Storming – идеальный инструмент для быстрого погружения в предметную область, особенно когда нет чёткой документации.

☀Объяснение:

Проблема:
HTTP POST не является идемпотентным по определению. Если клиент повторяет запрос из-за таймаута, сервер не может отличить повтор от нового запроса. Это приводит к дублированию операций (списаний, созданий заказов).

Решение – идемпотентный ключ (Idempotency Key):
Клиент генерирует уникальный ключ (например, UUID) и передаёт его в заголовке Idempotency-Key. Сервер хранит этот ключ вместе с результатом операции в течение определённого времени (например, 24 часа). При повторном запросе с тем же ключом сервер возвращает ранее сохранённый результат, не выполняя операцию повторно.

Алгоритм работы сервера:
Получить ключ из заголовка.
Проверить в хранилище (Redis, БД), есть ли уже выполненная операция с этим ключом.
Если есть – вернуть сохранённый ответ.
Если нет – выполнить операцию (списание денег), сохранить ключ и результат, затем вернуть ответ.
Пример кода (Node.js):
javascript

const idempotencyKey = req.headers['idempotency-key'];
const cached = await redis.get(idempotencyKey);
if (cached) return JSON.parse(cached);
const result = await processPayment(req.body);
await redis.setex(idempotencyKey, 86400, JSON.stringify(result));
res.json(result);

Почему не подходят другие варианты:
B (IP-адрес) – не надёжен: несколько клиентов за NAT, динамические IP.
C (rate limiting) – не решает дублирование из-за таймаута, а лишь ограничивает частоту.
D (DELETE) – не подходит для создания ресурса/списания средств.

Реальный пример:
Stripe требует обязательный заголовок Idempotency-Key для идемпотентных запросов. Это позволяет клиентам безопасно повторять запросы при сетевых сбоях.

Что должен зафиксировать аналитик:
«API должен поддерживать заголовок Idempotency-Key для всех небезопасных методов (POST, PUT, PATCH)».
«Ключ должен храниться не менее 24 часов».
«Ответ на повторный запрос с тем же ключом должен быть идентичен первому».

Вывод: Idempotency Key – стандарт защиты от двойной обработки в REST API, обязательный для финансовых и критических операций.

☀Объяснение:

Диаграмма коммуникации (раньше называлась диаграммой кооперации) фокусируется на связях между объектами/компонентами и нумерует сообщения в порядке их передачи. В отличие от диаграммы последовательности, где время течёт вертикально, здесь время показано номерами (1, 1.1, 2 и т.д.), а пространственное расположение отражает топологию связей.

Когда что использовать:
Диаграмма последовательности – лучше для детального анализа временнóй логики, асинхронных вызовов, параллельных процессов. Но при 10 сервисах она становится громоздкой (много линий времени).
Диаграмма коммуникации – компактнее для большого числа участников, хорошо показывает, кто с кем связан, и позволяет быстро пронумеровать вызовы. Отлично подходит для архитектурных обсуждений на доске.

Почему B правильный ответ:
В задаче важны не временные отрезки (сколько миллисекунд), а порядок вызовов и структура связей. Диаграмма коммуникации помещает все микросервисы на один лист и стрелками с номерами показывает последовательность. Это удобно для презентации архитектуры команде и стейкхолдерам.

Реальный пример:
В интеграционном проекте с 6 внешними сервисами диаграмма коммуникации помогла выявить циклические зависимости (А → Б → В → А), которые не замечали на диаграмме последовательности.

Что должен зафиксировать аналитик:
Для описания высокоуровневого потока с большим числом участников использовать диаграмму коммуникации.
Для детальной отладки с таймингами – диаграмму последовательности.

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

☀Объяснение:

Blue‑Green deployment – это техника, при которой существуют два идентичных окружения: «синее» (blue, текущая production-версия) и «зелёное» (green, новая версия).
Новая версия разворачивается в зелёной среде, пока синяя продолжает обслуживать трафик.
Проводятся smoke-тесты зелёной среды.
В один момент (атомарно) переключается маршрутизатор (балансировщик, DNS), и весь трафик направляется на зелёную среду.
Если возникли проблемы – переключаем обратно на синюю за секунды.
Синяя среда сохраняется как резервная, позже удаляется.
Почему отсутствует простой:
Переключение трафика происходит мгновенно (обновление конфигурации балансировщика или смена DNS-записи). Старые поды не удаляются до переключения, поэтому пользователи не замечают никакого прерывания.

Сравнение с другими стратегиями:
Rolling update (A) – постепенная замена подов. Может быть почти незаметным, но требует, чтобы приложение было отказоустойчивым к разным версиям одновременно. Риск – простой при ошибке в последней партии.
Canary deployment (C) – сначала новая версия получает небольшой процент трафика (например, 1%), что позволяет оценить работу, но для бездымного переключения на 100% также нужен финальный атомарный шаг.
A/B тестирование (D) – не про деплой, а про эксперименты.

Реальный пример:
В Netflix используется Blue‑Green для критических сервисов. Перед переключением проводят полный цикл интеграционного тестирования в зелёной среде. При обнаружении проблем – просто не переключают трафик.

Что должен зафиксировать аналитик:
Требование: «Критические сервисы должны разворачиваться по стратегии Blue‑Green с нулевым временем простоя».
Наличие двух полных окружений (ресурсы могут быть уменьшены на время, но должны быть готовы к переключению).
Процедура отката – переключение обратно на blue.

Вывод: Blue‑Green deployment – золотой стандарт для систем, где недопустим простой, но требует удвоения ресурсов во время деплоя.