Инцидент закрыт, канал заархивирован, черновик постмортема уже написан — не дежурным, а моделью, которая прочитала timeline, переписку в Slack и данные расследования. Так это работает у incident.io: шаблон задаёт, какие секции доверены AI, документ живёт в статусах In progress → In review → Completed.
Вендорский слой под этим подвижен. Jeli уходит в end of life 22 декабря 2026, разбор инцидентов переезжает в Post-Incident Reviews внутри веб-интерфейса PagerDuty — пока в статусе Early Access. FireHydrant куплен Freshworks и складывается в их ServiceOps. Шаблон переживёт эту перестановку, и он же решает, что достанется агенту, а что придётся написать человеку.
Поля делятся на два класса
Часть постмортема выводима из систем. Timeline собирается из алертов, деплоев и сообщений в канале. Detection — из времени срабатывания алерта. Impact считается по метрикам и статус-странице. Resolution виден по действию, которое остановило деградацию. Всё это модель достаёт без участия человека и делает это аккуратнее уставшего дежурного в три часа ночи.
Другая часть не выводима ниоткуда. Почему решение выглядело правильным в тот момент. Какую информацию видел человек, когда его принимал. Что чуть не пошло хуже, но не пошло.
| Поле | Откуда берётся | Кто заполняет |
|---|---|---|
| Timeline, Detection, Impact, Resolution | алерты, деплои, метрики, канал | агент |
| Root Causes, Trigger | гипотезы плюс подтверждение в данных | человек, агент помогает |
| Where we got lucky, Lessons Learned | голова участника | только человек |
| Action Items | решение команды | только человек |
Ценность инженера в постмортеме сместилась вниз этой таблицы. Верхние строки автоматизируются, нижние — нет, и именно они делают документ полезным через полгода.
Два поля, которые чаще всего теряют
Популярный каркас «пять вопросов» — что случилось, почему, каков импакт, как реагировали, как предотвратим — короче канонического шаблона из SRE Book на три поля. Два из них стоит вернуть.
Trigger отдельно от Root Causes. Триггер — что запустило («деплой v2.3.0 в 14:18»). Причина — почему система оказалась к этому уязвима («миграция без индекса проходит ревью, потому что чеклист DB-изменений в репозитории не используется»). Слепив их в одно поле, вы получаете базу, где инциденты совпадают по триггеру и расходятся по механизму. Поиск похожих случаев — хоть агентом, хоть глазами — начинает выдавать шум.
Where we got lucky. Единственное место, где фиксируются риски, не выстрелившие в этот раз: таблица была почти пустой, инцидент попал в дневной трафик, второй регион не задело случайно. Это не наблюдаемые события — их некому записать, кроме участника. Строчка отсюда обычно стоит трёх пунктов из Lessons Learned.
Скелет
Date / Authors / Status — метаданные, ставит система
Summary — 3-5 строк для тех, кто не читал канал
Impact — пользователи, минуты, деньги
Root Causes — почему система была уязвима
Trigger — что запустило, отдельным полем
Resolution — что остановило деградацию
Detection — как узнали и через сколько
Action Items — owner + дедлайн, по одной строке
Lessons Learned
What went well
What went wrong
Where we got lucky — не пропускать
Timeline — UTC, факты без интерпретации
Supporting information — графики, запросы, ссылки на PRТринадцать секций для SEV3 выглядят избыточно — половина закрывается одной строкой. Пустой заголовок честнее отсутствующего: он показывает, что вопрос задавали.
Когда постмортем обязателен
Канон формулирует триггеры порогами, а не severity-шкалой: видимый пользователю простой или деградация выше порога, потеря данных любого объёма, вмешательство дежурного вроде отката релиза или перенаправления трафика, время разрешения выше порога, отказ мониторинга. Плюс право любого стейкхолдера запросить разбор.
Матрица «SEV1/SEV2 — обязательно» — локальная надстройка над этим списком, удобная, если severity уже определена строгими критериями, а не ощущением дежурного. Порог по сожжённому error budget добавляют туда же — цифра берётся из вашей политики, канон её не задаёт.
Где умирают action items
Пункт без владельца-человека и даты — не действие, а формулировка сожаления. Команда владельцем быть не может: ответственных нет, когда их несколько. Автоматическое создание тикетов из шаблона снимает единственный шаг, на котором постмортем обрывается, — перенос решений в трекер.
Отдельный сигнал — повторяющиеся разборы одного класса. Три постмортема с одинаковой причиной означают, что проблема не в знаниях, а в отсутствии автоматизации, и дальше это считается как toil.
Что не автоматизируется
Модель воспроизведёт разметку, соберёт хронологию и предложит формулировку причины. Она не создаст условий, в которых человек напишет «я не понял алерт» вместо «алерт был неочевиден».
У blameless есть и машинное следствие. «Bob удалил таблицу» не даёт агенту ничего: имя не признак. «Система позволила удалить таблицу одной командой без подтверждения» — описание механизма, по которому находится следующий такой же случай. Обвинительный постмортем плох не только для культуры, он ещё и бесполезен как данные.