Протягом останніх двох з невеликим кварталів ми провели інтенсивну інженерну роботу під внутрішньою кодовою назвою «Код помаранчевий: незначні невдачі», спрямовану на те, щоб зробити інфраструктуру Cloudflare більш стійкою, безпечною та надійною для кожного клієнта.
Раніше цього місяця команда Cloudflare завершила цю роботу.
Хоча підвищення стійкості ніколи не буде остаточно завершеним завданням і завжди залишатиметься головним пріоритетом упродовж усього циклу розробки, ми вже завершили роботу, яка дозволила б уникнути глобальних збоїв, що сталися 18 листопада 2025 року та 5 грудня 2025 року
Ця робота була зосереджена на кількох ключових напрямках: безпечніші зміни конфігурації, зменшення впливу збоїв та перегляд наших процедур «розбиття скла» та управління інцидентами. Ми також запровадили заходи для запобігання відхиленням та погіршенню показників з часом, а також покращили систему інформування клієнтів під час перебоїв у роботі.
Тут ми детально пояснюємо, що ми відправили, і що це означає для вас.
Безпечніші зміни конфігурації
Що це означає для вас: у більшості випадків зміни внутрішньої конфігурації Cloudflare більше не надходять у нашу мережу миттєво, а впроваджуються поступово з моніторингом стану в режимі реального часу. Це дозволяє нашим інструментам моніторингу виявляти проблеми та усувати їх, перш ніж вони вплинуть на ваш трафік.
Щоб виявляти потенційно небезпечні розгортання до їх потрапляння у виробниче середовище, ми визначили високоризикові конвеєри конфігурації та створили нові інструменти для ефективнішого керування змінами конфігурації.
Щодо продуктів, які працюють у нашій мережі, обробляючи трафік клієнтів та отримуючи зміни конфігурації, ми більше не розгортаємо ці зміни в мережі миттєво. Натомість відповідні команди застосували методологію «розгортання з урахуванням стану», яку ми використовуємо під час випуску програмного забезпечення, для всіх операцій з розгортання конфігурацій. Це стосується, зокрема, команд розробників продуктів, які безпосередньо постраждали внаслідок інцидентів.
Центральним елементом цього є новий внутрішній компонент під назвою Snapstone, який ми розробили для забезпечення розгортання змін конфігурації з урахуванням стану системи. Snapstone — це система, яка об’єднує зміни конфігурації в пакет, а потім забезпечує їх поступове впровадження з дотриманням принципів модерації стану. До появи Snapstone застосування цієї методології до конфігурації було можливим, але складним. Це вимагало значних зусиль від кожної команди та не застосовувалося послідовно в усій мережі. Snapstone заповнює цю прогалину, пропонуючи єдиний спосіб поступового розгортання, моніторингу стану в режимі реального часу та автоматичного відновлення попередньої версії під час розгортання конфігурацій.
Особлива перевага Snapstone полягає в його гнучкості. Snapstone не є просто засобом усунення конкретних помилок, що трапилися в минулому, а дає командам можливість динамічно визначати будь-які елементи конфігурації, що потребують моніторингу стану — чи то файл даних, подібний до того, що спричинив збій 18 листопада, чи то контрольний прапорець у нашій глобальній системі конфігурації, подібний до того, що був причетний до збою 5 грудня. Команди створюють ці конфігураційні блоки на вимогу, а Snapstone забезпечує їх безпечне розгортання скрізь, де вони використовуються.
Це дає нам те, чого раніше не було: коли під час перевірки ризиків або операційного досвіду виявляється небезпечний шаблон конфігурації, виправити ситуацію дуже просто — достатньо завантажити його в Snapstone, і шаблон конфігурації негайно отримає безпечне розгортання.
Що це означає для вас: у разі виявлення проблеми в нашій мережі наші системи тепер реагують на неї більш плавно. Це значно зменшує потенційний радіус впливу, що гарантує доставку вашого трафіку навіть у найгірших випадках.
Команди розробників продуктів ретельно проаналізували, як вручну, так і за допомогою автоматизованих засобів, можливі причини збою продуктів, які відіграють ключову роль в обслуговуванні трафіку клієнтів. Команди усунули непотрібні залежності під час виконання та впровадили покращені механізми обробки помилок. Відтепер ми будемо використовувати останню відому справну конфігурацію, де це можливо («застарілий збій»), а якщо це неможливо, ми проаналізували кожен випадок збою та впровадили принцип «fail open» або «fail close» залежно від того, чи краще обслуговувати трафік зі зниженою функціональністю, ніж взагалі не обслуговувати його.
Розгляньмо приклад того, як це працює. Наш збій у листопаді 2025 року був спричинений невдалим розгортанням нашого класифікатора машинного навчання для Bot Management. Згідно з нашими новими процедурами, якщо знову будуть згенеровані дані, які наша система не зможе прочитати, система відмовиться використовувати оновлену конфігурацію та натомість використовуватиме стару. Якби стара конфігурація з якоїсь причини була недоступна, вона не відкрилася б, щоб забезпечити безперебійне обслуговування виробничого трафіку клієнтів, що є набагато кращим результатом, ніж простої.
Отже, якби та сама зміна в Bot Management, яка спричинила збій у листопаді, була впроваджена зараз, система виявила б збій на ранній стадії розгортання, перш ніж він вплине на щось більше, ніж невеликий відсоток трафіку.
Ми також почали подальшу сегментацію нашої системи, щоб для різних груп трафіку працювали окремі екземпляри сервісів. Cloudflare вже використовує ці когортні групи клієнтів для зменшення масштабів збитків за допомогою методів управління трафіком, а ця додаткова робота з сегментації процесів забезпечує нам потужні можливості надійності в майбутньому.
Наприклад, система виконання Workers поділена на кілька незалежних сервісів, що обробляють різні групи трафіку, один з яких обробляє лише трафік для наших безкоштовних клієнтів. Зміни впроваджуються в ці сегменти на основі когорт клієнтів, починаючи з безкоштовних клієнтів. Ми також надсилаємо оновлення швидше та частіше до найменш критичних сегментів, а до найважливіших — повільніше.
Отже, якби в систему виконання Workers було впроваджено зміну, яка спричинила б порушення трафіку, це вплинуло б лише на невелику частину наших безкоштовних користувачів, перш ніж проблему було б автоматично виявлено та усунуто.
Якщо розглянути систему виконання Workers, то за сім днів на початку цього місяця процес розгортання було запущено понад 50 разів. Ви можете побачити, як кожна зміна відбувається «хвилями», коли вона поширюється до периферії, часто паралельно з наступними та попередніми версіями:
Ми працюємо над поширенням цієї схеми розгортання на багато інших наших систем у майбутньому.
Переглянуті процедури «розбиття скла» та управління інцидентами
Що це означає для вас: якщо інцидент все ж таки станеться, ми матимемо інструменти та команди для чіткішої комунікації та швидшого його вирішення, мінімізуючи час простою.
Cloudflare працює на Cloudflare. Ми використовуємо власні продукти Zero Trust для захисту нашої інфраструктури, але це створює залежність: якщо збій у всій мережі впливає на ці інструменти, ми втрачаємо ті самі шляхи, які нам потрібні для їх виправлення. До запуску ініціативи «Код помаранчевий» наші шляхи «розбиття скла» були доступні лише обмеженому колу співробітників і надавали мінімальні можливості роботи з інструментами. Нам було необхідно зробити ці інструменти та шляхи доступнішими загалом під час перебоїв в електропостачанні.
Щоб вирішити цю проблему, ми провели комплексний аудит інструментів, необхідних для видимості системи, налагодження та внесення змін у виробництво. Зрештою, ми розробили резервні шляхи авторизації для 18 ключових сервісів, що підтримувалися новими аварійними скриптами та проксі-серверами.
Протягом усієї програми «Код помаранчевий» ми переходили від теорії до практики. Після навчань у невеликих командах, 7 квітня 2026 року ми провели загальноінженерні навчання, в яких взяли участь понад 200 членів команди. Хоча автоматизація підтримує функціональність цих шляхів, такі вправи гарантують, що наші інженери мають м'язову пам'ять, щоб використовувати їх в стресових ситуаціях.
Ці зусилля також були зосереджені на потоці інформації. Коли внутрішня видимість порушена, реагування на інциденти сповільнюється, а наша здатність спілкуватися із зовнішнім світом погіршується. Історично склалося так, що технічні спостереження в найгарячіші моменти не завжди призводили до чітких оновлень для наших клієнтів.
Щоб подолати цю розбіжність, ми створили спеціальну команду комунікацій для тісної співпраці з фахівцями з реагування на надзвичайні ситуації. Так само, як наші інженери відпрацьовували процедури «розбиття скла», ця команда використовувала програму «Код помаранчевий» для тренувань з оптимізації частоти та чіткості оновлень для клієнтів. Завдяки тому, що ми маємо як інструменти для аналізу, так і структуру для обговорення, ми можемо швидше вирішувати інциденти та краще інформувати наших клієнтів.
Ми систематизували наші вдосконалення
Що це означає для вас: ми пам’ятатимемо уроки, отримані з наших інцидентів, і систематизуватимемо відповідні рішення. Наша мережа стане лише стійкішою.
Щоб уникнути відхилень та повторного виникнення регресій в роботі, виконаній в рамках проєкту «Код помаранчевий», команда створила внутрішній кодекс, який закріплює всі наші рекомендації у чітких та лаконічних правилах.
Кодекс тепер є обов'язковим для всіх інженерних команд та команд розробників і став центральною частиною внутрішніх процедур Cloudflare. Дотримання цих правил забезпечується за допомогою перевірки коду штучним інтелектом, який автоматично виділяє всі випадки, що можуть суперечити рекомендаціям, після чого необхідно провести додаткову перевірку вручну. Це застосовується без винятку до всієї нашої кодової бази. Мета проста: створити інституційну пам'ять, яка сама себе забезпечить.
У перебоях у роботі в листопаді та грудні спостерігалася однакова причина збою: код, який припускав, що вхідні дані завжди будуть правильними, і не передбачав плавного переходу до альтернативного режиму роботи у разі порушення цього припущення. Сервіс Rust під назвою .unwrap() замість обробки помилки; код Lua індексував об'єкт, якого не існувало. Обом моделям можна запобігти, якщо винести з них уроки та дотримуватися їх.
Кодекс є частиною нашої відповіді. Це живе сховище інженерних стандартів, написаних експертами в предметній області за допомогою нашого процесу запиту коментарів (RFC), а потім перетворених на практичні правила. Найкращі практики, які раніше існували лише в головах старших інженерів або були виявлені лише після інциденту, тепер стали спільним знанням, доступним для всіх. Кожне правило має простий формат: «Якщо вам потрібен X, використовуйте Y» з посиланням на RFC, яке пояснює, чому.
Наприклад, в одному RFC тепер зазначено: «Не використовуйте .unwrap() поза тестами та build.rs. Інший принцип фіксує ширший: «Сервіси ПОВИННІ перевіряти, чи залежності вищестоящого рівня знаходяться в очікуваному стані, перш ніж обробляти їх».
Якби ці правила були запроваджені раніше, збої в листопаді та грудні стали б відхиленими запитами на злиття, а не глобальними інцидентами.
Правила без застосування — це пропозиції. Кодекс інтегрується з агентами на базі штучного інтелекту на кожному етапі життєвого циклу розробки програмного забезпечення, від перевірки дизайну до розгортання та аналізу інцидентів. Це зміщує точку втручання на більш ранній етап — від «загального збою» до «відхиленого запиту на злиття». Діапазон впливу порушення звужується з мільйонів запитів, на які це впливає, до одного розробника, який отримує конструктивні зауваження ще до того, як його код потрапить у виробниче середовище.
Кодекс є живим документом і буде постійно вдосконалюватися з часом. Фахівці у відповідній галузі складають RFC з метою систематизації найкращих практик. Інциденти виявляють прогалини, які стають новими RFC. Кожен затверджений RFC генерує правила Кодексу. Ці правила передаються агентам, які переглядають наступний запит на злиття. Це маховик: досвід перетворюється на стандарти, стандарти — на контроль за дотриманням, а контроль — на підвищення мінімальних вимог для всіх.
Справа не лише в коді: головне — це спілкування
Що це означає для вас: прозорість важлива для нас. Якщо щось піде не так, ми зобов’язуємося інформувати вас про кожен крок, щоб ви могли зосередитися на тому, що для вас важливо.
Глобальні збої змусили нас переглянути основні процеси та культурні підходи, що виходять навіть за рамки інженерії та розробки продуктів. В рамках ширших ініціатив програми «Код помаранчевий» ми запровадили додаткові цілі рівня обслуговування (SLO) для всіх наших сервісів, запровадили глобальний журнал змін, інтегрували всі команди в нашу систему координації технічного обслуговування та підвищили прозорість у всій компанії щодо нашого накопичення заявок на «запобігання інцидентам».
Ми також покращили спосіб комунікації з нашими клієнтами під час збоїв. Наша мета — попередити вас про проблему одразу після її підтвердження, ще до того, як ви її помітите. На той час, як ви помітите затримку або помилку, наша мета — щоб оновлення вже чекало на вас у сповіщеннях.
Під час активного інциденту ми тепер надаємо оновлення через певні проміжки часу (наприклад, кожні 30 або 60 хвилин), навіть якщо оновлення просто звучить як «Ми все ще тестуємо виправлення; нових змін поки що немає». Це дозволяє вам планувати свій день, а не постійно оновлювати сторінку статусу.
Наша робота не завершена, коли ситуація повертається до норми. Ми надаємо детальні аналітичні звіти, в яких пояснюємо, що сталося, чому це сталося та які конкретні структурні зміни ми впроваджуємо, щоб уникнути повторення подібних ситуацій.
Ця ініціатива завершена. Але наша робота над забезпеченням стійкості ніколи не закінчується.
Ми дуже серйозно ставимося до інцидентів і запровадили спільну відповідальність у всій організації Cloudflare, запитуючи кожну команду: що можна було б зробити краще? Це визначило нашу роботу протягом останніх двох кварталів.
Хоча ця робота ніколи не завершується остаточно, ми впевнені, що зараз ми перебуваємо в набагато кращому становищі, і завдяки цьому Cloudflare стала значно сильнішою.