Одна политика — все регионы: Google Cloud и ответственность глобальной плоскости управления

Кратко

• 12 июня 2025 года непреднамеренно пустые поля в политике квот почти одновременно попали в региональные хранилища данных Service Control в Google Cloud. Ранее развёрнутый программный код не имел ни надлежащей обработки ошибок, ни защиты функциональным флагом; обработка политики приводила к аварийному завершению бинарных файлов Service Control во всех регионах. Многие API Google Cloud, Google Workspace и Google Security Operations возвращали ошибки 503. Существующие потоковые и инфраструктурные ресурсы (IaaS) в основном продолжали работать, но пути управления и API, необходимые для проверки, изменения, масштабирования или восстановления сервисов, были широко нарушены.
• Непосредственный дефект был узким, но сбой ответственности — архитектурным. Google имел регионально распределённые экземпляры сервисов и поэтапный выпуск бинарных версий, однако вызвавшая инцидент политика глобально реплицировалась в течение секунд. Механизм поражения обошёл региональное обучение, которое должен был дать поэтапный выпуск. Восстановление затем создало эффект стада против Spanner в крупных регионах, поскольку перезапускаемые задачи не имели рандомизированной экспоненциальной задержки (backoff). Публичная инфраструктура Cloud Service Health также зависела от пострадавшей среды, что задержало первое уведомление Google примерно на час.
• Более ранние инциденты показывают разные причины, но повторяющиеся вопросы о логической независимости. В июне 2019 года автоматизация обслуживания вывела кластеры сетевой плоскости управления в нескольких физических локациях, были отозваны маршруты BGP, а инструменты диагностики конкурировали за перегруженную сеть. В феврале 2021 года скрытый дефект, сработавший при изменениях квот пиринга, заблокировал глобальное программирование сети. В марте 2021 года недопустимые маршруты выявили известный дефект вендора, а в некоторых локациях Cloud Interconnect не хватало разнообразия вендоров маршрутизаторов. Это не один повторяющийся дефект ПО; это повторные проверки изоляции общих причин, полномочий изменений, восстановления сети и правдивой видимости.
• Google несёт ответственность за валидацию глобально реплицируемых данных, изоляцию функций плоскости управления, сохранение безопасного поведения (fail-static или fail-open) там, где это допустимо, обеспечение независимых каналов коммуникации об инцидентах и подтверждение выполнения обещанных исправлений. Клиенты не могут исправить эти платформенные механизмы, но они отвечают за определение операций, зависящих от API плоскости управления, мониторинг извне провайдера, тестирование деградированных режимов и покупку разнообразия маршрутов и провайдеров, а не расчёт на номинальные каналы. Мультирегиональное развёртывание снижает многие риски, но само по себе не устраняет глобальную политическую плоскость или общую магистраль.

Сбой был управленческим решением, принятым одновременно везде

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

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

Это различие объясняет, почему инцидент 12 июня 2025 года был одновременно меньше, чем полное отключение инфраструктуры, и больше, чем обычная проблема API. Вполном отчёте об инциденте Service Controlговорится, что существующие потоковые и инфраструктурные ресурсы (IaaS) напрямую не пострадали от первичного сбоя. Тем не менее длинный список продуктов испытывал внешние ошибки API, включая Identity and Access Management, Cloud Storage, BigQuery, Cloud Run, Cloud DNS, Cloud Load Balancing, Hybrid Connectivity, Network Connectivity Center, Spanner, продукты мониторинга, консоль и несколько сервисов ИИ.

Способность продолжать обслуживание из уже запрограммированного состояния пережила лучше, чем способность попросить платформу решить или изменить что-то.

Механизм был необычно ясен в публичном отчёте Google. 29 мая новая функция Service Control для дополнительных проверок политики квот была выпущена по регионам. Поэтапный выпуск бинарных версий завершился без выявления дефекта, потому что сбойный путь кода требовал более позднего изменения политики. Функция не была защищена флагом, который позволял бы постепенно включать её для выбранных проектов, а обработка недопустимых данных позволяла нулевому значению вызывать аварийное завершение процесса.

12 июня примерно в 10:45 по тихоокеанскому времени политика квот с непреднамеренно пустыми полями была записана в региональные таблицы Spanner, используемые Service Control.

Поскольку метаданные квот были спроектированы для глобального перемещения с почти мгновенной согласованностью, данные появились во всех регионах в течение секунд. Затем каждый региональный экземпляр Service Control столкнулся с одними и теми же входными данными и вошёл в цикл аварийных перезапусков.

Это не случай отсутствия резервирования. Региональные экземпляры сервисов и региональные хранилища данных существовали. Это также не просто случай, когда инженер нажал не ту кнопку. Производственная система приняла структурно небезопасные данные политики, критический путь не имел защитной обработки ошибок, функция достигла каждого региона без независимо контролируемого пути активации, а система распространения была быстрее системы валидации. Архитектура превратила один недопустимый логический объект в глобальное событие.

