Шаблон разбора инцидента в агентных системах¶

Этот шаблон нужен не для красивого документа, а для того, чтобы разбор инцидента заканчивался конкретными корректирующими действиями, обновлениями артефактов жизненного цикла и изменениями в дисциплине оценивания.

Используй его после этапа сдерживания, когда трассы, подтверждения, данные поэтапного выпуска и активный набор артефактов уже восстановлены.

1. Краткое описание¶

incident_id:
Дата и время:
Уровень серьезности:
Статус:
Владелец:
Краткое резюме инцидента:

2. Что произошло¶

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

Главная цель этого блока: коротко и без интерпретаций зафиксировать саму цепочку события.

3. Какие артефакты были активны¶

trace_id:
session_id:
bundle_id:
change_id:
rollout_wave:
policy_bundle:
approval_mode:
tool_principal:

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

4. Действия сдерживания¶

Какие действия были предприняты в первые минуты:
Что именно было отключено, ограничено или переведено в ограниченный режим:
Требовался ли откат:
Были ли отозваны субъекты, соединители или возможности:

Здесь полезно различать:

временное сдерживание;
постоянное исправление.

5. Первопричина¶

Какая непосредственная причина инцидента:
Какие сопутствующие факторы усилили проблему:
Какой шлюз, проверка или предположение не сработали:
Была ли проблема в политике, подтверждениях, поэтапном выпуске, памяти, наблюдаемости или инвентаре:

Этот блок должен вести к системному объяснению, а не к формуле "модель ошиблась".

6. Что не сработало в слое управления¶

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

Здесь важно описывать не только ошибку, но и отсутствие нужного защитного ограничения.

7. Зона воздействия¶

Какие пользователи, системы или данные были затронуты:
Был ли доступ к внешним системам:
Были ли затронуты записи памяти:
Это единичный запуск или повторяющийся рисунок поведения в волне поэтапного выпуска / семье сессий:

8. Корректирующие действия¶

Для каждого действия полезно указать:

действие;
владелец;
срок;
какой артефакт обновляется.

Минимальные типы корректирующих действий обычно такие:

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

9. Что меняется в артефактах жизненного цикла¶

Новый change_id, если нужен корректирующий выпуск:
Новый bundle_id, если меняется конфигурация выпуска:
Нужен ли новый retirement_plan:
Нужно ли обновить реестр или инвентарь:
Нужно ли обновить классификацию инцидентов или правила разбора:

Этот блок полезен, потому что связывает разбор инцидента с управляемыми артефактами, а не только с задачами в трекере.

10. Что меняется в оценках и поэтапном выпуске¶

Какие случаи должны попасть в набор оценочных примеров:
Какие поведенческие или контрольные оценки нужно добавить:
Нужно ли менять критерии шлюза поэтапного выпуска:
Нужно ли менять область канареечного выпуска или порог подтверждения:

Если инциденты не возвращаются в оценки и правила поэтапного выпуска, организация обычно повторяет один и тот же класс ошибок.

Разбор цепочки с дублем тикета

Для инцидента в триаже обращений поддержки разбор должен явно ответить: какой вызов create_ticket создал побочное действие, какой idempotency_key был или отсутствовал, какой policy_bundle и rollout_wave это пропустили, почему side_effect_unknown не остановил повтор, и какие корректирующие действия обновляют набор оценочных примеров, шлюз выпуска, политику подтверждений, запись реестра и план вывода из эксплуатации старого создателя тикетов.

Канонические сценарии разбора инцидентов

Разбор инцидента должен возвращать разные классы отказов в контур управления для трех канонических сценариев. Триаж обращений поддержки проверяет корневую причину дубля тикета, область подтверждения, idempotency_key, сдерживание побочного эффекта и исправление оценки и поэтапного выпуска. Внутренний ассистент знаний проверяет устаревший источник, свежесть поиска, происхождение памяти, разрыв контроля доступа и исправление базы знаний. Координация инцидентов проверяет задержку эскалации, побочные эффекты уведомлений, разрыв владения ответом, сбой передачи управления и обновление обучения после инцидента.

11. Короткий шаблон в YAML¶

postmortem:
  incident_id: inc-2026-04-09-001
  severity: sev2
  owner: platform-operations
  active_artifacts:
    trace_id: trace-2026-04-09-001
    session_id: session-2026-04-09-001
    bundle_id: bundle-2026-04-07-a
    change_id: chg-2026-04-07-001
    rollout_wave: canary
  root_cause:
    primary: approval_scope_too_broad
    contributing:
      - missing_targeted_eval
      - stale_rollout_gate
  corrective_actions:
    - owner: platform-safety
      action: tighten_approval_policy
      due: 2026-04-12
    - owner: runtime-team
      action: add_regression_eval
      due: 2026-04-13
  lifecycle_updates:
    change_id: chg-2026-04-09-003
    bundle_id: bundle-2026-04-09-b

12. Что сделать сразу¶

Сначала пройди по короткому списку и отдельно отметь все ответы «нет»:

Есть ли в постмортеме точный incident_id?
Восстановлены ли trace_id, session_id, bundle_id и change_id?
Есть ли не только первопричина, но и сопутствующие факторы?
Зафиксированы ли пробелы управления?
Есть ли конкретные корректирующие действия с владельцами и сроками?
Понятно ли, какие артефакты жизненного цикла должны обновиться?
Возвращается ли инцидент в оценки и критерии поэтапного выпуска?