Cloudflare назвали причину вчорашнього збою

Вчора Cloudflare зіткнулася з серйозним глобальним збоєм, який призвів до масових HTTP 5xx помилок та недоступності ключових сервісів компанії.

Проблема почалася о 11:20 UTC, коли інтернет-користувачі по всьому світу почали бачити сторінки з помилками замість сайтів, що працюють через Cloudflare. На піку інциденту компанія фактично не могла обробляти більшість основного трафіку.

Cloudflare наголосила, що інцидент не був результатом кібератаки. Причиною стала внутрішня помилка — зміна прав доступу в одній із ClickHouse-баз, через яку система згенерувала некоректний конфігураційний файл для модуля Bot Management. Цей файл був критично важливим, бо саме він визначає параметри для класифікації ботів і оновлюється кожні пʼять хвилин. Після хибного оновлення конфігурація миттєво поширилася мережею та спричинила масштабний збій у проксі-сервісах FL та FL2.

Проблемний файл містив подвоєну кількість параметрів, що перевищувало встановлені межі. Через це модуль Bot Management аварійно падав, що спричинило лавиноподібний каскад помилок у проксі, який почав повертати масові HTTP 5xx.

Кожен модуль у проксі має обмеження, щоб уникнути неконтрольованого споживання пам’яті та заздалегідь резервує ресурси для підвищення продуктивності. У випадку Bot Management існує обмеження на кількість ознак машинного навчання, що можна використовувати під час роботи — зараз ліміт становить 200, тоді як фактичне використання близько 60.

Коли проблемний файл з більш ніж 200 ознаками поширився на сервери, це обмеження було перевищено, що викликало паніку системи. Код FL2 на Rust, який перевіряє ліміт і спричинив необроблену помилку, виглядав так:

Після ідентифікації проблеми о 14:30 UTC Cloudflare зупинила поширення некоректного файлу та вручну оновила його до стабільної версії. Повне відновлення сервісів завершилося о 17:06 UTC.

Які сервіси постраждали найбільше

Збій зачепив практично всі ключові сервіси Cloudflare:

• CDN та системи безпеки — масові HTTP 5xx.
• Turnstile — компонент авторизації не завантажувався.
• Workers KV — різке зростання помилок через недоступність проксі.
• Dashboard — значна частина користувачів не могла ввійти.
• Email Security — тимчасова відсутність доступу до джерела репутації IP.
• Access — масштабні проблеми з автентифікацією.

Усі ці збої були прямим наслідком падіння основного проксі-двигуна FL/FL2, через який проходить фактично весь трафік Cloudflare.

Чому виникла помилка усередині ClickHouse

Корінь інциденту — зміна прав доступу в ClickHouse. Після оновлення користувачі почали бачити не лише таблиці з бази default, а й дублікати з бази r0, де зберігаються фізичні шарди. Саме на ці таблиці вийшов запит, який генерує feature file для Bot Management. У результаті файл став удвічі більшим, що й зламало модуль.

Класичний запит на отримання параметрів для feature file, який раніше повертав одну копію даних, після зміни прав почав повертати дублікати:

SELECT
    name,
    type
FROM system.columns
WHERE
    table = 'http_requests_features'
order by name;

Через доступ до фізичних таблиць r0 замість розподіленої абстракції обсяги даних збільшилися вдвічі, і файл ознак перевищив критичні ліміти, закладені в проксі. Проксі FL2 почав стабільно падати, а старий FL не падав, але повертав нульові оцінки ботів, що спричиняло додаткові помилки та некоректні блокування.

Компанія назвала цю подію найгіршим збоєм за останні шість років та перепросила клієнтів. У Cloudflare заявили, що вже розпочали масштабну роботу з посилення захисту та перевірки внутрішніх механізмів, зокрема вдосконалюють валідацію внутрішніх конфігураційних файлів, запроваджують додаткові глобальні «kill switches», переглядають підхід до обробки помилок, щоб внутрішні звіти не перевантажували систему, а також проводять повний аналіз усіх можливих моделей краху в проксі-модулях.

Хронологія ключових подій

• 11:05 — внесено оновлення прав доступу в ClickHouse.
• 11:28 — початок інциденту, перші помилки.
• 13:05 — Workers KV і Access переведено на резервний режим.
• 14:24 — зупинка генерації некоректних файлів.
• 14:30 — відновлення основного трафіку.
• 17:06 — повне відновлення всіх сервісів.

Нагадаємо, що пару тижнів назад відбувалися глобальні збої в роботі хмарних провайдерів AWS та Azure.