Называть инцидент отключением из-за некорректной политики — точно, но неполно. Политика была триггером. Более крупные причины — объём полномочий, связанных с ней, и отсутствие изоляции между приёмом, репликацией, интерпретацией и обслуживанием. Ответственный вопрос не только в том, почему существовало пустое поле. А в том, почему любая отдельная политика могла стать исполняемым состоянием отказа везде, прежде чем один регион, одна когорта проектов или один теневой валидатор успели её отклонить.

Короткий триггер привёл к долгому и неравномерному восстановлению

В хронологии Google две очень разные истории. Обнаружение и диагностика были быстрыми. Полное восстановление — нет.

Медленный путь в us-central1 является центральным для анализа рисков. Когда задачи Service Control перезапускались, они создавали концентрированный спрос на таблицу Spanner под ними. Задачам не хватало рандомизированной экспоненциальной задержки, необходимой для предотвращения синхронизированных повторных попыток. Google пришлось ограничить создание задач и направлять трафик в мультирегиональные базы данных. Другими словами, первый сбой был небезопасной интерпретацией глобальных данных; второй — поведением восстановления, перегрузившим общую зависимость.

Собственная литература Google по SRE давно описывает эту опасность. Её глава опротиводействии каскадным сбоямобъясняет, как повторные попытки и перезапуски могут держать бэкенд перегруженным и как рандомизированная экспоненциальная задержка, плавная деградация и контролируемый сброс нагрузки могут предотвратить превращение локальной проблемы с ёмкостью в каскад. Отчёт 2025 года прямо обязуется проверять системы на наличие этой задержки. Важно не то, что Google не последовал предложению в книге. А то, что известный класс опасностей распределённых систем остался в критическом сервисе, чья популяция перезапусков была региональной, а поддерживающие данные — глобальными.

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

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

Длинный хвост также важен для коммуникации с клиентами. Предварительный отчёт Google описывал трёхчасовое глобальное событие, в то время как страница инцидента продолжала перечислять восстановление продуктов до 18:18. У некоторых продуктов были очереди после возвращения обслуживания API. У клиента, чей запрос не удался в основное окно, могли быть повторные попытки, поставленные в очередь задания, частичные рабочие процессы, устаревшие кэши или сторонний сервис, восстанавливавшийся дольше. «Зелёное» состояние провайдера — это начало сверки с клиентом, а не доказательство того, что каждый бизнес-процесс цел.

Региональное развёртывание не создало регионального обучения

Прогрессивная поставка должна превращать расстояние в доказательства. Изменение достигает небольшой популяции; операторы наблюдают за его поведением; только затем оно движется дальше. Google использовал поэтапный по регионам выпуск бинарных версий нового кода Service Control, но развёртывание никогда не задействовало путь кода, который позже отказал. Активирующая политика следовала другому механизму распространения, оптимизированному для того, чтобы состояние квот становилось глобальным в течение секунд. Код был постепенным; значение кода — нет.

Это тонкий, но значимый сбой контроля изменений. Команды часто рассматривают бинарные версии, конфигурацию, схему, политику и данные как отдельные объекты. Однако производственное поведение возникает из их комбинации. Спящая функция может пройти все региональные ворота, пока значение конфигурации не разбудит её везде. Схема может быть валидной для писателя, но невалидной для более старого читателя. Глобально реплицируемая политика может сделать региональные канареечные развёртывания нерелевантными. «Красная кнопка» может существовать, но всё равно зависеть от сломанной плоскости управления, чтобы вступить в силу.

Текущее руководство Google по инфраструктуре признаёт этот риск.Руководство по строительным блокам надёжностиговорит, что глобальные ресурсы устойчивы к зональным и региональным инфраструктурным инцидентам, но могут стать едиными точками отказа, когда критическая ошибка конфигурации имеет глобальный охват. Оно рекомендует тщательный контроль изменений и, для исключительно требовательных рабочих нагрузок, региональную защиту в глубину. Сопутствующееруководство по управлению и мониторингусоветует прогрессивное развёртывание и дополнительную проверку глобальных ресурсов.

Инцидент 2025 года применяет ту же логику внутри провайдера: глобальный охват — это преимущество надёжности против физических отказов и опасность радиуса поражения для плохого логического состояния.

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

Репликация должна быть достаточно инкрементальной, чтобы сохранять интервал обнаружения, даже если конечное бизнес-состояние должно стать глобально согласованным.

Это не означает, что каждая глобальная политика должна стать медленно несогласованной. Решения о квотах и авторизации могут требовать своевременного и согласованного состояния. Вопрос дизайна в том, можно ли отделить валидацию от полномочий. Кандидатная политика может реплицироваться как инертные данные, анализироваться и оцениваться на трафике, похожем на производственный, и вступать в силу только после успешных проверок. Регионы могут сохранять последнюю известную хорошую политику, когда новый объект недействителен. Читатели могут отличать повреждение от законного отказа.

Глобальная согласованность не несовместима с поэтапной безопасностью; она просто требует большего, чем быстрая репликация.

Fail-open — это бизнес-решение и решение о безопасности, а не лозунг

