Resumo

  • O Google Cloud atribui o incidente de serviço de alta severidade da us-west1, em 20 de agosto, a uma manutenção óptica programada que provocou congestionamento inesperado em The Dalles, no Oregon. O registro oficial cita 27 produtos.
  • O provedor recomendou failover para outras regiões quando viável. A recomendação dependia de dados replicados, controles de tráfego, credenciais, dependências e autoridade de mudança já funcionarem fora da região.

A manutenção estava no calendário; o congestionamento não. O ponto operacional é a folga de capacidade que permanece durante uma intervenção planejada. Segundo o Google, essa folga ficou insuficiente na us-west1 e os sintomas atravessaram uma ampla camada de serviços.

O registro começa às 15h40 UTC de 20 de agosto. A primeira atualização pública apareceu às 16h44min37s, mais de uma hora depois, relatando timeouts, degradação, erros e latência elevada em vários produtos. Às 17h13min59s e novamente às 17h32min15s, a empresa orientou clientes a usar outras regiões quando possível.

A atualização final afirma que engenheiros restauraram capacidade e que o problema estava mitigado às 17h22 UTC. Essa avaliação retrospectiva só foi publicada às 19h37min40s. No intervalo, o Google informou que as ações de mitigação tinham terminado enquanto produtos individuais continuavam a se recuperar. O registro do incidente encerra às 19h20.

Os horários representam estados distintos: início registrado, mitigação da restrição subjacente, encerramento do registro e publicação da explicação final. Nenhum deles determina sozinho quando uma aplicação específica voltou a operar normalmente.

Classificado como de alta severidade e impacto SERVICE_OUTAGE, o incidente relaciona 27 produtos. A lista cobre computação, armazenamento, bancos de dados, processamento de dados, compilação, monitoramento, identidade e mensageria. Compute Engine, GKE, Cloud Run, Cloud Storage, Cloud SQL, BigQuery, Pub/Sub, Cloud Monitoring, IAM e Persistent Disk estão entre os nomes.

Essa abrangência aponta para uma dependência regional comum, não para 27 interrupções totais e idênticas. O Google não publica taxa de impacto por produto, número de requisições com falha, universo de clientes ou projetos, mapa por zona nem distribuição de latência. Os efeitos podem ter variado, mas o registro não os separa.

As primeiras mensagens também exibiam a marca de localização Global ao lado do Oregon. A narrativa, porém, localiza os sintomas dos clientes na us-west1. A marca pode refletir o escopo do produto ou uma classificação da página de status; ela não sustenta a afirmação de uma queda mundial do Google Cloud.

O material de arquitetura do Google explica que produtos em nuvem dependem de funções comuns, incluindo rede, acesso a data centers e autorização de identidade. Replicação e failover entre regiões também passam pela rede física. Assim, restaurar capacidade óptica pode remover o gargalo compartilhado sem concluir instantaneamente a recuperação de cada serviço gerenciado.

Para o cliente, “usar outra região quando viável” é uma condição, não uma garantia. A região secundária precisa existir; os dados precisam atender ao objetivo de ponto de recuperação; DNS ou balanceamento, filas, identidades, serviços externos e a cadeia de autorização precisam sobreviver ao incidente.

A orientação de confiabilidade do Google recomenda testar failover regional, rollback e restauração de dados, além de verificar o deslocamento do tráfego e a sincronização das réplicas. Um desenho de arquitetura ou um ambiente secundário nunca exercitado não demonstra o objetivo de tempo de recuperação.

O registro público não identifica circuito, operadora, topologia, capacidade retirada, limiar de congestionamento ou ação exata de manutenção. Tampouco prova perda de dados, rompimento de fibra, evento de segurança ou falha de um cliente identificado. O Google promete uma análise posterior, ainda ausente do registro capturado.

A conclusão sustentada é mais estreita: segundo o Google, o trabalho programado reduziu a capacidade de rede utilizável até causar congestionamento regional, e a recuperação avançou por muitos serviços. Capacidade do provedor, saúde do produto e estado da aplicação do cliente devem ser medidos separadamente.

Fontes