Помилка світового масштабу. Як інтернет «ліг» через збій у США й чому він досі такий вразливий

Зсередини самої Cloudflare ситуація була не менш напруженою. Інженери спершу помітили симптоми у внутрішньому сервісі Workers KV і сприйняли це як локальну проблему з продуктивністю. Проте вже о 11:31 автоматичні системи забили на сполох, а о 11:35 було створено звіт щодо інциденту.

На додачу ще й власний сайт Cloudflare зі статусом сервісів почав працювати з перебоями. Але не через сам збій, а через паніку користувачів: мільйони людей одночасно намагалися оновити сторінку. Всередині компанії це на мить викликало побоювання, що хтось атакує і саму мережу, і систему сповіщення одночасно.

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

«Сьогодні стався найгірший збій у роботі Cloudflare з 2019 року, — того-таки дня написав генеральний директор мережі Метью Прінс. — За останні 6+ років у нас не було жодного іншого збою, який би спричиняв зупинку більшої частини основного трафіку через нашу мережу». Від імені всієї команди Cloudflare Прінс перепросив «за біль, який ми сьогодні завдали Інтернету».

Водночас у компанії наголосили, що це не була кібератака. Глобальний колапс спровокувала рутинна зміна прав доступу до бази даних, яку інженери провели ще об 11:05. Це зіпсувало файл конфігурації для системи боротьби з ботами, що призвело до краху програмного забезпечення, яке керує трафіком у всій мережі.

Але як один файл зміг «покласти» світовий інтернет?

Анатомія збою

Американська компанія Cloudflare працює як глобальний «зворотний проксі». Коли ви заходите на певний сайт, ваш запит спершу потрапляє на сервери Cloudflare. Там він проходить перевірку безпеки, фільтрацію від ботів та DDoS-атак, а вже потім перенаправляється на справжній сервер сайту.

За відсіювання небажаних гостей відповідає модуль Bot Management, який оцінює кожен запит за допомогою машинного навчання та набору ознак, як-от репутація IP-адреси чи поведінка браузера. Список цих правил зберігається в спеціальному файлі, який автоматично генерується і розсилається на всі сервери мережі.

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

Але ці зміни мали несподіваний побічний ефект. Запит, який формував файл для бот-менеджера, просив у ClickHouse перелік колонок певної таблиці, проте не уточнював назву самої бази даних. Після зміни прав доступу одна й та сама логічна таблиця стала доступною у двох базах. Система сприйняла це буквально і почала повертати дубльовані списки колонок з обох джерел.

Ситуацію ускладнювала нестабільна поведінка мережі. Позаяк файл генерувався кожні кілька хвилин, сервери отримували то «здорову» версію (зі старого кластера, який ще не зачепили оновлення), то «поламану» (з оновленого). Через це графіки помилок стрибали вгору-вниз, збиваючи інженерів Cloudflare з пантелику.

Справжній прорив у розслідуванні стався вже після обіду. О 13:05 за Гринвічем (15:05 за київським часом) інженери відкотили свій основний проксі-сервер до попередньої версії, що дало їм змогу відновити координацію. До 13:37 вони запевнилися в тому, що причиною інциденту став файл конфігурації Bot Management. А о 14:24 фахівці остаточно встановили причину халепи.

«Ми визначили, що модуль керування ботами був джерелом 500 помилок, і що це було спричинено неправильним файлом конфігурації», — йдеться у звіті Cloudflare.

Тієї ж миті команда зупинила автоматичне оновлення налаштувань і примусово розіслала на сервери стару, перевірену версію файлу. Ефект був миттєвим: до 14:30 основна хвиля помилок спала, а о 17:06 всі операції були повністю відновлені, й проблеми не стало.

Втім, збій 18 листопада наочно показав, як один-єдиний баг у системі фільтрації ботів однієї компанії може одночасно вдарити по поїздах у Франції, банках у США та ШІ-лабораторіях по всьому світу.

Настала хмарна монополія?

Ми вже писали про схожий випадок глобального збою в інтернеті минулого місяця. Виник він у глобальній хмарній платформі Amazon Web Services 20 жовтня 2025 року. Тоді регіон AWS US-EAST-1 у Північній Вірджинії «ліг» більш ніж на пів доби. Збій тривав понад 15 годин, а його причиною, за словами Amazon, стала помилка у системі управління DNS для бази даних DynamoDB.

У Downdetector підрахували, що той інцидент спровокував понад 17 мільйонів звітів про збої в понад 60 країнах світу. Як і Cloudflare місяцем пізніше, Amazon тоді чітко заявила, що це не була кібератака. Тобто в обох випадках глобальний колапс починався не зі зловмисного трафіку ззовні, а з внутрішньої автоматизації та налаштувань, які пішли шкереберть. І це проблема для нас усіх.

За оцінкою W3Techs, у листопаді 2025 року послугами Cloudflare користувалися 81,5% сайтів, які покладаються на службу зворотного проксі-сервера — це 20,4% від усіх вебсайтів світу загалом.

