Крупнейший сбой 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