Google обязался модуляризировать Service Control, чтобы затронутая функция политики могла быть изолирована и переведена в режим fail-open, позволяя запросам API продолжаться, если соответствующая проверка не удалась. Это значимая коррекция, но фраза «fail-open» нуждается в границах. Проверка квоты, решение об аутентификации, биллинговый контроль и контроль предотвращения злоупотреблений имеют разные последствия при недоступности.

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

Правильное деградированное поведение зависит от назначения контроля, свежести доверенного состояния, обратимости действий и потенциала мошенничества, потери данных или неконтролируемых расходов.

Архитектурасервисной инфраструктуры Googleразделяет плоскости управления, контроля и данных, показывая, насколько широки функции платформы: аутентификация, авторизация, квоты, ограничение скорости, аудит, биллинг, логирование и мониторинг. Именно эта широта делает модульное поведение отказов важным. Один парсер или путь политики не должен превращать каждый тип решения в одинаковый ответ 503.

Ответственный дизайн публиковал бы принципы, а не чувствительные детали реализации. Какие классы проверок используют последние известные хорошие данные? Какие могут временно работать в режиме fail-open? Какие закрываются (fail-closed), потому что доминируют последствия для безопасности? Какие жёсткие пределы остаются во время деградированного обслуживания? Как сверяются исключительные использования? Могут ли клиенты выбирать более строгое поведение для регулируемых рабочих нагрузок? Как платформа отличает недействительную политику провайдера от законного отказа в квоте клиента?

Это также меняет тестирование. Недостаточно подтвердить, что хорошая политика возвращает правильный ответ. Тесты должны внедрять пустые поля, неизвестные поля, устаревшие версии, частичную репликацию, повреждённые объекты, недоступные хранилища, медленные чтения и конфликтующие политики. Они должны доказывать, что один модуль может быть обойдён без обхода несвязанных защит. Они должны измерять видимое клиенту поведение во время деградированной работы и проверять, что восстановление не воспроизводит отклонённые или дублирующиеся изменения непредсказуемо.

Система статуса разделила сбой, который должна была описывать

Примерно в первый час клиенты не получали публичный отчёт об инциденте Cloud Service Health, потому что сама эта инфраструктура была недоступна. Некоторые клиенты также запускали мониторинг в Google Cloud, поэтому и сервис, и доказательства его работы отказывали вместе. Сбой нарушил не только производство, но и эпистемический контроль: способность знать, что происходит, решать, следует ли переключаться, и объяснять ситуацию пользователям.

Это было не беспрецедентно. Во время глобального сбоя аутентификации Google 14 декабря 2020 годаотчёт об инцидентеговорит, что внутренние инструменты Cloud Support были затронуты, клиенты не могли создавать или просматривать обращения в консоли, а коммуникация на панели задерживалась до окончания основного воздействия. Это событие произошло из-за автоматического управления квотами, сократившего ёмкость центральной системы идентификации. Существующие конфигурации сетевой плоскости данных оставались работоспособными, но аутентифицированные сервисы, доступ API, консоли и многие внутренние инструменты — нет.

Механизм отличается от 2025 года; повторяющаяся проблема в том, что идентификация, поддержка, мониторинг и коммуникация могут разделять судьбу с сервисами, которые они должны диагностировать.

С тех пор Google задокументировал более явную модель коммуникации. Егоруководство по коммуникации об инцидентахразличает Personalized Service Health, который использует контекст проекта и может интегрироваться с оповещениями и API, и публичную панель Cloud Service Health. То же руководство признаёт, что Personalized Service Health зависит от таких сервисов, как IAM, и рекомендует откат к публичной панели и RSS-каналу, когда персонализированные системы недоступны. Это разумный совет, но июнь 2025 года показывает, что публичный канал также нуждается в операционной независимости.

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

У клиентов есть параллельная обязанность.Руководство по интеграции Personalized Service Healthявно говорит, что сервис не может знать, критичен ли каждый продукт для конкретного приложения или продолжает ли приложение работать при отказе одной зависимости. Операторам нужны собственные проверки пользовательского пути, метрики приложений, сетевая телеметрия и сигналы тревоги бизнес-процессов. По крайней мере один путь должен работать вне Google Cloud и доставлять в канал инцидентов, не зависящий от идентификации Google. Статус провайдера — это подтверждение, а не первый и единственный детектор.

Для этого разделения есть причина управления. Задержка страницы статуса меняет поведение клиентов. Команды могут тратить время на поиск в собственных развёртываниях, выполнять рискованные откаты, масштабироваться в сломанную плоскость управления или откладывать переключение в ожидании подтверждения. Тишина поддержки также может побудить нижестоящих провайдеров публиковать догадки. Доступность коммуникации — это поэтому контроль риска с измеримыми целями обнаружения и публикации, а не любезность, добавленная после инженерной работы.

Существующие рабочие нагрузки пережили лучше, чем действия, призванные их спасти

