Как писать постмортемы: шаблон и разбор хороших примеров

Постмортем — это не отчёт «кто виноват», а инструмент инженерного обучения после инцидента. Хороший постмортем объясняет, что случилось, как команда это заметила, почему защита не сработала раньше и какие изменения снизят риск повторения.

В SRE-подходе постмортем связывает инциденты с доступностью, SLO, алертами, процессами релиза и архитектурными решениями. Он помогает перейти от «сервер упал» к проверяемым фактам: какие сигналы изменились, какие зависимости отказали, где была задержка в обнаружении и восстановлении.

Ниже — практический шаблон постмортема, правила его написания и разбор примеров: от краткого сбоя сайта до сложной деградации API.

Что такое постмортем и зачем он нужен

Постмортем — это разбор инцидента после восстановления сервиса. Его цель — сохранить знания, которые появились во время расследования, и превратить их в конкретные улучшения.

Инцидентом может быть не только полный даунтайм. Постмортем стоит писать после деградации latency, всплеска 5xx, потери данных, ошибочного деплоя, истечения SSL-сертификата, отказа фоновой очереди, проблем с DNS или ситуации, когда пользователи заметили сбой раньше команды.

Хороший постмортем отвечает на четыре вопроса:

1) Что произошло — краткое описание влияния на пользователей и сервисы.

2) Как это обнаружили — алерт, обращение пользователя, мониторинг доступности, метрики, логи, статус внешнего провайдера.

3) Почему это произошло — не один «root cause», а цепочка технических и процессных факторов.

4) Что изменим — действия, владельцы, сроки и критерии готовности.

Без постмортемов команда быстро забывает детали. Через неделю остаются только общие формулировки: «были проблемы с базой», «релиз оказался неудачным», «Nginx отдал 502». Через месяц тот же класс ошибки повторяется, потому что выводы не были зафиксированы и доведены до изменений в системе.

Если вы только выстраиваете процесс реагирования, полезно начать с базового плана на случай падения сайта: что делать, если упал сайт. Постмортем начинается уже после тушения пожара, но качество разбора зависит от того, насколько аккуратно команда работала во время инцидента.

Когда постмортем обязателен, а когда достаточно короткой заметки

Не каждый сбой требует документа на десять страниц — формат должен соответствовать влиянию инцидента.

Полный постмортем нужен, если было одно из условий:

1) Пользовательское влияние — сайт или API были недоступны, часть функций не работала, пользователи видели ошибки, заказы не создавались, платежи не проходили.

2) Нарушение SLO или SLA — инцидент съел заметную часть error budget или повлиял на договорные обязательства. Если команда использует SLI, SLO и SLA, постмортем должен явно показывать, какие показатели пострадали. Подробнее о выборе таких показателей — в материале что такое SLI, SLO и SLA.

3) Долгое обнаружение — проблема существовала раньше, чем её заметили: мониторинг молчал, алерт был слишком шумным, проверка шла не из той точки или с неправильным интервалом.

4) Повторяемость — похожий сбой уже случался. Это почти всегда значит, что предыдущие выводы были недостаточными или задачи не довели до конца.

5) Потеря или повреждение данных — даже краткий инцидент с данными требует подробного разбора: восстановление, бэкапы, права доступа, идемпотентность, повторная обработка.

Короткой заметки достаточно, если влияние было минимальным: внутренний сервис кратко деградировал, пользователи не пострадали, причина очевидна, а исправление уже закрывает класс ошибки. Но даже она должна содержать время, влияние, причину и действие.

Практичное правило: если инцидент обсуждали в чате больше 20–30 минут, стоит оставить письменный след — не обязательно большой документ, но факты нужно зафиксировать.

Blameless-подход: без поиска виноватых, но с ответственностью

В SRE-культуре постмортем обычно делают blameless — без обвинений конкретных людей. Это не значит, что никто ни за что не отвечает: разбор ищет слабые места системы, а не удобного виновника.

Фраза «дежурный не заметил алерт» почти бесполезна. Лучше написать: «алерт пришёл в канал с высоким уровнем шума, не был продублирован в пейджер, runbook не указывал на срочность ситуации». Так появляется поле для улучшений: маршрутизация алертов, severity, эскалация, инструкции.

