Прямой ответ
Postmortem — письменный разбор инцидента после его устранения. Принцип «без обвинений» (blameless) означает, что разбор ищет системные причины, а не виновного: если вывод сводится к «разработчик допустил ошибку», инцидент повторится, поскольку условия, позволившие ошибке привести к отказу, остались на месте.
Различие формулировок определяет полезность разбора:
| С обвинением | Без обвинения |
|---|---|
| Разработчик выкатил нерабочую версию | Развёртывание не проверило работоспособность до переключения трафика |
| Дежурный не заметил тревогу | Оповещение сработало через 20 минут после начала деградации |
| Ошиблись в конфигурации | Изменение конфигурации применяется без проверки и откатывается вручную |
Правая колонка описывает то, что можно исправить. Левая — то, что повторится при следующей смене дежурного.
Структура разбора включает шесть разделов:
1. Краткое описание. Что произошло, сколько длилось, какое влияние на пользователей. Один-два абзаца, понятные не только инженерам.
2. Хронология. Время обнаружения, первых действий, попыток восстановления, устранения. Хронология показывает, где потеряно время: часто обнаружение занимает больше, чем само исправление.
3. Влияние. Число затронутых пользователей, длительность, потерянные данные, финансовые последствия. Количественная оценка нужна для приоритизации действий.
4. Причины. Непосредственная причина и условия, которые сделали её возможной. Вопрос «почему» задаётся несколько раз, пока ответ не перестанет указывать на человека.
5. Что сработало хорошо. Не только ошибки: обнаружение, автоматический откат, корректная работа деградации. Это фиксирует практики, которые стоит сохранить.
6. Действия. Конкретные задачи с владельцем и сроком. Действие без владельца не выполняется; о практике — в статье про инцидент-менеджмент.
Критерий качества действий: каждое должно снижать вероятность повторения либо сокращать время восстановления. «Быть внимательнее» не является действием, поскольку не меняет систему.
Практика: проведение разбора
1. Пишите разбор в течение суток. Через неделю детали теряются, а хронология восстанавливается по памяти с ошибками.
2. Собирайте хронологию из данных. Время из журналов, метрик и истории развёртываний точнее воспоминаний участников; о данных — в статье про SLO и error budget.
3. Отделяйте факты от интерпретаций. «Задержка выросла в 09:12» — факт. «Из-за новой версии» — гипотеза, требующая подтверждения.
4. Задавайте вопрос «почему» до системного уровня. Ответ «человек ошибся» требует следующего вопроса: что в системе позволило ошибке привести к отказу.
5. Формулируйте действия проверяемо. «Добавить проверку работоспособности перед переключением трафика» проверяемо; «улучшить процесс развёртывания» — нет.
6. Отслеживайте выполнение действий. Разбор, действия которого не выполнены, не предотвращает повторения. Список действий проверяется наравне с задачами разработки.
7. Публикуйте разбор внутри команды. Доступность разборов снижает страх сообщать о проблемах; о снижении шума тревог — в статье про усталость от оповещений.
8. Не требуйте разбора для каждого сбоя. Мелкие инциденты фиксируются кратко; полный разбор нужен там, где влияние существенно или причина неочевидна.
Рекомендации:
- Не используйте разбор для оценки сотрудников. Как только postmortem влияет на оценку, информация в нём перестаёт быть полной.
- Включайте в разбор участника со стороны. Свежий взгляд задаёт вопросы, которые команда считает очевидными.
- Фиксируйте время обнаружения отдельно от времени устранения. Улучшение обнаружения часто даёт больший эффект, чем ускорение исправления.
- Проверяйте гипотезы до внесения в разбор. Причина, указанная без подтверждения, направляет действия в неверную сторону.
- Возвращайтесь к старым разборам. Повторение похожих инцидентов означает, что действия не были выполнены либо не решили причину.
Практический сценарий: два одинаковых инцидента за квартал из-за невыполненных действий
Контекст: сервис падал дважды за три месяца с одинаковым проявлением — исчерпанием пула соединений с базой данных. Первый разбор был проведён и закрыт.
- Диагностика. Сравнение двух разборов показало совпадение непосредственной причины: долгая транзакция удерживала соединения, и пул исчерпывался. Различались только обстоятельства запуска.
- Анализ действий. Первый разбор содержал три действия: ограничение времени транзакции, метрика занятости пула, тревога при приближении к пределу. Выполнено не было ни одного — у действий отсутствовали владельцы и сроки.
- Действия. (а) Разбор переписали: каждое действие получило владельца и дату; (б) добавили ограничение времени транзакции на уровне базы, поскольку это не зависит от дисциплины в коде; (в) добавили метрику занятости пула с порогом 80 процентов; (г) ввели правило: разбор закрывается только после выполнения всех действий; (д) добавили ежемесячную проверку открытых действий из разборов.
- Результат. Третьего инцидента не произошло, а ограничение на уровне базы сработало дважды, предотвратив исчерпание пула.
Вывод: разбор без выполнения действий создаёт иллюзию работы над надёжностью. Ключевой элемент postmortem — не документ, а отслеживание действий с владельцами и сроками; системные меры на уровне платформы надёжнее мер, зависящих от внимательности людей.
FAQ
Что означает «без обвинений» на практике? Разбор описывает условия, позволившие ошибке привести к отказу, и меры по их устранению. Персональная ответственность не обсуждается в документе.
Нужен ли разбор для каждого инцидента? Нет. Краткая фиксация нужна всегда, полный разбор — для инцидентов с существенным влиянием или неочевидной причиной.
Кто должен писать разбор? Участник, знакомый с деталями, при участии человека со стороны. Автор не обязан быть руководителем.
Как проверить, что разбор полезен? По выполнению действий и по отсутствию повторных инцидентов с той же причиной. Повторение означает, что мера не сработала.
Источники: Google SRE Book (Postmortem Culture), SRE Workbook, PagerDuty Response — ссылки в шапке.