Cloudflare снова обрушил тысячи платформ. Вина финансистов или технарей?

Ужасно другое — то, что вслед за Cloudflare валятся тысячи платформ, включая банки, онлайн-магазины, медиа, SaaS-продукты и даже государственные сервисы. Падает не только трафик - падает бизнес.

И вот тут вопрос не к Cloudflare. Вопрос к самим компаниям: кто виноват - финансисты или технари?

В таблице всё выглядит идеально. Один поставщик, один контракт, одна зона ответственности. CDN, DNS, WAF, DDoS и TLS - всё под одной крышей, красиво, удобно и "оптимизировано по затратам".

На бумаге - экономия. В реальности - инженерная рулетка.

Пока всё работает, финансовая стратегия выглядит блестяще. Но как только у Cloudflare случается глобальный сбой, все эти таблицы мгновенно теряют смысл. Бизнес останавливается. Продажи исчезают. Пользователи идут к конкурентам. И начинается паника.

— Почему у нас всё лежит?
— Почему не можем переключиться?
— Почему пользователи жалуются?
— Где резерв?

Резерва нет. Его просто не предусмотрели. Он не вписался в бюджет.

Парадокс в том, что стоимость резерва несоизмеримо меньше, чем потери от простоя. Но пока аварии не случилось, CFO и CEO не видят угрозы. Именно поэтому план-Б в большинстве компаний появляется только после первой катастрофы.

Инженеры и архитекторы прекрасно понимают, как работает сеть. Они знают, что ни один CDN не гарантирует 100 % аптайма, что DNS у Cloudflare - не страховка, а просто удобный сервис, и что никакая SLA не спасает, когда рушится целая сеть узлов.

Но ещё хуже другое: когда сами технари даже не предложили план-Б. Это происходит гораздо чаще, чем принято думать.

Даже если финансисты отказали бы в бюджете, можно было бы предусмотреть минимальный аварийный сценарий - дешевый, но работающий. Речь не о миллионах. Речь о паре вечеров, паре Terraform-конфигов, и минимальных затратах на вторую CDN-цепочку. План Б можно собрать буквально на тех же сервисах, что уже используются, просто с альтернативным маршрутом.

Никто ведь не мешает:

Но этого не делают. Потому что и так работает. А когда всё рухнет - начинается привычный хор: мы не ожидали, что упадёт Cloudflare.

И вот самое поразительное. На собеседованиях на должности CTO, архитектора, SRE-инженера или Head of Dev кандидата мгновенно завернут, если он скажет, что одного CDN достаточно для отказоустойчивости. Это даже не обсуждается. Интервью вежливо прекращают.

Все участники понимают: такой ответ - маркер непрофессионализма. Это всё равно что архитектор, который проектирует небоскрёб без запасной лестницы.

Но стоит этим людям попасть в компанию, как всё забывается. На практике те же архитекторы выстраивают инфраструктуру ровно по той схеме, за которую на собеседовании их бы не взяли: один CDN, один DNS, один SPOF на всех.

В теории - прекрасная архитектура на слайдах PowerPoint. В продакшне - стопроцентный сценарий фатальной зависимости.

Возможно, так удобнее. Возможно, так быстрее запустить MVP. Но когда продукт перестаёт быть стартапом и становится основным источником выручки, продолжать играть в один провайдер и бог с ним - это не техническая ошибка, это халатность.

Когда Cloudflare стал стандартом де-факто, индустрия перестала думать. Все просто пошли за ним, потому что "так делают все".

И действительно - Cloudflare огромен, быстр, надёжен. Но ни один инженер не может честно сказать, что полагается на одну внешнюю систему “на всякий случай”. Это противоречит базовым принципам отказоустойчивости.

Тем не менее, компании продолжают ставить всё на одну карту. А потом, когда происходит очередной сбой, в корпоративных чатах звучит стандартное: "Мы столкнулись с проблемами на стороне внешнего провайдера…"

Нет, это не внешние проблемы. Это внутреннее бездействие. Вы просто не построили запасной маршрут.

Компании инвестируют миллионы в отказоустойчивые базы данных, резервные дата-центры, многозонные Kubernetes кластеры и автоматизацию развёртываний. Но при этом весь входящий трафик клиентов всё равно идёт через одну внешнюю точку, полностью подконтрольную другому бизнесу.

