В феврале 2026 года одно событие заставило всех нас переосмыслить, насколько современная инфраструктура зависит от горстки провайдеров. Один крупный сбой в работе Cloudflare нарушил работу широкого спектра глобальных онлайн-сервисов. Корпоративные инструменты, потребительские платформы, приложения для доставки еды, сайты для ставок и даже другие облачные провайдеры — никто не избежал последствий.
Алекс Холенев знает ответ с обеих сторон. Будучи старшим инженером-руководителем с более чем 15-летним опытом создания распределенных систем планетарного масштаба, он возглавлял инфраструктурные команды в Google, занимал пост управляющего директора по ИТ в Сбербанке во время модернизации на 30 миллионов долларов в 36 центрах обработки данных, а сегодня признан экспертом в области высоконагруженных распределенных систем.
В этом интервью мы обсудили, почему современное облако все еще не справляется с глобальным масштабом, что сбой Cloudflare говорит о высоконагруженных системах и что будет дальше.
Алекс, для начала этого интервью: не могли бы вы объяснить, что сделало недавний сбой Cloudflare столь значимым в глобальном масштабе, с точки зрения распределенных систем?
Что ж, февральский сбой был, я бы сказал, хрестоматийным примером отказа «плоскости управления» (control plane), и тип отказа имеет значение. Внутренняя ошибка в API адресации привела к непреднамеренному отзыву префиксов BGP (Border Gateway Protocol). Проще говоря, Cloudflare фактически сообщил остальной части интернета: «нас больше нет». С точки зрения распределенных систем это создало «маршрутизационное черное дыру».
И почему эффект распространился глобально, а не остался локальным?
Поскольку Cloudflare выступает в качестве критически важного шлюза для огромной части веба, исчезновение этих маршрутов вызвало глобальную «охоту за путями BGP». Интернет-провайдеры были вынуждены постоянно и массово пересчитывать интернет-маршруты. Именно это вызвало глобальные скачки задержек, которые ощутили все, и странную ситуацию, когда сервисы технически работали, но логически были недоступны. Серверы были в порядке. Карта к ним — нет.
Знаете, исходя из моего опыта работы с распределенными системами планетарного масштаба, меня всегда поражает одна закономерность: в таком масштабе вы терпите неудачу не потому, что ломается оборудование. Вы терпите неудачу, потому что ломается карта системы. Cloudflare — самый наглядный недавний пример, но лежащий в основе механизм тот же, который я наблюдал годами.
Почему современные распределенные системы при масштабировании склонны к каскадным сбоям и «эмерджентной хрупкости», даже при наличии резервирования и отказоустойчивости?
В массивных системах резервирование может незаметно обернуться против вас. Сбои в таком масштабе редко связаны с выходом из строя одного аппаратного узла. Они связаны с коррелированными ошибками. Как мы видели в случае с Cloudflare, проблема была не в «шторме повторных попыток» (retry storm), а в «ядовитой пилюле» конфигурации. Когда ошибочная конфигурация или логическая ошибка внедряется в избыточную систему, она не «переключается на резерв». Она реплицирует сбой на всех узлах одновременно.
То есть само резервирование становится вектором?
Почти. Именно это люди подразумевают под «эмерджентной хрупкостью». Сложность этих взаимодействий растет быстрее, чем наша способность их картировать, что позволяет одной логической ошибке обойти каждый физический уровень резервирования, который мы построили. Я видел версии этого много раз во время моей консалтинговой работы в Accenture, когда руководил слиянием ИТ двух банков и выделением крупной компании FMCG в Европе. Когда вы объединяете или разделяете системы такого размера, вы очень быстро обнаруживаете, что «резервный» и «независимый» — это не синонимы. Две системы могут выглядеть полностью дублированными на бумаге, но при этом иметь скрытую вышестоящую зависимость, общую библиотеку, общий сервис конфигурации. В тот момент, когда эта одна вещь выходит из строя, обе копии падают вместе.
Стал ли сегодняшний интернет структурно зависимым от небольшого числа крупных инфраструктурных провайдеров?
Да. Интернет структурно централизовался поверх децентрализованного протокола. В этом парадокс современной сети. Уровень маршрутизации по-прежнему распределен. Уровень приложений, уровень CDN и уровень DNS сошлись под управлением нескольких крупных провайдеров.
Но разве это не является самой проблемой? Горстка компаний как единая точка отказа для мировой экономики?
Это реальный риск, я не собираюсь этого отрицать. Но стоит сказать, что крупные провайдеры, Google, Cloudflare, AWS, относятся к этому серьезно, и это видно по тому, как они инвестируют. Возглавляя команды в Google, я видел масштабы инвестиций в многоуровневую защиту (defense in depth), специализированные зоны изоляции и стандарты SRE (Site Reliability Engineering). Эти компании не просто продают услуги. Они, по сути, поддерживают сантехнику современного интернета, и автоматические ограничители, которые они строят, не позволяют большинству локальных проблем перерасти в глобальные катастрофы.
Я бы добавил, что я был по обе стороны этого. В Сбербанке мы управляли ИТ для банка с 70 миллионами пользователей и более чем миллиардом платежей в день, и в таком масштабе вы глубоко зависите от своих инфраструктурных провайдеров. В Google я был по другую сторону стола, управляя частями глобальных сервисов копирования и репликации, от которых зависят другие компании. С обеих точек зрения честный ответ один и тот же. Зависимость реальна, концентрация реальна, и компромисс, на который мы коллективно пошли, заключается в том, что консолидация дала нам такой уровень надежности и инженерной строгости, которого не обеспечил бы более фрагментированный интернет. Является ли этот компромисс устойчивым в долгосрочной перспективе — это уже другой вопрос.
Существуют ли фундаментальные ограничения у классических моделей распределенных систем, таких как CAP, консенсус и репликация, в глобальном масштабе?
CAP — это теорема, а не закон, и на практике вы обходите ее ограничения с помощью архитектурных решений, в основном локализации. В моей работе в Google, вместо того чтобы навязывать глобальный консенсус для каждой транзакции, мы использовали внутренние реализации Bigtable, где мы привязывали экземпляры к определенным регионам. Сохраняя управление данными близко к пользователю и минимизируя межкластерные зависимости, мы сдерживали «радиус поражения». Таким образом, когда конкретный кластер сталкивается с проблемами, сбой остается там, где он начался, вместо того чтобы распространяться на региональном или глобальном уровне.
Вы все еще назвали бы CAP правильной ментальной моделью, или индустрия тихо отходит от нее?
Я бы сказал, и то, и другое. CAP по-прежнему полезен как инструмент для размышлений, особенно для младших инженеров, изучающих, где находятся жесткие компромиссы. Но после 15 лет работы с базами данных, распределенным хранилищем и репликацией на Java и C++ я бы сказал, что практические пределы — это не сам CAP. Это то, о чем CAP не говорит: задержка, частичные сбои, расхождение часов, стоимость координации. Возвращаясь ко времени работы в NetCracker, где я руководил производительностью и масштабируемостью продуктов, включая горизонтальное масштабирование и оптимизацию баз данных, один и тот же урок повторяется. Теоретическая модель говорит вам, что невозможно. Она не говорит вам, что дорого, а в глобальном масштабе «дорого» — это то, что вас убивает. Так что отрасль не отошла от CAP. Она обошла его.
По вашему опыту, какие архитектурные принципы в крупномасштабных системах хранения данных (подобных тем, что используются в Google) наиболее важны для предотвращения каскадных сбоев?
В команде Google Warsaw Infra Storage нашими двумя основными средствами защиты были прозрачная миграция и репликация. Прозрачная миграция позволяла нам перемещать экзабайты данных между аппаратными наборами или местоположениями без ведома прикладного уровня о произошедшем сдвиге. Это способ перемещения систем, находящихся в зоне риска, до того, как они вызовут какие-либо проблемы. Представьте себе: вы пользуетесь сервисом, а ответственные лица перемещают ваши данные из одного места в другое, но вы продолжаете им пользоваться. Вы ничего не видите. Никакого простоя, никаких ошибок, никаких переподключений. В этом цель. Мы внедрили прозрачную миграцию в продакшн и пилотировали репликацию как часть новой файловой системы Google. Сложность не в самом перемещении. Сложность в том, чтобы убедиться, что приложение над ним понятия не имеет, что что-то происходит.
Репликация — это вторая часть, и мы рассматривали ее как осознанный компромисс. Мы решили больше тратить на хранение. Таким образом, если что-то пойдет не так, это не сильно нас затронет. Мы сделали копии наших данных. Мы распределили эти копии по разным зонам, чтобы, если одна зона столкнется с большой проблемой, другие продолжали работать. Это помогает нам гарантировать, что мы не потеряем никаких данных и нам не придется останавливать работу. Никакие данные не теряются. У нас нет простоев. Это дорого стоит, но отказ от этого в долгосрочной перспективе обошелся бы нам еще дороже.
Почему системы, спроектированные как отказоустойчивые, все же выходят из строя в продакшене? Какие аспекты реального поведения труднее всего уловить в теории?
Теория, как правило, предполагает, что каждый путь кода протестирован, но реальные события «черного лебедя» почти всегда скрываются в пробелах. Вот почему тестовое покрытие имеет такое большое значение. Любая логика, которая регулярно не проверяется в тестовой среде, становится потенциальным источником уязвимости в тот момент, когда она попадает в продакшн.
Реальное поведение также страдает от того, что я бы назвал «темными зависимостями» (dark dependencies). Это связи между системами, которые нигде не задокументированы и становятся видимыми только во время сбоя. Это та проводка, которую никто не нарисовал на схеме. Эти логические повреждения и непроверенные граничные случаи гораздо опаснее любого простого аппаратного сбоя, потому что они не активируют ваш мониторинг, не отображаются на ваших дашбордах и не соответствуют режимам сбоев, для которых были написаны ваши инструкции по устранению неполадок (runbooks).
Если нынешняя модель облачных и распределенных систем приближается к своим пределам, какая архитектурная парадигма может ее заменить?
Мы движемся к тому, что я бы назвал автономной инфраструктурой, основанной на намерениях (intent-based infrastructure). Нынешняя модель слишком сильно опирается на статичные, управляемые человеком конфигурации, такие как таблицы BGP, которые по своей сути подвержены человеческим ошибкам. Следующая парадигма будет включать системы, где инженеры определяют высокоуровневые «намерения», такие как требуемая задержка или уровень изоляции, а инфраструктура использует оркестровку на базе ИИ для самоконфигурирования на лету. Это смещает акцент с «управления серверами» на «управление политиками», где система автоматически изолирует себя или перенаправляет трафик на основе сигналов о состоянии в реальном времени, прежде чем человек вообще обнаружит узкое место.
Видели ли вы когда-нибудь систему, которая вела себя так, что это фундаментально противоречило ее базовой модели или архитектурным предположениям?
Да. Когда я руководил ИТ в Сбербанке, мы взялись за проект по упрощению. Мы в итоге отключили 1480 приложений в 36 центрах обработки данных, что сэкономило банку около 30 миллионов долларов в год. На бумаге отключение этих так называемых «устаревших» приложений выглядело просто. На практике эти отключения часто вызывали сбои в современных системах, которые, как мы полагали, были полностью независимы. Эти «фантомные зависимости» показали нам, что задокументированная архитектура и фактические пути связи даже близко не совпадали. Система тихо эволюционировала на протяжении десятилетий, и ни одна схема не успевала за ней. Это было суровым напоминанием о том, что в сложных системах реальность «как построено» часто противоречит модели «как спроектировано».
Какие проекты или решения больше всего сформировали ваше представление о надежности и масштабируемости в крупномасштабных системах?
Мой опыт руководства командой Google Warsaw Infra Storage был наиболее формирующим. Мы работали, руководствуясь четкой философией. Надежность должна проверяться проактивно, с помощью того, что мы называем «учениями по надежности» (reliability drills). Мы не просто проектировали успех. Мы проводили специальные учения, чтобы убедиться, что сможем быстро и безопасно откатить изменения в любом сценарии. Цель была двоякой. Во-первых, наши системы должны были выдерживать сбои в сервисах, от которых они зависели, не падая. Во-вторых, мы должны были убедиться, что мы сами не являемся критической зависимостью для кого-либо еще. Вот что я имею в виду под «декаплированной надежностью» (decoupled reliability). Сбой в одной части стека не должен автоматически становиться сбоем для всей остальной экосистемы. И это то, что имеет значение. Системы меняются, языки меняются, масштаб меняется, но дисциплина вопроса «как это сломается» раньше, чем «как это работает», — вот что отличает инфраструктуру, которая остается, от той, которая нет.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Carl Williams