Плохая формулировка:

Инженер случайно выкатил неправильную конфигурацию, из-за этого сайт упал.

Хорошая формулировка:

В конфигурации nginx.conf было изменено правило проксирования для /api. Изменение прошло review, но в CI не было проверки маршрута /api/health, а canary-деплой не использовался. После применения конфигурации балансировщик начал отдавать 502 для части запросов.

Разница в том, что вторая версия показывает механизмы отказа: она не снимает ответственность с команды, но переводит обсуждение в инженерную плоскость.

Blameless-подход особенно важен для обнаружения скрытых причин. Если люди боятся наказания, они будут сглаживать детали: «наверное, случайность», «так совпало», «ничего страшного» — и документ станет политически безопасным, но технически бесполезным.

При этом постмортем не должен быть мягким. Если не было тестов, пишите «не было автоматической проверки». Если алерт сработал поздно, пишите «алерт сработал поздно». Если rollback занял 40 минут из-за ручных действий — пишите именно так.

Шаблон постмортема

Ниже — шаблон, который можно использовать как основу в Notion, Confluence, Git-репозитории или любой внутренней базе знаний. Он подробный для серьёзных инцидентов, но его можно сокращать.

1) Название — коротко и конкретно: «Деградация API заказов из-за исчерпания пула соединений PostgreSQL», а не «Проблема с API».

2) Дата и время — начало, обнаружение, начало работ, восстановление, полное закрытие. Всегда фиксируйте часовой пояс: 2026-04-18 14:05 MSK.

3) Статус документа — draft, review, final. Постмортем лучше публиковать быстро, даже если сначала это черновик.

4) Краткое резюме — 3–5 предложений: что произошло, сколько длилось, кого затронуло, как восстановили.

5) Влияние на пользователей — конкретно: какие страницы, API-методы, регионы, тарифы, клиенты или внутренние команды пострадали. Если точной оценки нет, пишите границы: «затронуты все пользователи веб-интерфейса», «ошибки наблюдались только в /checkout».

6) Детальная временная шкала — события по минутам: деплой, алерт, первые признаки, действия инженеров, rollback, восстановление, дополнительные проверки. Не редактируйте историю под красивый рассказ.

7) Что сработало хорошо — быстрый rollback, полезный дашборд, корректный алерт, готовый runbook, понятная коммуникация.

8) Что сработало плохо — позднее обнаружение, неполные логи, ручной доступ к продакшену, слишком общий алерт, отсутствие владельца сервиса.

9) Причины и способствующие факторы — техническая причина, архитектурные ограничения, пробелы в тестах, процессах, мониторинге и документации.

10) Обнаружение — кто или что первым заметило проблему: мониторинг доступности, метрики приложения, synthetic checks, жалобы пользователей или статус внешнего провайдера. Например, Statuser проверяет сайт с заданным интервалом и присылает уведомление о сбое — такой сигнал удобно включать во временную шкалу как независимый внешний источник.

11) Реакция и восстановление — что сделали для стабилизации: rollback, переключение трафика, увеличение лимитов, отключение feature flag, очистка очереди, восстановление из бэкапа.

12) Action items — список задач с владельцами, сроками и измеримым результатом. «Улучшить мониторинг» — плохая задача. «Добавить алерт на долю 5xx по /api/orders выше порога в течение 5 минут, владелец Иван, срок до 25 апреля» — хорошая.

13) Ссылки — дашборды, графики, логи, PR, релизы, алерты, тикеты, статус-страницы, переписка инцидентного канала.

Для небольших команд можно оставить шесть обязательных блоков: резюме, влияние, таймлайн, причина, восстановление, задачи. Остальное — по необходимости.

Как собрать факты до написания

Постмортем пишется не по памяти. Чем больше времени прошло после инцидента, тем сильнее искажается картина: кто-то помнит симптомы, кто-то — свой кусок расследования, кто-то — только финальное исправление.

Начните со сбора артефактов.

1) Метрики — latency, traffic, errors, saturation. Эти четыре сигнала часто дают каркас расследования: выросла ли задержка, изменился ли объём трафика, появились ли ошибки, был ли исчерпан ресурс. Разбор методики — в материале четыре золотых сигнала в мониторинге.

