«Фіксили одне — зламали інше»: Cloudflare назвали причину свого нещодавнього збою

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Нещодавно, 5 грудня, у Cloudflare стався другий масштабний збій, який на піку накрив 28% усього HTTP-трафіку, який проходить через сервіси компанії.

Що саме сталося

Cloudflare збільшила ліміт HTTP-тіла запитів з 128 КБ до 1 МБ, щоб закрити критичну вразливість CVE-2025-55182, повязану з React Server Components. Це оновлення викочували поступово.

Паралельно компанія миттєво вимкнула внутрішній WAF-тестовий інструмент, і саме ця зміна стала тригером збою.

У застарілій FL1-версії проксі вимкнення тестового ruleset-у спричинило некоректну обробку правила з дією execute. Lua-модуль отримав nil замість коректного об’єкта та падав із фатальним винятком, через що мережа почала масово повертати HTTP 500:

[lua] Failed to run module rulesets callback late_routing:
... attempt to index field 'execute' (a nil value)

Цікаво, що у новому Rust-проксі FL2 цієї проблеми немає. Збій виникав лише у клієнтів FL1-мережі з увімкненим Cloudflare Managed Ruleset. Cloudflare мала killswitch для екстреного вимкнення проблемних правил, але вперше його застосували до правила з дією execute. Код FL1 не враховував таку ситуацію, тож після вимкнення система отримала фатальний nil у критичному місці пайплайну. І ця помилка роками залишалася непоміченою :)

if rule_result.action == "execute" then rule_result.execute.results = ruleset_results[tonumber(rule_result.execute.results_index)] end

Таймлайн інциденту

Після двох інцидентів за два тижні (18 листопада та 5 грудня) компанія оголосила про масштабні зміни в інфраструктурі. Перш за все компанія посилить поступові викатки і впровадить версіонування конфігурацій. Тепер усі конфігурації проходитимуть ті ж перевірки, що й програмний код, а система отримає автоматичний механізм відкату у разі проблем.

Також Cloudflare оновить аварійні сценарії. Компанія забезпечить доступ до аварійних інструментів навіть під час внутрішніх збоїв, щоб команда могла керувати системою за будь-яких умов і не втрачала контроль у критичних ситуаціях.

І наостанок компанія планує реалізувати логіку, яка не блокує роботу системи при збої. Якщо конфігурація пошкоджена, перевищує встановлені ліміти або не відповідає вимогам схеми, система не має виходити з ладу, а має переходити у безпечний режим роботи та продовжувати функціонувати без критичних зупинок.

Сподіваємося у них все вийде і більше анлаків не буде. Але, як всі ми знаємо, Бог любить трійцю, тому побачимо :)