Amazon Web Services, за даними Statista, контролює близько 30% світової хмарної інфраструктури. Разом із Microsoft Azure (20%) та Google Cloud (13%) ця «велика трійка» тримає у своїх руках понад 60% глобального ринку. І якщо у дата-центрі когось із них відбудеться збій, він миттєво перекинеться на левову частку застосунків та споживчих сервісів по всій планеті.

Експерти роками попереджали про небезпеку того, що занадто вже велика частина критичної інфраструктури опинилася в руках мізерної кількості компаній. Ще у 2018 році дослідники з університету Карнегі-Меллон опублікували працю О, яке крихке павутиння ми плетемо. Проаналізувавши 100 тисяч найпопулярніших сервісів, вони виявили, що понад 73% з них стануть вразливими, якщо впаде невелика кількість сторонніх провайдерів. Автори підрахували, що проблеми у топ-10 CDN або DNS-провайдерів можуть «вимкнути» від чверті до половини популярних вебсервісів. І це дані семирічної давнини: сьогодні, ймовірно, рівень залежності ще вищий.

«Інтернет був розроблений як стійка система, — пояснює виданню The Guadian Сьюлетт Дрейфус, викладачка обчислювальної техніки та інформаційних систем в Мельбурнському університеті. — Існувало багато інших каналів для обходу проблем або атак, але ми втратили частину цієї стійкості, ставши настільки залежними від кількох гігантських технологічних компаній, які надають не тільки послуги зберігання даних, але й послуги з обробки даних».

Головний аналітик Forrester Research Брент Елліс оцінює загальні збитки від збою Cloudflare у понад 250 млн доларів для всіх постраждалих підприємств (у переліку є ChatGPT, X, Spotify та інші). Зокрема платформа для створення онлайн-магазинів Shopify втратила понад 4 млн доларів США. Самій же Cloudflare інцидент обійшовся у майже 1,8 млрд доларів США ринкової вартості.

Як розв’язати проблему

Гендиректор Cloudflare Меттью Прінс заявив, що відтепер компанія ставитиметься до автоматично згенерованих внутрішніх файлів із такою ж підозрою, як і до небезпечних даних ззовні. Крім того, інженери додають глобальні «аварійні вимикачі», щоб у разі проблем можна було миттєво відключити лише один модуль (як той-таки Bot Management), не кладучи при цьому всю мережу.

«Такий збій, як сьогодні, неприйнятний», — наголосив Прінс.

Проте бізнесу радять не покладати всі надії лише на роботу над помилками техногігантів. Наприклад, латформа для моніторингу цифрових сервісів Catchpoint рекомендує розділяти ризики: мовляв, компанії, які використовують стратегію multi-CDN (одночасне використання кількох провайдерів доставки контенту), в разі чого здатні перемкнути трафік за лічені секунди, на відміну від клієнтів з одним провайдером, чия робота паралізується.

Важливо й те, як виробникам організувати роботу своїх гаджетів, коли падають сервери. Як писав The Guardian, у день збою AWS власники «розумних ліжок» Eight Sleep виявили, що не можуть налаштувати температуру чи положення матраца — а все тому, що застосунок залежав від дата-центру US-EAST-1. І коли там стався збій, користувачі втратили змогу регулювати базові функції.

Згодом Eight Sleep випустила оновлення з «режимом збою», яке дозволяє керувати ліжком через Bluetooth, навіть якщо інтернет зник. Однак техностартап Ditto, що надає базу даних для застосунків у режимі реального часу, назвав це типовим прикладом того, як робити не слід. Натомість він просуває архітектуру offline-first: згідно з нею, пристрої повинні працювати локально за замовчуванням, а з хмарою з'єднуватися, лише «коли це корисно».

Тим часом на «хмарних гігантів» уже звернули увагу регулятори. 18 листопада Єврокомісія розпочала три розслідування в рамках Закону про цифрові ринки (DMA). Брюссель хоче з’ясувати, чи варто вважати Amazon і Microsoft «гейткіперами», які контролюють доступ до цифрової економіки. Якщо так — компаніям дадуть пів року на те, щоб «забезпечити повну відповідність своїх визначених послуг хмарних обчислень зобов’язанням DMA».

«Ми також розглянемо, чи потрібно оновлювати чинні правила DMA, щоб Європа могла йти в ногу з практиками, що швидко розвиваються, у хмарному секторі», — додає Тереза ​​Рібера, виконавчий віце-президент з питань чистого, справедливого та конкурентного переходу.

Злізти з «хмарної голки» буде неспросто. Нині більшість світових компаній навряд чи можуть просто взяти й замінити умовний Cloudflare на експериментальні протоколи. Але після двох глобальних збоїв лише за одну осінь стало ясно: людству доведеться екстренно шукати нову рівновагу між зручністю централізації й елементарною безпекою для всієї планети.

Інакше наступна несправність (а це лише питання часу) вкотре вимкне все і одразу, відрізавши населення від інтернету на невизначений термін.