2) Логи — приложения, веб-сервера, балансировщика, базы данных, очередей, системные логи. Они нужны не только для поиска ошибки, но и для проверки гипотез: когда началось, какие пользователи пострадали, были ли ретраи, какие статусы возвращались.

3) Трассировки — особенно полезны для микросервисов: показывают, где запрос провёл время — API gateway, сервис авторизации, база, внешняя интеграция, очередь.

4) События инфраструктуры — деплои, перезапуски, изменения конфигурации, масштабирование, миграции, обновления пакетов, ротация сертификатов, изменения DNS.

5) Коммуникация — сообщения из инцидентного канала, тикеты поддержки, письма провайдера, уведомления мониторинга. Весь чат в документ вставлять не нужно, но ключевые решения стоит перенести в таймлайн.

6) Проверки доступности — внешний мониторинг помогает отделить локальную проблему от реального пользовательского влияния. Если Statuser фиксирует timeout или 5xx каждые несколько минут, эти события легко сопоставить с внутренними метриками и логами.

Если к моменту расследования всё уже работает, не ограничивайтесь фразой «не воспроизводится» — для таких случаев есть отдельный подход: как определить причину кратковременных сбоев, если всё уже работает.

Разбор хороших примеров постмортема

Ниже — три условных примера. Они не привязаны к конкретной компании, но показывают, чем хороший постмортем отличается от формального отчёта.

1) Сбой сайта после изменения Nginx

Плохое резюме:

После изменения конфигурации сайт временно не работал. Конфигурацию откатили.

Такой текст не объясняет влияние и не помогает предотвратить повторение.

Хорошее резюме:

12 мая с 11:14 до 11:32 MSK главная страница и часть страниц каталога возвращали 502 Bad Gateway для всех пользователей. Причиной стало изменение proxy_pass в конфигурации Nginx: запросы к upstream отправлялись на неверный порт. Ошибка не была поймана на этапе CI, потому что smoke-тест проверял только /health, который обслуживался локально. Восстановление выполнено rollback конфигурации и перезагрузкой Nginx.

Почему пример хороший: есть время, влияние, техническая причина, пробел в проверках и способ восстановления. Из него естественно следуют задачи: добавить smoke-тесты на пользовательские маршруты, валидировать upstream перед reload, внедрить canary для конфигурации reverse proxy.

2) Деградация API из-за пула соединений

Плохая причина:

База не справилась с нагрузкой.

Это слишком широко: база могла быть медленной из-за индексов, блокировок, I/O, сети, нехватки соединений или плохого запроса.

Хорошая причина:

После релиза 2026.05.3 сервис orders-api начал открывать отдельное соединение к PostgreSQL для каждого фонового воркера. При росте очереди число активных воркеров увеличилось, пул соединений был исчерпан, новые запросы ожидали свободного соединения до таймаута. Пользователи видели 504 в checkout. Алерт по CPU базы не сработал, потому что CPU оставался в норме; алерта на ожидание соединений не было.

Почему пример хороший: он показывает, что проблема была не просто «в базе», а в модели использования ресурса. Action items здесь — лимит воркеров, connection pooling, метрики ожидания соединений, нагрузочный тест для сценария роста очереди.

Если расследование упирается в метрики и непонятные корреляции, пригодится пошаговый подход из материала как расследовать деградацию производительности по метрикам.

3) Просроченный SSL-сертификат

Плохой вывод:

Нужно внимательнее следить за сертификатами.

Это пожелание, а не инженерное улучшение.

Хороший вывод:

Сертификат для api.example.com истёк в 03:00 MSK. Автообновление certbot было настроено только для www.example.com, потому что api.example.com добавили позже вручную. Мониторинг срока действия сертификата был включён для основного домена, но не для поддомена API. Пользователи мобильного приложения не могли подключиться к API из-за ошибки TLS.

Action items: добавить все публичные домены в inventory, включить мониторинг срока действия сертификатов, проверить auto-renew для каждого имени, добавить тест TLS handshake в synthetic monitoring.

Хороший постмортем в таком случае не ограничивается командой certbot renew: он показывает, почему домен выпал из процесса, и закрывает класс ошибки.

