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): держать явную вертикаль управления, распределить роли до начала работы, вести рабочий журнал по ходу дела, объявлять инцидент рано и часто. Советую читать ради разборов, а не ради списка правил: случай Google Home показывает цену необъявленного инцидента нагляднее любого тезиса.
Наталья Савенкова — SRE. Рецепты выживания в продакшне для инженера по надежности (2024). Читал и рекомендую: шестьдесят страниц коротких рецептов без теории. К этому листу относятся рецепты про людей: как каждый по-своему ломается под стрессом и зачем дежурному личный чек-лист.
Максим Батырев — 45 татуировок менеджера. Правила российского руководителя (МИФ). Книга про управление людьми, про IT в ней ничего нет. Читал ради коротких правил, и одно из них совпало с главным правилом этого листа: «Сначала боремся со следствиями, потом с причинами».

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

PagerDuty — Incident Response Documentation. Открытое руководство по реагированию: Before / During / After, шаблоны сообщений, роли, чек-листы. По моим наблюдениям, чаще всего именно его берут как стартовый шаблон в новых командах. Apache 2.0, переиспользуемое.
Atlassian — Incident Management Handbook. Практичный справочник от команды, прошедшей через множество публичных инцидентов. Советую читать вторым, после PagerDuty: другой взгляд на тот же процесс.
Stephen Whitworth — The Incident Maturity Model (incident.io, декабрь 2024). Читал и советую ради двух разделов: про порочный круг, в котором инциденты перестают объявлять, и про разрозненные инструменты. Три ступени зрелости в конце ведут к выводу «нужна платформа», и удивляться тут нечему: автор — сооснователь и CEO incident.io.
Мой разбор — Как не сойти с ума, чиня прод – практические заметки SRE (jtprog.ru, февраль 2026). Конспект книги Савенковой с моими пометками. К реагированию относится раздел про людей и работу в стрессе: личный чек-лист дежурного и конкретные фамилии в графике вместо «отвечают все». Его советую тем, кто выходит на первое дежурство.
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, следующий синк через двадцать минут» — полноценное сообщение, а не заполнение эфира.

Сам синк удобно вести как оборот цикла. У PagerDuty в подготовке IC он записан четырьмя шагами: оценить обстановку, стабилизировать, сообщить статус, проверить результат. Не помогло — снова с первого шага. Про шаг решения там сказано жёстко: неверное решение лучше, чем никакого. Я читаю этот цикл как прикладной вариант петли OODA: наблюдение, ориентация, решение, действие. У её автора, John Boyd, в брифинге The Essence of Winning and Losing на рисунке петли решение подписано как гипотеза, а действие как проверка. Для инцидента формулировка точная. Откат — это проверка гипотезы «виноват релиз», и в назначенное время IC спрашивает, подтвердилась ли она. Оттуда же второе: ориентация определяет и наблюдение, и решение, и действие. Поэтому синк я начинаю с общей картины, а не с опроса, кто чем занят. Заменить петля ничего не может. Это способ думать, а ролей, канала и журнала она не даёт.

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

Инцидент объявляют рано. В четырнадцатой главе SRE Book условия записаны заранее: для починки нужна вторая команда, сбой виден клиентам, час сосредоточенного разбора ничего не дал. Выполнено любое из трёх — это инцидент. Довод там же: лучше объявить, найти простую починку и закрыть, чем разворачивать процедуру через несколько часов, когда проблема разрослась.

В девятой главе Workbook разобран обратный случай. В понедельник 22 мая 2017 года дежурный разработчик Google Home заметил на графике лишние запросы и завёл баг. Почти две недели команда поднимала квоту и продолжала раскатку, общалась через трекер, а инцидент так никто и не объявил. В выходные 3 июня раскатка дошла до всех устройств, и пользователи теряли половину запросов. Вывод авторов занимает одну строку: управляемые инциденты закрываются быстрее. Там же видна граница правила «сначала гасим». Гашение сработало три раза, и сбой каждый раз возвращался, пока не нашли причину: раскатку после первого гашения стоило остановить.

Почему объявляют поздно, хорошо разобрал Stephen Whitworth из incident.io. Объявить инцидент трудно, и объявляют только крайние случаи. Практики становится меньше, навык уходит, следующий сбой команда отрабатывает медленно и силами нескольких ключевых людей. После слабой реакции не остаётся данных, улучшать нечего, и круг замыкается. В SRE Book то же сказано одной фразой: умение вести инцидент быстро атрофируется, если им не пользоваться постоянно. Поэтому падение числа объявленных инцидентов я не читаю как рост надёжности, пока не проверено, что объявить по-прежнему легко. А когда неясен уровень, работает правило PagerDuty: берут старший из двух и пересматривают на разборе.