Утверждение отчёта 2025 года о том, что существующие потоковые и инфраструктурные ресурсы не пострадали, следует читать внимательно. Оно демонстрирует полезное разделение между частями плоскости данных и путём управления. Оно не означает, что приложение было безопасно только потому, что его текущие виртуальные машины остались работать.

Облачные системы динамичны. Автоскейлеры создают экземпляры. Оркестраторы заменяют нездоровые узлы. Системы развёртывания получают артефакты и выполняют вызовы API. Базы данных переключаются. Сертификаты и токены ротируются. Serverless-сервисы вызывают пути управления провайдера за кажущимся простым запросом. Реагирующие на инциденты меняют правила файрвола, балансировщики нагрузки, DNS, маршруты, квоты и разрешения. Статическая плоскость данных может продолжать пересылку, в то время как бизнес-процесс вокруг неё теряет способность адаптироваться.

Сетевой сбой февраля 2021 года делает эту границу конкретной.Отчёт об инциденте сбоя программирования сетиговорит, что скрытый дефект был вызван, когда глобальная сетевая плоскость управления повторно обработала операции, связанные с изменениями квот пиринга. Новые, обновлённые, удалённые или мигрированные виртуальные машины и сетевые конечные точки не могли быть правильно запрограммированы, в то время как многие неизменённые экземпляры продолжали работать. Google приостановил живые миграции по всему миру; около 1000 кластеров GKE были затронуты невозможностью предоставлять узлы или кластеры; некоторые создания экземпляров и обновления балансировщиков нагрузки терпели неудачу с очень высокими показателями.

Здоровый существующий сервер не помогал группе автоскейлинга, которой нужен был новый подключённый к сети сервер.

Это парадокс плоскости управления в аварийном восстановлении. Действия в плане восстановления часто менее протестированы и более зависимы от плоскости управления, чем обычное обслуживание. Инструкция может говорить «создать ёмкость во втором регионе» или «переключить балансировщик нагрузки», но это операции API. Если инициирующий сбой нарушает создание ресурсов или глобальные обновления балансировщиков нагрузки, шаг восстановления недоступен именно тогда, когда он нужен.

Руководство по архитектуре аварийного восстановления Googleразличает действия плоскости данных и обновления плоскости управления и объясняет устойчивость конкретных сервисов. Егоруководство по проектированию надёжной инфраструктурырекомендует избегать или минимизировать зависимость от действий, не относящихся к плоскости данных, во время сбоев, таких как создание нового балансировщика нагрузки. Практический урок — заранее подготовить путь восстановления. Ёмкость может быть тёплой, а не гипотетической. Региональные конечные точки могут существовать до отказа глобального фронтенда. Записи DNS, учётные данные, маршруты, образы и инструкции могут быть доступны без административной операции в последнюю минуту.

Для каждого шага восстановления оператор должен уметь назвать API, поставщика идентификации, сетевой путь, DNS-резолвер, хранилище артефактов, секрет и человеческое одобрение, которые он требует. Затем упражнение должно удалять эти зависимости по одной. План, который успешен только пока консоль, IAM, Service Control, глобальное программирование сети и основной регион здоровы, — это процедура расширения, а не аварийное восстановление.

Сбой 2019 года показал, что физическое разделение может разделять одну границу автоматизации

2 июня 2019 года проекты Google Cloud в нескольких регионах США испытывали повышенную потерю пакетов более трёх часов. Некоторые сервисы Google не могли полностью перенаправлять пользователей в незатронутые регионы.Отчёт о сетевом инцидентеописал несколько сбоев, объединившихся в крупное отключение: задания сетевой плоскости управления были настроены на остановку для события обслуживания; несколько экземпляров управления кластерами подходили под один и тот же редкий тип события; а программная ошибка позволила автоматизации выводить независимые программные кластеры, даже если они находились в разных физических локациях.

Сеть первоначально продолжала работать в режиме «fail static» без своей плоскости управления. Несколько минут спустя маршруты BGP между затронутыми локациями были отозваны, что снизило пропускную способность сети и сделало некоторые регионы недоступными. Отказ диагностических инструментов в перегруженной сети замедлил расследование. Когда инженеры восстановили экземпляры плоскости управления, конфигурацию пришлось перестраивать и перераспределять, что продлило восстановление.

Здесь есть поразительное структурное сходство с 2025 годом. В 2019 году существовали физические локации и несколько менеджеров кластеров, но одна абстракция обслуживания выбрала их вместе. В 2025 году существовали региональные экземпляры Service Control, но одна глобальная политика достигла их вместе. Оба инцидента включали безопасный период, оказавшийся слишком коротким или слишком зависимым: маршрутизация fail-static в 2019 году и обход «красной кнопки» в 2025 году. Оба нарушили инструменты, используемые для понимания или коммуникации сбоя.

Оба пути восстановления должны были восстанавливать или перераспределять состояние управления в деградированных условиях.

