В понедельник, 22 июня, сеть Cloudflare пережила один из самых заметных сбоев года. Инженеры компании увидели рост ошибок и задержек примерно в 13:35 UTC, а к 14:37 UTC локализовали причину: обрыв магистрального оптоволокна на востоке Северной Америки. Это не BGP-ошибка и не выкатка плохого конфига — физическое повреждение кабеля у транзитного оператора, из-за которого трафик пошёл в обход и упёрся в перегруженные каналы.
На статус-странице Cloudflare сначала сообщила о «повышенном уровне ошибок и задержек в нескольких сервисах», а затем прямо указала, что расследует обрыв оптоволокна на востоке Северной Америки и что клиенты, подключающиеся через Северную Америку или обращающиеся к сервисам в Европе, будут видеть повышенные задержки и таймауты. Отдельно компания пояснила, что запланированное на те же сутки обслуживание дата-центра EWR в Ньюарке к инциденту отношения не имеет — совпадение по времени, но не по причине.
Масштаб последствий объясняется долей Cloudflare в интернете: через её сеть проходит около пятой части всех сайтов. По данным Downdetector, жалобы пошли на X, Reddit, Zoom, Discord, Microsoft Teams, Canva, Fortnite и часть сервисов Amazon Web Services. Первые признаки восстановления появились примерно через двадцать минут после начала инцидента, а позже Cloudflare отчиталась, что traffic engineering «снял большую часть перегрузки и потерь пакетов», и сеть стала «в основном стабильной, с незначительным остаточным влиянием» — то есть перекладывание трафика на другие маршруты сработало, но не мгновенно.
Для отрасли это уже не первый звонок: за последние полтора года крупные сбои Cloudflare случались и в ноябре 2025-го, и в феврале 2026-го, после чего компания запустила внутреннюю программу устойчивости Code Orange. Но нынешний инцидент отличается природой — здесь виноват не софт, а лопата. От архитектурных ошибок это защищает плохо: если весь ваш вход в приложение идёт через один CDN, любая проблема на его магистралях становится вашей проблемой.
Что из этого выносить в свою архитектуру. Во-первых, честно ответьте себе, есть ли у вас план на случай недоступности CDN: держите ли вы второй адрес для DNS-failover, какой TTL у ваших A/CNAME-записей (если 86400 — переключиться вы не успеете при всём желании), доступен ли origin напрямую. Во-вторых, во время таких сетевых деградаций 5xx и таймауты идут волнами: клиентам нужен retry с экспоненциальным backoff и джиттером, иначе ваш собственный фронтенд добьёт origin повторными запросами. В-третьих, заведите алерт не только на «ваш сервис упал», но и на «доля таймаутов к внешним API выросла» — в понедельник многие узнали о проблеме от пользователей, а не от мониторинга. И наконец, подпишитесь на статус-страницы провайдеров и держите ссылку на них в рантбуке: в первые 20 минут инцидента единственный полезный сигнал был именно там.
Комментарии