Два сбоя Cloudflare: что пошло не так и как они это чинят

Вроде на дворе уже май, а в памяти ещё свежи невероятные сбои в работе Cloudflare, которые положили чуть ли не половину интернета. У компании произошло два масштабных сбоя: 18 ноября 2025 и 9 декабря 2025. Представьте, сколько денег потеряли бизнесы, зависимые от Cloudflare, и сколько нервных клеток было сожжено в эти дни.

Cloudflare опубликовала подробные пост мортемы, почему это произошло. Но они на этом не остановились и (как и положено при хорошем пост мортеме) начали внедрять изменения, чтобы подобных сбоев больше не произошло. План они назвали «Code Orange: Fail Small» и суть его заключалась в том, чтобы стать более устойчивыми к ошибкам или отключениям, защитившись от масштабных сбоев.

⭐️ Интересные идеи ➡️ Оба сбоя произошли по схожим причинам: массовый деплой изменений в конфигурации сразу на все ЦОДы. Оказалось, что Cloudflare довольно внимательно подходят к релизам изменений в коде (куча quality gates, канареечные релизы и так далее), а конфиги раскатывают «как есть». После сбоев они решили применить для релиза конфигов модель релиза кода.

➡️ Оба сбоя разломали не только анализ клиентского трафика, но и множество связанных вещей (например, контрольную панель клиентов Cloudflare). При этом Cloudflare прекрасно понимают, что ошибки и сбои всё равно будут случаться, поэтому нужно научиться обрабатывать их наименее болезненным способом. Произошедшие сбои показали, что архитектура Cloudflare отличается высокой связанностью и поэтому они решили пересмотреть контракты, чтобы локальные ошибки не каскадировались.

➡️ Исправление сбоев было замедлено внутренними процедурами безопасности. С одной стороны, Cloudflare – это компания, которая сама занимается безопасностью, но с другой стороны её внутренние системы безопасности и циклические зависимости затормозили работу инженеров, которые не могли получить доступы к инструментам, необходимым для отладки. Сбои стали для них поводом пересмотреть свои процедуры быстрого получения доступов.

Для меня ключевой тейк этой статьи заключается в поводе подумать о том, что стоит провести pre mortem и подумать: где нам будет мучительно больно, если вдруг продакшену станет очень плохо? Я уверен, что у каждого читателя в голове сразу всплывёт пара-тройка идей (например, у меня всплыли наши долгие получения доступов к продовым ns кубера).

Приятного чтения 😉 ➖➖➖➖➖➖➖➖➖➖➖ 📝 @ulshinblog