После крупной аварии в команде обычно происходит одно из двух. Либо ищут, кто выкатил, — и тогда в следующий раз о проблеме узнают позже и от клиентов. Либо не разбирают вообще — «починили, поехали дальше», — и через месяц та же авария повторяется в соседнем сервисе.
Разбор аварии — это не ритуал и не наказание. Это единственный момент, когда система показывает свои настоящие слабые места бесплатно: платить за это знание вы уже закончили.
Где именно разбор остановится — там и окажется план действий.
Третье «почему» даёт действие «исправить фоновую задачу» — и та же утечка вернётся в соседнем сервисе. Пятое доходит до отсутствующих нормы на размер изменения и проверки на утечку: два пункта закрывают слой защиты сразу для всех задач.
Что разбирать, а что нет
Правило «разбирать аварии» без уточнения даёт одну из двух крайностей: либо разбирают всё и через месяц перестают, потому что это превращается в поток документов, либо не разбирают ничего, потому что каждый раз кажется, что случай мелкий. Поэтому первое, что заводят, — шкала тяжести, и она же определяет, кто участвует.
Рабочий вариант из четырёх ступеней, который подходит почти любой команде:
| Уровень | Что это | Что делаем |
|---|---|---|
| 1 — критическая | Сервис недоступен для всех или потеряны деньги и данные | Письменный разбор обязателен, встреча со всеми участниками, срок — три рабочих дня |
| 2 — серьёзная | Заметная часть пользователей или ключевая операция, обошлись без потери данных | Письменный разбор обязателен, встреча по желанию, срок — неделя |
| 3 — умеренная | Деградация, запасной путь сработал, пользователи почти не заметили | Короткая запись в общий журнал: что было, что сделали, нужны ли действия |
| 4 — мелкая | Сработала тревога, дежурный поправил за минуты, следов у пользователей нет | Строка в журнале дежурства, разбор только если повторяется |
Что делает эту шкалу работающей, а не формальной:
Уровень назначают по факту, а не по ощущению. Опорные вопросы: сколько пользователей затронуто, сколько это длилось, были ли потеряны данные, пришлось ли объясняться с клиентами. Назначает дежурный или владелец выпуска, и повысить уровень может кто угодно — это дешевле, чем спорить.
Повторяемость повышает уровень. Третья «мелкая» авария того же вида за месяц — это уровень 2, потому что мелкой оказалась не проблема, а каждый отдельный её случай. Это единственный способ поймать вялотекущие вещи, которые по отдельности не тянут на разбор.
У уровней 3 и 4 есть журнал. Простая таблица или канал, где строкой пишут: дата, что было, что сделали. Без него мелкие случаи не складываются в картину, и повторяемость никто не замечает. Просматривают этот журнал раз в две недели — и оттуда регулярно вылезает тема для нормального разбора.
Разбор без аварии — тоже уровень. Об этом ниже: «чуть не уронили» стоит разбирать, хотя в шкале его нет.
И граница, которую стоит держать: шкала существует, чтобы уменьшить число письменных разборов до тех, что действительно окупаются. Если по шкале выходит четыре письменных разбора в месяц, шкала настроена неверно или у системы проблема серьёзнее, чем процесс разбора.
Постмортем — это документ, а не встреча
Встреча без документа заканчивается ощущениями. Документ работает годами: его читают, когда в команду приходит новый человек, на него ссылаются в следующем разборе, по нему видно, что действительно изменилось.
Рабочая структура постмортема — пять частей.
Что видел клиент. Не «упал сервис заказов», а «с 14:05 до 15:20 покупатели не могли оформить заказ, 4 300 попыток завершились ошибкой». Это первая строка, потому что она задаёт масштаб: без неё разбор скатывается в обсуждение технической детали.
Хронология. Сухая линия времени: когда началось, когда заметили, кто что делал, когда стало лучше. Два интервала в ней важнее остальных — от начала до обнаружения и от обнаружения до восстановления. Первый лечится наблюдаемостью, второй — инструментами и инструкциями.
Причина. Не одна, а цепочка. Ниже про то, как её искать.
Что помогло и что мешало. Честно: сработал алерт или позвонил менеджер; нашли по журналам или гадали; была инструкция или собирали знание на ходу. Это самая полезная часть для следующего раза.
Действия. Список с ответственным и сроком. Про него отдельно ниже, потому что именно здесь постмортемы обычно и умирают.
Как это выглядит
Пять частей проще показать, чем описать. Вот сокращённый документ целиком — по нему видно и уровень детализации, и то, чего в нём быть не должно.
Авария 2026-09-18: не оформлялись заказы (уровень 1)
Что видел клиент
С 14:05 до 15:20 (75 минут) покупатели не могли оформить заказ:
4 300 попыток завершились ошибкой 500. Оплаты не проводились,
деньги не списывались. Данные не потеряны.
Хронология (время московское)
13:58 выкат сервиса заказов, версия 2.41.0 (штатный, через конвейер)
14:05 первые ошибки 500 на оформлении; тревога не сработала
14:19 сообщение от поддержки: жалобы клиентов
14:22 дежурный начал разбор, открыл экран сервиса
14:31 видно: пул соединений к базе исчерпан, 100 из 100 занято
14:44 найдена фоновая задача, открывающая соединение на строку
14:52 задача остановлена вручную; часть заказов начала проходить
15:08 выкат версии 2.41.1 с исправлением
15:20 доля ошибок вернулась к обычной; авария закрыта
Время до обнаружения: 14 минут. Время до восстановления: 75 минут.
Причина
Фоновая задача переноса адресов открывала соединение на каждую
строку и не закрывала его. За 7 минут заняла весь пул; запросы
пользователей не получали соединение и падали по таймауту.
Цепочка: нет ограничения на размер изменения -> кусок не рассмотрен
на ревью -> нет проверки на утечку соединений -> нет тревоги на
исчерпание пула -> обнаружили по жалобам клиентов.
Что помогло и что мешало
Помогло: экран сервиса показал пул сразу, без поиска по графикам.
Мешало: тревоги на пул нет — 14 минут потеряны. Инструкции по
исчерпанию пула нет, дежурный искал причину по памяти.
Мешало: откат не помог бы — задача уже работала, нужен был стоп.
Действия
1. Тревога на занятость пула > 80% на 2 минуты — Иванова, до 22.09
2. Проверка в конвейере: закрытие соединений в фоновых задачах —
Петров, до 26.09
3. Инструкция «исчерпан пул соединений» — дежурный текущей смены,
до 22.09
Что стоит заметить в этом примере. В хронологии — только факты с временем, без объяснений: объяснения живут в разделе про причину. Два интервала посчитаны и записаны отдельной строкой, потому что их сравнивают между авариями.
В причине — цепочка, а не одно предложение, и каждое звено цепочки превратилось или не превратилось в действие. В «что мешало» попало то, чего не хватило дежурному, — это самая ценная часть для следующего раза и самая часто пропускаемая. Имён нет нигде, кроме списка действий. И действий три, а не пятнадцать.
Такой документ пишут за сорок минут по свежей памяти, и главное — сразу: через неделю хронология восстанавливается по журналам вдвое дольше и с потерями.
Почему разбор безобвинительный — и что это значит на практике
Формулировка «человеческая ошибка» — это место, где разбор останавливается, не начавшись. Инженер выкатил ночью без проверки, удалил не ту таблицу, промахнулся окружением. Дальше следует выговор, и все расходятся с чувством, что проблема решена.
Она не решена. Вопрос, на который стоит ответить, звучит иначе: почему система позволила одному человеку это сделать и не заметила. Почему выкат не требовал подтверждения. Почему боевая база доступна с рабочего места. Почему одинаковые окружения различались одной буквой в имени.
Безобвинительность здесь — не мягкость к людям, а метод. Он держится на простом наблюдении: человек, который боится, скрывает детали. А детали — это ровно то, ради чего вы собрались.
Практические следствия для лида:
- В документе нет имён — есть роли: «дежурный», «автор изменения». Имена нужны только в списке действий, где кто-то отвечает за исправление.
- Первым говорит тот, кто был у руля, и говорит про факты, а не про оправдания. Задача ведущего — не дать разговору свернуть в «надо было быть внимательнее».
- Слово «надо было» — стоп-сигнал. Оно всегда обращено в прошлое и никогда не превращается в изменение системы.
- Ответственность за результат остаётся. Безобвинительный разбор не отменяет разговора с человеком, который систематически нарушает договорённости, — просто это другой разговор, в другое время и один на один.
Кто что делает во время аварии
Хронология в документе показывает, что делали, и не отвечает на вопрос, который решается заранее: кто за что отвечает, пока авария идёт. Без этого получается знакомая картина — пять человек в одном канале чинят одно и то же, никто не разговаривает с бизнесом, а решение об откате принимает тот, кто громче.
Роли на время инцидента, и их всего три:
Ведущий. Не чинит. Его работа — держать картину: что известно, что проверяем, кто чем занят, какое следующее решение. Он же объявляет уровень, решает об эскалации и следит, чтобы не чинили вслепую вдвоём. В маленькой команде это дежурный, но как только в разборе участвуют больше двух человек, ведущего выделяют отдельно — и это самое дешёвое улучшение процесса из всех.
Исполнители. Те, кто смотрит и правит. Правило одно: говорить, что делаешь, в канал, до того как сделать. «Перезапускаю реплику» — не «перезапустил реплику». Иначе два человека одновременно чинят разными способами, и понять, что помогло, невозможно.
Связь. Тот, кто разговаривает с внешним миром: отвечает поддержке, обновляет страницу состояния, докладывает руководству. Без этой роли ведущий отвечает на вопросы вместо того, чтобы вести, а это мгновенно удлиняет аварию. В небольшой команде роль берёт руководитель или менеджер продукта — ему для этого не нужно понимать причину, нужен доступ к ведущему.
Кто решает об откате. Ответ должен быть записан до аварии, потому что в аварии его искать некогда: решение принимает ведущий (или дежурный, если ведущего не выделяли), не собирая совещание и не дожидаясь автора изменения. Это решение по своей природе не требует консенсуса: откат почти всегда дешевле разбирательства, а разобраться можно после. Исключения — когда откат невозможен или опасен (схема данных уехала вперёд), и тогда ведущий объявляет «катим вперёд» и говорит, кто делает исправление.
Что пишут наружу. Три вещи, и только они: что не работает для пользователя, с какого времени, когда будет следующее сообщение. Ни причин, ни обещаний срока, ни технических подробностей — всё это меняется по ходу и создаёт обещания, которые потом нарушаются.
Следующее сообщение — даже если ничего не изменилось: тишина воспринимается хуже, чем «всё ещё разбираемся». И отдельно стоит договориться, кто имеет право писать наружу: в аварии сообщение от инженера в общий чат с догадкой о причине живёт дольше, чем сама авария.
Канал инцидента. Отдельный канал или ветка на каждую аварию, создаётся первым же действием. Смысл двойной: во время аварии — все в одном месте, а не в пяти личных переписках; после — это и есть черновик хронологии, из которого документ собирается за полчаса вместо вечера. Полезная привычка: писать в него время рядом с каждым важным наблюдением, даже если система ставит отметки сама.
Как искать причину: пять «почему» и цепочка защит
Самый простой рабочий приём — задавать «почему» до тех пор, пока ответ не превратится в то, что можно изменить.
Заказы не оформлялись. Почему? Сервис заказов не отвечал. Почему? Кончились соединения к базе. Почему? Фоновая задача открывала соединение на каждую строку и не закрывала. Почему? Ошибка прошла ревью — в изменении было 900 строк, и этот кусок не рассмотрели. Почему? Нет ни ограничения на размер изменения, ни проверки на утечку соединений.
Смотрите, что произошло: начали с «сервис лежал», закончили двумя конкретными изменениями — норма на размер изменения и автоматическая проверка. Если бы остановились на третьем «почему», действием стало бы «исправить фоновую задачу» — и та же ошибка вернулась бы в другом месте.
Обратите внимание, что эти два изменения — из разных мест: одно про то, как люди смотрят изменение, другое про то, что проверяет машина после них. Это и есть переход к следующему приёму.
Второй приём полезен для крупных аварий: посчитать слои защиты, которые не сработали. Обычно авария проходит через несколько: ревью не заметило, тесты не покрыли, выкат не был поэтапным, наблюдаемость не показала, алерт не сработал, откат оказался долгим. Каждый не сработавший слой — отдельный кандидат в план действий, и часто дешевле починить второй или третий слой, а не первый.
Авария проходит насквозь все шесть слоёв защиты; в план действий берут не первый слой, а самый дешёвый.
План действий: где постмортемы умирают
Раздел «действия» есть почти в каждом постмортеме. А через квартал выясняется, что сделана в лучшем случае часть, и причины всегда одни и те же.
Слишком много пунктов. Пятнадцать действий после одной аварии — это способ не сделать ни одного. Оставьте два-три: те, что закрывают самый дешёвый слой защиты.
Пункты без владельца и срока. «Улучшить мониторинг» не выполнит никто. «Добавить алерт на исчерпание пула соединений, ответственный такой-то, до пятницы» — выполнимо.
Пункты вне обычного потока работы. Если действия не попали в тот же список задач, что и вся остальная работа, они живут только в документе. Заводите их сразу и с тем же приоритетом, что и продуктовые задачи, — иначе они всегда проиграют.
Никто не проверяет. Простое правило: следующий разбор начинается с проверки действий предыдущего. Один вопрос вслух — и через месяц процент выполнения меняется радикально.
Полезно делить действия на два вида: чтобы не повторилось (устранить причину) и чтобы в следующий раз было легче (заметить раньше, восстановиться быстрее). Второй вид дешевле и часто ценнее: причин у аварий бесконечно много, а время обнаружения одно на все.
Два интервала, которые сравнивают между авариями: первый лечится наблюдаемостью, второй инструментами и инструкциями.
Разбирать то, что не случилось
Самый дешёвый источник тех же знаний — случаи, когда авария не произошла. Платить за них не пришлось, а слабое место они показывают так же ясно.
Близкие промахи. «Чуть не уронили»: удалили не ту таблицу на стенде, который оказался почти как прод; выкатили в прод неверную настройку и откатили через минуту, пока никто не заметил; заметили в ревью строку, которая обрушила бы базу. Такие случаи разбирают короткой записью в том же журнале, что уровни 3 и 4, и вопрос задают ровно тот же: почему система это позволила. Ценность в том, что здесь нет ни давления, ни ущерба, ни спешки — то есть разбор получается спокойнее и честнее, чем после настоящей аварии.
Главное препятствие — о них не рассказывают: человек, который чуть не уронил прод, не имеет никакого стимула это афишировать. Лечится это только примером: лид рассказывает о своих, и рассказывает буднично. Как только в журнале появляется несколько таких записей от разных людей, поток становится постоянным.
Успешные откаты. Выкат оказался плохим, откатились за две минуты, пользователи не заметили — казалось бы, разбирать нечего. А разобрать стоит одну вещь: что позволило заметить и откатиться так быстро. Это ровно тот механизм, который вы захотите иметь в следующий раз, и полезно понимать, был он или повезло.
Учения. Самый недооценённый приём: сломать что-нибудь специально, в рабочее время, с готовностью вернуть. Погасить одну копию сервиса, отключить кеш, задержать ответы внешнего провайдера, переключить базу на резервную копию. Разбирают учение так же, как аварию, и находки получаются те же — с той разницей, что вы выбрали время, объём и участников. Начинают с самого дешёвого (одна копия, один запасной путь) в тестовом контуре, и только потом обсуждают учения в проде.
Ревизия старых разборов. Раз в полгода перечитать разборы за период и задать два вопроса: какие причины повторяются (одна и та же слабость в разных обёртках — это тема для отдельной работы, а не для очередного пункта плана) и какие действия из прошлых разборов оказались бесполезными. Второе важно: план действий, который не помог, — это тоже находка, и она удерживает от повторения того же рецепта.
Общее правило у всех четырёх приёмов одно: знание о слабом месте не обязано стоить аварии. Команда, которая разбирает только настоящие аварии, платит за каждый урок полную цену.
Глубже: два интервала, которые считают по всем авариямрасширенное
Раз второй вид действий — про «заметить раньше и восстановиться быстрее», у этого должны быть числа, иначе непонятно, работают ли действия. Числа — те самые два интервала из хронологии, и считают их по каждой аварии:
Время до обнаружения — от начала проблемы до момента, когда о ней узнали. Здесь важна ещё одна пометка: узнали сами (тревога) или от людей (поддержка, клиент, руководитель). Доля аварий, о которых узнали от людей, — самая честная оценка мониторинга, и она обычно неприятно высока в начале.
Время до восстановления — от обнаружения до возврата к нормальной работе. Внутри него полезно выделять третий интервал — время до диагноза: если из семидесяти пяти минут шестьдесят ушло на «понять, где сломалось», работать надо с наблюдаемостью, а не с процедурами выката.
Как этим пользоваться, чтобы не превратить в отчётность:
- Смотрят медиану и выбросы за квартал, а не отдельную аварию: одна авария ничего не говорит, десять — говорят про систему.
- Разбирают выбросы, а не среднее: та авария, где до обнаружения прошло два часа, содержит больше информации, чем все остальные вместе.
- Не сравнивают команды и не ставят целью. Обе величины зависят от природы аварий, и как цель они превращаются в соблазн закрывать инциденты побыстрее и занижать уровень.
- Показывают бизнесу вместе с числом аварий. «Обнаружение упало с 40 минут до 6 за квартал» — единственная форма, в которой работа над наблюдаемостью выглядит как результат, а не как расход.
Третье число, которое стоит считать рядом: доля выполненных действий из предыдущих разборов. Если она ниже половины, дело не в наблюдаемости и не в людях — план действий не попадает в обычный поток работы, и чинить надо это.
Глубже: дежурства, которые не выжигают командурасширенное
Дежурство — это обещание, что кто-то посмотрит на систему в нерабочее время. Оно быстро превращается в источник выгорания, если организовано без правил.
Дежурит команда, а не герой. Ротация по всем, включая лида. Единственный человек, который «всегда на связи, он же лучше всех знает», — это гарантированная потеря этого человека через год и полная остановка при его отпуске.
У дежурного нет плановых задач. Смена — это отдельная роль, а не нагрузка сверху. Иначе получается двойной проигрыш: и задачи сорваны, и на инциденты нет сил.
Каждый алерт ведёт к действию. Алерт без инструкции — это способ разбудить человека, который не знает, что делать. Если реакция на алерт — «посмотреть и ничего не сделать», алерт удаляют: он тренирует команду не реагировать. Как строить алерты от бюджета ошибок и с инструкцией в каждом, разобрано в статье про SLO и алерты (Java, Go, Node, Python).
Число ночных подъёмов — метрика системы, а не характер дежурного. Если за месяц было восемь подъёмов, это не «тяжёлый месяц», это счёт, предъявляемый вместе с техническим долгом в разговоре о приоритетах.
После тяжёлой ночи — выспаться, а не работать. Правило простое и требует явного разрешения от лида, иначе им никто не воспользуется.
Три вещи, без которых эти правила остаются пожеланиями.
Передача смены. Дежурство заканчивается не «по календарю», а разговором на десять минут: что происходило, что осталось незакрытым, за чем стоит присмотреть, какие тревоги шумят и почему. Без передачи новый дежурный в первую ночь встречает тревогу, про которую предыдущий уже знает, что она ложная, — и тратит час. Форма простая: короткая запись в канале дежурства по одному шаблону («смена такая-то: было / осталось / присмотреть»), и она же становится тем журналом, из которого потом видна повторяемость.
Тревога из чужой зоны. Разбудило то, чего дежурный не знает — чужой сервис, чужая база, чужая интеграция. Правило на этот случай записывают заранее, иначе в три ночи человек либо лезет в незнакомое, либо не делает ничего: дежурный не чинит чужое, он передаёт.
Его работа — оценить, что видит пользователь, и позвать того, кто отвечает; для этого нужен список владельцев с контактами, доступный из канала дежурства, и договорённость, что звонок по этому списку в три ночи — нормально. Если владельца нет вовсе, это находка: сервис без владельца всплывает ровно в такие моменты.
Компенсация. Дежурство — работа в нерабочее время, и у неё должна быть цена, иначе ротация превращается в тихое сопротивление. Варианты, из которых выбирают: доплата за смену, отгул за ночной подъём (не за смену, а именно за подъём), сокращённый день после тяжёлой ночи.
Что именно — вопрос компании, а вот что не работает: «это часть работы старшего инженера» и «мы же редко дёргаем». Практический минимум, который лид может ввести своей властью без бюджета: подъём ночью = сдвиг начала следующего дня, и это правило объявляют явно, а не оставляют на усмотрение.
И одна формулировка, которая помогает в разговоре с руководством: дежурство — это страховка от простоя, и её цена сравнивается не с зарплатой, а со стоимостью часа недоступности. В этой рамке расходы на компенсацию перестают выглядеть льготой.
Коротко
- Постмортем — документ, а не встреча: он живёт годами и работает, когда в команду приходит новый человек и когда случается следующий разбор. Первая строка — что видел клиент; два ключевых интервала — до обнаружения и до восстановления.
- Безобвинительность — метод, а не мягкость: испуганный человек прячет детали, а детали и есть цель разбора. «Человеческая ошибка» — не причина, а место, где разбор остановился. Правильный вопрос: почему система это позволила и не заметила.
- «Почему» задают до изменения, которое можно внести; для крупных аварий считают все не сработавшие слои защиты.
- В плане действий два-три пункта с владельцем и сроком, заведённые в общий список задач; следующий разбор начинается с проверки предыдущего.
- Дежурит команда по ротации, у дежурного нет плановых задач, а каждый алерт ведёт к действию.
- Шкала тяжести из четырёх уровней решает, что разбирают письменно, а что строкой в журнале; повторяемость повышает уровень, повысить его может кто угодно.
- Во время аварии три роли: ведущий (не чинит), исполнители (говорят, что делают, до того как сделали) и связь с внешним миром; решение об откате принимает ведущий без совещания.
- Время до обнаружения и до восстановления считают по всем авариям, отмечая, узнали сами или от людей; смотрят медиану и выбросы за квартал, не сравнивая команды и не делая целью.
- Знание о слабом месте не обязано стоить аварии: разбирают близкие промахи, удачные откаты, учения и раз в полгода перечитывают старые разборы.
- Дежурство держится на передаче смены, правиле «чужое не чиню, а передаю» со списком владельцев и явной компенсации за ночной подъём.
Что почитать дальше
- SLO и алерты (Java, Go, Node, Python) — бюджет ошибок, скорость его сгорания и алерты, на которые есть смысл реагировать.
- Технический долг — как превратить счёт из ночных подъёмов в аргумент о приоритетах.
- Наблюдаемость: журналы (Java, Go, Node, Python) — что должно быть в журнале, чтобы разбор занимал минуты, а не часы.