Первые 15 минут инцидента: регламент, который не даёт паниковать

MAATRIX

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

Почему именно первые 15 минут решают всё

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

Есть и вторая ловушка — распыление. Без заранее розданных ролей за одну проблему в панике хватаются два-три человека, каждый лезет в свою консоль, никто не координирует действия, а после инцидента невозможно восстановить, кто что менял и в каком порядке. Разбор такого инцидента превращается в допрос по памяти, а не в чтение таймлайна.

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

Важная оговорка: этот регламент — не план восстановления (runbook) для конкретной проблемы и не полноценный incident response plan для случая взлома, где на первом месте — не уничтожить улики. Здесь речь о первых 15 минутах любого серьёзного инцидента доступности: сайт лежит, сервис не отвечает, а что именно случилось — вы ещё не знаете. Задача этих минут — не починить, а перевести ситуацию из хаоса в управляемое состояние, из которого дальше можно чинить осознанно.

Минута 0-3: подтвердить масштаб, а не верить одному сообщению

Первая реакция на сообщение "у меня не открывается сайт" — не бросаться чинить, а проверить, насколько это вообще массовая проблема. Одно сообщение от одного пользователя может означать что угодно: проблему на его стороне (провайдер, DNS-кэш, заблокированный IP), баг в конкретном сценарии или действительно масштабную аварию. Реагировать на каждое единичное сообщение как на P1-инцидент — верный способ выгореть на ложных тревогах; не реагировать вовсе — способ пропустить реальный.

Минимальный чек за первые пару минут:

• Проверить статус-страницу мониторинга (Uptime Kuma, Zabbix, любой внешний чекер) — упал ли алерт независимо от жалобы пользователя.
• Открыть сайт/сервис самостоятельно с чистого устройства или через внешний сервис проверки (не из офисной сети — она может быть в другом маршруте до сервера).
• Проверить, есть ли ещё жалобы — в почте поддержки, в Telegram-чате, в тикетах — за последние 10-15 минут.
• Если есть внешний аптайм-монитор с несколькими точками наблюдения — посмотреть, фиксируют ли падение хотя бы 2 из 3 локаций (одна точка может врать из-за проблем на своей стороне).

# быстрая проверка снаружи, если под рукой только консоль
curl -o /dev/null -s -w "%{http_code} %{time_total}s\n" https://example.com
curl -o /dev/null -s -w "%{http_code} %{time_total}s\n" https://example.com/api/health

Если оба сигнала — и мониторинг, и внешняя проверка — подтверждают проблему, это официально инцидент, и дальше по регламенту. Если подтверждения нет, это ещё не повод расслабляться: возможно, проблема локальная (регион, конкретный провайдер, конкретный браузер) — тогда сужаем масштаб и разбираемся точечно, не поднимая всю команду. Здесь же полезно подключить мониторинг и алерты при падении сайта — если он настроен заранее, этот шаг занимает 30 секунд, а не пять минут догадок.

Отдельная грабля: не путайте "сайт не открывается у меня" с "сайт лежит". Разница может быть в DNS, в блокировке IP на конкретном провайдере, в устаревшем кэше браузера. Именно поэтому подтверждение масштаба — обязательный шаг: он экономит часы, которые иначе уйдут на лечение несуществующей проблемы.

Минута 3-6: оповестить нужных людей по заранее известному списку

Если масштаб подтверждён, следующий шаг — не диагностика, а оповещение. Это контринтуитивно: хочется сразу лезть чинить. Но если оповещение отложить, "потом" обычно наступает через 40 минут, когда уже не остаётся сил написать про то, что происходит, — а команда тем временем работает вслепую, не зная, кто уже в курсе и кто чем занят.

Регламент должен заранее отвечать на три вопроса, а не решать их в моменте:

1. Кого оповещать — конкретные роли и контакты, не "кого-нибудь из разработки". Обычно: ответственный инженер (кто чинит), тимлид или технический руководитель (кто принимает решения по эскалации), человек, отвечающий за коммуникацию с клиентами (кто пишет статус-апдейты).
2. По какому каналу — отдельный канал/чат именно для инцидентов, не общий рабочий чат, где сообщение потеряется среди обсуждения дизайна кнопки. Плюс резервный канал (звонок, SMS), если основной недоступен — он тоже может лежать вместе с остальной инфраструктурой.
3. Что писать в первом сообщении — минимальный шаблон, чтобы не тратить время на формулировки под давлением:

[ИНЦИДЕНТ] <название сервиса> недоступен
Обнаружено: 14:32
Подтверждено: мониторинг + внешняя проверка
Масштаб: похоже, весь сервис (или: только раздел X)
Кто занимается: <имя>
Статус: диагностика началась

Смысл этого шага не в бюрократии, а в том, чтобы не тратить критическое время на вопрос "кому вообще писать" именно тогда, когда думать некогда. Если у команды заранее есть проверенный список контактов и обязанностей на случай аварии, можно свериться по нему за секунды, а не вспоминать, кто сейчас отвечает за эту зону.

Отдельно стоит решить заранее: кто имеет право объявить инцидент официально. Без этого правила случается обратная проблема — все ждут, пока кто-то скажет "да, это инцидент", а по факту его никто не объявляет, и работа идёт неформально, без записи и координации.

