18 листопада багато користувачів у всьому світі раптом опинилися в інтернеті 2000-х. Сайти не відкривалися, застосунки падали, авторизація не працювала. В Україні одночасно «заглючили» державні сервіси, ритейл, маркетплейси, логістика.
Причина виявилася не в «великій хакерській атаці», а в збої сервісу, про який більшість користувачів ніколи не чула: Cloudflare. Компанії, яка фільтрує ботів, відбиває DDoS-атаки й прискорює завантаження сторінок для мільйонів сайтів по всьому світу – включно з українськими.
Ця історія – не лише про «один невдалий апдейт». Це кейс про те, як кілька приватних компаній перетворилися на невидиму критичну інфраструктуру інтернету, та чому збій у Сан-Франциско сьогодні означає прямі втрати в українському e-commerce.
Невидимий гігант: що таке Cloudflare насправді
Якщо спростити до однієї фрази, Cloudflare – це проміжний шар між вашим браузером і сайтом. Ви вводите адресу – і часто спершу летите не на сервер магазину чи медіа, а на інфраструктуру Cloudflare.
Там із вашим запитом відбувається кілька речей:
- Фільтрація загроз.
Система дивиться, хто ви: реальна людина чи бот, частина DDoS-атаки, сканер вразливостей тощо. Саме тут народжуються знайомі всім «підтвердіть, що ви людина» та сторінки перевірки перед входом на сайт. - Прискорення контенту.
Через мережу CDN (Content Delivery Network) Cloudflare зберігає копії статичних елементів сайту (картинки, скрипти, частину сторінок) на своїх серверах по всьому світу. Чим ближче до вас датацентр – тим швидше відкривається сторінка. - Маскування беку.
Реальні IP-адреси та структура інфраструктури власника сайту ховаються за «парасолькою» Cloudflare, зменшуючи ризик прямих атак.
У результаті Cloudflare перетворився з «антиспам-сервісу» на величезний розподілений шлюз, через який ходить відчутна частина глобального веб-трафіку. Компанія обробляє десятки мільйонів запитів щосекунди, має сотні датацентрів у понад 300 містах світу і заробляє понад $2 млрд на рік.
Для пересічного користувача він майже невидимий. Але для бізнесу – це ключовий «захисний барʼєр» і прискорювач, який одночасно став єдиною точкою відмови.
Від Honey Pot до Cloudflare: як ідея «дивитися на спам» переросла в глобальний щит
Історія Cloudflare починається далеко від мільярдів і IPO.
- 2004 рік.
Американці Метью Прінс та Лі Холловей запускають Project Honey Pot – сервіс, який дозволяє власникам сайтів відстежувати, як спамери збирають адреси електронної пошти. Головне питання – «звідки береться спам?». - Болюче усвідомлення.
Користувачам виявилося замало просто «дивитися на проблему в красивих графіках». Вони хотіли активного захисту – не лише знати, звідки йде токсичний трафік, а й блокувати його на вході. - 2009 рік – поворотний момент.
Метью Прінс їде в Гарвардську бізнес-школу по MBA й зустрічає там Мішель Затлін. Разом вони перезбирають продукт у бізнес-план: не просто ловити «поганих хлопців», а стати хмарним firewall’ом – «вогняною стіною в хмарі». - Перемога й перші гроші.
Новий продукт виграє конкурс бізнес-планів Гарварду, отримує фінансування від Venrock та Pelion. Так народжується те, що згодом стане Cloudflare.
Назву теж шукали не з першого разу: «Project Web Wall» звучав занадто технічно й сиро. Рішення підкинув друг Прінса: якщо ви будуватимете «firewall in the cloud», це має бути щось про хмару й вогонь. Так зʼявився Cloudflare – «хмарний спалах».
Далі – типова історія стрімкого scale-up’у:
- за шість років – офіси в кількох країнах та сотні датацентрів;
- вдалий вихід на Нью-Йоркську біржу у 2019-му;
- до 2025-го Прінс – найбагатша людина штату Юта, Затлін – серед найзаможніших self-made жінок світу.
На цьому тлі майже трагічно виглядає історія третього співзасновника – Лі Холловей вийшов з компанії у 2015 році через серйозні проблеми зі здоров’ям.
Що сталося 18 листопада
- Cloudflare викотив зміну в системі управління бот-трафіком (Bot Management).
- Через помилку налаштувань бази даних конфігураційний файл для цього модуля раптово виріс удвічі.
- Файл перевищив технічний ліміт, почали падати проксі-сервери Cloudflare.
- Сайти, які використовували сервіс, стали віддавати помилки – хоча їхні власні сервери працювали.
- Інцидент тривав кілька годин і став найбільшим з 2019 року.
Один файл, який “поклав” пів інтернету
Звучить як жарт: «файл конфігурації виявився зависоким – і все впало». Але саме так, у спрощеному вигляді, виглядав корінь проблеми.
Що відбулося технічно:
- Змінили права в базі даних.
У Cloudflare оновили дозволи для однієї з БД, яку використовує модуль Bot Management. Саме він вирішує, кого пропускати, а кого вважати небезпечним ботом. - База почала повертати «зайві» дані.
Через зміну дозволів запити почали віддавати дублікати, яких не мало бути. Ці дані кожні кілька хвилин упаковувалися в конфігураційний файл для всієї мережі. - Файл роздувся понад ліміт.
Конфігурація виросла приблизно вдвічі й перевищила максимальний розмір, на який були налаштовані окремі компоненти проксі-ПЗ. - Проксі почали падати.
Частина вузлів не могла коректно прочитати файл, процеси вилітали з помилками, користувачі бачили 5xx-коди, «Error 500» або сторінки Cloudflare про те, що «щось не так з сервісом». - Ефект доміно.
Глобальна мережа Cloudflare – це сотні датацентрів, що працюють синхронно. Тому збій однієї ключової конфігурації швидко перетворюється на масове «флапання»: частина трафіку відновлюється, частина падає знову, поки система намагається застосувати й переосмислити конфігурацію.
Усе це відбувалося без жодного хакера на горизонті. Cloudflare офіційно підтвердив: інцидент не був пов’язаний із кібератакою, це наслідок внутрішньої помилки в логіці налаштувань.
Як це виглядало в Україні: від 2000 втрачених замовлень на годину до планів «обходу»
Для українських користувачів це були «просто глюки». Але для бізнесу – цілком відчутні гроші.
Серед постраждалих – сайти:
- державних органів (міністерства, держсервіси);
- великих ритейлерів та маркетплейсів (Eva, Maudau, Rozetka, Varus, «Аврора», «Епіцентр» тощо);
- логістики, аптечних мереж, виробників FMCG.
Eva: сотні тисяч гривень за кілька годин
У мережі Eva збій зафіксували приблизно о 13:31. Далі ситуація розвивалася за сценарієм «гойдалки»: сайт то падав, то відновлювався з інтервалами 5–10 хвилин.
У компанії оцінюють прямі втрати як приблизно 2000 втрачених замовлень на годину. Непрямі збитки – відтік частини аудиторії, зіпсований користувацький досвід, додаткове навантаження на підтримку – порахувати набагато складніше.
Maudau: зупинені замовлення та затримки логістики
У маркетплейсу Maudau для частини користувачів сайт просто не відкривався близько півтори години. Але проблема не обмежилася «неклікнутими кошиками».
Через збій у роботі Cloudflare заторкнулися й поштові оператори. Частину замовлень зі складу банально не змогли вчасно передати до перевізників – відправлення пішли пізніше, ніж планувалося.
Оцінка від представників Maudau: сукупні збитки ритейлу й e-commerce сягнули мільйонів.
Varus, «Аврора», «Епіцентр», Rozetka та інші
- У Varus фіксували часткову недоступність сайту, мобільного застосунку й ряду внутрішніх сервісів. Критичних фінансових втрат офіційно не називають, але компанія вже розробила механізм оперативного перемикання трафіку в обхід Cloudflare і прямо говорить про пошук альтернатив.
- «Аврора» та «Епіцентр» повідомляють про кілька годин проблем із сайтами й особистими кабінетами. Офіційно – без «фатальних» втрат: замовлення все ж таки були опрацьовані, хоча й з ускладненнями.
- У Rozetka частина користувачів не могла авторизуватися. У компанії кажуть, що мають страхувальні рішення на такі випадки, тож ситуацію вдалося втримати в прийнятних межах.
У виробника «Моршинської» та «Миргородської» IDS Ukraine також спостерігали проблеми із завантаженням корпоративних ресурсів, але без серйозного впливу на операційну діяльність.
Що це означає для українського бізнесу
- Навіть короткий збій інфраструктурного сервісу, як Cloudflare, вимірюється тисячами втрачених замовлень на годину.
- Страждають не лише «вітрини», а й бек-офіс: склади, інтеграції з поштою, внутрішні системи.
- Переходити «з Cloudflare на когось іншого» бізнеси поки не поспішають – аналогів за якістю й масштабом мало.
- Натомість компанії говорять про disaster-плани (плани аварійного відновлення) й механізми швидкого обходу сервісу у разі наступних інцидентів.
Коли один приватний провайдер стає «атомною електростанцією» інтернету
Історія зі збоєм Cloudflare оголила проблему, про яку роками говорили технічні експерти, але мало хто хотів чути поза профільними конференціями: надмірна концентрація інтернет-інфраструктури в руках кількох гравців.
Сьогодні картина виглядає так:
- значна частина сайтів сидить на кількох великих хмарних платформах (AWS, Azure, Google Cloud);
- ті самі сайти часто використовують один із двох-трьох глобальних CDN/WAF-провайдерів (Cloudflare, Akamai, Fastly тощо);
- DNS, сертифікати, авторизація, платежі – також зосереджені у невеличкій групі великих компаній.
Чому так сталося?
- Економіка масштабу.
Побудувати власну глобальну мережу захисту й прискорення – мільярдні інвестиції. Орендувати її «як сервіс» — дешевше, швидше й логічно для 99% бізнесів. - Зручність.
Один провайдер, одна панель управління, одна команда підтримки. Для девелоперів і CIO це мрія. - Безпека.
Парадоксально, але багато компаній ідуть до Cloudflare саме за безпекою: вони не можуть самостійно відбивати великі DDoS-атаки чи будувати складні bot-management-системи.
Зворотний бік – концентрація ризику:
- вихід з ладу одного великого «шару» інтернету миттєво перетворюється на системну подію, а не «локальну проблему провайдера»;
- для регуляторів і державних органів це вже скоріше питання надійності критичної інфраструктури, ніж абстрактний «збій хмарного сервісу».
Cloudflare, по суті, опинився в ролі енергетичного оператора для цифрового світу: коли в нього аварія – миготять світлом тисячі «квартир» по всій планеті.
Що робити українським компаніям: не панікувати, але готуватися до наступного збою
Усі експерти, яких цитують у матеріалах, сходяться в одному: масовий відтік з Cloudflare навряд чи станеться. Сервіс занадто сильний, зручний і ефективний, а його конкуренти також не застраховані від збоїв.
Але інцидент дуже чітко показав, що жити без справжнього disaster-плану – розкіш, яку e-commerce і ритейл більше не можуть собі дозволити.
1. Реальний, а не «формальний» disaster-plan
- Прописати конкретні тригери, коли інцидент вважається критичним (частка 5xx-помилок, тривалість, тип сервісів, що лежать).
- Визначити відповідальних за рішення «перемикаємося з Cloudflare», а не чекати, поки «якось само розсмокчеться».
- Регулярно проводити тренування: симулювати недоступність CDN/WAF, дивитися, що реально відбувається з кошиком, оплатою, логістикою.
2. Механізм швидкого обходу Cloudflare
Випадок Varus показує тренд: компанії починають будувати архітектуру з «байпасом» – можливістю швидко перевести трафік в обхід проблемного шару.
Це може бути:
- альтернативний маршрут на рівні DNS;
- тимчасовий перехід напряму на origin-сервери;
- використання резервного, менш потужного, але простішого CDN/WAF.
Такі сценарії мають бути заздалегідь протестовані, інакше у «день Х» ризикує впасти вже не лише Cloudflare, а й внутрішні системи компанії.
3. Архітектура «graceful degradation»
“Graceful degradation” перекладається як поступова деградація, плавне зниження ефективності або поступове скорочення можливостей. Це властивість системи (часто комп’ютерної), яка дозволяє їй продовжувати працювати, незважаючи на помилки в окремих частинах, або поступово втрачати функціонал, а не виходити з ладу повністю.
Ключове питання: що бачить користувач, коли зовнішній сервіс «лежить»?
- Чи може він хоча б подивитися каталог та ціни?
- Чи може оформити замовлення в мінімалістичному режимі, без зайвих інтеграцій?
- Чи є офлайн-режими для частини бек-офісних операцій (склади, підтвердження, відвантаження)?
Системи, які передбачають контрольовану деградацію («щось відключаємо, але основне працює»), значно краще переживають такі інциденти, ніж ті, що падають цілком від одного зовнішнього тайм-ауту.
4. Перегляд залежностей і SLA
Після збою має сенс:
- перерахувати критичні зовнішні сервіси: від Cloudflare до платіжних шлюзів і авторизації;
- переглянути SLA ((Service-Level Agreement – Угода про рівень послуг), й договірні штрафи – чи дійсно вони стимулюють провайдерів інвестувати в надійність;
- вимагати прозорості post-mortem-звітів: що сталося, які уроки винесено, як змінять процеси.
Що далі: чи варто боятися наступного «чорного вівторка» інтернету
Чесна відповідь неприємна, але проста: так, подібні збої будуть ще.
Складність глобальної інтернет-інфраструктури зростає, кількість залежностей між сервісами – теж. Помилки в конфігурації, оновленнях, автоматизації – це не «якщо», а «коли».
Але це не означає, що бізнес має панікувати й намагатися «жити без Cloudflare». Навпаки:
- для більшості компаній користь від таких сервісів багаторазово перевищує ризики;
- завдання менеджменту – мінімізувати шкоду, коли щось таки йде не так.
Збій 18 листопада став болючим, але корисним нагадуванням:
- інтернет не децентралізована утопія, а кілька великих вузлів-посередників, збій яких відчуває пів світу;
- Україна – повноцінна частина цієї екосистеми, і її бізнес відчуває ті самі удари, що й глобальні гіганти;
- справжня стійкість починається не з ілюзії «цього не станеться», а з детального плану «що ми робимо, коли це таки станеться».
Cloudflare вже пообіцяв «зробити все, щоб подібне не повторилося». Українським компаніям варто зробити те саме – тільки щодо власної інфраструктури.
За матеріалами biz.liga.net
