Суббота, 3:47. Прод лежит четвёртый час. Шестеро в зуме, глаза красные, в чате клиенты, финдиректор считает: 87 000 долларов и растёт.
Понедельник, 9:00. CTO с красным лицом: кто допустил.
Сеньор молчит. Мидл в пол. Джун, чей коммит, не дышит. Через неделю та же дыра. И снова никто ничего не знает.
Эту сцену я видел десятки раз. Команда не учится, инцидент повторяется, люди выгорают. Разбор после падения нужен не для приговора. Он нужен, чтобы система в следующий раз не пустила ту же руку к той же кнопке.
Постмортем это разбор: что случилось, почему система это позволила, что мешает повтору, кто за шаг отвечает и к какой дате. Это не допрос, не штраф и не страница в вики «для галочки».
Без разбора, по цифрам Google SRE, около 60% инцидентов возвращаются. С формальной бумагой около 30%. С шагами, именами и проверкой через месяц около 5%. Семьдесят процентов пунктов из разборов не делается, если никто не возвращается к списку. Это и есть главная причина «мы же писали постмортем».
Сначала тон, потом шаблон
«Кто задеплоил баг» рождает тишину в следующий понедельник. «Что позволило багу доехать» рождает процесс.
Разработчик: не успел написать тесты, дедлайн. Дальше не «твоя ответственность», а почему в оценке не было времени на тесты. Пункты: плюс 20% на тесты в оценке, проверка в CI, staging обязателен до прода. Человек мог сломать прод одним действием. Значит, дыра в системе.
Если руководитель на разборе ищет фамилию, культуры не будет. Первая реплика на честное «это я нажал»: спасибо, что сказал, давайте закроем дыру. Наказывать за признание это учить прятать следующий инцидент.
Бумагу пишем, когда простой больше получаса, потеряны данные, дыра в безопасности, убыток заметный, пачка жалоб, сломан SLA. Мелочь, которая приходит третий раз, тоже разбираем. Разбор после удачного релиза тоже бывает: какие риски приняли сознательно и угадали. Тогда слот перестаёт пахнуть судом.
Пишет тот, кто тушил, или техлид, который был в канале. Не «виноватый»: он будет защищаться, не раскладывать.
Бумага, которая помещается на стол
Ниже каркас, который я таскаю. Цифры в примере живые: диск, логи, миграция.
# Диск на 100%, прод 2025-12-15
Начало: 22:47 UTC. Восстановили: 03:15. Длительность: 4 ч 28 мин. P0.
## Коротко
База не смогла писать WAL: диск был полный.
Недоступны все. ~100 000 пользователей. ~$87 000. 247 злых отзыва.
Корень: после миграции три месяца назад пропал logrotate, логи росли ~20 ГБ в день, 300 ГБ кончились за 15 дней.
Как подняли: стёрли старые логи, перезапустили базу.
Чтобы не повторить: logrotate везде, алерт на диск > 80%, проверка конфигов после миграции.Хронология таблицей, по логам и слаку, не по памяти через неделю. 22:47 ошибки к базе, 22:52 алерт доехал, 23:15 диск 100%, 23:45 чистка tmp не помогла, 00:30 DBA увидел логи приложения, 01:15 50 ГБ свободно и база дышит, 03:15 закрыли.
Пять «почему», пока не упрётесь в отсутствующую проверку, а не в фамилию.
- Почему прод упал? PostgreSQL не записал WAL.
- Почему не записал? Места на диске ноль.
- Почему диск полный? Логи приложения не ротировались.
- Почему не ротировались? Конфиг logrotate потерялся на миграции сервера.
- Почему потерю не увидели? Нет проверки критичных конфигов после переезда и нет алерта на заполнение диска.
Корень: миграция без автоматической проверки. Рядом способствующие: DBA не в первой линии дежурства, нет runbook на «диск полный», логи три месяца никто не смотрел.
Что сработало, тоже пишем. Дежурный ответил за пять минут при SLA пятнадцать. Эскалация на DBA не потерялась. Клиентам сказали правду на статус-странице. Иначе разбор выглядит как порка.
Пункты четырьмя полками, у каждого имя, дата, статус.
Предотвратить: включить logrotate, алерт на 80%, проверка конфигов после миграции, DBA в первую линию.
Заметить раньше: дашборд диска, еженедельный взгляд на рост логов, алерт на аномалию больше 10 ГБ в день.
Тушить быстрее: runbook «диск полный», скрипт очистки, учения на стейдже.
Научиться: разбор с командой, кусок в онбординге про мониторинг.
Без имени и даты пункт это пожелание. Больше семи-восьми живых пунктов команда не вывозит. Лучше три закрытых, чем пятнадцать в бэклоге стыда.
Резюме пишу так, чтобы его понял человек без стека. Бизнес читает только его. Дальше ссылки: тред, дашборд, логи, статус. Подписи техлида, дежурного, менеджера. Для P0 ещё разговор с теми, кто тушил, 60-90 минут: резюме, хронология, пять «почему», пункты, приоритет, имена. Модератор режет «это Вася». Переформулирует: что в ревью и в мониторинге пустило.
Пока память тёплая
Сразу после подъёма: заготовка бумаги, таймлайн из логов, скрины дашбордов, тред, коммиты рядом с дырой. Логи имеют обыкновение ротироваться именно тогда, когда они нужны.
22:47 мониторинг: ошибки к базе
22:52 дежурный взял алерт (SLA 15 мин, факт 5)
23:15 диск 100%
23:45 чистка tmp, места нет
00:30 DBA: логи приложения, 20 ГБ/день
01:15 50 ГБ свободно, база дышит
03:15 репликация живая, инцидент закрыт
Что сработало в ту ночь: дежурный не проспал, эскалация на DBA не потерялась, клиентам написали правду. Что нет: три месяца без ротации, диск без алерта, DBA не в первой линии, runbook на «диск полный» отсутствовал. Если писать только второе, разбор пахнет поркой и в следующий понедельник снова будут молчать.
Встреча через сутки-двое, не через месяц. Через месяц все уже уверены, что виноват релиз соседа.
После встречи автор обновляет документ за неделю, рассылает инженерной ленте, для критичного ещё шире. Потом еженедельный проход по пунктам: сделано, в работе, запланировано, стоит (и почему). Стоит больше двух недель: эскалация. Цель: больше 80% пунктов закрыты за месяц, средний срок две-три недели, повтор этой дыры ноль.
Раз в квартал смотрю пачку разборов вместе. Одинаковый корень три раза это уже не инцидент, это дыра в процессе. Runbook, который написали и ни разу не прогнали на стейдже, в три ночи не поможет. После диска мы заполнили том на копии и проверили: алерт пришёл, дежурный понял, скрипт отработал, текст в runbook читается сонным человеком.
Публичный разбор для клиентов уместен, когда им уже солгали тишиной. Внутренний честный важнее внешнего красивого.
Чем обычно портят
Пишут за полчаса, чтобы закрыть тикет, и кладут в вики. Ищут фамилию. Набирают двадцать пунктов и не делают ни одного. Не считают, вернулась ли дыра. Собираются через месяц, когда хронология уже миф.
Публичные разборы больших контор я читаю не ради морали, а ради хода. В 2017-м у AWS опечатка в команде погасила слишком много серверов S3: tooling больше не даёт снять сразу весь загон. У GitLab админ снёс прод вместо стейджа, бэкапы не проверялись, потеряли шесть часов данных и опубликовали всё, включая чат. У Knight Capital старый код ожил из-за кривого деплоя и за 45 минут сжёг 440 миллионов. Во всех трёх дыра была в системе, которая пустила одно движение без страховки. Фамилия инженера ничего не чинила.
Считать стоит четыре вещи. Сколько минут от падения до подъёма. Как часто падаем. Какая доля инцидентов уже была в прошлых бумагах. Какая доля пунктов жива через месяц. Если разбор начинается через три недели, вы разбираете легенду.
Внедрение с одного шаблона и одного следующего падения. Не с курсов и не с платформы за пять цифр. Следующий P0 разбираете по каркасу выше, в понедельник не спрашиваете «кто», в пятницу открываете список пунктов. Если пункты живы, культура уже началась. Если бумага снова легла в вики и диск снова кончился, вы купили себе ещё одну субботу в 3:47.
