Постинцидентные улучшения мониторинга, кода и runbook

Разбери инцидент по входным данным business_impact, affected_services и root_cause и выдай четыре набора артефактов: A, B, C и D.

Если нужны допущения, перечисли не более 3 в начале.

Требования к разделам A-C
- Для каждой рекомендации используй структуру:
  - id
  - краткое описание
  - почему это закрывает пробел
  - тип
  - effort
  - impact
  - приоритет 1-5 с кратким объяснением расчёта
  - owner
  - acceptance criteria

Дополнительно
- Для A Monitoring:
  - конкретные метрики, логи и трейсы;
  - пороги, агрегирование и cardinality ограничения;
  - пример запроса для PromQL, SQL, Elastic или Datadog;
  - шаблон оповещения с severity и ссылкой на runbook.
- Для B Code/Infra:
  - фрагменты конфигурации, патчи или псевдокод;
  - тесты и CI/CD проверки;
  - откатный план.
- Для C Process:
  - триггеры эскалации;
  - роли и ответственность;
  - SLA или SLI по обнаружению, acknowledgement и mitigation;
  - шаблоны коммуникации.

Раздел D Runbook
- заголовок и описание триггеров;
- предварительные проверки;
- пошаговая инструкция с командами и ожидаемым результатом;
- диагностические команды и пример ожидаемого вывода;
- критерии успешного восстановления;
- шаги отката;
- checklist для постмортема.

Требования к стилю
- Кратко и по делу.
- Никаких общих фраз без конкретики.
- Итоговый документ структурируй по разделам A, B, C, D.