Щось пішло не так. Як збій Cloudflare вплинув на українських айтівців і в чому була причина

У вівторок, 18 листопада стався масштабний збій в роботі сервісів Cloudflare. В результаті перестала працювати низка сервісів по всьому світу.

Проблеми торкнулися ChatGPT, DOU, YouTube, X (Twitter) та багатьох інших сайтів. Розповідаємо, в чому була причина і як збій вплинув на роботу українських IT-фахівців та компаній.

📈 Не працював навіть Downdetector

Перші проблеми із доступами до сайтів почали фіксувати близько 13:30. Користувачів викидало на сторінку із написом «internal server error» або вони не могли публікувати пости чи додавати контент. Згодом доступ до сервісів повертався, але через час знову падав.

Компанія Cloudflare незабаром після початку проблем повідомила, що спостерігається внутрішнє погіршення роботи сервісів і вони розслідують проблему. За пів години зазначили, що робота сервісів поступово відновлюється. Але перебої в роботі сайтів тривали.

До цього компанія на сторінці статусу системи повідомляла, що 18 листопада будуть проходити планові технічні обслуговування в центрах обробки даних у Сантьяго, Лос-Анджелесі, Атланті та на Таїті.

За даними Downdetector, який теж спочатку не працював, станом на 15:00 18 листопада спостерігалися проблеми в роботі сервісів Google, Microsoft, OpenAI, Meta, «Київстар», Vodafone, Deepstate, Rozetka, PayPal, Telegram, Canva, GitHub, Y Combinator та інших. Сайт DOU теж працював з перебоями.

🔎 У чому була причина збою Cloudflare

О 15:09 Cloudflare повідомила, що виявила причину збою і займається її усуненням. Згодом у блозі компанії співзасновник і CEO Метью Прінс пояснив, що причиною збою стала внутрішня помилка в їхній інфраструктурі. У компанії змінили налаштування прав доступу в одній із баз даних, через що система згенерувала некоректний конфігураційний файл для модуля Bot Management.

Його розмір раптово збільшився вдвічі, і файл почав автоматично розповсюджуватися на всі сервери Cloudflare. ПЗ, яке маршрутизує трафік, не було готове до такої зміни і почало видавати помилки. Спершу в Cloudflare думали, що це DDoS-атака, але згодом ідентифікували справжню причину. За словами Прінса, о 16:30 компанія зупинила поширення некоректних файлів і вручну відкотилася на попередню версію конфігурації, після чого сервіси поступово відновили роботу.

Нагадаємо, що, місяць тому, схожий на збій стався у сервісах Amazon. Тоді технічною причиною стала помилка з розв’язанням DNS для API DynamoDB у найбільшому серверному кластері компанії US-EAST-1.

⚙ Як збій вплинув на українське ІТ

Щоб краще зрозуміти, як саме інцидент відбився на роботі української IT-спільноти, DOU звернувся за коментарями до компаній і фахівців.

Віра Ткаченко, співзасновниця і CTIO MacPaw, каже, що вплив був помітний насамперед на другорядних сервісах:

«Деякі наші не ключові сайти були на безкоштовному плані (уже ні) — і вони постраждали. Усе інше було на enterprise-плані і працювало».

Найбільша проблема виникла з вебстором застосунків MacPaw. Він деякий час залишався недоступним, оскільки проходить через захист від DDoS-атак на Cloudflare. Команда тимчасово вимкнула частину правил безпеки, щоб відновити доступ до сторінки, а згодом повернула їх. Під час інциденту з’ясувалося, що внутрішній моніторинг обходив цей рівень захисту — через це компанія не одразу помітила падіння.

«У нашій компанії заведено писати Post Mortems після інцидентів. Тому ми проводимо всебічний аналіз цього інциденту, щоб не потрапляти у схожі ситуації в майбутньому», — додає Ткаченко.

Денис Румянцев, CTO дейтинг-застосунку Hily в appflame, розповідає, що у частини ремоут-співробітників одночасно перестав працювати VPN. Через це ті, хто не мав активної сесії, втратили доступ до GitLab та внутрішніх сервісів і тимчасово не могли пушити зміни. Паралельно команда побачила помилки в Cursor у режимі auto / gpt-5 і була змушена перейти на Composer-1.

