Incident Response

«Работаем вместе» без распределения ролей — IC, Ops Lead и Comms Lead в одном лице — антипаттерн, который я регулярно вижу в командах. Выглядит это всегда одинаково. Решения растворяются в общем чате, стейкхолдерам не пишет никто, MTTR растёт, а клиенты молчат просто потому, что им некуда написать. Incident Response — это процесс координации: явные роли, пути эскалации, ритм сводок, структурированная передача между сменами. Цель в моменте — минимизировать MTTR, не нарушая режим blameless и сохранить достаточно сигнала для последующего постмортема. Не путать с Blameless Postmortem — тот разбирает по следам, а этот лист про то, что происходит в моменте.

Что должен уметь

Главный навык на уровне L5 — держать баланс между гашением и расследованием. На сороковой минуте сервис всё ещё лежит, потому что команда копает в код и ищет причину, а задача в моменте другая: вернуть сервис. Откат, переключение на резерв, деградация с сохранением главного сценария, добавление мощностей, увод трафика. Причины разбираются потом, в постмортеме. Сначала пациента стабилизируют, диагноз ставят после. Я регулярно вижу IC, которые дают команде уйти в расследование, — так и получается MTTR в два часа.

Понимает базовые роли (IC, Comms Lead, Ops Lead); знает, кого звать в инциденте; зовёт IC, когда непонятно.
Следует runbook для типового сценария; фиксирует свои действия в журнале инцидента с отметками времени; эскалирует, если шаги не работают.

Выступает Operations Lead в небольших инцидентах: ведёт диагностику, гасит, координирует команду; знает процедуру отката для своих сервисов.
Ведёт журнал инцидента как связный рассказ: что произошло, что попробовали, что сработало. Этот журнал становится основой хронологии в постмортеме.

Выступает Incident Commander: координирует действия команды, делает общий синк каждые 15–30 минут, принимает решения о rollback / эскалации / привлечении дополнительных людей.
Держит баланс гашения и расследования: понимает, когда хватит временной заплатки — вернуть сервис и разобраться в постмортеме, — а когда копать надо сразу.
Проводит структурированную передачу между сменами в затяжных инцидентах: короткая сводка, что делается прямо сейчас, что осталось непонятным.

L6+

Внедряет процесс реагирования в команде или организации: формальные роли, шаблоны сообщений, тренировки (game day, wheel of misfortune), реакция по уровню severity.
Связывает реагирование с уровнем организации: политика внешней коммуникации, уведомление регулятора, эскалация к руководству. Защищает тон blameless там, где давление максимально.

Материалы

Книги

Betsy Beyer et al. — Site Reliability Engineering (O’Reilly, 2016), глава 13 «Emergency Response». Типология аварий и разборы случаев из Google.
Betsy Beyer et al. — Site Reliability Engineering (O’Reilly, 2016), глава 14 «Managing Incidents». Канонические роли (IC, Ops, Comms), Incident Command System, шаблон incident document.
Betsy Beyer et al. — The Site Reliability Workbook (O’Reilly, 2018), глава 9 «Incident Response». Четыре разбора — три инцидента Google (в том числе откровенно плохо отработанных) и глава про процесс PagerDuty. Оттуда же четыре правила, на которых держится IMAG (Incident Management At Google): держать явную вертикаль управления, распределить роли до начала работы, вести рабочий журнал по ходу дела, объявлять инцидент рано и часто.

Статьи и руководства

PagerDuty — Incident Response Documentation. Открытое руководство по реагированию: Before / During / After, шаблоны сообщений, роли, чек-листы. По моим наблюдениям, чаще всего именно его берут как стартовый шаблон в новых командах. Apache 2.0, переиспользуемое.
Atlassian — Incident Management Handbook. Практичный справочник от команды, прошедшей через множество публичных инцидентов.
NIST — SP 800-61 Rev. 3 (апрель 2025). Актуальная рекомендация по реагированию на инциденты безопасности в контексте CSF 2.0; заменила Rev. 2. Для инцидентов надёжности она SRE Workbook не заменяет, но нужна там, где надёжность пересекается с управлением рисками безопасности.

Инструменты

Alerting / on-call rotation — PagerDuty как дефолт индустрии; Grafana IRM для тех, кто уже живёт в Grafana Cloud. Маршрутизация алертов, политики эскалации, ротация дежурств. Два бывших фаворита из этого ряда выбывают: Atlassian закрывает Opsgenie (продажи прекращены в 2025, полное отключение — апрель 2027, миграция в Jira Service Management), а Grafana свернула отдельный OnCall в пользу общего IRM и переводит OSS-репозиторий в архив. Если выбираете инструмент сейчас — проверяйте не функциональность, а то, что продукт вообще будет жив через два года.
Платформы для инцидентов — incident.io, FireHydrant. Автоматизация рутины: создание канала в Slack, назначение ролей, статусная страница, сбор хронологии. Полезны, когда команда выходит за десятки инцидентов в месяц. Команде, у которой инцидент раз в две недели, такая платформа не годится — ритуал есть, наполнять его нечем.
Status pages — Atlassian Statuspage, Better Stack. Внешняя коммуникация.
Журнал инцидента в отдельном канале Slack — самая базовая форма: один канал на инцидент, хронология в реальном времени с явными отметками времени. Достаточно для большинства команд без отдельной платформы.

