Разбор инцидентов и blameless postmortem: практическое руководство
Продвинутое3 минРедакция Innovialabs
Коротко
Во время инцидента назначьте ответственного и сначала восстановите сервис, а после — проведите разбор без поиска виноватых, найдите системные причины и доведите каждое действие до выполнения.
Коротко о главном
Хороший процесс работы с инцидентами состоит из двух частей:
- Во время сбоя — быстро восстановить сервис, а не искать идеальное решение. Помогают четкие роли и один канал коммуникации.
- После сбоя — blameless postmortem: разбор, который ищет слабые места в системе и процессах, а не виноватого человека.
Почему без обвинений? Если за ошибку наказывают, люди скрывают детали, и команда теряет самую ценную информацию о том, как на самом деле работает система.
Роли во время инцидента
Даже в маленькой команде роли стоит разделить, иначе все чинят одно и то же и никто не общается с бизнесом.
| Роль | Задача |
|---|---|
| Incident Commander | Координирует работу, принимает решения, не чинит сам |
| Ops / технический лидер | Диагностирует и применяет исправления |
| Communications | Обновляет статус для клиентов, поддержки и руководства |
| Scribe | Ведет хронологию: что заметили, что сделали, когда |
В небольшой команде один человек может совмещать роли, но Incident Commander должен быть назначен явно.
Коммуникация во время сбоя
- Создайте отдельный канал под инцидент и ведите обсуждение только там.
- Объявите уровень серьезности и кто командует.
- Публикуйте регулярные обновления через понятные интервалы, даже если новостей нет.
- Внешний статус пишите простым языком: что не работает, кого касается, когда следующее обновление.
- Приоритет — смягчение последствий: откат релиза, переключение трафика, отключение фичи. Корневую причину ищут потом.
Шаблон постмортема
Проводите разбор, пока детали свежи, обычно в течение нескольких рабочих дней.
## Краткое описание
Что произошло, на кого повлияло, сколько длилось.
## Влияние
Затронутые пользователи, функции, нарушенные SLO.
## Хронология
Время — событие — кто что сделал.
## Корневые причины и способствующие факторы
## Что сработало хорошо
## Что пошло не так и где нам повезло
## Action items
Задача — владелец — срок — ссылка на тикет.
Как искать корневые причины
- 5 Whys — задавайте «почему?» несколько раз, пока не дойдете до процесса или системы. Остановка на «инженер ошибся» — признак плохого разбора.
- Ищите несколько способствующих факторов: у сложных сбоев редко одна причина.
- Спрашивайте «как система позволила этому случиться?» вместо «кто это сделал?».
- Отделяйте триггер (что запустило сбой) от причин (почему он стал возможен и почему его не поймали раньше).
Как довести action items до конца
Постмортем без выполненных задач — это просто текст. Чтобы задачи не терялись:
- У каждой задачи — один владелец и срок.
- Задачи заводятся в обычный трекер, а не остаются в документе.
- Формулируйте конкретно: не «улучшить мониторинг», а «добавить алерт на долю ошибок оплаты».
- Делите задачи на быстрые (на этой неделе) и системные (требуют планирования).
- Регулярно проверяйте статус открытых задач из постмортемов на встречах команды.
Частые ошибки
- Поиск виноватого вместо поиска причин.
- Разбор только крупных аварий — небольшие инциденты дешевле анализировать, а уроки те же.
- Слишком много action items, которые никто не успеет сделать.
- Постмортем, который никто не читает: делитесь выводами со всей командой.