Меня зовут Дима Синявский, я SRE-инженер в Ви.Tech. Я решил написать о работе с инцидентами, ведь мы часто говорим, что "тушим пожары". Так вот мне стало интересно, можно ли что-то полезного взять у реальных пожарных и МЧС в IT.

Когда срабатывает алерт в три часа ночи, ваша дежурная команда превращается в "пожарных": вы мгновенно собираетесь, диагностируете «возгорание» и пытаетесь потушить пламя до того, как оно перекинется на пользователей. Но есть один нюанс: пожарные службы оттачивают свои регламенты столетиями, а IT-команды часто полагаются на стихийные действия и «опыт старших товарищей».

Мы привыкли заимствовать практики из других ИТ-компаний, но редко смотрим за пределы индустрии. А ведь системы управления инцидентами в аварийно-спасательных службах прошли проверку реальными катастрофами – лесными пожарами, землетрясениями, терактами. Их эффективность не обсуждается: от чёткости действий зависят жизни людей.

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

Система командования инцидентами у пожарных

В 1970-х годах пожарные бригады Южной Калифорнии столкнулись с проблемой: при крупных лесных пожарах десятки независимых команд прибывали на место, но никто не знал, кто за что отвечает. Возникал хаос: дублирующиеся действия, противоречивые приказы, потеря контроля.

Решение пришло в виде Системы командования инцидентами (Incident Command System, ICS) – стандартизированной структуры управления, разработанной Федеральным агентством по чрезвычайным ситуациям США (FEMA) и сегодня лежащей в основе реагирования на ЧС по всему миру. Её ключевые принципы:

  • Единая цепочка командования – каждый имеет одного прямого руководителя

  • Управляемость – один руководитель контролирует 3–7 подчинённых

  • Общий язык – единая терминология для всех служб.
    И это важно даже на уровне ваших логов! Смотрите статье "Практики SRE: стандартизация логов"

  • Модульность – структура масштабируется под любой инцидент

Эта система легла в основу Национальной системы управления инцидентами (NIMS) США, которая обеспечивает согласованное реагирование всех служб от пожарных до медиков при любых масштабах ЧС.

В России аналогичная система существует в рамках Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций (РСЧС). Основа – принцип единоначалия и чёткое распределение полномочий между уровнями управления: федеральным, региональным, муниципальным и объектовым

Google и PagerDuty, столкнувшись с аналогичными проблемами в распределённых системах, адаптировали ICS под свои нужды. Google создал фреймворк IMAG (Incident Management and Governance), который организует реагирование через иерархическую структуру с чёткими ролями, задачами и каналами коммуникации. В основе подхода – те же три столпа: ясность, контроль и коммуникация.

Четыре роли в инциденте, которые спасут вас от хаоса

В пожарной команде никто не кричит «делайте что хотите» – у каждого своя зона ответственности. Внедрите ту же дисциплину в вашу команду.

Руководитель инцидента (Incident Commander)

Не тот, кто лучше всех кодит, а тот, кто управляет процессом. Его задачи:

  • Определить цель инцидента («восстановить доступность платежного шлюза для 95% трафика»)

  • Назначить роли и делегировать задачи

  • Принимать ключевые решения (откат, миграция, информирование клиентов)

  • Поддерживать общую картину ситуации.

В российской пожарной тактике ключевая фигура – Руководитель тушения пожара (РТП). Это старшее оперативное должностное лицо, которое управляет на принципах единоначалия всеми силами на месте происшествия.

Важно: РТП не участвует непосредственно в тушении – его задача управлять процессом. Если он сам берётся за рукав, управление распадается.

Точно так же и в IT: руководитель инцидента не должен одновременно быть и техлидом. Он не участвует в технических действиях – его работа видеть лес, а не деревья. Это принципиально: если он сам начинает чинить, управление инцидентом распадается.

При крупных ЧС создаётся оперативный штаб – орган управления, в который входят представители различных служб (медицинская, коммунальная, транспортная). Это прямой аналог расширенной команды при крупном инциденте в IT, где к работе подключаются не только инженеры, но и представители поддержки, юристы, PR.

Технический руководитель (Tech Lead)

Старший инженер, который руководит диагностикой и исправлениями:

  • Формулирует гипотезы о причине проблемы

  • Организует эксперименты для их проверки

  • Принимает технические решения (какой фикс применить, в каком порядке)

  • Отчитывается перед руководителем инцидента

Ответственный за коммуникации (Communications Lead)

Ваш фильтр от информационного шума. Он:

  • Является единственной точкой входа/выхода для запросов

  • Готовит статусные обновления для команды и стейкхолдеров

  • Управляет внешними коммуникациями (статус-страница, уведомления клиентам)

  • Защищает технарей от отвлечений – критически важная функция

Ответственный за планирование (Planning Lead)