Первый вопрос после объявления — кого задело и есть ли обходной путь. Просевшую метрику режут по платформе, региону, версии клиента и способу оплаты, пока не найдётся срез, который просел один. Зона поиска сужается со всей системы до него, и звать можно конкретных людей. Это другой разрез, чем деление пополам из Systematic Troubleshooting: там делят цепочку запроса, здесь аудиторию. Тот же ответ решает, поднимать ли инцидент выше технического уровня. Не работает оплата через СБП, а карта и оплата при получении работают: ключевой сценарий жив, инцидент остаётся на уровне сервиса. СБП — единственный способ принять деньги? Тогда встала выручка, и эскалация идёт до бизнеса. Правило у меня одно: сигнал поднимается на уровень выше, только когда сломан сценарий этого уровня.

Действие называют вслух до того, как его сделать. «Собираюсь перезапустить сервис X в кластере Y» — и пауза на возражения. Чужие намерения я подтверждаю так же конкретно: услышал «сейчас поправлю» — спрашиваю, что именно и где. В четырнадцатой главе SRE Book молчаливая самодеятельность стоит среди трёх причин, по которым неуправляемый инцидент разрастается. Инженер в учебном сценарии вносил изменения с лучшими намерениями, никого не предупредил и сделал плохую ситуацию намного хуже. У PagerDuty IC перед решением спрашивает, есть ли сильные возражения, и нарочно не спрашивает «все согласны?»: на второй вопрос отвечают хором, а тихие молчат. Рядом у меня стоит правило выбора действия. Не трогать наугад то, с чем не знаком, и из двух вариантов начинать с того, который проще откатить.

Зовут в инцидент экспертизу, а не всех. Требование «подключите всех немедленно» звучит логично и обычно ухудшает дело. IC сначала решает, какая экспертиза нужна под текущую гипотезу, и зовёт её поимённо, а остальные остаются свежими к моменту, когда понадобятся. Вторая половина той же работы — закрывать исполнителей от начальства. В руководстве PagerDuty у этого явления есть имя, executive swoop: старший по должности приходит в звонок и начинает отменять решения IC. Ответ там умещается в вопрос: «Вы берёте командование на себя?» Да — командование передаётся вслух. Нет — решения остаются за IC. Самая частая разновидность, по их же наблюдению, на вид безобидна: руководитель просит список затронутых клиентов. Ответ записан дословно: либо список, либо починка, не оба сразу.

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

С инструментами происходит то же, что с каналами. Whitworth в статье про зрелость пишет, что многие компании, с которыми разговаривает incident.io, ведут один инцидент в семи и более инструментах. Набрать столько нетрудно: мониторинг, чат, трекер, система дежурств, статусная страница, runbook, документ постмортема. Каждый добавляли по отдельности под понятную задачу, а набор целиком никто не пересматривал. Это tool sprawl, и платят за него руками. Дежурный копирует данные между окнами, полной картины нет ни в одном, а хронологию для постмортема потом восстанавливают часами. Вывод «значит, нужна платформа» в статье ожидаем. Я беру из неё другое: перед тем как добавить восьмой инструмент, стоит назвать тот, который он заменит.

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

Первые минуты дежурный проходит по списку, а не по памяти. Под стрессом каждый ломается по-своему: один жмёт всё подряд, другой замирает, третий пропадает из канала. Свой способ полезно знать заранее и держать против него личный чек-лист из нескольких строк: подышать, записать идеи действий, пройтись, открыть инструкцию по оповещению. Идею я вынес из книги Натальи Савенковой и в разборе назвал такой список очень мощным инструментом. Командный вариант того же — форма первых действий при сбое. С ней реакция меньше зависит от того, кто именно сегодня дежурит, и это уже территория Playbooks.

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 — кто реагирует и в каком состоянии.
Systematic Troubleshooting — методология разбора неизвестной поломки; здесь координация вокруг него, там сам поиск.
MTTR Optimization — время инцидента по отрезкам: обнаружение, реакция, гашение, устранение. Здесь — как прожить эти отрезки организованно, там — как их мерить.
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. По основным операционным практикам эта ветка закрыта.

Открытым остался один вопрос: кому командовать. Whitworth рисует три ступени как лестницу, по которой идут вверх: выделенная центральная команда, затем команды-владельцы, затем вся компания, где инцидент может объявить и служба поддержки. Robert Ross, CEO FireHydrant, в 2023 году писал другое: большинству команд нужна комбинация распределённой и централизованной модели. Оба автора руководят компаниями, которые продают платформы для инцидентов, так что оба текста я читаю с поправкой. Независимого сравнения моделей на данных мне не попадалось.