Incident Management

Зачем

Без процесса инцидент превращается в хаос: 15 человек в одном Zoom, никто не координирует, support не знает что писать, fix коммитится без review и ломает ещё больше. Incident Command System (адаптированный из firefighting FEMA) даёт роли, протокол коммуникации и discipline mitigation-first. Команды со зрелым процессом восстанавливают сервис в 3-5× быстрее (MTTR 15 минут vs 1 час) — это разница между «customer не заметил» и «попадание в news».

Mental model

«Incident response — не "тушить пожар", а запустить организованный процесс. IC координирует, не чинит. Mitigation важнее investigation: сначала верни сервис, потом разбирайся почему. Каждое решение логируется — это потом будет timeline post-mortem.»

Три кита:

1. ICS roles — IC (координатор), Ops (фикс), Comms (статус), Scribe (timeline). Один человек = одна роль, иначе бьётся фокус.
2. Severity classification — SEV-1 (полный outage / data loss, page всех, <30 мин mitigate), SEV-2 (major degradation, IC роли, <2ч), SEV-3 (single feature, working hours), SEV-4 (cosmetic, backlog).
3. Mitigate first, investigate later — Google SRE Book Ch.14. Rollback / flag off / failover / circuit break до понимания root cause. Investigation в проде = continuing downtime.

Что на диаграмме

• Service (production) — checkout-service v2.4 + DB + LB. Точка возгорания: только что деплоили.
• Detection — Prometheus считает SLO burn → Alertmanager роутит по severity → PagerDuty эскалирует по политике (primary → secondary → EM).
• People (ICS) — IC, Ops, Comms, Scribe, SME on-demand. Каждый со своей ролью и границами ответственности.
• War room — Slack channel #inc-2026-05-14-checkout, Zoom bridge, Incident.io как оркестратор, runbook. Единственный источник правды на время инцидента.
• Customer comms — Statuspage.io, X/Twitter, support macros, subscribed customers.
• Mitigation toolkit — rollback (80% случаев), feature flag off, region failover, manual circuit break.

Edges показывают flow: detection chain (svc → prom → alertmanager → pagerduty → ic), IC делегирует роли, Ops следует runbook → rollback, Comms пишет в statuspage. Scribe пинит decisions в Slack и автоматом капчурит таймлайн через Incident.io.

Сценарии

SEV-1 textbook (28 минут) — детект на 90с (SLO burn 14× normal), IC ack на 2-й минуте, формальное /incident declare SEV-1, авто-создание Slack + Zoom + invite. IC делегирует роли явно по именам («Rajiv = Ops, Sofia = Comms, Devon = Scribe»). Ops подтверждает recent deploy через 5 минут, IC одобряет rollback, rollback завершается на 10-й минуте, 30-минутное окно верификации, [Resolved] на 30-й минуте. Ключевое: IC не открывал IDE, Comms не писала код, Ops не обновляла statuspage — роли сохранены, хаоса нет.

Communication cadence (правило 30 минут) — как Comms Lead ведёт 4 statuspage updates за 28-минутный инцидент. Шаблоны: [Investigating] → [Identified] → [Monitoring] → [Resolved]. Плоский язык, без жаргона («delays processing your order», не «kafka consumer lag»). Обновление минимум каждые 30 минут — silence читается как «не знаем / не парим / прячем». Для SEV-1 — твит из основного бренд-аккаунта (не только status). Support получает canned macros одновременно с публикацией. Кейс показывает: Comms Lead существует ровно для того, чтобы IC и Ops оставались сфокусированы.

Follow-the-sun handoff (8h SEV-2) — Stripe деградировал, US IC Maya переключила на Adyen fallback за 50 минут. К концу US business day — формальный handoff в EU. PagerDuty эскалирует Lukas в Berlin за 30 минут до окна, Scribe walks Lukas через timeline, Maya даёт verbal brief (severity, текущая митигация, открытые гипотезы, SME, vendor contacts, pending decisions). 30-минутное overlap, формальная передача IC роли в Incident.io. Без handoff обе зоны думают что «кто-то смотрит» — инцидент дрейфует unmonitored. Anti-pattern: outgoing IC просто уходит спать.

Анти-паттерн: investigation > mitigation (45-минутная кроличья нора) — Tom (он же автор v2.4) пейджится, confirmation bias («моё не могло сломаться»), скипает IC role assignment, лезет в traces вместо rollback. Через 25 минут добавляет неправильный индекс на DB. На 32-й минуте EM Sarah берёт IC, командует rollback, 45 минут downtime вместо 5. $50K revenue lost, статус-пейдж молчал 45 минут, Twitter и HackerNews узнали раньше клиентов. Lessons: автор deploy disqualifies из IC роли; мандатное IC declaration <5 мин; «recent deploy?» — first hypothesis.

Trade-offs (ADR)

ADR-IM-001: Rotating IC vs Dedicated IC team (см. на ноде svc).

