Runbook — Реакция на инцидент

Универсальный playbook для critical-инцидентов в Notty CMS: продакшн недоступен, данные повреждены, утечка, массовый сбой content API. Для конкретных сценариев есть специализированные runbooks (database-restore.md, rollback.md, secret-rotation.md) — этот документ описывает координирующий процесс.

Severity

Уровень	Что значит	Реакция
SEV1	Прод недоступен / потеря данных / утечка секретов	немедленно, on-call
SEV2	Деградация: high error rate, latency 2-3× baseline	в часы дежурства
SEV3	Локальная регрессия (один content type, один webhook)	в рабочее время

Phases

1. Detect (минуты)

Сигналы:

• Алёрты Prometheus/Alertmanager (см. docs/observability/).
• Жалобы пользователей в operations-канале.
• Эскалация от внешних систем (DR-провайдер, заказчик).

При SEV1/SEV2 — открыть инцидент в operations-канале (#incidents):

🚨 SEV1 INCIDENT
- title: <короткое>
- impact: <что не работает у клиента>
- IC: <incident commander>
- comms: <кто пишет апдейты наружу>
- bridge: <ссылка на VC>

2. Stabilize (10-30 мин)

Цель — остановить ущерб, не «починить навсегда». Допустимые действия:

• rollback свежего деплоя (rollback.md);
• ротация скомпрометированных секретов (secret-rotation.md);
• блок поломанного клиента/IP через rate limit или ingress;
• остановка фоновых job'ов: POST /api/admin/jobs/:id/cancel для poisoned задач, PUT /api/admin/scheduled-jobs/:id (enabled: false);
• блок webhook'ов с растущим dead-letter (PUT /api/webhooks/:id/health).

Что не делаем:

• ничего необратимого без записи (snapshot + audit-log);
• руками не правим production БД через SQL;
• не удаляем backup'ы и не отключаем алёрты «потому что мешают».

3. Mitigate / Restore (минуты-часы)

Конкретные ветки:

• развалена БД → database-restore.md;
• проблема в коде → rollback или hotfix на новом тэге через deploy.md;
• утечка → secret-rotation.md + audit;
• перегрузка → ручной scale (scale-out.md) + включить cache/replica.

Каждое действие фиксируем в timeline инцидента (с точным временем).

4. Verify

• verify-deploy.sh зелёный.
• Алёрты гасятся.
• Метрики вернулись к baseline ≥ 30 минут.
• Клиент подтверждает (если SEV1).

5. Communicate

• Внутри: апдейты в operations-канале каждые 15 минут до closure.
• Наружу (если затронуты клиенты): шаблонное сообщение от Comms-лида.
• После closure — Resolved в канале с финальной версией timeline.

6. Postmortem (≤ 5 рабочих дней)

Шаблон:

# Postmortem — <короткий заголовок>

## Что произошло

короткое summary

## Impact

кто/сколько пострадало, окно

## Timeline

- 14:02 — алёрт NottyDBReplicaFallback
- 14:04 — IC объявлен
- ...

## Root cause

что именно пошло не так и почему это не отловили раньше

## Action items

- [ ] <конкретное действие, owner, deadline>
- [ ] ...

## Что сработало

- ...

## Что не сработало

- ...

Action items идут в Task Master с приоритетом. Постмортем — без поиска виноватых; цель — сделать систему устойчивее.

Контакты

В каждом окружении ведите свой oncall.md рядом с этим файлом — кто on-call, как звонить (PagerDuty/Opsgenie ID), эскалация.