Для крупных инцидентов – отдельная роль, отвечающая за:

  • Сбор данных из мониторинга, логов, отчётов команд

  • Поддержание протокола инцидента в актуальном состоянии

  • Подготовку прогнозов и планов на следующие 30–60 минут

Для небольших инцидентов роли могут совмещаться (например, коммуникации берёт на себя руководитель), но разделение ответственности должно быть чётким.

Протокол инцидента

В пожарной службе есть План действий по инциденту (IAP) – официальный документ с целями, тактикой и распределением ресурсов на ближайшие 12–24 часа .

В российской системе пожаротушения существует официальный документ – «Журнал учёта донесений о пожаре». Это не отчёт «для галочки», а рабочий инструмент, который:

  • Ведётся с момента получения сообщения о пожаре

  • Фиксирует все донесения, прибытие подразделений, изменения тактики

  • Служит основой для передачи смены и последующего анализа

В российском IT-сообществе его аналог чаще называют протоколом инцидента или журналом инцидента, это такой же рабочий и��струмент как у пожарных, который:

  • Начинается с первой минуты инцидента (даже если фактов мало)

  • Содержит всё: описание проблемы, гипотезы, выполненные действия, данные, решения

  • Ведётся в реальном времени и доступен всем участникам

  • Служит основой для передачи смены и постмортема

Структура протокола инцидента: 

# Инцидент: [Краткое название]
## Приоритет: P0 / P1 / P2
## Воздействие: [Кто и как страдает]
## Текущая ситуация: [Что происходит сейчас]
## Цель: [Что хотим достичь за ближайшие 30 минут]
## Выполненные действия:
- 14:05 Обнаружено падение latency в сервисе Х
- 14:07 Запущена диагностика зависимостей
## Гипотезы:
- Проблема в обновлении сервиса Y (версия 2.3.1)
## Дальнейшие шаги:
- Проверить логи сервиса Y за последние 15 минут
## Команда:
- Руководитель: Петр Романов
- Техлид: Мария Сидорова
- Коммуникации: Алексей Козлов

Протокол инцидента объединяет информационные острова, которые обычно вырастают в чатах и личных заметках. Это ваша карта происходящего. В Google он является обязательным элементом процесса реагирования на инциденты .

ЕДДС: единый пункт приёма и координации

В системе МЧС России ключевую роль играет Единая дежурно-диспетчерская служба (ЕДДС) – круглосуточный орган, осуществляющий приём сообщений о происшествиях, их регистрацию и координацию реагирования. ЕДДС обеспечивает:

  • Единый номер вызова (112).

  • Централизованный сбор и обработку информации.

  • Координацию действий всех служб на территории муниципального образования.

В IT-мире аналогом является единый канал инцидента в мессенджере или тикет в системе отслеживания, который становится единственной точкой входа для всей информации по инциденту. Это гарантирует, что все участники получают одну и ту же актуальную информацию.

Протокол SBAR: как говорить кратко, когда вокруг паника

В условиях стресса люди говорят много и путано. Чтобы сэкономить время, позаимствуйте протокол SBAR из медицины – он же используется в авиации и МЧС.

SBAR – это структурированный метод передачи критической информации, состоящий из четырёх компонентов:

Situation – ситуация, что происходит сейчас
Background – контекст проблемы
Assessment – ваша оценка
Recommendation – рекомендация, что предлагаете сделать

Это дисциплинирует мышление и экономит драгоценные минуты, когда каждая секунда на счету. В медицинской практике внедрение SBAR сократило количество ошибок коммуникации на 30%. Используйте SBAR для всех статусных обновлений и запросов информации.

В первые минуты инцидента у вас нет полной картины – и это нормально. Сила SBAR не в том, чтобы сразу дать идеальный анализ, а в том, чтобы структурировать даже неполную информацию и избежать хаоса в чате.

Пример использования SBAR в инциденте

Ситуация: 02:17 сработал алерт – выросли ошибки в основном сервисе заказов.

02:19 (Situation) Алерт: 5xx в /orders выросли с 0.1% до 35% за 2 минуты. Средний ответ вырос с 150 мс до 5 с.
(Background) Последний деплой – 4 часа назад. Никаких изменений в инфраструктуре не было.
(Assessment) Пока не вижу причины. В графане вижу, что запросы к БД выросли в 10 раз. Кэш Redis отвечает быстро (5 мс), но количество хитов упало в 20 раз.
(Recommendation) Пока смотрим логи приложения и Redis. Апдейт через 5 минут.

02:25 (Situation) 5xx держатся на уровне 30%. Загрузка CPU БД – 95%, большинство запросов таймаутятся.
(Background) В 02:15 в логах кластера Redis был рестарт одного из шардов. С этого момента количество хитов в кэше упало на 80%, количество миссов выросло пропорционально.
(Assessment) Гипотеза: рестарт шарда кэша привёл к потере большей части ключей. Приложение начало делать кэш-миссы и ходить напрямую в БД на каждый запрос. БД не справляется с нагрузкой.
(Recommendation) Предлагаю включить рейт-лимитинг на шлюзе до 50% от текущего трафика, чтобы снизить нагрузку на БД. Параллельно – запустить прогрев кеша. Нужен аппрув от @onacll-orders

