Инцидент — неплановое нарушение или ухудшение работы сервиса; при его обработке важно восстановить работу и ограничить ущерб. Проблема — причина или совокупность причин, которые требуется исследовать и устранить. Задача — конкретная единица работы. После стабилизации фиксируют хронологию, влияние, причины и действия с ответственными, а не просто закрывают уведомление.
Участвовали ли вы в разборе инцидентов? Чем инцидент отличается от проблемы и задачи?
Восстановление сервиса, исследование причин и последующие действия: как объяснить термины и свою роль в разборе инцидента.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Сначала разделите понятия. Инцидент — неплановое нарушение или ухудшение нормальной работы сервиса. Проблема — его причина или потенциальная причина будущих инцидентов. Задача — конкретная работа, например добавить проверку или изменить конфигурацию. Внутренние названия сущностей в трекере могут отличаться, поэтому полезно уточнить процесс команды.
Восстановить сервис и устранить все причины — не обязательно одно действие. Откат релиза может завершить активную фазу инцидента, а исследование причины и постоянное исправление продолжатся отдельно. Нельзя считать причиной просто имя человека, выполнившего изменение.
В рассказе о своём опыте обозначьте роль: дежурили, диагностировали, собирали хронологию, общались с пользователями или выполняли последующие действия. Разберите реальный случай, не присваивая себе координацию всей команды.
После стабилизации обычно фиксируют:
- влияние на пользователей и длительность нарушения;
- последовательность событий и принятых решений;
- технические и процессные факторы;
- что помогло обнаружить проблему и что задержало реакцию;
- конкретные улучшения, ответственных и способ проверки результата.
Действия должны уменьшать вероятность повторения или последствия сбоя. Формулировка «быть внимательнее» не заменяет изменение защиты, наблюдаемости или процесса. Сам документ без выполнения согласованных действий не завершает работу над устойчивостью. Такой подход описан в главе Google SRE о разборе инцидентов.
Если участвовали только в учебном разборе или читали готовые отчёты, честно отделите это от production-практики. Не раскрывайте персональные данные и закрытые подробности инцидента.