Три часа ночи. Телефон разрывается от алертов. Сайт не отвечает. Мониторинг показывает аномальный трафик. Это DDoS-атака. Что делать?
В этой статье — полный гайд по управлению инцидентами при DDoS-атаках. От первых минут паники до спокойного post-mortem на следующей неделе. Эти практики основаны на опыте Google SRE, Netflix, и других компаний, которые регулярно сталкиваются с атаками.
Почему важен процесс
Во время инцидента мозг работает в режиме стресса. Креативность падает, память ухудшается, легко сделать глупую ошибку. Поэтому нужен заранее отработанный процесс — runbook, который можно выполнять механически.
Компании без процесса во время атаки:
- Паникуют и делают случайные изменения
- Не координируются — один чинит, другой ломает
- Забывают уведомить клиентов и руководство
- Не документируют действия — потом не могут понять что произошло
- Повторяют одни и те же ошибки
Компании с процессом:
- Спокойно следуют плану
- Чётко распределяют роли
- Коммуницируют по установленным каналам
- Документируют каждый шаг
- Учатся на каждом инциденте
flowchart TD
A[Алерт: аномалия] --> B{Это атака?}
B -->|Да| C[Активировать защиту]
B -->|Нет| D[Мониторинг]
C --> E[Включить WAF]
E --> F[Rate limiting]
F --> G{Продолжается?}
G -->|Да| H[Under Attack Mode]
G -->|Нет| I[Мониторинг 30 мин]
H --> J{Помогло?}
J -->|Нет| K[Провайдер]
J -->|Да| I
I --> L[Инцидент закрыт]
K --> L
Severity Levels
Не все инциденты одинаковы. Небольшой всплеск трафика и полная недоступность сайта требуют разного уровня реагирования. Определите severity levels заранее.
Основа
30-60 минут
Мини-защита
1 день
Система
1-2 недели
Устойчивость
Постоянно
Роли в команде реагирования
Во время инцидента люди должны знать свои роли. Без чёткого распределения — хаос: все делают одно и то же или, наоборот, важные вещи никто не делает.
Первые 15 минут
Первые минуты инцидента — самые важные. Вот чек-лист действий:
Проверьте алерты — это реальная проблема или ложное срабатывание? Откройте сайт из разных локаций (используйте downfor.io, isitdown.site или VPN). Посмотрите метрики: RPS, error rate, response time. Убедитесь что проблема существует.
Создайте incident channel в Slack/Teams (например #incident-2024-01-15-ddos). Напишите первое сообщение: что происходит, severity, кто IC. Призовите нужных людей (@oncall, @security). С этого момента всё обсуждение — только в incident channel.
Включите экстренную защиту: Cloudflare Under Attack Mode, блокировка подозрительных IP/стран, увеличьте rate limits. Цель — стабилизировать сервис, даже если не идеально. Полное решение — потом.
Обновите status page (StatusPage, Cachet, Instatus). Отправьте первое сообщение клиентам: 'Мы обнаружили проблему, работаем над решением'. Уведомите руководство через заранее согласованный канал. Не ждите полной информации — коммуницируйте что знаете.
INCIDENT DECLARED
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Severity: SEV1 (Critical)
Started: 2024-01-15 03:42 UTC
Status: Investigating
What's happening:
- Main website returning 503 errors
- Abnormal traffic spike detected (10x normal)
- Suspected DDoS attack
Incident Commander: @alice
Tech Lead: @bob
Comms Lead: @carol
Current actions:
- Enabling Cloudflare Under Attack mode
- Analyzing traffic patterns
Next update: in 15 minutes
All discussion in this channel only.Диагностика атаки
После первичной митигации нужно понять характер атаки. Это поможет выбрать правильную стратегию защиты.
Вопросы для диагностики
- Какой тип атаки? — L3/L4 (volumetric — много трафика) или L7 (application — много запросов к динамике)? Подробнее: виды атак L3/L4/L7.
- Откуда идёт трафик? — Один IP, подсеть, страна или распределённый botnet?
- Какие URL атакуют? — Главная страница, API, поиск, login?
- Какие паттерны? — Одинаковые User-Agent, специфичные заголовки, характерные payload'ы?
- Когда началось? — Резко или постепенно нарастало? (как отличить от поломки)
Команды для анализа
Стратегии митигации
В зависимости от типа атаки применяются разные стратегии. Часто нужна комбинация нескольких подходов.
Коммуникация во время инцидента
Коммуникация во время инцидента часто важнее технического решения. Клиенты могут простить даунтайм, но не простят молчание или ложь.
Принципы коммуникации
- Коммуницируйте рано — первое сообщение через 15 минут после начала инцидента, даже если не знаете деталей.
- Коммуницируйте часто — обновления каждые 30-60 минут для SEV1, каждые 2 часа для SEV2.
- Будьте честны — не преуменьшайте проблему, не обещайте то, что не можете гарантировать.
- Признавайте влияние — покажите что понимаете как это влияет на клиентов.
- Давайте ETA осторожно — лучше "работаем над решением" чем "починим через час" (и не починить).
Status Page
Status page (Statuspage, Cachet, Instatus и др.) — главный канал коммуникации с клиентами. Убедитесь что:
- Он хостится отдельно от основного сайта (иначе упадёт вместе с ним)
- Вы можете обновлять его из любой сети (не требует VPN в офис)
- Клиенты знают о его существовании (ссылка в футере, в документации)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
INITIAL (Investigating)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
We are investigating reports of degraded performance
on [service name]. Some users may experience slow
load times or errors.
Our team is actively working to identify and resolve
the issue. We will provide updates as we learn more.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
UPDATE (Identified)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
We have identified the cause of the issue affecting
[service name]. Our infrastructure is experiencing
a high volume of malicious traffic (DDoS attack).
We have engaged our DDoS mitigation systems and are
working to filter malicious traffic while preserving
access for legitimate users.
We apologize for the disruption and appreciate your
patience.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
UPDATE (Monitoring)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
We have implemented mitigation measures and are seeing
improvement in service availability.
Some users may still experience brief delays while we
fine-tune our filters.
We are continuing to monitor the situation closely.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
RESOLVED
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The issue has been resolved. [Service name] is now
operating normally.
Our security team successfully mitigated a DDoS attack
that began at [time] and lasted approximately [duration].
We apologize for any inconvenience caused. A detailed
incident report will be published within 48 hours.Завершение инцидента
Инцидент не заканчивается когда сервис восстановлен. Нужно убедиться в стабильности, откатить временные меры и задокументировать произошедшее.
Критерии завершения
- Сервис полностью функционален минимум 30 минут
- Метрики вернулись к нормальным значениям
- Нет признаков продолжающейся атаки
- Все временные митигации задокументированы
Действия после восстановления
- Monitoring period — наблюдайте 1-2 часа перед снятием усиленной защиты
- Постепенный откат — снимайте защитные меры по одной, наблюдая за метриками
- Финальное обновление — сообщите клиентам что инцидент закрыт
- Сохраните логи — убедитесь что логи периода атаки сохранены для анализа
- Назначьте post-mortem — запланируйте встречу на ближайшие 24-48 часов
Post-Mortem
Post-mortem (или incident review) — это разбор инцидента с целью извлечь уроки и предотвратить повторение. Это НЕ поиск виноватых — это анализ системы.
Blameless Culture
Ключевой принцип эффективных post-mortem — blameless culture. Мы анализируем системы и процессы, не людей. Если человек сделал ошибку — значит система позволила эту ошибку сделать. Как изменить систему, чтобы ошибка стала невозможной?
Почему это важно:
- Люди честно рассказывают что произошло, не боясь наказания
- Находятся реальные причины, а не козлы отпущения
- Команда учится, а не прячет проблемы
Структура post-mortem документа
# Incident Post-Mortem: DDoS Attack on 2024-01-15
## Summary
Brief description of the incident in 2-3 sentences.
## Impact
- Duration: 2 hours 15 minutes
- User impact: 100% users unable to access service
- Revenue impact: ~$X,XXX in lost transactions
- SLA impact: Monthly uptime dropped to 99.7%
## Timeline (all times UTC)
- 03:42 - First alerts triggered (high error rate)
- 03:45 - On-call engineer acknowledges alert
- 03:48 - Incident declared, SEV1
- 03:52 - Cloudflare Under Attack mode enabled
- 04:15 - Traffic pattern analyzed, geo-blocking CN enabled
- 04:45 - Service partially restored
- 05:30 - Custom WAF rules deployed
- 05:57 - Full service restored
- 06:30 - Incident closed
## Root Cause
What actually caused the problem?
A volumetric L7 DDoS attack targeting /api/search endpoint.
Attack originated from ~50,000 IPs, primarily from CN region.
Peak traffic: 500k RPS (normal: 5k RPS).
The /api/search endpoint was not rate-limited and performed
expensive database queries, making it an attractive target.
## What Went Well
- Alerting detected the issue within 3 minutes
- Team assembled quickly despite 3am time
- Cloudflare mitigation was effective once enabled
- Communication to customers was timely
## What Went Wrong
- No rate limiting on /api/search
- On-call runbook did not include DDoS response
- Took 30 minutes to identify attack pattern
- Geo-blocking decision delayed due to uncertainty
## Action Items
| Action | Owner | Due Date | Status |
|--------|-------|----------|--------|
| Add rate limiting to /api/search | @bob | 2024-01-22 | TODO |
| Update runbook with DDoS section | @alice | 2024-01-20 | TODO |
| Add traffic anomaly detection alerts | @carol | 2024-01-25 | TODO |
| Conduct DDoS response drill | @alice | 2024-02-01 | TODO |
## Lessons Learned
1. Every public API endpoint needs rate limiting
2. Runbooks should cover DDoS scenarios specifically
3. Consider always-on bot protection, not just reactiveДля SEV1/SEV2 — в течение 24-48 часов после инцидента. Пока детали свежи в памяти. Не откладывайте — через неделю люди забудут важные нюансы. Для SEV3 — можно в течение недели или объединить несколько мелких инцидентов.
Все кто был вовлечён в инцидент: IC, tech leads, communications, on-call. Опционально: руководитель (для понимания context), представитель support (знает реакцию клиентов). Не нужно приглашать весь отдел — только тех кто может дать информацию или принять решения по action items.
Action items должны быть конкретными, с owner и due date. Заведите их как задачи в трекере (Jira, Linear). Отслеживайте выполнение на weekly sync. Action items без follow-up бесполезны — инцидент повторится.