Формат интервью по диагностике инцидентов проще понять на реальном разборе, чем на абстрактном списке шагов.
Эта глава показывает, как развивается живая инцидентная задача: какие сигналы появляются по ходу разговора, как кандидат расставляет приоритеты и какие действия действительно продвигают расследование вперед.
Для подготовки это полезно как практический эталон: по нему удобно сверять темп рассуждения, качество вопросов и глубину проверки гипотез, а внутри компании использовать как материал для обучения интервьюеров.
Практическая польза главы
Ход расследования
Отрабатывайте порядок расследования: симптом, гипотеза, проверка, подтверждение, действие.
Поиск первопричины
Отделяйте от вторичных эффектов, чтобы временные меры не маскировали системную проблему.
Временная стабилизация
Подбирайте меры по горизонту: срочное снижение ущерба, затем исправление и защитные ограничения на будущее.
Разбор после инцидента
Чётко формулируйте, что изменится в системе после инцидента и по каким сигналам будет видно улучшение.
Источник
Публичное интервью на DevOops
Статья Александра Поломодова с разбором публичного интервью по диагностике инцидента.
легче понять на живом примере, чем по одному только описанию формата. На DevOops 2023 показали публичную сессию, где шаг за шагом виден весь разговор: от обсуждения архитектуры до поиска причины сбоя и выбора дальнейших действий.
Участники интервью
- Интервьюер: Александр Поломодов
- Кандидат: Салих Фахрутдинов, Senior в Tinkoff Origination Platform
Сценарий интервью
По сценарию кандидат и интервьюер работают в одной команде . Кандидат выступает в роли ведущего инженера, а интервьюер — младшего инженера. Ведущий инженер уезжает на конференцию, младший остаётся на дежурстве, происходит инцидент, и дальше расследование развивается как совместная рабочая сессия.
Такая ролевая модель делает разговор ближе к реальной эксплуатации: можно увидеть, как кандидат задаёт темп расследованию, направляет менее опытного коллегу и держит фокус на проверяемых шагах, а не на случайных догадках.
Теория
Интервью по диагностике инцидентов
9-этапный каркас расследования инцидента и логики интервьюера.
Архитектура системы
Перед началом расследования участники быстро выравнивают контекст и обсуждают архитектуру финтех-приложения Yellow.
Масштаб
Около 1 млн
Функциональность
Дебетовые и кредитные карты, платежи
Интерактивная схема архитектуры
Переключайтесь между путём инициализации и основным потоком данных, чтобы увидеть, как приложение загружается и где проходит платёжный сценарий. Кнопка воспроизведения автоматически прокрутит шаги по порядку.
Запуск приложения
Пользователь открывает веб-клиент или мобильное приложение
Секция инициализации
Инцидент
Пользовательский путь
Список продуктов
Карта #1
Дебетовая • ****4521
Карта #2
Кредитная • ****8832
Платежи
Форма платежа
Перевод средств
После уточняющих вопросов по архитектуре интервью переходит к диагностике. Младший инженер сообщает о симптоме — сработал алерт на снижение числа платежей — и вместе с ведущим инженером начинает разбирать возможные причины.
Что оценивается в процессе
- •Насколько последовательно кандидат строит расследование и не распадается на хаотичный перебор версий
- •Как он формулирует гипотезы и подбирает проверки с понятной целью
- •Насколько уверенно использует операционные метрики и диагностические эвристики как опору, а не как набор выученных слов
- •Умеет ли вести менее опытного коллегу через расследование спокойно и понятно
- •Удерживает ли баланс между быстрым смягчением эффекта и полноценным исправлением
В таких разговорах кандидат обычно сначала смотрит на , чтобы быстро понять, что происходит с потоком запросов, ошибками и длительностью, а затем сверяет картину с , если нужно понять, не упирается ли система в загрузку ресурсов, насыщение или локальные ошибки на конкретных узлах.
В хорошем ответе кандидат различает и движение к : сначала уменьшает пользовательский ущерб, а затем доводит расследование до объяснимого и проверяемого вывода.
Ключевые выводы
Реалистичность формата
Сценарий с ведущим и младшим инженером делает интервью похожим на реальное дежурство и помогает оценить не только техническую часть, но и качество координации под давлением.
Архитектурный контекст
Разговор начинается с архитектуры системы, поэтому гипотезы строятся не в вакууме, а опираются на реальные зависимости, сервисы и пользовательский путь.
Практика vs теория
Такой разбор дополняет теорию конкретным темпом разговора: видно, какие вопросы действительно двигают расследование вперёд, а какие только создают шум.
Источники
Связанные главы
- Интервью по диагностике инцидентов - даёт теоретический 9-этапный каркас, который используется в этом практическом разборе.
- Интервью по системному дизайну: 7-шаговый подход - помогает увидеть, как структура архитектурного разговора адаптируется к диагностике инцидента.
- Как оценивают интервью по системному дизайну и как управляется его сложность - показывает, как оценивать шаги кандидата и калибровать сложность в реальном времени.
- Site Reliability Engineering - закладывает базовые практики мониторинга, алертинга и реакции на инциденты.
- The Site Reliability Workbook - добавляет прикладные сценарии дежурств, разборов инцидентов и улучшения операционных практик.
- Release It! - систематизирует типовые режимы отказа и защитные приёмы для эксплуатационных систем.