Причины не взаимозаменяемы. Инцидент 2019 года был сбоем сетевого управления и автоматизации обслуживания; инцидент 2025 года — сбоем данных политики и API-контроля. Ответственность не должна сплющивать их в «у Google снова было отключение». Ценность сравнения в том, чтобы проверить, обнаруживает ли организация неоднократно, что номинально независимые компоненты всё же разделяют административный домен, механизм распространения, аварийный инструмент или зависимость восстановления.

Обязательства Google 2019 года включали отклонение затронутых запросов обслуживания, сохранение локальной конфигурации плоскости управления, продление длительности работы сети в режиме fail-static, усиление аварийных инструментов и расширение тестов аварийного восстановления. Текущий вопрос ответственности не в том, предотвратили бы эти действия несвязанный нулевой указатель 2025 года. А в том, стал ли лежащий за ними метод управления стандартом: картографировать общие полномочия, сохранять безопасное состояние, держать аварийные средства управления вне основного домена отказа и тестировать катастрофический коррелированный сбой.

Программа исправлений имеет институциональную ценность только когда её паттерн контроля выходит за пределы команды, написавшей посмертный анализ (postmortem).

Разнообразие пиринга и транзита — это вопрос судьбы, а не количества каналов

Доступность облака достигает клиентов через сети. Рабочая нагрузка может быть здоровой внутри региона, пока пользователи не могут до неё добраться, потому что отказали граничная сеть, магистральный маршрут, пиринговая сессия, транзитный провайдер, DNS-путь или гибридный канал. И наоборот, два канала доступа могут выглядеть разнообразными в заказе, но сходиться в одном мегаполисе, одном провайдере, одной модели маршрутизатора, одной границе Google или одной системе управления.

Отчёт об инциденте магистрали Googleот 17 марта 2021 года иллюстрирует эту разницу. Подключение новых маршрутизаторов изменило, какие маршруты получают определённые роли маршрутизаторов. Эти маршруты выявили известный дефект в конкретной модели маршрутизатора, что привело к сбоям процессов маршрутизации. Автоматическое перенаправление снизило риск более широкого каскада, но вызвало потерю пакетов во время конвергенции. Ручное смягчение вызвало ещё один период перегрузки, а в некоторых локациях Cloud Interconnect воздействие было продолжительным из-за недостаточного резервирования вендоров маршрутизаторов.

Межрегиональный трафик с частными IP, трафик с публичными IP, балансировщики нагрузки, VPN-туннели и внешняя связность были затронуты в разных пропорциях.

Вот почему обзор устойчивости должен перейти от «у нас два канала». Обзор должен спрашивать, кто владеет каждым волоконным путём, какое здание и домен доступности границы он использует, какой вендор маршрутизаторов и линейка ПО его завершают, какой Cloud Router управляет его сессиями BGP, как сходятся маршруты, может ли резервная ёмкость выдержать всю нагрузку и не зависят ли оба пути от одной плоскости управления провайдера. Он должен наблюдать реальные изменения маршрутов и проводить плановые отзывы, а не принимать диаграмму топологии как доказательство.

Обзор Cloud Interconnectпредлагает конфигурации с 99,9 и 99,99 процента и объясняет, что одинарное соединение не имеет SLA по времени безотказной работы.Руководство Partner Interconnectтребует четыре VLAN-подключения через два мегаполиса и домены доступности границ для рекомендуемой топологии 99,99 процента; оно также отмечает, что сегмент провайдера вне сети Google нуждается в собственных гарантиях. Использование нескольких поставщиков услуг может улучшить доступность, но только если их базовые пути действительно раздельны и имеют достаточно ёмкости при переключении.

Пиринг внутри облака не является транзитом по умолчанию.Документация VPC Network Peeringгласит, что пиринг нетранзитивен: если сеть A пирится с B, а A также пирится с C, B не получает тем самым связь с C. Это ограничение может быть полезной границей изоляции, но оно удивляет команды, которые предполагают, что центральная VPC автоматически действует как транзитный хаб. Во время сбоя импровизированный путь восстановления может не работать, потому что заявленная топология никогда не поддерживалась. Там, где требуется транзит, он должен быть спроектирован явно, с обменом маршрутами, политикой, ёмкостью, проверкой безопасности и поведением при отказе, протестированными от начала до конца.

Интернет-транзит заслуживает той же точности. Публичный доступ через двух ISP всё равно может входить в сеть Google через общую пиринговую площадку. Частный канал и интернет-VPN могут давать лучшее административное разнообразие, но оба могут зависеть от магистрали Google или той же идентификации клиента и DNS. Второе облако может снизить концентрацию провайдера только если приложение, данные, идентификация, инструменты развёртывания, наблюдаемость и DNS-переключение могут работать там независимо. Подсчёт логотипов — это не архитектура.

Мультирегион — сильная защита от неправильного класса сбоев

Мультирегиональный дизайн остаётся ценным. Он может защитить от отказа электроэнергии, локальной потери ёмкости, зонального аппаратного сбоя и многих региональных программных проблем. Ошибка не в использовании нескольких регионов; ошибка в трактовке этой фразы как полного утверждения независимости.

Сетевое событие 2019 года затронуло несколько регионов, потому что граница автоматизации плоскости управления пересекла физические локации. Инцидент с пиринговыми квотами 2021 года затронул программирование сети глобально, потому что соответствующий контроллер и ресурсы VPC имели глобальный охват. Событие Service Control 2025 года затронуло каждый регион, потому что плоскость политик была глобальной. В каждом случае больше реплик приложения внутри затронутого административного домена не могло устранить общую причину.

Документация Google по надёжности проводит полезное различие между географическим охватом и надёжностью приложения. Глобальные ресурсы могут быть высокоустойчивыми к региональному инфраструктурному сбою, оставаясь при этом едиными точками отказа через конфигурацию. Мультирегиональные ресурсы могут пережить потерю одного региона, но оставаться зависимыми от глобальной идентификации, управления API, сетевого управления или глобального фронтенда. Клиентам нужен граф зависимостей, отмечающий и географию, и полномочия.

Этот граф должен включать как минимум пять слоёв. Первый — исполнение: где реально работают процессы и данные. Второй — управление: какие API создают, маршрутизируют, авторизуют, масштабируют и переключают эти ресурсы. Третий — доступ: какие DNS, пиринг, транзит, каналы, VPN, магистральные пути соединяют пользователей и операторов. Четвёртый — наблюдение: где живут логи, метрики, статусные каналы, страницы и поддержка. Пятый — восстановление: какие репозитории, учётные данные, люди и внешние сервисы нужны для восстановления работы.

Зависимость независима только если одно и то же правдоподобное событие не может отключить её вместе с основной. Два региона, управляемые одной недействительной глобальной политикой, не независимы для этого события. Два стека мониторинга, доставляемые через одну систему идентификации, не независимы для сбоя аутентификации. Два канала на одном ПО маршрутизатора не независимы для соответствующего дефекта вендора. Тёплый сервис в другом облаке не независим, если единственный контроль DNS, репозиторий артефактов или вход оператора живут в Google Cloud.

Этот анализ не должен превратиться в дорогое требование, чтобы каждая небольшая рабочая нагрузка работала через трёх провайдеров. Контроли должны быть соразмерны. Публичный информационный сайт может принять несколько часов простоя и держать внешнюю страницу статуса. Сервис авторизации платежей может нуждаться в предварительно подготовленной ёмкости, независимом транзите, внешнем мониторинге и протестированном резервном провайдере. Ответственный акт — знать, какие зависимости остаются общими, оценить последствия и получить явное согласие владельца бизнеса.

Cloudflare превратил инцидент одного провайдера в урок о зависимостях для другого

Событие июня 2025 года пересекло корпоративную границу особенно поучительным образом.Собственный отчёт Cloudflare об отключенииговорит, что Workers KV частично зависел от стороннего облачного провайдера. Когда эта зависимость отказала, Workers KV стал недоступен, и широкий набор продуктов Cloudflare, использующих его, был нарушен, включая Access, Gateway, WARP, Turnstile, Images, Stream, части панели управления и другие сервисы. Основные CDN и сервисы безопасности Cloudflare не были полностью отключены, но зависимость сделала сбой плоскости управления Google Cloud видимым через продукты, продаваемые под именем другого провайдера.

Это не доказательство того, что аутсорсинг безответственен по своей природе. Провайдеры разумно покупают услуги друг у друга. Это доказательство того, что коммерческая дистанция зависимости не снижает её операционные последствия. Клиент может верить, что диверсифицировался, купив Google Cloud для инфраструктуры и Cloudflare для периферийной безопасности, однако контрольный сервис Cloudflare может зависеть от Google Cloud. Результирующая цепь может быть Google Cloud → Workers KV → Access → вход оператора клиента. Без раскрытия и тестирования клиент не может увидеть, что вторичный контроль разделяет основной домен отказа.

Cloudflare принял свою часть ответственности. Его отчёт описал, какие сервисы зависели от Workers KV, отметил, что основной сервис изначально не переключился со стороннего пути хранения, и описал работу по уменьшению или устранению зависимостей для критических продуктов. Google остаётся ответственным за отказ вышестоящей платформы; Cloudflare остаётся ответственным за решение допустить зависимость критического внутреннего сервиса без надлежащей непрерывности; конечный клиент остаётся ответственным за оценку того, есть ли у доступа к его собственным системам аварийный маршрут. Эти обязанности параллельны, а не взаимоисключаемы.

Современныерепортажи Associated Pressфиксировали видимые нарушения в популярных онлайн-сервисах и десятки тысяч сообщений пользователей. Такие репортажи полезны для демонстрации публичного охвата, но количество сообщений об отключении не является переписью пострадавших людей, запросов или финансовых потерь. Более сильное доказательство — в технических отчётах провайдеров и данных транзакций клиентов. Ответственность должна сопротивляться и преуменьшению, и зрелищности: широкий каскад зависимостей важен, даже когда нет точной общей цифры глобальных потерь.

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

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

Кредит по SLA не доказывает, что зависимость приемлема

Соглашения об уровне обслуживания полезны, потому что определяют измеримое обязательство и средство правовой защиты. Они не являются полной оценкой риска. Ежемесячный процент безотказной работы усредняет время и часто применяется к конкретному продукту или настроенной топологии. Он может исключать конфигурацию клиента, сторонние сегменты, квоты, предварительные функции или сбои вне покрываемого сервиса. Средство правовой защиты обычно представляет собой кредит против будущих расходов, а не компенсацию потерянного дохода, аварийного труда, регуляторной экспозиции или вреда пользователям клиента.

ТекущийSLA Cloud Interconnect, например, различает производственные топологии и одинарные соединения и требует доказательств от клиента для претензий. Эта структура может поощрять правильную топологию, но она не может сказать совету директоров, терпима ли четырёхчасовая потеря гибридного доступа. Продуктовый SLA также не описывает коррелированный сбой между API, используемым для изменения сервиса, мониторингом, используемым для наблюдения за ним, и каналом поддержки, используемым для сообщения о нём.

Клиенту нужна цель уровня обслуживания для собственного пользовательского пути. Эта цель должна включать облачные продукты, сетевые пути, внутренние сервисы и поставщиков, необходимых для завершения пути. Она должна измерять и обслуживание в устойчивом состоянии, и действия восстановления. Платёжный процесс, который остаётся доступным, но не может добавить ёмкость, может быть здоров сейчас и под непосредственным риском. База данных, которая обслуживает чтения, но не может повысить реплику, может иметь сниженную восстанавливаемость ещё до того, как пользователи увидят ошибки.

Условия ответственности и кредитов Google — это юридические распределения, а не инженерные доказательства. И наоборот, публичные извинения провайдера не являются доказательством халатности или юридическим признанием. Эта статья возлагает операционную и управленческую ответственность на основе контроля: кто спроектировал путь распространения, кто принял зависимость, кто мог её тестировать и кто должен проверять исправление. Юридическая ответственность зависит от контракта, юрисдикции, фактов и судебного разбирательства за пределами технического отчёта об инциденте.

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

Список исправлений Google заслуживает доверия только когда становится доказательством

Отчёт об инциденте 2025 года содержит сильный набор обязательств. Google заморозил изменения Service Control и ручные отправки политик после восстановления.

Он сказал, что модуляризирует сервис и будет переводить в fail-open там, где уместно, проверять системы, потребляющие глобально реплицируемые данные, распространять такие данные инкрементально со временем валидации, требовать защиты критических бинарных версий функциональными флагами, отключёнными по умолчанию, улучшать статический анализ и тестирование недопустимых данных, проверять рандомизированную экспоненциальную задержку, улучшать внешние коммуникации и поддерживать доступность мониторинга и коммуникации при отключении Google Cloud.

Эти действия необычно хорошо соответствуют наблюдаемой цепочке отказа. Остающейся проблемой является уверенность. Обещание может закрыть действие в системе отслеживания, не доказывая, что риск снизился в производстве. Google должен публиковать статус завершения, метод валидации и остаточные ограничения для действий с наибольшим воздействием, даже если детальная архитектура остаётся конфиденциальной.

Для безопасности глобальных политик доказательства могут включать процент критических потребителей политики за поэтапной активацией; автоматические показатели отказов для повреждённых данных-кандидатов; минимальные интервалы наблюдения перед глобальным авторитетом; и успешные упражнения, в которых плохой объект останавливается в одной когорте. Для изоляции отказов — тесты, показывающие, что модуль квот может отказать, пока несвязанные проверки API продолжаются, и что решения, чувствительные к безопасности, сохраняют свою границу.

Для восстановления Google должен показать ограничения перезапуска флота, соответствие задержке, резервированную ёмкость хранилища и результаты нагрузочных тестов одновременного восстановления регионов. Для коммуникации он должен публиковать время от первого воздействия на клиента до внутреннего обнаружения, первого публичного уведомления, первого заявления с охватом и доступности независимого пути статуса во время учений. Для институционального обучения — сообщать, были ли найдены и исправлены аналогичные глобальные потребители за пределами Service Control.

Более ранние инциденты обостряют необходимость такого продолжения. После 2019 года Google обещал более длительную работу сети в режиме fail-static, сохранение конфигурации управления, надёжные аварийные инструменты и расширенные тесты катастроф. После февраля 2021 года — дальнейшую регионализацию глобальных компонентов сетевого управления, автоматические паузы миграций и лучшую устойчивость плоскости данных при неотвечающих контроллерах. После марта 2021 года — функциональные домены для enforcement политики маршрутов и улучшенное тестирование сборок маршрутизаторов.

Каждое обязательство могло быть выполнено в рамках своей программы; публичная запись не даёт единого постоянного представления об уверенности, показывающего, как менялся со временем риск общих причин платформы.

Книга Google по SRE описываетпосмертные анализы как систему обучения, с действиями, привязанными к причинам, и без сведения сложных инцидентов к индивидуальной вине. Тот же принцип поддерживает внешнюю ответственность. Цель публикации доказательств — не выставить сотрудника или пригласить клиентов управлять сетью Google. Она в том, чтобы клиенты могли отличить временный обход от устойчивого контроля, видеть, что остаётся открытым, и решать, адекватна ли их собственная обработка риска.

