Зачем нужен план реагирования на инциденты
Инциденты случаются. Серверы падают, деплои ломают продакшен, базы данных повреждаются, проверку SSL истекают, DNS propagation не работает, а DDoS-атаки приходят в 3 часа ночи. Разница между командами, которые справляются хорошо, и командами, которые впадают в хаос — не в технических навыках, а в подготовке.
План реагирования на инциденты (IRP) — это документированный процесс, определяющий, что происходит при сбое. Он описывает, кто отвечает, как течёт коммуникация, какие действия предпринимать на каждом этапе и как извлечь уроки. Без него каждый сбой превращается в хаотичную борьбу, где забываются критические шаги, а восстановление занимает гораздо больше времени.
Уровни серьёзности инцидентов
Не все инциденты одинаковы. Определите уровни серьёзности для правильной реакции:
| Уровень | Название | Определение | Время реакции | Пример |
|---|---|---|---|---|
| SEV-1 | Критический | Полный отказ сервиса, потеря данных, нарушение безопасности | Немедленно (минуты) | Сайт недоступен, БД скомпрометирована |
| SEV-2 | Серьёзный | Значительная деградация, основная функция сломана | В течение 30 минут | Оплата не работает, 50% ошибок |
| SEV-3 | Умеренный | Частичная деградация, есть обходной путь | В течение 2 часов | Медленная загрузка, один API документацию-эндпоинт |
| SEV-4 | Низкий | Косметические проблемы, незначительные баги | Следующий рабочий день | Глитч UI, некритичная функция |
Роли при реагировании
Чёткие роли предотвращают путаницу в стрессовых ситуациях:
- Командир инцидента (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) для быстрого обнаружения. И никогда не пропускайте пост-инцидентный разбор — так команды учатся справляться с инцидентами, которые неизбежно будут.