Надписи в скобках, это пояснение для примера, в реальном сообщении достаточно соблюдать порядок и писать отдельными абзацами – люди привыкнут и будут читать это как шаблон. Или можно исползовать одну букву для обозначния (многим легче так наполнять).

Почему это помогает
Первый статус честный: пока не вижу причины. Но он уже даёт команде ориентиры – куда смотреть и что проверять. Второй статус показывает прогресс: появилась гипотеза с причиной и предложением конкретного действия. Никакой паники и "всё горит" – только факты, наблюдения и запросы о помощи. Руководитель инцидента за 15 секунд понимает ситуацию, а не тратит минуты на уточняющие вопросы в чате.

Профессиональное реагирование – это не про мгновенное прозрение. Это про структурированный процесс: собрал данные, сформулировал гипотезу, предложил действие. И здесь простой протокол из медицины оказывается полезен нам.

Передача смены: как не потерять контекст в 4 утра

Длительный инцидент – это марафон. В пожарной тактике при длительных работах предусмотрен строгий порядок передачи руководства тушением от одного РТП другому.

Также и в IT должна быть процедура передачи ответственности, которую следует отрабатывать заранее:

  1. Брифинг 1:1. Уходящий и приходящий руководители проводят короткую встречу (5–10 минут).

  2. Основа – протокол инцидента. Новый руководитель изучает его полн��стью до начала работы.

  3. Ключевые моменты брифинга:

    • Текущее состояние инцидента и достигнутый прогресс.

    • Актуальные гипотезы и план на ближайшие 30 минут.

    • Доступные ресурсы и ограничения.

    • Критические точки, где нельзя ошибиться.

  4. Стартовый брифинг. Новый руководитель кратко резюмирует ситуацию для всей команды.

Передача – не формальность. Это гарантия, что контекст не потеряется, а инцидент не затянется на лишние часы из-за путаницы. В пожарных службах переход ответственности считается критически важным этапом операции, а не признаком неудачи .

Постмортем: не ищем виноватого – учимся на системе, а не на людях

Пожарные после тушения крупного пожара проводят After Action Review (AAR) – структурированный разбор без поиска виноватых. Цель – понять, что сработало, что нет, и как улучшить процессы.

В мире SRE это трансформировалось в blameless (необвинительный) постмортем. Ключевой принцип: фокус на системных причинах, а не на человеческих ошибках. Мы это называем это чаще постмортем или разбор инцидента. Ключевой принцип, заимствованный из практик Google SRE – фокус на системных причинах, а не на человеческих ошибках.

Вместо: «Инженер Иван неправильно настроил конфигурацию»

Спросите: «Почему система позволила применить конфигурацию без валидации?», «Как система защищена от неверной конфигурации?»

Каждый вывод должен превращаться в конкретное действие с ответственным и дедлайном. И главное – эти пункты нужно выполнять. Только так инцидент становится инвестицией в надёжность, а не просто потерянным временем.

Как внедрить это завтра

Не нужно ждать идеального момента. Начните с малого:

  1. На следующем инциденте назначьте роли явно. Даже если их двое – руководитель и техлид. Объявите это в чате

  2. Заведите протокол инцидента по шаблону выше. Назначьте ответственного за его ведение

  3. Попробуйте SBAR для следующего сообщения статуса. Посмотрите, как сократится время на уточнения.

  4. Проведите постмортем по безобвинительной методике. Спросите «почему система позволила?», а не «кто виноват?»

Эти практики не требуют новых инструментов или бюджета. Они требуют дисциплины и готовности признать: хаос при инциденте – это не данность, а следствие отсутствия структуры.

Заключение

Пожарные не тушат пожары интуитивно. У них есть регламенты, отработанные на тысячах реальных ситуаций – и в России, и за рубежом. Мы, как инженеры, любим изобретать собственные велосипеды, но иногда разумнее взять готовое решение и адаптировать его под свои задачи.

Система командования инцидентами, протокол SBAR, протокол инцидента, чёткое распределение ролей – всё это не «теория менеджмента», а инструменты, спасающие жизни в реальном мире. Адаптируйте их для вашего продакшена. Потому что когда горит продакшен, разница между хаосом и контролем измеряется не минутами простоя, а доверием пользователей и вашим собственным выгоранием.

Инциденты неизбежны. Хаос при их обработке нет.

P.S. У больших компаний часто есть публичная документация по работе с инцидентами, потому детали можно подсматривать у них:

UPD 13.02.2026: добавил пример использования SBAR в инциденте