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