Relatório de incidente do Google Cloud – 2025-06-13
(status.cloud.google.com)- Em 12 de junho de 2025, houve aumento de erros 503 em solicitações de APIs externas no Google Cloud, Google Workspace e Google Security Operations, afetando clientes no mundo todo
- Uma nova verificação de política de cota do Service Control encontrou dados de política com campos vazios e causou um loop de crashes por null pointer; esse caminho não foi executado durante o rollout
- Como a mudança de política foi replicada de tabelas regionais do Spanner para o mundo todo em poucos segundos, as implantações do Service Control em cada região seguiram o mesmo caminho de falha, transformando o problema em um incidente global
- A equipe de SRE iniciou a resposta em até 2 minutos, identificou a causa em até 10 minutos e concluiu o rollout do red-button em cerca de 40 minutos, mas a recuperação de us-central1 levou até cerca de 2 horas e 40 minutos
- As medidas para evitar recorrência se concentram em congelar mudanças no Service Control, desativar flags de funcionalidade por padrão, propagar dados replicados globalmente de forma gradual e melhorar o tratamento de erros e o backoff exponencial aleatório
Escopo do incidente e cronograma
- Clientes foram afetados por um aumento de erros 503 em solicitações de APIs externas nos produtos Google Cloud, Google Workspace e Google Security Operations
- Todos os principais horários estão em US/Pacific
- Início do incidente: 12 de junho de 2025, 10:49
- Mitigação em todas as regiões exceto us-central1: 12:48
- Fim do incidente: 13:49
- Duração total: 3 horas
- Escopo do impacto: Global
- Clientes enfrentaram problemas intermitentes de acesso a APIs e interfaces de usuário nos serviços afetados
- Recursos existentes de streaming e IaaS não foram afetados
Caminho de verificação sob responsabilidade do Service Control
- As APIs do Google e do Google Cloud são fornecidas por meio do plano de gerenciamento e controle de APIs do Google
- Esse plano de gerenciamento e controle verifica, para cada solicitação de API:
- se a solicitação foi autorizada
- se ela pode passar por verificações como políticas e cotas e seguir para o endpoint
- O binário central do sistema de verificação de políticas é o Service Control
- O Service Control é um serviço regional e usa um datastore regional que lê informações de cotas e políticas
- Os metadados desse datastore são replicados quase imediatamente pelo mundo todo para o gerenciamento de políticas de cota do Google Cloud e dos clientes
Causa direta: campo de política vazio e null pointer
- Em 29 de maio de 2025, um novo recurso para verificações adicionais de políticas de cota foi adicionado ao Service Control
- A mudança de código e a release do binário passaram por rollout por região, mas o caminho de código que falhou só era executado com uma mudança específica de política, por isso não foi validado durante o rollout
- O código problemático tinha um red-button para desligar esse caminho de fornecimento de políticas, mas não tinha tratamento de erros adequado nem proteção por flag de funcionalidade
- Como o null pointer não foi tratado corretamente, isso levou ao crash do binário do Service Control
- O Google afirmou que, se estivesse protegido por uma flag de funcionalidade, o problema teria sido detectado em staging ao ativá-lo gradualmente por região, começando por projetos internos
Processo de propagação global
- Por volta de 10:45 PDT de 12 de junho de 2025, uma mudança de política foi inserida em uma tabela regional do Spanner usada pelo Service Control para políticas
- Esses dados de política incluíam campos vazios não intencionais
- Como o gerenciamento de cotas opera globalmente, esses metadados foram replicados para o mundo todo em poucos segundos
- O Service Control em cada região leu os campos vazios ao executar verificações de cota sobre as políticas no datastore regional, acionando o caminho de código que encontrou o null pointer
- Como resultado, o binário entrou em loop de crashes em cada implantação regional
Resposta e atraso na recuperação
- A equipe de SRE começou a triagem e a resposta em até 2 minutos após o início do incidente
- Em até 10 minutos, identificou a causa raiz e iniciou a aplicação do red-button
- O red-button ficou pronto para rollout cerca de 25 minutos após o início do incidente
- O rollout do red-button foi concluído em até 40 minutos após o início do incidente, e sinais de recuperação começaram a aparecer nas regiões menores
- Em regiões grandes como us-central1, os jobs do Service Control foram reiniciados, criando um herd effect na infraestrutura dependente, especialmente nas tabelas do Spanner, e causando sobrecarga
- O Service Control não tinha uma implementação adequada de backoff exponencial aleatório para evitar isso
- Em us-central1, após reduzir a carga fazendo throttling da criação de jobs e roteando o tráfego para um banco de dados multirregional, a resolução completa levou até cerca de 2 horas e 40 minutos
- Depois disso, o Service Control e o serving de APIs foram totalmente recuperados em todas as regiões
- Produtos relacionados do Google e do Google Cloud foram recuperados sequencialmente, em alguns casos levando mais tempo dependendo da arquitetura
Página de status e comunicação com clientes
- O primeiro relatório de incidente no Cloud Service Health foi publicado cerca de 1 hora depois do início dos crashes
- O motivo do atraso foi que a própria infraestrutura do Cloud Service Health estava fora do ar por causa desse incidente
- Alguns clientes também tiveram falhas na infraestrutura de monitoramento que rodavam no Google Cloud, ficando sem conseguir identificar sinais do incidente ou a extensão do impacto nos negócios e na infraestrutura
- O Google afirmou que melhorará as comunicações externas automáticas e manuais para que os clientes recebam mais rapidamente as informações necessárias para responder a problemas, gerenciar seus sistemas e dar suporte aos próprios clientes
- Também afirmou que garantirá que a infraestrutura de monitoramento e comunicação continue atendendo os clientes mesmo quando o Google Cloud e os produtos básicos de monitoramento estiverem fora do ar
Ações imediatas e plano de prevenção de recorrência
- Logo após a recuperação, todas as mudanças na stack do Service Control e todos os pushes manuais de políticas foram congelados
- O Google afirmou que dará prioridade e concluirá com segurança as seguintes ações:
- Modularizar a arquitetura do Service Control para isolar funcionalidades e mudar para uma estrutura fail open, permitindo que solicitações de API continuem sendo processadas mesmo que verificações relacionadas falhem
- Auditar todos os sistemas que consomem dados replicados globalmente
- Mesmo quando houver requisitos de negócio para consistência quase imediata em escala global, propagar a replicação de dados de forma gradual, com tempo suficiente para validação e detecção de problemas
- Proteger todas as mudanças em binários críticos com flags de funcionalidade e deixá-las desativadas por padrão
- Melhorar práticas de análise estática e testes para tratar erros corretamente e permitir fail open quando necessário
- Auditar e garantir que os sistemas usem backoff exponencial aleatório
- Melhorar a comunicação com clientes
- Manter a operação da infraestrutura de monitoramento e comunicação mesmo durante incidentes no Google Cloud e nos produtos básicos de monitoramento
Serviços afetados e impacto residual
- Muitos produtos do Google Cloud foram afetados, incluindo Identity and Access Management, Cloud Build, Google Cloud Storage, Cloud Monitoring, Cloud Run, Google BigQuery, Vertex Gemini API, Apigee, Google Cloud Bigtable, Cloud Functions, Cloud Load Balancing, Cloud Firestore, Cloud Logging, Cloud Spanner, Google App Engine, Google Cloud Console, Google Compute Engine, Cloud SQL, Cloud Pub/Sub, Persistent Disk, Google Security Operations, entre outros
- Entre os produtos do Google Workspace, foram afetados AppSheet, Gmail, Google Calendar, Google Drive, Google Chat, Google Voice, Google Docs, Google Meet, Google Cloud Search e Google Tasks
- Alguns produtos tiveram impacto residual mesmo após a mitigação do incidente principal
- O backlog do Google Cloud Dataflow foi reduzido gradualmente, e atrasos permaneceram em us-central1
- O Vertex AI Online Prediction continuou apresentando altos índices de erros 5xx em alguns modelos do Model Garden e depois foi totalmente recuperado às 18:18 PDT
- O Personalized Service Health teve atrasos nas atualizações, e foi recomendado aos clientes usar o painel do Cloud Service Health
1 comentários
Este é o link para a versão do texto que não é GN+.