Кейсы системного аналитика: 8 рабочих ситуаций с логикой решения

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

Кейс 1. Интеграция двух систем: как описать обмен

Условие: заказ из магазина идёт в учётную систему, а статус доставки — обратно в личный кабинет. Что проверяют: задаёте ли вы вопросы до схемы. Кто инициатор обмена, как часто идёт передача, какой формат, какой объём и пик, что при сбое, чьи справочники.

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

• кейс: заказ не дошёл из магазина в учётную систему — логика: логи обеих сторон, время первой ошибки, коды ответов, состояние записи в базе, затем правила повторов.
• типичные ошибки: рисовать схему до вопросов об инициаторе и частоте, забыть про пик, не описать поведение при сбое.

Кейс 2. Идемпотентность и повторная доставка

Условие: клиент дважды нажал «Оплатить», а интеграция повторила запрос. Что проверяют: понимание, что повтор — норма, а не редкий баг: запрос теряется, ответ не доходит, брокер доставляет сообщение ещё раз.

Логика решения: ключ идемпотентности от инициатора, уникальный идентификатор операции, сохранённый результат первого вызова вместо нового списания, проверка состояния записи перед изменением. Согласуйте с разработкой, кто генерирует ключ, где он хранится и сколько живёт; проверку на повтор внесите в критерии приёмки.

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

Кейс 3. Ошибка на проде: порядок разбора

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

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

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

Кейс 4. Брокеры сообщений: очередь, топик, повторы

Условие: события заказов должны получать склад, аналитика и биллинг. Логика решения: очередь отдаёт сообщение одному потребителю, топик — всем подписчикам или группам. Нужно трём системам — берите топик; раздаёте задачи между экземплярами сервиса — очередь.

Гарантии доставки: at most once теряет, at least once повторяет, exactly once дороже и ограничен. Порядок держится только внутри раздела по ключу, например по номеру заказа. Для «зависших» сообщений задайте таймаут и очередь необработанных, повторные считайте по журналу.

• кейс: событие заказа нужно трём системам — логика: топик с группами потребителей, at least once плюс идемпотентность получателей, порядок по ключу, очередь необработанных.
• типичные ошибки: ждать порядок по всему топику, держать сообщение в очереди бесконечно, выбирать exactly once без оценки цены.

Кейс 5. Требования: как писать проверяемо

Условие: просят, чтобы «система работала быстро и надёжно». Логика решения: у каждого требования есть число, условие и способ проверки. Нагрузка: операции в час и пиковый коэффициент. Время отклика: доля запросов в пределах предела при заданной нагрузке.

Отказоустойчивость: допустимый простой в месяц, потеря записей, время восстановления. Логирование: что пишем, сколько храним, кто читает. Права: кто какие действия выполняет и как это разделено по ролям. Требование без способа проверки — это пожелание.

• кейс: «должно работать быстро и надёжно» — логика: нагрузка и пик, доля запросов в пределах времени отклика, простой, потеря записей, логи, роли.
• типичные ошибки: оценки без чисел, «удобный интерфейс» без критерия, отсутствие способа проверки требования.

Кейс 6. Конфликт требований и изменение на этапе приёмки

Условие: за неделю до сдачи просят добавить поле в отчёт и поменять правила расчёта, команда в срок не успевает. Логика решения: выпишите интересы и риски сторон, предложите варианты — урезать объём до одного сценария, вынести в следующий этап, сделать временное решение.

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

• кейс: новое поле и правила расчёта за неделю до сдачи — логика: интересы сторон, варианты по объёму и этапам, решение владельца продукта, письменная фиксация, новые критерии приёмки.
• типичные ошибки: решать за заказчика, молча соглашаться, писать «доделаем позже» без даты, менять объём без пересмотра тестов.

Кейс 7. Данные и проверка гипотез запросом

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

Оцените объём: сколько строк затронет правка и каким будет пик. Приёмы: группировка и подсчёт уникальных значений, соединение с источником, оконные функции, ограничение по периоду. Тяжёлые запросы запускайте на копии базы.

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

Кейс 8. Документация: что обязательно в спецификации

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

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

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

Что сделать: короткий чеклист

• Разберите одну рабочую ситуацию по шагам: условие, вопросы, решение, сбой.
• Проговорите ответ на кейс вслух за две минуты.
• Для каждого кейса назовите две типичные ошибки — свою и чужую.
• Проверьте требования: число, условие, способ проверки.
• Соберите список вопросов для интеграции: инициатор, частота, формат, объём, сбой.
• Разберите повторную доставку: ключ идемпотентности, идентификатор операции, проверка состояния.
• Сделайте шаблон разбора инцидента: влияние, факты, гипотезы, документация.
• Пройдите бесплатную диагностику из 20 вопросов и отметьте слабые темы.

Где тренировать

Темы из гайда разобраны в тестах портала — каждый вопрос с объяснением ответа:

• Вопросы для системного аналитика с разбором — Системный аналитик
• Кейсы на собеседовании аналитика
• Вопросы на собеседовании системного аналитика
• Курс «API и интеграции»: 107 вопросов
• SQL-задачи на собеседовании

Кейсы системного аналитика — про порядок в голове: уточнить условие, договориться о правилах обмена, проверить гипотезу фактами, записать вывод в документацию. Разберите одну ситуацию вслух и проверьте себя на вопросах для системного аналитика с объяснением ответов — так пробелы видны быстрее, чем при чтении теории.

Частые вопросы