Збій також зупинив JitPack, що паралізувало частину CI-процесів для Android. Попри це, за словами Румянцева, сам застосунок продовжив працювати стабільно, а метрики не показали жодних ризиків.

Схожу картину описує інший представник компанії — Team Lead Software Engineer PHP імейл-сервісу Mailkeeper Денис Коршак. За його словами, команда протягом години спостерігала падіння загального трафіку на систему. Тоді ж почали погано працювати трекінги мейлових метрик і деякі лінки посадки користувачів.

«Цілковитих відмов різних частин нашого проєкту не було, а пікові втрати за мейловим трафіком були менші ніж 30%, у порівнянні з очікуваними», — каже він.

Команда обговорила можливі альтернативи, але вирішила нічого не робити, щоб не створити додаткових репутаційних ризиків для мейлової інфраструктури. Напряму на роботу продукту сервіс не вплинув, а потенційна шкода залежатиме від того, наскільки сильно це зачепило партнерів сервісу, каже Коршак.

Тарас Романик, Competency Manager в ELEKS, зазначив, що більшість ключових сервісів залишалися доступними. Але спостерігалися певні проблеми. Зокрема, повністю припинив роботу сайт освітньої платформи Pluralsight. Stack Overflow вилогінював користувачів, але помилку швидко усунули.

Загалом, за словами Тараса, LinkedIn, GitHub, GitLab, Bitbucket, Azure DevOps та популярні навчальні платформи працювали стабільно. Навіть Copilot не відчув збою.

У Laba Group кажуть, що під час збою частина доменів працювала нестабільно. У когось сайт відкривався з помилками, у когось — взагалі не завантажувався. Це стосувалося як публічних доменів продукту, так і кількох внутрішніх сервісів, що використовують Cloudflare.

Збої вплинули й на роботу розробників компанії. Деякі не могли стабільно зайти на prod/dev/stage-оточення, перевірити деплой або прогнати тести. Частина інтеграцій, що працюють через HTTP-запити до власних доменів компанії, теж працювала нестабільно.

Щоб підтримати процеси всередині, команда тимчасово використовувала прямий доступ до серверів — через IP або локальні хости.

📎 Якими можуть бути наслідки збою і чи є альтернативи Clouflare

Через глобальний збій у сервісах Cloudflare виникає питання, чи існують робочі альтернативи і як ринок може реагувати на подібні інциденти. За словами Микити Галкіна, GDE та Fractional CTO/Principal Engineer, у сегменті B2C Cloudflare нині є стандартом.

Масові продукти використовують Cloudflare як базовий інструмент, оскільки він дає змогу зменшити витрати на трафік, забезпечує глобальну доступність і пропонує широку систему рішень.

Галкін пояснює, що його особистий досвід пов’язаний переважно з B2B-стартапами та скейлапами, де немає такого навантаження на інфраструктуру, тому Cloudflare там необов’язковий. Але для бізнесів, що працюють з великою аудиторією, ситуація інша — цілковитої альтернативи немає.

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

«Активізуються фінансові й технічні стартапи, які спробують надати insurance для таких випадків. Але альтернативи Cloudflare рівня індустріального стандарту я зараз не бачу», — підсумовує Галкін.

У De Novo зазначають, що падіння Cloudflare одразу тягне за собою великі частини інтернету, тому бізнесам варто мати план резервування. За їхніми словами, один зі способів мінімізувати наслідки — використовувати кілька CDN одночасно (наприклад, поєднання Cloudflare з Fastly, Akamai, Bunny чи Imperva), керуючи трафіком через DNS-балансувальники або мульти-CDN-платформи. У такому разі, якщо один провайдер виходить із ладу, трафік автоматично перемикається на інший.

Ще одна порада стосується DNS. Якщо DNS розміщений поза Cloudflare — наприклад, у AWS Route53, NS1, DNSMadeEasy чи ClouDNS — сайт залишається доступним навіть тоді, коли CDN або проксі Cloudflare недоступні. Якщо ж DNS також у Cloudflare, компанія повністю залежить від однієї інфраструктури, і ризики істотно зростають.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU