И вот тут я прям остановилась: это не «улучшили надёжность», а «переделали механизм риска»

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

Звучит почти как кодовое имя из шпионского романа. Но смысл гораздо приземлённее и, честно, важнее: Cloudflare поменяла то, как она выкатывает конфигурации, как откатывает ошибки и как вообще получает доступ к собственной инфраструктуре, если всё пошло не туда.

И это как раз тот случай, когда новость вроде корпоративная, а касается вообще всех, кто хоть раз открывал сайт и видел, что «что-то не грузится». Потому что если у провайдера такого масштаба ломается не один сервер, а сам способ раскатывать изменения по сети, последствия разлетаются очень широко. Ну, неприятная штука, если коротко.

Что именно они сделали — и почему это не просто красивый пресс-релиз

Я полезла разбираться, потому что название «Fail Small» сначала звучит почти как лозунг на кружке. А по факту речь о довольно жёсткой инженерной дисциплине: если что-то идёт не так, ошибка должна зацепить как можно меньшую часть трафика, а не всю сеть сразу.

Главная новость тут — новый внутренний механизм Snapstone. Это, если по-человечески, способ упаковывать конфигурацию в управляемый пакет и выкатывать её постепенно, а не «разом на всё и сразу». То есть не так: нажали кнопку — и поехало по всей глобальной инфраструктуре. А аккуратно, с проверкой состояния в реальном времени и автоматическим откатом, если что-то выглядит подозрительно.

Cloudflare прямо пишет, что теперь для части конфигураций применяется health-mediated deployment — я загуглила, и это по сути «выкатка с оглядкой на здоровье системы»: сначала маленькая порция изменений, потом смотрят, живо ли всё, и только потом расширяют. Для софта это давно не редкость. А вот для конфигов — именно там, где многие компании и спотыкаются — это уже куда интереснее.

Почему их так торопили те самые ноябрь и декабрь

У Cloudflare тут очень конкретный нерв, без абстрактного «мы стали лучше». Компания прямо говорит: эти изменения были бы достаточны, чтобы избежать глобальных отключений 18 ноября и 5 декабря 2025 года.

И вот это, пожалуй, самая любопытная часть. Потому что аварии случились не из-за какого-то космического форс-мажора, а из-за вполне обычных вещей, которые обычно считаются скучными: конфигурационный файл, флаг в глобальной системе, выкатывание изменений. То есть вся эта хрупкость сидела не в какой-то экзотике, а в повседневной инженерной рутине. Серьёзно, иногда самые дорогие проблемы живут в самом будничном месте.

Теперь Cloudflare говорит: если похожая ошибка появится снова, система не будет слепо принимать новый конфиг. Она либо оставит last known good configuration — то есть последнюю известную рабочую версию, — либо уйдёт в режим fail open или fail close в зависимости от сценария.

Тут, кстати, важно не перепутать. Fail open — это когда система, если уж ей плохо, лучше продолжает обслуживать трафик хоть с урезанной функциональностью, чем валится в полный простой. Fail close — наоборот: лучше остановиться, чем пустить опасное или некорректное поведение дальше.

И Cloudflare, судя по описанию, теперь пытается для каждого случая выбрать не абстрактно «правильный», а практический вариант. Это уже похоже не на лозунг, а на реальную инженерную логику.

Мне тут особенно бросилось в глаза слово «blast radius»

Это такой корпоративный термин, который обычно переводят как «радиус поражения». По-человечески: насколько далеко разлетится ошибка, если что-то сломалось.

И вот именно его Cloudflare пытается уменьшить. Для этого сеть начали сильнее дробить на независимые сегменты. Например, отдельные копии сервисов обслуживают разные группы трафика. Если я правильно считываю логику, идея простая: ошибка не должна иметь доступ ко всему сразу.

Даже у Workers — это облачная платформа Cloudflare, где компании запускают код близко к пользователям, почти на краю сети, — выкаты теперь идут по сегментам. Сначала, например, на бесплатных клиентов, потом дальше. И если обновление ломается, оно должно задеть только маленькую долю трафика, а не весь сервис.

Это, кстати, уже не просто «красивая инженерия». Это попытка сделать так, чтобы облачная инфраструктура вела себя как взрослая система: ошиблась — локализовала ущерб, а не устроила глобальный спектакль.

Аварийный доступ — это тоже часть истории, и тут я даже немного вздохнула

Cloudflare ещё и пересмотрела свои break glass процедуры. Это, если совсем по-простому, аварийные «стеклянные кнопки»: способы получить срочный доступ к системам, когда обычные защищённые пути недоступны.

Проблема, как выяснилось, в том, что Cloudflare сама же живёт на своих же продуктах безопасности. А если из-за сетевого сбоя эти инструменты тоже отваливаются, получается странная петля: чтобы починить инфраструктуру, нужно добраться до инструментов, которые сами уже не работают как надо. Ну, прекрасная корпоративная загадка, правда?

Поэтому компания говорит, что провела аудит критичных сервисов, сделала резервные пути авторизации для 18 ключевых систем и добавила аварийные скрипты и прокси. То есть теперь, если инцидент действительно большой, у команды должно быть больше способов не просто смотреть на проблему, а реально влезть в неё и починить.

Я честно не уверена, что это уже работает — и вот почему мне так кажется

Реальная польза, конечно, в том, что Cloudflare меняет не одну конкретную болячку, а сам принцип: как изменения попадают в сеть, как они откатываются и как далеко может улететь ошибка. Это уже похоже на системную работу, а не на «ну мы после инцидента ещё раз поговорили на совещании».

Но подвох, конечно, есть. И он вполне взрослый. Компания сама пишет, что улучшение надёжности никогда не бывает делом «готово и забыли». Новые меры должны пройти проверку в реальной эксплуатации. Потому что красиво описать постепенный rollout — это одно. А выдержать тысячи конфигураций, разные продуктовые команды и живую, постоянно меняющуюся глобальную сеть — совсем другое.

Меня тут цепляет именно это: Cloudflare уже не рассказывает абстрактно про resilience, а признаёт, что уязвимым местом были вполне конкретные механизмы выката и аварийного доступа. Это честнее, чем обычный корпоративный туман. Но и верить на слово тут, конечно, не хочется. Хочется увидеть, как это переживёт следующий сложный день.

Если ваш сайт лежал в ноябре или декабре — теперь понятно, где была дыра

Если вы пользуетесь сервисами, которые завязаны на Cloudflare, вся эта история — довольно прямое объяснение того, почему что-то внезапно переставало работать. И, по идее, вероятность, что это повторится, должна стать ниже. Если что-то и пойдёт не так, то теперь сбой должен быть короче и «уже» по радиусу — то есть затронуть меньше людей.

Когда я читаю про эти постепенные выкаты, мне сразу хочется, чтобы каждый, кто хоть раз дрожащей рукой нажимал «задеплоить» в пятницу вечером, понимал: инфраструктура не должна быть такой послушной, чтобы разваливаться от одного твоего клика. Пусть она иногда сопротивляется нашей спешке — это к лучшему.

И, честно, вот это мне кажется главным. Не очередное «мы стали сильнее», а вполне конкретный вывод: если инфраструктура слишком легко принимает изменения, то в один момент она начинает падать не из-за одного страшного бага, а из-за собственной скорости. А это уже совсем другая история. И не очень весёлая.

Материалы