Все теперь используют AI для пост-мортемов. Pitch очевиден: пост-мортемы трудоёмки, чистый лист пугает, а AI хорошо производит структурированные, уверенно звучащие документы быстро.
Мы видели много вариантов «AI для пост-мортемов» — и в наших инструментах, и у клиентов. Они означают совершенно разные вещи. Стоит разобраться, что именно вы покупаете или строите.
Уровень 1: AI-ассист по черновику
AI заполняет timeline из чат-логов Slack и pager-уведомлений, предлагает summary в одно предложение и тегирует severity по упоминаниям в discussion.
Человек редактирует всё. AI экономит первые 30 минут «вспомнить, что вообще было».
Работает, потому что timeline-логи структурируемы, а саммаризация коротких текстов — сильная сторона LLM.
Trade-off: если в чате было много шума или OOC-обсуждений, AI выдёргивает шум как «важное событие». Редактор всё равно нужен.
Уровень 2: AI-предложение возможных причин и contributing factors
LLM получает timeline + метрики + diff-релиза за период и предлагает гипотезы: «возможные contributing factors: A, B, C». Каждая с подкреплением (ссылками на конкретные строки логов или коммиты).
Это полезно, если AI представляет гипотезы как вопросы для проверки, а не как ответы. Опасно, если команда воспринимает это как «AI сказал — значит так и есть».
Реальное правило: AI-сгенерированный root cause должен явно маркироваться. Лучше всего — поле «AI hypothesis (needs verification)» отдельно от поля «Root cause (confirmed)».
Уровень 3: Auto-generated entire document
Целый пост-мортем пишется AI: summary, timeline, root cause, impact, action items.
Здесь начинается интересное: документ выглядит хорошо. Структура правильная. Тон blameless. Action items звучат разумно.
И почти всегда — там есть как минимум одна неправда. AI придумывает детали, которых не было в источниках, потому что для коротких логов структура «нужно сказать что-то конкретное про root cause» подталкивает LLM к hallucination.
Есть команды, для которых это работает: они используют auto-generated draft как скелет, а потом 80% перепишут руками. Чистая экономия — 1 час из 4-х на сам процесс письма.
Есть команды, для которых это вредно: они принимают черновик как-есть после быстрого взгляда и публикуют. Через два спринта оказывается, что половина пост-мортемов содержит неправильные root cause, и решения принимались на основе фантомов.
Уровень 4: AI как continuous incident analyst
AI получает доступ к runbook-ам, прошлым пост-мортемам, monitoring-данным и кодовой базе. Когда происходит новый инцидент, он:
-
находит похожие прошлые инциденты;
-
показывает action items оттуда, которые не были закрыты;
-
предлагает изменения, основанные на исторических паттернах.
Это исследовательский фронтир. Прототипы есть, но операционно зрелые внедрения — редкость. Главная сложность — доверие: команда должна научиться валидировать рекомендации AI, иначе они или игнорируются, или принимаются вслепую.
Что мы рекомендуем
-
Начинайте с уровня 1. Низкий риск, реальная экономия времени.
-
Уровень 2 — с осторожностью. AI-гипотезы должны быть отделены от подтверждённых выводов в самом UI.
-
Уровень 3 — только если у вас есть процесс ревью. Иначе hallucinated root cause попадут в производственные решения.
-
Уровень 4 — экспериментируйте на pilot-командах. Это не «купить продукт» — это «построить процесс».
Главное
«Использовать AI для пост-мортемов» — слишком расплывчатая фраза, чтобы быть полезной. Уровень автоматизации меняет не только нагрузку на инженеров, но и распределение ответственности. На уровне 1 ответственность остаётся у людей. На уровне 3 — она диффундирует в инструмент, и в момент следующего инцидента похожего типа никто не сможет вспомнить, кто принял решение и на каких данных. Это другая проблема, чем «писать пост-мортем долго», и она реальнее.