Независимый обзор добавил бы ценности для наиболее глобальных контролов. Он мог бы выборочно проверять проектные документы, записи развёртываний, результаты внедрения сбоев, независимость «красной кнопки» и закрытие действий. Публичный результат мог бы указывать охват, исключения и выводы, не раскрывая эксплуатируемые внутренности. Самоотчёт даёт техническую глубину; независимая уверенность даёт доверие к тому, что критерии закрытия не определялись только командой, ответственной за поставку.

Что клиентам следует тестировать до следующего глобального инцидента

Ни один клиент не может включить функциональный флаг внутреннего бинарного файла Service Control Google или изменить репликацию его таблиц политик. Советы, говорящие клиентам просто «постройте архитектуру лучше» после широкомасштабного сбоя провайдера, несправедливо переносят ответственность. Тем не менее клиенты делают важные выборы о том, сколько власти сбой провайдера имеет над их бизнесом.

Начните с пути обслуживания. Определите, какие пользовательские транзакции продолжаются, если все API управления Google Cloud недоступны три часа. Тестируйте с приостановленными новыми развёртываниями, замороженным автоскейлингом, недоступными изменениями IAM, заблокированными модификациями балансировщиков нагрузки и недоступной поддержкой. Измеряйте, когда ёмкость, учётные данные, сертификаты, очереди или запланированные задания становятся ограничивающим фактором. Результат часто будет кривой, а не бинарным ответом: сервис продолжается при текущей нагрузке некоторое время, затем деградирует по мере накопления рутинных управляющих действий.

Затем тестируйте доступ операторов. Держите аварийные учётные данные, получение и проверка которых не требуют основного пути идентификации облака. Поддерживайте минимальное рабочее пространство инцидента, список контактов, инструкции, архитектурные диаграммы и издателя статуса вне Google Cloud. Убедитесь, что команда может связаться с сетевыми операторами и критическими поставщиками без корпоративного пакета совместной работы, если он разделяет идентификацию Google. Проверяйте каждый аварийный инструмент на скрытые зависимости DNS, электронной почты, единого входа и секретов.

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

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

Наконец, сверяйте после упражнения. Определите, какие транзакции не удались, какие были повторены, какие дублировались, какие остались в очереди и какие клиенты нуждаются в уведомлении. Восстановление провайдера не гарантирует корректность приложения. Цели восстановления должны включать очистку очередей и валидацию данных, а не только HTTP-проверку здоровья.

Для небольших организаций соразмерная версия может быть скромной: внешняя проверка доступности, страница статуса у другого провайдера, экспортированные контакты и инструкции, протестированные резервные копии, известные ручные процедуры и задокументированное решение о том, оправдана ли стоимость мультиоблака. Ответственность не синонимична максимальной архитектуре. Это способность показать, что осознанное решение о риске заменило случайную зависимость.

Оценочная карта ответственности плоскости управления и сети

Совет директоров, регулятор или крупный клиент не нуждаются в проприетарном исходном коде, чтобы задавать точные вопросы. Им нужны доказательства, соответствующие наблюдаемым режимам отказа.

Оценочную карту следует читать по строкам и столбцам. Функциональный флаг без независимого статуса недостаточен. Четыре подключения Interconnect без разнообразия провайдеров и маршрутизаторов могут быть недостаточны. Мультирегиональное приложение без предварительно подготовленного восстановления может всё ещё зависеть от глобального контроллера. Надёжность складывается из композиции контролов и доказательств, что композиция работает при сбое.

Устойчивый сигнал — скорость общей власти

Облачные платформы создают ценность, централизуя решения. Одна политика может управлять тысячами проектов. Одна сеть может переносить трафик между континентами. Один API может создавать инфраструктуру за секунды. Тот же рычаг определяет радиус поражения ошибки.

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

Ответ Google определил правильные темы: инкрементальное распространение, функциональные флаги, модульные отказы, задержка и независимая коммуникация. Клиенты должны ожидать доказательств, что эти изменения работают, оставаясь честными о рисках, которые они всё ещё несут. Рабочая нагрузка может быть распределена по регионам и всё равно зависеть от одного глобального решения. Бизнес может купить две сети и всё равно использовать один путь к судьбе. Страница статуса может быть публичной и всё равно жить внутри инцидента.

Правильный стандарт ответственности не в том, что глобальное облако никогда не должно отказывать. Он в том, что глобальная власть должна двигаться не быстрее, чем контроли, которые её валидируют; региональные системы должны уметь отклонять или переживать небезопасное общее состояние; сетевые пути и пути восстановления должны быть независимы в работе, а не только в названиях; и клиенты должны иметь возможность видеть сбой, пока ещё есть время действовать. В облачной плоскости управления скорость — это сила. Устойчивость начинается с ограничений на то, куда эта сила может распространяться.