Зачем нужен постмортем: не отчёт, а инструкция для следующего
Когда система падает, первое желание — найти виноватого и наказать. Второе — написать документ, чтобы закрыть вопрос. Оба желания вредят делу: если за инцидент наказывают, подробности перестают доходить до разбора, а если документ пишут ради галочки, он превращается в формальность, которую никто не читает.
Настоящая цель постмортема — сэкономить время следующему человеку, который столкнётся с тем же отказом. Если документ написан хорошо, этот человек потратит час вместо ночи. Если плохо — он потратит ночь, а потом напишет свой постмортем, в котором повторит те же ошибки.
Чтобы постмортем работал, он должен отвечать на три вопроса:
- Что именно видел пользователь?
- Почему это случилось?
- Что мы сделали, чтобы это не повторилось?
Ответы на эти вопросы не должны быть формальными. Если в документе написано «мы исправили ошибку», это ничего не значит. Если написано «мы добавили проверку на запуск тестов в ветке прода», это уже полезно. Если ещё и указано, почему проверка не работала раньше, — это идеально.
Почему поиск виноватого убивает разбор
Когда за инцидент наказывают, люди начинают скрывать детали. Они пишут в постмортеме то, что безопасно, а не то, что важно. В результате документ превращается в набор общих фраз: «мы провели анализ», «приняли меры», «ситуация под контролем».
Пример: в одной компании после каждого инцидента проводили разбор, но в документах никогда не упоминали, что кто-то забыл запустить тесты или не проверил конфигурацию. Вместо этого писали: «мы усилили мониторинг» или «улучшили процесс выкатки». Через год выяснилось, что половина инцидентов повторяется, потому что настоящие причины так и не были устранены.
Чтобы постмортем был полезным, он должен быть честным. Если кто-то допустил ошибку, это нужно указать — но не для того, чтобы наказать, а для того, чтобы следующий человек знал, на что обратить внимание. Если ошибка была системной (например, тесты не запускаются на определённой ветке), это нужно исправить, а не замалчивать.
Структура, которая работает
Хороший постмортем состоит из шести частей:
-
Что видел пользователь Описание проблемы с точки зрения того, кто с ней столкнулся. Не «сервис упал», а «пользователи получали ошибку 502 при попытке зайти на главную страницу». Если были жалобы в саппорт, их можно процитировать.
-
Срок отказа Когда проблема началась и когда закончилась. Если отказ был частичным (например, только для определённых запросов), это тоже нужно указать.
-
Ход событий по времени Хронология: что происходило с момента обнаружения проблемы до её устранения. Здесь важны не только действия команды, но и автоматические реакции системы (например, перезапуск сервиса или срабатывание алерта).
-
Причина Не повод («выкатили ошибку»), а настоящая причина («ошибка доехала до прода, потому что проверка не запускается на этой ветке»). Если причина неочевидна, можно описать, как её искали.
-
Почему не заметили раньше Здесь важно указать, что именно не сработало: алерт был слишком шумным, тесты не покрывали этот кейс, мониторинг не отслеживал нужный параметр.
-
Что меняем Конкретные действия, которые предотвратят повторение инцидента. Не «усилим мониторинг», а «добавим алерт на запуск тестов в ветке прода» или «расширим покрытие тестами на случай X».
Причина vs повод: почему «выкатили ошибку» — это не ответ
Когда в постмортеме пишут «причина — выкатили ошибку», это ничего не объясняет. Ошибки выкатывают постоянно, но не все из них приводят к инцидентам. Настоящая причина — это то, что позволило ошибке дойти до пользователей.
Примеры:
- Повод: «выкатили баг». Причина: «баг доехал до прода, потому что тесты не запускались на этой ветке».
- Повод: «упал сервис». Причина: «сервис упал, потому что не было лимита на количество одновременных запросов».
- Повод: «пользователи не могли зайти». Причина: «авторизация не работала, потому что база данных переполнилась из-за отсутствия очистки старых записей».
Если в постмортеме указана только причина-повод, следующий человек, столкнувшись с той же проблемой, не сможет её предотвратить. Он просто повторит те же действия: выкатит ещё одну ошибку и удивится, почему она снова дошла до пользователей.
Сроки: пишите, пока помните детали
Постмортем нужно писать сразу после инцидента, пока все детали свежи в памяти. Если отложить на потом, часть информации забудется, а часть исказится. В результате документ превратится в набор общих фраз, которые никому не помогут.
Пример: в одной компании разборы инцидентов писали раз в месяц, когда у команды появлялось «свободное время». К этому моменту многие детали уже забывались, и в документах оставались только общие выводы: «мы провели анализ», «приняли меры». Когда через полгода случился похожий инцидент, команда потратила два дня на то, чтобы разобраться, что произошло, — хотя вся информация уже была в старых постмортемах, но в них не было подробностей.
Если нет времени писать полный постмортем сразу, можно сделать краткую заметку с хронологией и основными фактами, а потом дополнить её, когда появится возможность.
Что делать с пунктом «что меняем», чтобы он не остался списком благих намерений
Пункт «что меняем» — самый важный в постмортеме, но и самый опасный. Если написать в нём общие фразы («усилим мониторинг», «улучшим процесс»), он превратится в бесполезный список. Чтобы этого не произошло, нужно указать конкретные действия с ответственными и сроками.
Примеры:
- Плохо: «усилим мониторинг». Хорошо: «добавим алерт на запуск тестов в ветке прода (Иван, до конца недели)».
- Плохо: «улучшим процесс выкатки». Хорошо: «введём обязательную проверку конфигурации перед выкаткой (Мария, до 15 числа)».
- Плохо: «расширим покрытие тестами». Хорошо: «добавим тесты на случай X (Пётр, до конца месяца)».
Если в пункте «что меняем» нет конкретных действий, сроков и ответственных, он останется списком благих намерений, который никто не выполнит.
Тупик: писать разбор ради галочки и складывать в общий диск
Если постмортем пишут ради галочки, он никому не нужен. Такой документ складывают в общий диск, где его никто не читает, и через полгода история повторяется.
Признаки бесполезного постмортема:
- Нет конкретных причин, только поводы («выкатили ошибку»).
- Нет хронологии, только общие выводы («мы провели анализ»).
- Пункт «что меняем» состоит из общих фраз («усилим мониторинг»).
- Нет ответственных и сроков.
Чтобы постмортем был полезным, он должен быть:
- Честным: в нём должны быть указаны настоящие причины, а не поводы.
- Конкретным: в нём должны быть указаны конкретные действия, а не общие фразы.
- Своевременным: его нужно писать сразу после инцидента, пока все детали свежи в памяти.
Если постмортем не отвечает этим критериям, его лучше не писать вообще — он только создаст иллюзию безопасности.
Позиция редакции
Постмортем — это не отчёт, а инструмент для улучшения системы. Если его пишут ради галочки, он бесполезен. Если в нём скрывают детали, чтобы не наказывать виноватых, он вредит делу. Единственный способ сделать постмортем полезным — писать его честно, конкретно и вовремя.
Эта позиция неверна, если:
- В вашей компании за инциденты не наказывают, но при этом никто не читает постмортемы.
- Вы пишете постмортем не для команды, а для внешних аудиторов, которым нужны формальные отчёты.
- Ваша система настолько стабильна, что инциденты случаются раз в несколько лет, и каждый раз их причины уникальны.