После крупной аварии в команде обычно происходит одно из двух. Либо ищут, кто выкатил, — и тогда в следующий раз о проблеме узнают позже и от клиентов. Либо не разбирают вообще — «починили, поехали дальше», — и через месяц та же авария повторяется в соседнем сервисе.
Разбор аварии — это не ритуал и не наказание. Это единственный момент, когда система показывает свои настоящие слабые места бесплатно: платить за это знание вы уже закончили.
Постмортем — это документ, а не встреча
Встреча без документа заканчивается ощущениями. Документ работает годами: его читают, когда в команду приходит новый человек, на него ссылаются в следующем разборе, по нему видно, что действительно изменилось.
Рабочая структура постмортема — пять частей.
Что видел клиент. Не «упал сервис заказов», а «с 14:05 до 15:20 покупатели не могли оформить заказ, 4 300 попыток завершились ошибкой». Это первая строка, потому что она задаёт масштаб: без неё разбор скатывается в обсуждение технической детали.
Хронология. Сухая линия времени: когда началось, когда заметили, кто что делал, когда стало лучше. Два интервала в ней важнее остальных — от начала до обнаружения и от обнаружения до восстановления. Первый лечится наблюдаемостью, второй — инструментами и инструкциями.
Причина. Не одна, а цепочка. Ниже про то, как её искать.
Что помогло и что мешало. Честно: сработал алерт или позвонил менеджер; нашли по журналам или гадали; была инструкция или собирали знание на ходу. Это самая полезная часть для следующего раза.
Действия. Список с ответственным и сроком. Про него отдельно ниже, потому что именно здесь постмортемы обычно и умирают.
Почему разбор безобвинительный — и что это значит на практике
Формулировка «человеческая ошибка» — это место, где разбор останавливается, не начавшись. Инженер выкатил ночью без проверки, удалил не ту таблицу, промахнулся окружением. Дальше следует выговор, и все расходятся с чувством, что проблема решена.
Она не решена. Вопрос, на который стоит ответить, звучит иначе: почему система позволила одному человеку это сделать и не заметила. Почему выкат не требовал подтверждения. Почему боевая база доступна с рабочего места. Почему одинаковые окружения различались одной буквой в имени.
Безобвинительность здесь — не мягкость к людям, а метод. Он держится на простом наблюдении: человек, который боится, скрывает детали. А детали — это ровно то, ради чего вы собрались.
Практические следствия для лида:
- В документе нет имён — есть роли: «дежурный», «автор изменения». Имена нужны только в списке действий, где кто-то отвечает за исправление.
- Первым говорит тот, кто был у руля, и говорит про факты, а не про оправдания. Задача ведущего — не дать разговору свернуть в «надо было быть внимательнее».
- Слово «надо было» — стоп-сигнал. Оно всегда обращено в прошлое и никогда не превращается в изменение системы.
- Ответственность за результат остаётся. Безобвинительный разбор не отменяет разговора с человеком, который систематически нарушает договорённости, — просто это другой разговор, в другое время и один на один.
Как искать причину: пять «почему» и цепочка защит
Самый простой рабочий приём — задавать «почему» до тех пор, пока ответ не превратится в то, что можно изменить.
Заказы не оформлялись. Почему? Сервис заказов не отвечал. Почему? Кончились соединения к базе. Почему? Фоновая задача открывала соединение на каждую строку и не закрывала. Почему? Ошибка прошла ревью — в изменении было 900 строк, и этот кусок не рассмотрели. Почему? Нет ни ограничения на размер изменения, ни проверки на утечку соединений.
Смотрите, что произошло: начали с «сервис лежал», закончили двумя конкретными изменениями — норма на размер изменения и автоматическая проверка. Если бы остановились на третьем «почему», действием стало бы «исправить фоновую задачу» — и та же ошибка вернулась бы в другом месте.
Второй приём полезен для крупных аварий: посчитать слои защиты, которые не сработали. Обычно авария проходит через несколько: ревью не заметило, тесты не покрыли, выкат не был поэтапным, наблюдаемость не показала, алерт не сработал, откат оказался долгим. Каждый не сработавший слой — отдельный кандидат в план действий, и часто дешевле починить второй или третий слой, а не первый.
Ту же логику разбора удобно тренировать на готовых случаях: в кабинете для этого есть тренажёр по производственным авариям — десять разборов по схеме «причина → чем подтвердить → что делать сейчас → чтобы не повторилось».
План действий: где постмортемы умирают
Из десяти постмортемов в среднем девять содержат раздел «действия», и в семи из них ничего не сделано через квартал. Причины всегда одни и те же.
Слишком много пунктов. Пятнадцать действий после одной аварии — это способ не сделать ни одного. Оставьте два-три: те, что закрывают самый дешёвый слой защиты.
Пункты без владельца и срока. «Улучшить мониторинг» не выполнит никто. «Добавить алерт на исчерпание пула соединений, ответственный такой-то, до пятницы» — выполнимо.
Пункты вне обычного потока работы. Если действия не попали в тот же список задач, что и вся остальная работа, они живут только в документе. Заводите их сразу и с тем же приоритетом, что и продуктовые задачи, — иначе они всегда проиграют.
Никто не проверяет. Простое правило: следующий разбор начинается с проверки действий предыдущего. Один вопрос вслух — и через месяц процент выполнения меняется радикально.
Полезно делить действия на два вида: чтобы не повторилось (устранить причину) и чтобы в следующий раз было легче (заметить раньше, восстановиться быстрее). Второй вид дешевле и часто ценнее: причин у аварий бесконечно много, а время обнаружения одно на все.
Дежурства, которые не выжигают команду
Дежурство — это обещание, что кто-то посмотрит на систему в нерабочее время. Оно быстро превращается в источник выгорания, если организовано без правил.
Дежурит команда, а не герой. Ротация по всем, включая лида. Единственный человек, который «всегда на связи, он же лучше всех знает», — это гарантированная потеря этого человека через год и полная остановка при его отпуске.
У дежурного нет плановых задач. Смена — это отдельная роль, а не нагрузка сверху. Иначе получается двойной проигрыш: и задачи сорваны, и на инциденты нет сил.
Каждый алерт ведёт к действию. Алерт без инструкции — это способ разбудить человека, который не знает, что делать. Если реакция на алерт — «посмотреть и ничего не сделать», алерт удаляют: он тренирует команду не реагировать.
Число ночных подъёмов — метрика системы, а не характер дежурного. Если за месяц было восемь подъёмов, это не «тяжёлый месяц», это счёт, предъявляемый вместе с техническим долгом в разговоре о приоритетах.
После тяжёлой ночи — выспаться, а не работать. Правило простое и требует явного разрешения от лида, иначе им никто не воспользуется.
Коротко
- Постмортем — документ, а не встреча: он живёт годами и работает при онбординге и в следующих разборах.
- Первая строка — что видел клиент; два ключевых интервала — до обнаружения и до восстановления.
- Безобвинительность — метод, а не мягкость: испуганный человек прячет детали, а детали и есть цель разбора.
- «Человеческая ошибка» — не причина, а место, где разбор остановился. Правильный вопрос: почему система это позволила и не заметила.
- «Почему» задают до изменения, которое можно внести; для крупных аварий считают все не сработавшие слои защиты.
- В плане действий два-три пункта с владельцем и сроком, заведённые в общий список задач; следующий разбор начинается с проверки предыдущего.
- Дежурит команда по ротации, у дежурного нет плановых задач, а каждый алерт ведёт к действию.
Что почитать дальше
- SLO и алерты — бюджет ошибок, скорость его сгорания и алерты, на которые есть смысл реагировать.
- Технический долг — как превратить счёт из ночных подъёмов в аргумент о приоритетах.
- Наблюдаемость: журналы — что должно быть в журнале, чтобы разбор занимал минуты, а не часы.