План реагирования на инциденты: пошаговое руководство для веб-команд

Зачем нужен план реагирования на инциденты

Инциденты случаются. Серверы падают, деплои ломают продакшен, базы данных повреждаются, проверку SSL истекают, DNS-пропагация не работает, а DDoS-атаки приходят в 3 часа ночи. Разница между командами, которые справляются хорошо, и командами, которые впадают в хаос — не в технических навыках, а в подготовке.

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

Уровни серьёзности инцидентов

Не все инциденты одинаковы. Определите уровни серьёзности для правильной реакции:

Роли при реагировании

Чёткие роли предотвращают путаницу в стрессовых ситуациях:

• Командир инцидента (IC) — владеет инцидентом от обнаружения до разрешения. Принимает решения, делегирует задачи, ведёт таймлайн. НЕ занимается технической отладкой — его задача координация
• Технический лид — ведёт расследование и исправление. Сообщает результаты IC
• Лид коммуникаций — управляет внешними коммуникациями: обновления статус-страницы, уведомления клиентов, ответы в соцсетях
• Скрайб — документирует всё в реальном времени: таймлайн, действия, решения. Становится основой пост-инцидентного разбора

В небольших командах один человек может совмещать роли, но IC и Технический лид должны быть разными людьми.

Фаза 1: Обнаружение

Чем быстрее обнаружен инцидент, тем меньше ущерб. Источники обнаружения:

• Автоматический мониторинг сайтов — проверки доступности, алерты на частоту ошибок, пороги задержки. Инструменты вроде Enterno.io обнаруживают недоступность за минуты и уведомляют через email, Slack, Telegram или вебхук
• Синтетический мониторинг — плановые проверки, имитирующие действия пользователя
• RUM (Real User Monitoring) — данные о производительности и ошибках с клиентской стороны
• Сообщения клиентов — тикеты поддержки, жалобы в соцсетях

Цель: обнаруживать инциденты в течение 5 минут. Если первыми сообщают клиенты — мониторинг не справился.

Фаза 2: Сортировка и оценка

После обнаружения быстро оцените инцидент:

• Каков масштаб влияния? (затронутые пользователи, влияние на выручку, данные под угрозой)
• Какой уровень серьёзности?
• Каков вероятный охват? (один сервис, вся платформа, конкретный регион)
• Ситуация ухудшается или стабильна?

Решение: назначить серьёзность, активировать IRP, назначить IC, уведомить дежурную команду.

Фаза 3: Локализация

Остановите ущерб до выяснения корневой причины:

• Откат — если инцидент совпал с недавним деплоем, откатывайте немедленно. Самый быстрый путь
• Изоляция — если один сервис вызывает каскадные отказы, изолируйте его (circuit breaker, feature flag, DNS)
• Масштабирование — если проблема в трафике, увеличьте мощности
• Блокировка — при атаке блокируйте вредоносный трафик (WAF, IP-блокировка, rate limiting)
• Перенаправление — переключите трафик на резервную систему или страницу обслуживания

Цель локализации — не идеальный фикс, а немедленное снижение ущерба. Быстрый workaround за 10 минут лучше идеального решения за 2 часа.

Фаза 4: Разрешение

С локализованным ущербом работайте над настоящим исправлением:

• Определите корневую причину через логи, метрики и трейсы
• Реализуйте и протестируйте исправление на стейджинге
• Задеплойте с усиленным мониторингом
• Убедитесь, что фикс решил проблему (проверьте ошибки, задержку, отзывы пользователей)
• Уберите временные меры локализации

Фаза 5: Коммуникация

Коммуникация идёт на протяжении всего инцидента:

• Статус-страница — обновляйте при каждой смене фазы (расследуем, определили, мониторим, решено)
• Внутренние обновления — каждые 30 минут или при смене фазы
• Коммуникация с клиентами — для SEV-1/SEV-2 проактивное уведомление о влиянии и ETA
• Краткое резюме для руководства — бизнес-влияние и сроки

Фаза 6: Пост-инцидентный разбор

Самая важная фаза — и чаще всего пропускаемая. В течение 48 часов проведите безобвинительный разбор (ретроспективу):

• Таймлайн — восстановите, что именно произошло, когда и какие действия были предприняты
• Анализ корневой причины — используйте технику «5 Почему» для проникновения глубже непосредственного триггера
• Что сработало хорошо — какие части реагирования были эффективны? Что мониторинг обнаружил рано?
• Что пошло не так — где реагирование дало сбой? Какой информации не хватало?
• Действия — конкретные, назначенные, ограниченные по срокам улучшения для предотвращения повторения

Ключевой принцип: безобвинительность. Разбор исследует системы и процессы, а не людей. «Почему система это допустила?» а не «Кто это сделал?»

Чеклист для вашего IRP

• Определения уровней серьёзности с SLA по времени реакции
• Расписание дежурств и пути эскалации
• Определения ролей (IC, Тех. лид, Комм. лид, Скрайб)
• Шаблоны коммуникаций для статус-страницы, email и мессенджеров
• Ранбуки для типичных инцидентов (откат деплоя, отказ БД, DDoS, истечение сертификата)
• Доступы — убедитесь, что дежурные имеют доступ к продакшену ДО инцидента
• Процедуры «боевого штаба» — выделенный канал, видеозвонок, общий дашборд
• Шаблон и процесс пост-инцидентного разбора

Заключение

План реагирования превращает хаотичное тушение пожаров в структурированный, повторяемый процесс. Определите уровни серьёзности, назначьте чёткие роли, задокументируйте ранбуки и регулярно практикуйтесь. Инвестируйте в мониторинг (с инструментами вроде Enterno.io) для быстрого обнаружения. И никогда не пропускайте пост-инцидентный разбор — так команды учатся справляться с инцидентами, которые неизбежно будут.