Кратко

  • Google Cloud связывает сервисный инцидент высокой тяжести в us-west1 20 августа с плановым обслуживанием оптики, которое вызвало неожиданную перегрузку в агломерации The Dalles в Орегоне. Официальная запись перечисляет 27 продуктов.
  • Google дважды рекомендовала по возможности переключиться в другие регионы. Для этого клиенту уже требовались актуальные реплики, управление трафиком, учетные данные, внешние зависимости и полномочия на переключение.

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

В записи начало инцидента указано как 15:40 UTC 20 августа. Первое публичное сообщение появилось в 16:44:37, более чем через час, и говорило о тайм-аутах, ухудшении работы, ошибках и повышенной задержке в нескольких продуктах. В 17:13:59 и 17:32:15 компания рекомендовала клиентам использовать другие регионы, если это возможно.

В итоговом сообщении сказано, что инженеры восстановили емкость, а основная проблема была смягчена к 17:22 UTC. Эта ретроспективная оценка опубликована только в 19:37:40. Между этими моментами Google объявила меры смягчения завершенными, хотя отдельные продукты продолжали восстанавливаться. Сама запись об инциденте закрыта в 19:20.

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

Инцидент имеет высокую тяжесть и тип воздействия SERVICE_OUTAGE; в нем перечислены 27 продуктов. Список охватывает вычисления, хранение, базы данных, обработку данных, сборку, мониторинг, идентификацию и обмен сообщениями. В него входят, среди прочих, Compute Engine, GKE, Cloud Run, Cloud Storage, Cloud SQL, BigQuery, Pub/Sub, Cloud Monitoring, IAM и Persistent Disk.

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

В первых обновлениях рядом с Орегоном также стояла отметка местоположения Global. Однако описание последовательно помещает клиентские симптомы в us-west1. Метка может обозначать охват продукта или классификацию на странице состояния и не доказывает глобальный отказ Google Cloud.

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

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

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

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

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

Источники