Forward from: Мишка на сервере
Крупнейший сбой Cloudflare с 2019 года: разбор корневой причины и уроки для SRE
Привет, %username%! Думаю ты слышал, что 18 ноября 2025 года в 11:20 UTC Cloudflare полностью потеряла способность маршрутизировать трафик на протяжении 6 часов. Сбой вызвал каскадные ошибки 5xx по всей сети, затронув CDN, WAF, Zero Trust и внутренние системы. По масштабу это самый серьезный инцидент за последние 6 лет.
Корневая причина: неожиданное поведение ClickHouse
Инцидент начался не с DDoS-атаки или сбоя hardware, а с изменения разрешений в ClickHouse:
- В 11:05 команда внесла изменение, разрешив пользователям видеть метаданные таблиц в базе данных r0
- Это изменение привело к тому, что распределенные запросы ClickHouse стали возвращать дублирующиеся строки с метаданными
- Файл конфигурации системы управления ботами, генерируемый каждые 5 минут, внезапно удвоился в размере (превысил лимит в 200 функций ML)
- Некорректный файл был автоматически распространен на все прокси-сервера сети
Техническая цепочка сбоя
- 11:05 — Изменение доступа к ClickHouse.
- 11:20 — Некорректный файл конфигурации ботов достиг прокси-серверов.
- 11:28 — FL2 (новая версия прокси) начала возвращать HTTP 5xx.
- 11:30-13:05 — Инженеры искали проблему, изначально подозревая DDoS и Workers KV.
- 13:05-13:37 — Временный откат Workers KV и Access, частичное улучшение.
- 14:24 — Прекращена генерация новых файлов конфигурации.
- 14:30 — Ручная установка правильного файла, перезапуск FL2.
- 17:06 — Полное восстановление всех систем.
Затронутые сервисы
- Основной трафик: HTTP 5xx ошибки на 80% запросов.
- Turnstile: Полная недоступность (аутентификация CAPTCHA).
- Workers KV: Повышенная задержка и ошибки.
- Cloudflare Access: Невозможность входа в панель управления.
- Информационная панель: Прерывистая доступность.
- Email: Задержки в обработке и снижение точности антиспам-фильтрации.
Уроки для инфраструктуры любого масштаба
- Защита от "хороших" изменений: Даже полезные изменения в доступности могут иметь непредсказуемые эффекты.
- Observability must be deeper: Метрики должны показывать не только "что", но и "почему" на каждом этапе конвейера.
- Configuration as a threat: Файлы конфигурации - это потенциальный вектор катастрофического сбоя, требующий защиты на уровне кода.
- Graceful degradation: Система должна работать с устаревшей, но валидной конфигурацией, а не падать от некорректной.
Какая из найденных причин сбоя Cloudflare кажется вам самой неожиданной или недооценённой в крупных инфраструктурах? Что у тебя делается для защиты от подобных каскадных отказов конфигурации в ваших системах? Какие подходы к изоляции и обработке ошибок конфигураций наиболее эффективны по твоему мнению? Какую роль должны играть метрики и observability в быстром выявлении root cause подобных инцидентов? Были ли у тебя в практике инциденты, вызванные изменениями доступа или разрешений в хранимых данных? Какие практики проверки и roll-back конфигурации уже применяются у вас, а какие собираетесь внедрить после анализа кейса Cloudflare? Как реализуется graceful degradation у вас в платформе, и сталкивался ли ты с нарушением этого принципа?
#Cloudflare #SRE #DevOps #Outage #IncidentManagement #Observability
#HighAvailability #FaultTolerance #RootCauseAnalysis #Postmortem #BestPractices #ConfigurationManagement #Microservices
Привет, %username%! Думаю ты слышал, что 18 ноября 2025 года в 11:20 UTC Cloudflare полностью потеряла способность маршрутизировать трафик на протяжении 6 часов. Сбой вызвал каскадные ошибки 5xx по всей сети, затронув CDN, WAF, Zero Trust и внутренние системы. По масштабу это самый серьезный инцидент за последние 6 лет.
Корневая причина: неожиданное поведение ClickHouse
Инцидент начался не с DDoS-атаки или сбоя hardware, а с изменения разрешений в ClickHouse:
- В 11:05 команда внесла изменение, разрешив пользователям видеть метаданные таблиц в базе данных r0
- Это изменение привело к тому, что распределенные запросы ClickHouse стали возвращать дублирующиеся строки с метаданными
- Файл конфигурации системы управления ботами, генерируемый каждые 5 минут, внезапно удвоился в размере (превысил лимит в 200 функций ML)
- Некорректный файл был автоматически распространен на все прокси-сервера сети
Техническая цепочка сбоя
- 11:05 — Изменение доступа к ClickHouse.
- 11:20 — Некорректный файл конфигурации ботов достиг прокси-серверов.
- 11:28 — FL2 (новая версия прокси) начала возвращать HTTP 5xx.
- 11:30-13:05 — Инженеры искали проблему, изначально подозревая DDoS и Workers KV.
- 13:05-13:37 — Временный откат Workers KV и Access, частичное улучшение.
- 14:24 — Прекращена генерация новых файлов конфигурации.
- 14:30 — Ручная установка правильного файла, перезапуск FL2.
- 17:06 — Полное восстановление всех систем.
Затронутые сервисы
- Основной трафик: HTTP 5xx ошибки на 80% запросов.
- Turnstile: Полная недоступность (аутентификация CAPTCHA).
- Workers KV: Повышенная задержка и ошибки.
- Cloudflare Access: Невозможность входа в панель управления.
- Информационная панель: Прерывистая доступность.
- Email: Задержки в обработке и снижение точности антиспам-фильтрации.
Уроки для инфраструктуры любого масштаба
- Защита от "хороших" изменений: Даже полезные изменения в доступности могут иметь непредсказуемые эффекты.
- Observability must be deeper: Метрики должны показывать не только "что", но и "почему" на каждом этапе конвейера.
- Configuration as a threat: Файлы конфигурации - это потенциальный вектор катастрофического сбоя, требующий защиты на уровне кода.
- Graceful degradation: Система должна работать с устаревшей, но валидной конфигурацией, а не падать от некорректной.
Какая из найденных причин сбоя Cloudflare кажется вам самой неожиданной или недооценённой в крупных инфраструктурах? Что у тебя делается для защиты от подобных каскадных отказов конфигурации в ваших системах? Какие подходы к изоляции и обработке ошибок конфигураций наиболее эффективны по твоему мнению? Какую роль должны играть метрики и observability в быстром выявлении root cause подобных инцидентов? Были ли у тебя в практике инциденты, вызванные изменениями доступа или разрешений в хранимых данных? Какие практики проверки и roll-back конфигурации уже применяются у вас, а какие собираетесь внедрить после анализа кейса Cloudflare? Как реализуется graceful degradation у вас в платформе, и сталкивался ли ты с нарушением этого принципа?
#Cloudflare #SRE #DevOps #Outage #IncidentManagement #Observability
#HighAvailability #FaultTolerance #RootCauseAnalysis #Postmortem #BestPractices #ConfigurationManagement #Microservices