Минута 5-8 (параллельно): начать фиксировать таймлайн с первой секунды

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

Таймлайн не обязан быть красивым — подойдёт общий текстовый документ, тред в канале инцидента или файл прямо на сервере:

14:32  Первая жалоба от клиента в поддержку
14:34  Подтверждено мониторингом, объявлен инцидент
14:36  Оповещена команда, канал #incident-2026-08-27
14:38  Диагностика: проверка nginx, БД, диска
14:41  Обнаружено: диск /var заполнен на 100%, БД пишет в WAL
14:43  Начата очистка старых логов, освобождение места
14:47  Место освобождено, БД снова принимает записи
14:49  Сайт отвечает 200 на всех проверках
14:52  Финальное подтверждение стабильности (5 минут без ошибок)

Зачем это нужно именно с первых минут, а не задним числом:

• Для разбора после инцидента. Качественный разбор инцидента держится на точной последовательности событий — без неё выводы будут спекулятивными, а не основанными на фактах.
• Для координации в моменте. Если в канал заходит новый человек (например, эскалировали к более опытному инженеру), таймлайн — это способ ввести его в курс за 10 секунд, а не пересказывать всё заново.
• Для оценки того, что уже пробовали. Без записи легко повторить одно и то же действие дважды или, наоборот, забыть, что гипотеза уже проверена и отклонена.

Практический совет: не совмещайте роль "кто чинит" и "кто пишет таймлайн" в одном человеке, если команда позволяет разделить эти роли — инженер, который одновременно набирает команды в консоли и ведёт хронологию, хуже справляется с обеими задачами.

Минута 8-11: решить, нужно ли сообщать пользователям

Это решение часто откладывают до последнего — "напишем, когда точно разберёмся" — и это ошибка в обе стороны: слишком раннее сообщение может быть неточным, а слишком позднее оставляет пользователей в неведении и увеличивает поток одинаковых обращений в поддержку, которые отвлекают команду от инцидента.

Ориентир для решения — не точность диагноза, а сам факт: если проблема подтверждена и масштабна (недоступен сайт, не проходят платежи, не работает ключевая функция), пользователей стоит уведомить, даже если причина ещё не найдена. Формулировка на этом этапе не обязана содержать техническую причину — она должна содержать факт и обещание держать в курсе:

Мы знаем о проблемах с доступностью сайта.
Команда уже работает над решением.
Следующее обновление — через 20 минут или раньше, если ситуация изменится.

Здесь стоит заранее решить два организационных вопроса, а не изобретать их в моменте:

• Где публиковать статус — отдельная статус-страница (даже минимальная, на Uptime Kuma или другом self-hosted решении), соцсети, баннер на самом сайте (если он частично доступен), рассылка по email для критичных для бизнеса клиентов.
• Кто формулирует текст — не инженер, который чинит проблему: под давлением велик соблазн написать слишком технично или слишком неточно ("уже почти починили", хотя это не факт). Как писать клиентам после инцидента, не усугубляя ситуацию — отдельная тема, но базовое правило работает уже здесь: короткие точные апдейты без обещаний, которые можете не выполнить.

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

Минута 10-15: диагностика по чек-листу, а не хаотичный перебор

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

Заранее подготовленный чек-лист решает эту проблему — не находит причину за вас, а задаёт порядок проверки самых частых причин недоступности, от простого к сложному:

Важное правило этого шага: одно изменение за раз, с записью в таймлайн до и после. Если проверили гипотезу и она не подтвердилась — явно зафиксировали это в таймлайне и перешли к следующей, а не оставили половину команды "на всякий случай" крутить старую гипотезу параллельно с новой.

Если за 15 минут причина не найдена и проблема продолжается — это сигнал к эскалации: подключить более опытного специалиста, поднять приоритет, при необходимости связаться с поддержкой хостера. Регламент первых 15 минут не обещает решить проблему за 15 минут — он обещает, что к этому моменту у вас есть подтверждённый масштаб, оповещённая команда, растущий таймлайн, принятое решение по коммуникации и структурированная диагностика. Дальше — уже работа по существу проблемы, а не по организации хаоса вокруг неё.

Держите под рукой готовый скрипт или шпаргалку с этими командами прямо на сервере или в закреплённом сообщении канала инцидентов — при стрессе легко забыть даже базовый флаг -h у df.

Как довести регламент до состояния "реально работает"

Написанный документ, который никто не открывал полгода, в момент инцидента будет либо забыт, либо неактуален. Несколько правил, которые делают регламент рабочим, а не формальностью:

• Держите регламент отдельно от систем, которые может задеть авария. Если единственная копия лежит на wiki, размещённой на том же сервере, что и продакшн, — в момент инцидента вы её не откроете. Храните копию независимо: в облаке, в закреплённом сообщении мессенджера, в распечатанном виде у ответственных.
• Проверяйте актуальность контактов раз в квартал. Люди меняют номера, увольняются, меняются роли — регламент с устаревшими контактами создаёт ложное чувство подготовленности.
• Прогоняйте регламент на учениях, а не только на реальных авариях — без практики в тексте остаются пробелы, которые вскрываются только под реальным давлением.
• После каждого реального инцидента дополняйте регламент, если что-то пошло не так именно в организационной части — это дешевле, чем повторять ту же ошибку в следующий раз.

Частые вопросы