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

3 утра. Pager пищит. Половина пользователей не может зайти. Что делать? Это не про панику — это про процесс.

Главные правила

1. Stop the bleeding first. Сначала восстанови сервис, потом ищи причину.
2. Один Incident Commander. Не «давайте все вместе» — нужен координатор.
3. Communicate. Статус каждые 30 минут даже если «ничего нового».
4. Document live. Кто что когда сделал — в треде Slack.
5. Blameless. После — разбор без обвинений людей.

Фреймворк PICERL (NIST SP 800-61)

1. Preparation (до инцидента)

Готовиться надо когда всё спокойно:

• Runbooks для типовых проблем
• On-call rotation
• Контакты эскалации
• Доступы (kubectl, AWS console, БД read-only)
• Шаблон status page
• Дашборды observability

2. Identification (минуты 0-5)

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

• Алерт → проверь real impact (не false positive)
• Какие сервисы затронуты?
• Сколько пользователей?
• Когда началось?

3. Containment (минуты 5-30)

Остановить кровотечение. Быстрые победы:

• Rollback последнего деплоя (если timeline совпадает)
• Disable feature flag для проблемной фичи
• Failover на replica
• Scale up если ресурсы заканчиваются
• Rate limit для перегрузки
• Drain bad node если железо барахлит

4. Eradication (минуты 30+)

Устранить корневую причину:

• Патч с фиксом
• Удалить compromised компонент
• Закрыть уязвимость

5. Recovery

Вернуть в нормальное состояние, проверить что фиксит, мониторить, постепенно снимать ограничения.

6. Lessons learned (через 24-72 часа)

Post-mortem. О нём — отдельная глава ниже.

Роли в крупном инциденте

• Incident Commander (IC) — главный координатор. Не делает работу руками, дирижирует.
• Communications Lead — общается с пользователями, бизнесом, status page.
• Operations Lead — технический лидер, делегирует работу инженерам.
• Scribe — записывает timeline в реальном времени.
• SMEs (Subject Matter Experts) — конкретные инженеры систем.

Алгоритм дебага

Шаг 1. Сколько и кому больно?

• Все? Один регион? Один tenant?
• Какие endpoints?
• Когда началось точно?

Шаг 2. Что изменилось?

• Последние деплои (CI/CD timeline)
• Изменения конфигов / feature flags
• Облачные incidents (status.aws.amazon.com)
• DNS изменения
• Cert expiration
• Limits / quotas

Шаг 3. Куда смотреть

• Метрики — RED для сервисов, USE для нод
• Логи — Loki / ELK с фильтром по error level
• Traces — где в цепочке зависает
• K8s events — kubectl get events --sort-by='.lastTimestamp'
• CloudWatch / cloud provider — здоровье LB, RDS, кэшей

Status page communication

Шаблоны:

🟡 Investigating — We're investigating reports of [issue]. Updates in 30 min.

🟠 Identified — We've identified the issue: [одно предложение]. Working on fix.

🟢 Monitoring — Fix is deployed. Monitoring for 30 min before all-clear.

✅ Resolved — Service restored. Post-mortem within 48h.

Правила:

• Каждые 30 минут — обновление, даже «ничего нового»
• Будь честным, не обещай ETA
• Не вали технические детали на конечных пользователей

Post-mortem — blameless

Структура документа

1. Summary — одно предложение что случилось
2. Impact — кого, насколько, сколько по времени, в деньгах если можно
3. Timeline — минуты с заходами действий и observations
4. Root cause(s) — что технически вызвало (часто их несколько)
5. Contributing factors — что усугубило (monitoring gap, поздно увидели)
6. What went well — да, и это
7. What went wrong
8. Action items — с owners и due dates

5 Whys

Чтобы дойти до root cause — задавай «почему?» 5 раз:

Симптом: API упало
1. Почему? — Pod упал с OOM
2. Почему? — Memory leak в новой версии
3. Почему утечка? — Не закрывали БД connections
4. Почему не закрывали? — Connection pool не имел timeout
5. Почему? — Конфиг был скопирован из примера без проверки

→ Root cause: процесс review не проверяет config-related defaults
→ Action: чек-лист review для config файлов

Blameless principle

Цель — найти процесс, который позволил ошибке случиться. Не человека.

«Alice задеплоила в пятницу» — плохо.
«У нас не было guard rail против пятничных деплоев» — хорошо.

Action items — главное в post-mortem

Без action items post-mortem бесполезен.

Хорошие action items

• SMART (Specific, Measurable, Achievable, Relevant, Time-bound)
• Есть owner
• Есть due date
• Трекаются как Jira ticket
• Review на каждом sprint planning

Типы

• Detection: как обнаружить быстрее (новый алерт)
• Mitigation: как уменьшить blast radius (canary, feature flags)
• Prevention: как избежать повторения (test coverage, review)
• Process: процессы (runbook, training)

Чек-лист готовности к инциденту

Ресурсы

• 📖 «The Site Reliability Workbook» — Chapter on Incident Response
• 📖 «Seeking SRE» — David Blank-Edelman
• 📰 Honeycomb blog — incident analysis
• 📰 Increment Magazine — On-Call
• 📺 PagerDuty channel — incident management