Частые ошибки в постмортемах

Постмортем может быть написан аккуратно, но всё равно не принести пользы — обычно проблема в одном из повторяющихся анти-паттернов.

1) Слишком много хронологии и мало выводов — таймлайн важен, но сам по себе он не улучшает систему. После временной шкалы должны быть причины, пробелы и задачи.

2) Один root cause вместо цепочки факторов — крупные инциденты редко происходят из-за одной причины. Обычно есть три слоя: технический дефект, отсутствие защиты и задержка обнаружения.

3) Размытые action items — «провести анализ», «улучшить стабильность», «добавить мониторинг» почти невозможно проверить. Каждая задача должна иметь владельца, срок и критерий завершения.

4) Отсутствие пользовательского влияния — инженерный разбор без ответа «что видели пользователи» неполон. Для бизнеса и поддержки важнее не то, какой под умер, а сколько времени нельзя было оформить заказ или открыть личный кабинет.

5) Сокрытие неудобных фактов — если rollback был невозможен из-за ручной миграции, это нужно написать. Если алерт проигнорировали из-за alert fatigue — тоже. Про настройку алертов без перегруза есть отдельный материал: как строить алерты, которые не раздражают.

6) Задачи не отслеживаются после публикации — постмортем без follow-up быстро превращается в архив. Назначьте владельца, который проверит выполнение задач через неделю или месяц.

7) Документ пишется слишком поздно — если начать через две недели, детали будут потеряны. Черновик лучше создать в день инцидента, даже если финальная причина ещё неизвестна.

Как внедрить постмортемы в команде

Чтобы постмортемы прижились, их нужно сделать частью процесса, а не разовым усилием после редкого крупного сбоя.

1) Заведите единый шаблон — команда не должна каждый раз думать, с чего начать. Шаблон снижает порог входа и делает документы сравнимыми.

2) Определите критерии — заранее договоритесь, какие инциденты требуют полного разбора (см. раздел выше), а какие можно закрыть короткой заметкой.

3) Назначайте владельца — не обязательно человека, который «виноват». Он отвечает за сбор фактов, проведение разбора, публикацию и follow-up по задачам.

4) Проводите разбор быстро — оптимально в течение 1–3 рабочих дней, пока детали ещё свежие.

5) Делайте документы доступными — постмортемы должны читать разработчики, DevOps, поддержка, продуктовые менеджеры и руководство. Если есть внешняя статус-страница, публичную версию можно подготовить отдельно. О роли таких страниц — в статье что такое статус-страница сервиса.

6) Связывайте выводы с мониторингом — почти каждый инцидент должен улучшать наблюдаемость: новый алерт, дашборд, synthetic check, уточнение порогов, изменение интервала проверки. Но не добавляйте алерт ради галочки: он должен требовать действия.

7) Проверяйте выполнение задач — раз в спринт или месяц просматривайте открытые action items по инцидентам. Если задачи постоянно переносятся, значит команда формально пишет постмортемы, но не использует их для снижения риска.

Хороший итог постмортема — не красивый документ, а изменение системы: быстрее обнаруживаем, точнее диагностируем, безопаснее выкатываем, проще откатываем, меньше зависим от ручной памяти конкретного инженера.

FAQ

Нужно ли писать постмортем, если пользователи ничего не заметили?

Да, если инцидент мог затронуть пользователей или показал слабое место системы. Near miss часто полезнее реального сбоя: он даёт шанс исправить проблему до влияния на бизнес.

Кто должен писать постмортем?

Обычно владелец инцидента или дежурный инженер, который координировал восстановление. Но документ должен проходить review у участников расследования: разработчиков, DevOps, SRE, поддержки.

Можно ли публиковать постмортем наружу?

Да, если инцидент затронул клиентов и компания готова к прозрачной коммуникации. Публичная версия должна объяснять влияние, причину и меры, но не раскрывать чувствительные детали инфраструктуры.

Чем постмортем отличается от RCA?

RCA обычно фокусируется на root cause analysis — поиске причины. Постмортем шире: он включает влияние, таймлайн, обнаружение, восстановление, коммуникацию, что сработало хорошо и какие изменения будут сделаны.