Best practices

Роли важнее людей. Назначаются они вслух — даже когда в инциденте два человека, потому что «работаем вместе» звучит по-командному, а на деле означает, что решения растворяются в группе, апдейты не делает никто, MTTR растёт, и через час выясняется, что стейкхолдеры всё это время читали чужую переписку и делали собственные выводы. Все три роли достались одному дежурному? Пусть он произнесёт это как выбор: «я IC, я же Ops, коммуникацию беру на себя». Тогда в голове три отдельных списка задач, а не одна каша.

Дальше — темп. Апдейт каждые 15–30 минут идёт независимо от того, есть новости или нет. Молчание читают двояко: либо «всё совсем плохо», либо «уже починили, можно расходиться». Оба прочтения вредны. «Нового нет, продолжаем митигацию X, следующий синк через двадцать минут» — полноценное сообщение, а не заполнение эфира.

И главное правило момента: митигация важнее причины. «Сначала найдём root cause, потом починим» — вот так и получается, что на сороковой минуте сервис всё ещё лежит, а половина команды читает код. Задача одна — вернуть сервис. Откат, переключение, деградация с сохранением основного сценария, добавление мощностей, увод трафика. Причины разберём потом.

Один канал на инцидент. Технические детали в одном чате, апдейты для бизнеса в другом, синк с руководством в третьем — и полной картины нет ни у кого. Канал один: timeline в закреплённом сообщении, текущее действие в теме канала, наружу — страница статуса. Остальное производные. Я регулярно вижу, как рассинхрон между каналами рождает второй инцидент поверх первого: руководитель прочёл соседний тред и решил, что уже починили.

Разговор с бизнесом — отдельно от разговора инженеров. В общем техническом канале стейкхолдеры теряются в жаргоне и пугаются фразы «у нас 503 на checkout». Comms Lead держит внешний канал и переводит: не «503 на checkout endpoint», а «оплата недоступна примерно у 15% пользователей». Апдейты по расписанию, технические подробности туда не едут.

Game day и wheel of misfortune — часть процесса, а не «когда будет время». Тренировка проверяет роли, путь эскалации, runbook и коммуникации до того, как всё это понадобится всерьёз. Частоту задаёт ротация дежурства и темп изменений, сценарии берутся из публичных постмортемов и своих прошлых инцидентов. Универсального коэффициента снижения MTTR тут нет, и эффект приходится мерить у себя.

Связанные листья

Blameless Postmortem — обязательный разбор после значимого инцидента; качество журнала прямо определяет качество хронологии в постмортеме.
Runbooks — главный инструмент в моменте инцидента.
SLI-based Alerting — то, с чего реагирование начинается; качество SLO-алертов определяет соотношение сигнала и шума.
Postmortem Culture — норма blameless работает и в моменте инцидента — журнал ведётся без «кто это сделал», — а не только после.
Service Ownership — incident commander смотрит в каталог сервисов, чтобы понять владельца и путь эскалации.
Dev Team Partnership — модель взаимодействия определяет, кто берёт IC, Ops и Comms: у встроенной SRE и у консультирующей это разные люди.
Severity Classification — рамка для ответа на вопрос «насколько всё серьёзно»; она же задаёт интенсивность реакции.
Customer Communications — внешняя коммуникация во время инцидента.
War Room Patterns — операционная дисциплина для критических инцидентов, в которых участвует несколько команд.
On-Call Rotation — кто реагирует и в каком состоянии.
Action Items Tracking — закрытие инцидента включает постановку задач с владельцем, сроком и критерием; соседний лист — про дисциплину их выполнения.
ChatOps — современные инструменты для инцидентов (incident.io, Netflix Dispatch, FireHydrant) — это ChatOps внутри Slack: объявление инцидента, координация и сводки живут в чате, и там же остаётся журнал аудита.
Status Page Management — обновление публичной статусной страницы стоит в чеклисте IC прямо в моменте инцидента.
Game Day / Chaos Drills — регулярная проверка ролей, эскалации, runbook и коммуникаций до реального инцидента.
Playbooks — главный артефакт всей практики реагирования; как часто playbook’и реально открывают в инциденте — прямой показатель зрелости процесса.
Postmortem Database — платформы для инцидентов автоматически связывают инцидент, постмортем и базу; это инструментальная сторона той же пары практик.

Открытые вопросы

Почти всё, что раньше висело здесь в открытых вопросах, разъехалось по отдельным листьям внутри Incident Management: Severity Classification, Customer Communications, On-Call Rotation, War Room Patterns, Status Page Management. По основным операционным практикам эта ветка закрыта, и незакрытых кусков в ней я сейчас не вижу.