Если бы это была физическая инфраструктура, никто не стал бы прокладывать весь поток клиентов через один тоннель. Но в цифровом мире это почему-то считается "оптимизацией".

Когда Cloudflare падает - рушится весь этот "облакообразный" фасад. Открываются простые факты: у компании нет второго маршрута, нет независимого DNS, нет ранбуков, нет фейловера. И самое главное - нет ответственности.

Можно сколько угодно обсуждать бюджеты, политики и бюрократию. Но давайте честно: ответственность за план Б - прежде всего техническая.

Финансист может не понимать разницы между CDN и DNS. Но технарь обязан объяснить. Архитектор обязан настоять. SRE обязан показать последствия.

Объяснить финансистам важность резервирования - не проблема. Можно и нужно использовать все инструменты:

Даже самый осторожный CFO поймёт, что дополнительные 10–20 % бюджета на мульти-CDN дешевле, чем один день простоя.

Можно привлечь и разработчиков, чтобы продемонстрировать, как их фичи становятся бесполезными без доступности. Можно подключить и cybersecurity-команду, которая объяснит, что зависимость от одного вендора - это не только риск отказа, но и потенциальная уязвимость. Если упадёт защита на одном уровне, весь трафик открыт.

Но главное - эти разговоры нужно вести до аварии. Потому что после - это уже не архитектура, это разбор полётов.

Взрослый бизнес проектирует отказоустойчивость не на презентациях, а в реальности.

За последние два года было несколько заметных случаев, когда из-за сбоя Cloudflare или Fastly "падал пол-Интернета". Каждый раз одни и те же последствия: тысячи сайтов недоступны, пользователи в ярости, компании извиняются и обещают "повысить устойчивость".

Через пару месяцев - новая авария. Те же лица, те же заявления. План Б по-прежнему не реализован.

Один из крупных финтех-проектов в Восточной Европе в 2023 году потерял 9 часов работы API из-за проблемы в Cloudflare. Убытки оценили в $1,8 млн. После инцидента в отчёте написали: "Рассматривается внедрение резервного CDN". Спустя год резерв так и не внедрили.

Аргумент "это дорого" - любимое оправдание. Но в реальности - ложь.

Резервный DNS стоит несколько долларов в месяц. Второй CDN на 5 % трафика — в пределах сотен. Настройка health-checks и ранбуков — день работы инженера.

Это не инвестиция в железо, это инвестиция в репутацию. Потому что один час простоя крупного SaaS стоит дороже любого CDN. Согласно исследованию Gartner, средняя стоимость даунтайма для B2B-платформ превышает $300000 в час. Для B2C e-commerce — $100000–200000 в зависимости от региона. Любой резерв окупается мгновенно при первом же сбое.

Многие компании по-прежнему живут с иллюзией, что "инфраструктура - это технарская проблема". Нет. Инфраструктура - это часть бизнес-риска.

Если вы продаёте онлайн, инфраструктура - это ваш кассовый аппарат. Если он не работает, бизнес не существует. И если этот аппарат завязан на одного внешнего поставщика - вы не бизнес, вы клиент в очереди.

Поэтому грамотный CTO не просто "просит бюджет". Он учит руководство думать категориями риска, а не затрат. Он показывает цифры, строит графики, моделирует последствия, вовлекает product и security-команды.

Устойчивость — это не прихоть инженеров. Это форма корпоративной ответственности перед пользователем.

Когда Cloudflare падает, а вы лежите вместе с ним, виноваты не они. Виноваты вы.

Если вы финансист - потому что сэкономили там, где экономить нельзя. Если вы архитектор или CTO - потому что не настояли. Если вы инженер - потому что не предложили даже минимальный резерв.

Профессионал отличается от исполнителя тем, что предвидит сбой. И если технический состав не смог объяснить важность плана Б, значит, он сам не до конца верит в то, что делает.

Можно и нужно уметь продавать устойчивость - внутри компании. Это не вопрос денег. Это вопрос инженерной культуры.

Cloudflare точно не враг. Враждебной является привычка думать, что пронесёт. Пока одни компании проектируют отказоустойчивость, другие пишут оправдания для клиентов. И разница между ними - не в деньгах, а в зрелости. Устойчивость - не фича. Это уважение к пользователю. И если ваша платформа падает из-за сбоя одного провайдера, это не ошибка провайдера. Это диагноз вашей архитектуры.

Один CDN - это даже не стратегия, а слепая вера в удачу, но бизнес на удаче не строится.