18 листопада 2025 року мережа Cloudflare зазнала значних збоїв у передачі мережевого трафіку, які тривали приблизно дві години десять хвилин. Майже через три тижні, 5 грудня 2025 року, наша мережа знову не змогла обслуговувати трафік для 28% програм, що знаходилися за нашою мережею, протягом приблизно 25 хвилин.
Після обох інцидентів ми опублікували докладні аналітичні статті в блозі, але ми розуміємо, що нам потрібно зробити більше, щоб повернути вашу довіру. Сьогодні ми ділимося деталями роботи, яку проводить Cloudflare, щоб запобігти повторенню подібних збоїв.
Ми називаємо цей план «Код «помаранчевий»: невеликі збої», що відображає нашу мету зробити нашу мережу більш стійкою до помилок, які можуть призвести до серйозного збою. Код «помаранчевий» означає, що робота над цим проєктом має пріоритет над усім іншим. Для контексту, ми вже оголошували «код «помаранчевий» у Cloudflare після іншого серйозного інциденту, який вимагав першочергових дій від усіх співробітників компанії. Ми вважаємо, що нещодавні події вимагають такої ж уваги. Код «помаранчевий» — це наш спосіб забезпечити це, дозволяючи командам працювати міжфункціонально, коли це необхідно для виконання завдання, одночасно призупиняючи будь-яку іншу роботу.
Робота над кодом «помаранчевим» організована у трьох основних напрямках:
Вимагати контрольоване впровадження будь-яких змін конфігурації, що поширюються в мережі, так само, як ми це робимо сьогодні для бінарних випусків програмного забезпечення.
Переглядати, вдосконалювати та тестувати режими відмови всіх систем, що обробляють мережевий трафік, щоб гарантувати їх чітко визначену поведінку за будь-яких умов, включаючи несподівані помилки.
Змінити наші внутрішні процедури «розбивання скла»* та усунути будь-які циклічні залежності, щоб ми та наші клієнти могли діяти швидко та без проблем отримувати доступ до всіх систем під час інциденту.
Ці проєкти забезпечуватимуть ітеративні вдосконалення в міру їхнього виконання, а не одну «велику» зміну після їх завершення. Кожне окреме оновлення сприятиме підвищенню стійкості Cloudflare. В результаті ми очікуємо, що мережа Cloudflare стане набагато стійкішою, зокрема до таких проблем, як ті, що спричинили глобальні інциденти, з якими ми зіткнулися протягом останніх двох місяців.
Ми розуміємо, що ці інциденти є болісними для наших клієнтів та Інтернету в цілому. Нам дуже соромно за них, тому ця робота є головним пріоритетом для всіх співробітників Cloudflare.
* Процедури «розбиття скла» в Cloudflare дозволяють певним особам за певних обставин підвищити свої привілеї для виконання термінових дій з метою вирішення надзвичайних ситуацій.
У першому інциденті користувачі, які відвідували сайт клієнта на Cloudflare, бачили сторінки з помилками, які вказували на те, що Cloudflare не може надати відповідь на їхній запит. У другому випадку вони бачили порожні сторінки.
Обидва випадки відмови відбувалися за схожою схемою. У моменти, що передували кожному інциденту, ми миттєво впроваджували зміну конфігурації в наших центрах обробки даних у сотнях міст по всьому світу.
Зміна в листопаді була автоматичним оновленням нашого класифікатора Bot Management. Ми використовуємо різні моделі штучного інтелекту, які навчаються на основі трафіку, що проходить через нашу мережу, щоб створювати засоби виявлення, що ідентифікують ботів. Ми постійно оновлюємо ці системи, щоб випереджати зловмисників, які намагаються обійти наш захист та потрапити на сайти клієнтів.
Під час грудневого інциденту, намагаючись захистити наших клієнтів від вразливості в популярній платформі з відкритим кодом React, ми внесли зміну в інструмент безпеки, який використовують наші аналітики безпеки для покращення сигнатур. Подібно до терміновості нових оновлень для управління ботами, нам потрібно було випередити зловмисників, які хотіли скористатися цією вразливістю. Ця зміна і спровокувала початок інциденту.
Ця закономірність виявила серйозну розбіжність у тому, як ми впроваджуємо зміни конфігурації в Cloudflare, порівняно з тим, як ми випускаємо оновлення програмного забезпечення. Коли ми випускаємо оновлення версій програмного забезпечення, ми робимо це в контрольованому та моніторинговому режимі. Для кожного нового бінарного випуску розгортання повинно успішно пройти кілька шлюзів, перш ніж воно зможе обслуговувати світовий трафік. Спочатку ми розгортаємо зміни для трафіку співробітників, а потім обережно впроваджуємо їх для зростаючого відсотка клієнтів по всьому світу, починаючи з безкоштовних користувачів. Якщо ми виявляємо аномалію на будь-якому етапі, ми можемо скасувати випуск без будь-якого втручання людини.
Ми не застосовували цю методологію до змін конфігурації. На відміну від випуску основного програмного забезпечення, яке забезпечує роботу нашої мережі, коли ми вносимо зміни до конфігурації, ми змінюємо значення поведінки цього програмного забезпечення, і ми можемо зробити це миттєво. Ми надаємо цю можливість і нашим клієнтам: якщо ви внесете зміну в налаштування Cloudflare, вона пошириться глобально за лічені секунди.
Хоча така швидкість має переваги, вона також пов'язана з ризиками, які нам потрібно враховувати. Два останні інциденти продемонстрували, що нам потрібно ставитися до будь-яких змін, що застосовуються до способу обслуговування трафіку в нашій мережі, з такою ж обережністю, яку ми застосовуємо до змін у самому програмному забезпеченні.
Ми змінимо спосіб впровадження оновлень конфігурації в Cloudflare
Наша здатність розгортати зміни конфігурації глобально протягом кількох секунд була основною спільною рисою двох інцидентів. В обох випадках неправильна конфігурація вивела з ладу нашу мережу за лічені секунди.
Впровадження контрольованого розгортання нашої конфігурації, як ми вже робимо для випусків програмного забезпечення, є найважливішим напрямком роботи нашого плану Код «помаранчевий».
Зміни конфігурації в Cloudflare дуже швидко поширюються на мережу. Коли користувач створює новий DNS-запис або нове правило безпеки, воно досягає 90% серверів у мережі за лічені секунди. Це забезпечується програмним компонентом, який ми внутрішньо називаємо Quicksilver.
Quicksilver також використовується для будь-яких змін конфігурації, необхідних нашим власним командам. Швидкість — це особливість: ми можемо дуже швидко реагувати та глобально оновлювати поведінку нашої мережі. Однак, в обох інцидентах це призвело до поширення критичної зміни на всю мережу за лічені секунди, замість того, щоб пройти через шлюзи для її перевірки.
Хоча можливість розгортати зміни в нашій мережі майже миттєво корисна в багатьох випадках, вона рідко буває необхідною. Ведеться робота над тим, щоб розглядати конфігурацію так само, як і код, шляхом впровадження контрольованих розгортань у Quicksilver для будь-яких змін конфігурації.
Ми випускаємо оновлення програмного забезпечення для нашої мережі кілька разів на день за допомогою так званої Системи розгортання з урахуванням стану здоров'я (HMD). У цій структурі кожна команда Cloudflare, яка володіє сервісом (програмним забезпеченням, розгорнутим у нашій мережі), повинна визначити показники, які вказують на успішне або невдале розгортання, план розгортання та кроки, які необхідно вжити, якщо воно не вдасться.
Різні сервіси матимуть дещо різні змінні. Деяким може знадобитися довший час очікування, перш ніж перейти до інших центрів обробки даних, тоді як інші можуть мати нижчі допуски до рівня помилок, навіть якщо це призводить до хибнопозитивних сигналів.
Після розгортання наш інструментарій HMD починає ретельно працювати над цим планом, контролюючи кожен крок перед тим, як продовжити. Якщо будь-який крок завершиться невдачею, автоматично розпочнеться відкат, і за потреби команду можна буде сповістити команду.
До кінця Коду «помаранчевого» оновлення конфігурації відбуватимуться за тим самим процесом. Ми очікуємо, що це дозволить нам швидко виявляти проблеми, що виникли під час цих двох останніх інцидентів, задовго до того, як вони стануть широкомасштабними.
Як ми будемо вирішувати проблеми з відмовами між сервісами?
Хоча ми оптимістично налаштовані щодо кращого контролю над змінами конфігурації, ми знаємо, що помилки можуть траплятися і траплятимуться. Під час обох інцидентів помилки в одній частині нашої мережі перетворилися на проблеми в більшій частині нашого технологічного стеку, включаючи площину керування, на яку клієнти покладаються для налаштування використання Cloudflare.
Нам потрібно думати про обережне, поступове розгортання не лише з точки зору географічного прогресу (поширення на більшу частину наших центрів обробки даних) чи з точки зору зростання кількості населення (поширення на співробітників та типи клієнтів). Нам також потрібно планувати безпечніші розгортання, які містять збої внаслідок розвитку сервісу (поширення з одного продукту, такого як послуга Bot Management, до не пов'язаного з ним, наприклад, нашої панелі інструментів).
З цією метою ми зараз переглядаємо контракти на інтерфейс між кожним критичним продуктом і послугою, що входять до складу нашої мережі, щоб переконатися, що ми а) припускаємо, що збій станеться між кожним інтерфейсом, та б) обробляємо цей збій найбільш розумним чином.
Повертаючись до збою нашої служби Bot Management, існувало щонайменше два ключові інтерфейси, де, якби ми припустили, що станеться збій, ми могли б впоратися з ним настільки коректно, що навряд чи хтось із клієнтів постраждав би. Перший був в інтерфейсі, який зчитував пошкоджений конфігураційний файл. Замість паніки, мав би бути розумний набір перевірених налаштувань за замовчуванням, які б дозволили трафіку проходити через нашу мережу, тоді як ми б, у гіршому випадку, втратили точне налаштування в режимі реального часу, яке враховується в наших моделях машинного навчання для виявлення ботів.
Другий інтерфейс був між основним програмним забезпеченням, яке керує нашою мережею, та самим модулем Bot Management. У випадку, якщо наш модуль Bot Management вийшов з ладу (як це сталося), ми не повинні були б скидати трафік за замовчуванням. Замість цього, ми могли б знову ж таки придумати більш розумне налаштування за замовчуванням, яке б дозволяло пропускати трафік із задовільною класифікацією.
Як ми зможемо швидше вирішувати надзвичайні ситуації?
Під час інцидентів нам знадобилося занадто багато часу, щоб вирішити проблему. В обох випадках ситуацію погіршило те, що наші системи безпеки не дозволяли членам команди отримати доступ до інструментів, необхідних для вирішення проблеми, а в деяких випадках циклічні залежності уповільнювали нашу роботу, оскільки деякі внутрішні системи також ставали недоступними.
Як компанія з безпеки, всі наші інструменти працюють за рівнями автентифікації з детальним контролем доступу, щоб забезпечити безпеку даних клієнтів та запобігти несанкціонованому доступу. Це правильно, але водночас наші поточні процеси та системи уповільнювали нас, коли швидкість була головним пріоритетом.
Циркулярні залежності також вплинули на враження наших клієнтів. Наприклад, під час інциденту 18 листопада Turnstile, наше рішення для ботів без CAPTCHA, стало недоступним. Оскільки ми використовуємо Turnstile для входу на панель управління Cloudflare, клієнти, які не мали активних сеансів або токенів служби API, не могли увійти до Cloudflare в момент, коли це було найбільш необхідно для внесення критичних змін.
Наша команда переглядатиме та вдосконалюватиме всі процедури та технології «розбиття скла», щоб забезпечити якомога швидкий доступ до потрібних інструментів за потреби, дотримуючись при цьому наших вимог безпеки. Це включає перегляд та видалення циклічних залежностей або можливість швидкого їх «обходу» у разі інциденту. Ми також збільшимо частоту наших навчань, щоб усі команди добре розуміли процеси до виникнення будь-якого потенційного катастрофічного сценарію в майбутньому.
Хоча в цій публікації ми не висвітлили всю роботу, яка проводиться всередині компанії, описані вище напрямки роботи відображають головні пріоритети, на яких командам пропонується зосередитися. Кожен з цих напрямків роботи відповідає детальному плану, що стосується майже всіх продуктів і інженерних команд Cloudflare. У нас багато роботи.
До кінця першого кварталу, і значною мірою раніше, ми:
Забезпечимо охоплення всіх виробничих систем за допомогою розгортань з урахуванням стану (HMD) для управління конфігурацією.
Оновимо наші системи, щоб вони відповідали належним режимам відмови, що застосовуються для кожного набору продуктів.
Забезпечимо наявність процесів, щоб відповідні особи мали належний доступ для надання належного виправлення під час надзвичайної ситуації.
Деякі з цих цілей будуть актуальними завжди. Нам завжди потрібно буде краще справлятися з циклічними залежностями під час запуску нового програмного забезпечення, а наші процедури екстрених заходів повинні бути оновлені, щоб відображати зміни в наших технологіях безпеки з часом.
У цих двох останніх інцидентах ми підвели наших користувачів та Інтернет загалом. Нам є над чим працювати, щоб виправити ситуацію. Ми плануємо ділитися оновленнями в міру просування цієї роботи та цінуємо запитання й відгуки, отримані від наших клієнтів і партнерів.