• Rotating IC (senior engineers ротируются по неделе): organisational learning, эмпатия к ops, нет силоса. Но: качество неравномерно, конфликт с роадмапом, training pipeline.
• Dedicated IC team (3-6 человек full-time): consistent high quality, специализированные tools/runbooks. Но: knowledge silo, engineers перестают brать ownership за reliability ($1.5-3M/year payroll), «throw it over the wall» culture.
• Решение: default до ~100 engineers — rotating IC + маленькая Reliability Team (2-3 человека) которая owns process/tooling но не IC во время incident. После 200+ — hybrid Stripe-style EMOC. Никогда: чистый dedicated IC team.

ADR-IM-002: Blameless culture — насколько blameless и как enforce.

• Blameful (поиск виновного, public shaming): incidents скрываются, near-misses не репортятся, learning катастрофически замедляется (см. healthcare до Just Culture, авиация до CRM).
• Blame-washing (притворная blamelessness, втихую penalize в perf review): incongruence убивает доверие, хуже исходного.
• Решение (Allspaw + Dekker Just Culture): фокус на conditions/systems, имена используются (specificity > anonymity) но в context «what they knew at the time». Action items — system fixes, не person fixes («be more careful» = automatic reject). Separate track для performance issues в 1
  , не в post-mortem. Facilitator review-ит draft на blameful language.

Реальные системы

• Cloudflare 2019 BGP regex outage — 27 минут global downtime. Bad WAF regex с catastrophic backtracking положил CPU на edge всюду. Detection instant, mitigation — rollback rule, public post-mortem с timeline стал industry model.
• GitHub October 2018 — 24 часа degraded из-за network partition между US East/West DC. MySQL replication diverged, mitigation требовала manual reconcile. Process сработал, но архитектурная задолженность всплыла.
• AWS S3 Feb 2017 — оператор debugging billing service опечатался в команде, снёс index subsystem. 4 часа US-East-1 downtime. Restart в правильном order не делался годами — никто не помнил sequence. После: capacity-modifying команды требуют согласования + chaos game days.
• Knight Capital August 2012 — $440M loss за 45 минут из-за partial deploy + старого dead code, активированного flag-ом. Урок: deploy/rollback process должен verify что все инстансы на новой version. После — bankrupt.
• Facebook October 2021 — 6 часов outage из-за BGP + DNS misconfiguration. Backbone упал, потеряли способность управлять remote (включая badges доступа в офис). Lesson: out-of-band management plane обязателен.
• Slack January 4, 2021 — новогодний день, traffic surge + scale не догнал = cascading failure 1 час downtime. Public post-mortem: cold-start scenarios не тестировали. Game days добавлены.

Anti-patterns

• Нет IC — все чинят, никто не координирует, хаос (см. investigation-trap scenario).
• IC коммитит код — конфликт ролей. IC не должен иметь IDE открытого, делегирует Ops.
• Investigation первым делом — debug в проде вместо rollback, MTTR в 10× длиннее.
• Status page silence — customers идут на Twitter/HackerNews сами. Reputation hit > technical hit.
• Page для не-actionable алертов — alert fatigue, on-call игнорирует все pages, miss real one.
• No scribe — post-mortem становится reconstruction по памяти, неточным.
• «It's fixed» без verification — incident reopen через час. Минимум 30 минут steady state.
• No rotation — один герой пейджится ночами, выгорает, уходит.
• No runbook для top-10 failure modes — каждый incident учит «как restart Postgres» с нуля.
• Author of deploy = IC — confirmation bias, должен быть disqualified, эскалация на backup IC.
• Blame culture — «John caused outage». Killing learning. Blameless retros non-negotiable.

Когда НЕ использовать

ICS — это тяжёлый процесс. Не нужен для:

• SEV-3/SEV-4 — ticket в JIRA, фикс в working hours, никакой war room. ICS на cosmetic issue = театр.
• Команда меньше 5 человек — один human может быть IC+Ops+Comms (но всё равно severity заявить и timeline вести). Полный ICS = overkill.
• Maintenance windows / planned changes — это change management, не incident response. Discipline другая (rollback plan заранее, communication до начала).
• Performance regressions без user impact — это backlog, не page. Если pager уходит на «p99 +50ms но в SLO» — alert tuning broken.
• Внутренние tools / staging environments — без customer impact severity автоматом ≤ SEV-3. Не будите IC ночью из-за CI runner.

Главное правило тяжёлого процесса: он окупается частотой. Если SEV-1/SEV-2 случается раз в год — ROI на Incident.io лицензию и тренинги отрицательный. Если раз в месяц — окупается за квартал. Если раз в неделю — investing в reliability, не в incident process.

Применяется в кейсах

• [CONCEPT]error-budgets — SLO burn rate триггерит page; severity ≈ burn rate × impact
• [CONCEPT]post-mortems — blameless retro следует за каждым SEV-1/SEV-2 в 24-72ч
• [CONCEPT]observability — без traces/metrics/logs detection невозможен, MTTD растёт