Postmortem и база знаний: как не потерять урок инцидента

После инцидента команда пишет postmortem — и часто он остаётся в Confluence или Google Docs, откуда RAG на следующем алерте его не находит. Если база знаний не обновляется, дежурный снова ищет ответ с нуля. Ниже — минимальный цикл: инцидент → документ → индекс → проверка в чате.

Почему postmortem «не доезжает» до RAG

• Документ лежит вне каталога, который загружен в Adminica.
• Runbook устарел, а postmortem описывает новые шаги — в поиске побеждает старая версия.
• Текст написан для людей (нарратив), без заголовков и чек-листа — чанкинг режет смысл.
• Нет владельца: postmortem закрыт в тикете, в библиотеку никто не перенёс.

Минимальный цикл после инцидента

1. Шаблон postmortem — разделы: что случилось, root cause, timeline, что сработало / нет, action items.
2. Выделить runbook-delta — 5–10 пунктов «что делать при X» отдельным блоком или новой записью в библиотеке.
3. Загрузить в архив — Markdown/PDF через админку или библиотеку; дождаться обновления поискового индекса.
4. Проверка в чате — задать тот же вопрос, что был у дежурного: ответ должен цитировать новый фрагмент.
5. Связи в графе — привязать postmortem к сервису и старому runbook (depends_on), чтобы в UI чата были «связанные записи».

Что писать, чтобы RAG находил ответ

Структура документов для RAG — в подготовке документов; частота переиндексации — как часто переиндексировать.

Связка с дежурством

На время инцидента дежурный использует чат по runbook (ответ за минуту). После закрытия инцидента владелец сервиса за 48 часов обновляет библиотеку — иначе следующий дежурный получит старый ответ. Метрика зрелости: «время от postmortem до первого успешного golden-вопроса по этой теме».

Итог: postmortem ценен только когда его уроки попали в индексируемую базу и проверены запросом в RAG-чате. Иначе команда платит за один и тот же инцидент дважды.