Расскажите о серьёзном инциденте в продакшене, который вы разбирали: как действовали, как нашли причину и что изменили после.
Короткий ответ
- Структура рассказа: контекст, обнаружение, действия, причина, выводы
- Сначала остановить ущерб, потом искать первопричину
- Коммуникация во время инцидента: роли и статусы для бизнеса
- Диагностика по фактам: метрики, логи, последние изменения
- Blameless-постмортем с action items и сроками
- Показать личный вклад и извлечённые уроки
Интервьюер оценивает порядок действий под давлением и зрелость выводов, а не драматичность аварии.
Как сказать вслух
пример ответаЯ выбираю реальный инцидент и рассказываю по структуре: что за система, как узнали о проблеме, что делал я, в чём оказалась причина и что мы изменили. Подчёркиваю, что первым делом мы останавливали ущерб — например, откатили релиз, — а уже потом копали первопричину. Отдельно говорю про коммуникацию: кто вёл инцидент и как мы информировали бизнес. Заканчиваю постмортемом без поиска виноватых и конкретными изменениями — новым алертом, проверкой в CI, правкой runbook — которые не дали проблеме повториться.
Подробный ответ
Основной ответ
Сильный ответ строится по схеме: контекст (система, ваша роль), обнаружение (алерт или, хуже, жалобы пользователей — и вывод про мониторинг), реакция (оценка масштаба, объявление инцидента, роль incident commander, быстрая митигация — откат, переключение трафика, отключение фичи), диагностика (гипотезы по метрикам и логам, корреляция с последними изменениями — большинство инцидентов вызвано деплоем или конфигурацией), первопричина и устранение, затем blameless-постмортем: таймлайн, причины по «пяти почему», action items с владельцами и сроками. Важно показать приоритет: восстановление сервиса раньше полного понимания причины. Честность про собственные ошибки и выводы ценится выше идеальной истории.
Ключевые моменты
- Митигация прежде диагноза. Сначала вернуть сервис пользователям (откат, failover), и только затем искать первопричину.
- Управление инцидентом. Назначенный ведущий, отдельный канал, регулярные статусы — хаос в коммуникации удлиняет инцидент сильнее, чем техника.
- Blameless-культура. Разбор ищет системные причины, а не виноватых — иначе люди начинают скрывать проблемы.
- Доведённые action items. Ценность постмортема — выполненные изменения: алерты, тесты, автоматизация, а не документ в архиве.
Практический контекст
Этот вопрос есть практически в каждом интервью на SRE/DevOps: по рассказу видно и реальный опыт on-call, и зрелость инженерной культуры кандидата. Готовиться стоит заранее: выбрать один-два инцидента и отрепетировать рассказ на пять минут по структуре STAR. Красные флаги для интервьюера — обвинение коллег, «мы перезагрузили и всё прошло» без разбора, отсутствие изменений после инцидента.
Частые ошибки
- Рассказывают хаотично, без структуры и без своей роли в событиях
- Обвиняют коллег или «кривой код» вместо разбора системных причин
- Не могут назвать ни одного конкретного изменения после инцидента