18 листопада 2025 року інтернет-гігант Cloudflare пережив найгіршу аварію за останні шість років. Протягом кількох годин мільйони сайтів по всьому світу просто не працювали, показуючи користувачам помилки 5xx. Що саме трапилось і чому така банальна зміна в базі даних привела до глобального колапсу?
О 11:20 за UTC мережа Cloudflare почала масово видавати помилки. Для звичайних користувачів це означало одне: сайти, які вони намагались відкрити, просто не завантажувались. Спочатку в компанії навіть припустили, що це чергова DDoS-атака типу Aisuru, яка останнім часом дошкуляла багатьом сервісам. Але насправді причина виявилась набагато прозаїчнішою — і водночас показовішою.
Що пішло не так
Уся історія почалась з нешкідливої на перший погляд зміни. О 11:05 інженери Cloudflare оновили налаштування доступу до кластера ClickHouse — системи управління базами даних. Мета була благородною: покращити безпеку розподілених запитів, дозволивши користувачам бачити метадані всіх таблиць, до яких вони мають доступ.
Проблема виникла через те, що один із SQL-запитів у системі Bot Management не фільтрував результати за назвою бази даних. Після зміни прав доступу цей запит почав повертати дубльовані рядки — одні з основної бази даних default, інші з внутрішньої r0. Файл конфігурації, який містив близько 60 параметрів для машинного навчання, раптом подвоївся в розмірі.
Ефект доміно
Кожні п'ять хвилин система генерувала новий конфігураційний файл і розповсюджувала його по всій мережі Cloudflare. Якщо запит потрапляв на оновлений вузол кластера — файл виходив "поганим", якщо на старий — "хорошим". Тому сервіс то падав, то відновлювався, що спочатку заплутало інженерів.
Модуль Bot Management у проксі-сервері мав жорстке обмеження: максимум 200 параметрів для роботи моделі машинного навчання. Коли прийшов файл з понад 200 параметрами, система просто "запанікувала" — так у Rust називається аварійне завершення програми через необроблену помилку. Результат: масові помилки 5xx для всіх, хто використовував Bot Management.
Хто постраждав
Аварія зачепила не лише основну CDN-мережу Cloudflare. У зоні ураження опинились:
- Turnstile — система захисту від ботів перестала завантажуватись, блокуючи вхід користувачів на багато сайтів.
- Workers KV — хмарне сховище даних видавало масу помилок, оскільки залежало від проксі-сервера.
- Dashboard — панель керування Cloudflare стала недоступною для більшості користувачів через проблеми з Turnstile.
- Access — сервіс аутентифікації відмовляв у доступі практично всім користувачам до 13:05.
- Email Security — хоча пошта працювала, точність виявлення спаму тимчасово знизилась.
Як вирішували
Найцікавіше в цій історії — як команда Cloudflare справлялась з проблемою. Спочатку вони йшли хибним слідом, намагаючись обмежити трафік до Workers KV, думаючи, що проблема саме там. О 13:05 вдалось обійти проксі для Workers KV та Access, що трохи полегшило ситуацію.
Справжнє рішення прийшло о 14:24, коли команда зупинила генерацію нових конфігураційних файлів Bot Management і вручну впровадила стару, робочу версію. О 14:30 основний трафік відновився, а о 17:06 — повністю запрацювали всі сервіси.
Ця аварія — чудовий приклад того, як незначна зміна в одній частині системи може обвалити всю інфраструктуру. Cloudflare вже оголосив про плани посилення захисту: жорсткіша валідація конфігураційних файлів, більше "аварійних вимикачів" для критичних функцій, обмеження ресурсів для систем діагностики помилок.
Головне питання залишається відкритим: чи достатньо надійними є сучасні інтернет-інфраструктури, якщо один SQL-запит без фільтра може покласти половину інтернету?