ПостКрупнейший сбой Cloudflare с 2019 года: разбор корневой причины и уроки для SRE

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