Relatório de incidente do Google Cloud – 2025-06-13

• Em 12 de junho de 2025, houve um aumento global de erros 503 em requisições a APIs externas nos serviços Google Cloud e Google Workspace
• A causa do erro foi uma mudança de código no sistema Service Control e a aplicação incorreta de uma política contendo um campo em branco nos dados de política
• A falta de tratamento adequado de erros no binário principal e a ausência de aplicação de feature flags ampliaram a propagação do problema
• A recuperação levou de 2 a 3 horas, e a região us-central-1 teve um tempo maior de recuperação devido à sobrecarga de infraestrutura
• O Google anunciou medidas para evitar recorrência, como separação da arquitetura, melhoria no tratamento de erros e reforço da validação de dados

---

Visão geral completa do incidente

Resumo da indisponibilidade nos serviços Google Cloud e Google Workspace

• A partir das 10:49 (PDT) de 12 de junho de 2025, vários serviços, incluindo Google Cloud, Google Workspace e Google Security Operations, passaram a apresentar um aumento acentuado de erros 503 em requisições a APIs externas
• O Google expressou um profundo pedido de desculpas pelo impacto sério causado aos serviços e à confiança dos clientes
• O plano de gerenciamento e controle de APIs do Google é responsável pelas verificações de política e cota de cada requisição, e o sistema central de verificação opera como um binário chamado Service Control

Análise da causa do incidente

Mudança na estrutura do sistema – Service Control

• Em 29 de maio de 2025, foi adicionada ao Service Control uma nova funcionalidade para reforçar a verificação de políticas de cota
• O lançamento foi feito de forma gradual por região, mas o código problemático só era executado quando a política fosse realmente aplicada, o que impediu seu acionamento anterior e resultou em testes prévios insuficientes
• Nesse caminho da nova funcionalidade, não havia tratamento de erro adequado nem feature flags, fazendo com que o binário travasse em cadeia em uma situação de null pointer

Como o incidente ocorreu

• Às 10:45 (PDT) de 12 de junho de 2025, uma alteração de política foi inserida em uma tabela Regional Spanner
• Esses dados de política continham um campo em branco (Blank Field) não intencional, que foi replicado quase em tempo real no mundo todo
• Ao processar essa política, o Service Control sofreu um crash por null pointer, e as instâncias de cada região entraram globalmente em Crash Loop
• Em 2 minutos, a equipe de SRE começou a identificar o problema; em 10 minutos, descobriu a causa e bloqueou temporariamente o caminho do binário (red-button); em 40 minutos, a maioria das regiões já havia se recuperado

Problemas adicionais na recuperação

• Em algumas regiões de grande porte, como us-central-1, a reinicialização das tarefas do Service Control causou sobrecarga na infraestrutura (tabelas Spanner) devido ao herd effect
• O Service Control não aplicava backoff exponencial aleatório, o que aumentou ainda mais a carga sobre a infraestrutura
• Nessa região, a recuperação atrasou até 2 horas e 40 minutos; o impacto foi reduzido com desvio de tráfego, e no fim a recuperação completa do serviço foi concluída

Impacto ao cliente e alcance da indisponibilidade

• Os clientes enfrentaram falhas de acesso a APIs e interfaces de usuário, enquanto streaming e recursos de IaaS não foram afetados
• Impactos de latência e backlog continuaram por mais de 1 hora em alguns serviços
• Foi apresentada uma lista extensa de produtos Google Cloud e Google Workspace afetados pela indisponibilidade
  • Ex.: IAM, Cloud Build, Cloud Storage, BigQuery, AppSheet, Gmail, Google Drive e dezenas de outros serviços

Próximas melhorias

• Modularizar a arquitetura de serviços para separar cada função e introduzir tratamento aberto em falhas (fail open) quando ocorrerem incidentes
• Propagação gradual da replicação global de dados e reforço dos processos de validação real
• Reformulação da política para que toda mudança importante em binários use feature flags e fique desativada por padrão
• Revisão do desenho para permitir detecção de erros e fail open em incidentes por meio de análise estática e testes aprimorados
• Implementação de política de backoff exponencial aleatório e reforço da confiabilidade de monitoramento/comunicação
• Melhorias em redundância de infraestrutura e comunicação automatizada para garantir monitoramento e entrega rápida de informações aos clientes mesmo durante incidentes

Avisos do incidente e comunicação

• O aviso foi publicado no Cloud Service Health dentro de 1 hora após o incidente, mas a própria infraestrutura de monitoramento também foi afetada
• Alguns clientes tiveram dificuldade para identificar sinais e impactos da indisponibilidade porque seus próprios sistemas de monitoramento baseados no Google Cloud não funcionavam normalmente
• O Google prometeu reforçar no futuro a infraestrutura de monitoramento e comunicação com clientes

Linha do tempo principal do incidente (resumo do mini-relatório)

• Início do incidente: 12 de junho de 2025 às 10:49 (PDT)
• Recuperação da maioria das regiões: 12 de junho de 2025 às 12:48 (PDT)
• Fim do incidente: 12 de junho de 2025 às 13:49 (PDT)
• Duração total: cerca de 3 horas
• Regiões afetadas: mundo todo

Resumo das medidas posteriores

• Estão previstas salvaguardas para evitar falhas em caso de erro ou corrupção de dados na plataforma de gerenciamento de APIs
• Reforço de validação, testes e monitoramento antes da propagação de metadados globais
• Ampliação do tratamento de erros do sistema e dos testes integrados para dados inválidos

Lista de serviços afetados (trecho)

Principais serviços do Google Cloud

• Identity and Access Management, Cloud Build, Google Cloud Storage, Cloud Monitoring, BigQuery, Vertex Gemini API, Cloud Firestore, Looker, Cloud Run, Compute Engine etc.

Principais serviços do Google Workspace

• AppSheet, Gmail, Google Drive, Google Meet, Docs, Chat, Calendar etc.

Conclusão

• Este incidente foi resultado da combinação de problemas na estrutura do sistema de gerenciamento de políticas/cotas, falta de validação de integridade dos dados e ausência de um sistema adequado de tratamento de erros
• O Google prometeu melhorias em nível de arquitetura e reforço da capacidade de resposta a incidentes

[kunggom]

Este é o link para a versão do texto que não é GN+.

• https://pt.news.hada.io/topic?id=21447

[GN⁺]

Comentários no Hacker News

• Falando como alguém de dentro, estou usando uma conta temporária; a causa raiz deste incidente foi a liderança ignorar princípios para ganhar velocidade, e essa prática continuou por anos até finalmente chegar ao limite. O “query of death” que aconteceu desta vez é um tipo clássico de falha inevitável em servidores C++ antigos, em que o servidor cai por causa de uma consulta específica. O Service Control foi escrito em C++ e tentou minimizar esse tipo de falha usando várias diretrizes de engenharia. Ele operou por 10 anos sem grandes incidentes, mas a política global de cotas criada às pressas recentemente sob pressão da liderança foi o problema. Esse tipo de funcionalidade nova deveria ter sido desenvolvido como um serviço separado ou, no mínimo, seguindo as diretrizes existentes. O padrão que a equipe originalmente seguia é muito mais alto do que as contramedidas mencionadas no relatório oficial. A equipe está tentando manter os padrões anteriores na medida do possível

  • Não dá para colocar toda a culpa só na liderança. Não revisar com extremo cuidado uma implantação com raio global foi uma falha da cultura de engenharia. No mínimo, a política global deveria ter sido implantada antes do Service Control regional

• Acho o relatório do incidente interessante. A equipe de SRE respondeu rapidamente em 2 minutos, e o rollout do “red button” começou. O problema foi que, quando as tarefas do Service Control reiniciaram em regiões grandes como us-central-1, surgiu um “herd effect” que sobrecarregou a infraestrutura (a tabela do Spanner). Como o Service Control não implementava backoff exponencial aleatório, a recuperação completa demorou até 2 horas e 40 minutos. Nessa situação, as cotas normais se esgotam rapidamente e isso leva a novas falhas. Acho que, nesses casos, se a infraestrutura aguentar, também seria bom suspender temporariamente as cotas ou limitar mais lentamente o trabalho de recuperação

  • Nesse caso, backoff exponencial não era a medida adequada. Ao ler dados críticos na inicialização do servidor, isso é tratado intencionalmente sem retries, então não havia como aplicar backoff. Uma abordagem melhor seria distribuir rapidamente a carga para o banco de dados de backup que já existe. Há outras opções também

• Isso realmente parece um erro amador. NPE, sem tratamento de erro, sem backoff exponencial, sem cobertura de testes, sem testes em ambiente de staging, sem rollout gradual — tudo isso são falhas graves. Está tudo nos livros de SRE: sumário do Google SRE Book, Building Secure and Reliable Systems TOC. Fico me perguntando se o padrão caiu demais ou se os livros são só marketing

  • Na minha opinião, seja com humanos ou com automação, não existe perfeição nas defesas; no fim, é uma sequência de trade-offs. Não importa quantos testes unitários e de integração, análise estática e deploys sequenciais você faça: em escala, sempre podem aparecer lacunas inesperadas. É a mesma razão do trecho dos livros sobre “o esforço muito maior para adicionar mais um 9”. No pior caso, talvez fosse preciso duplicar toda a stack e reproduzir meses de tráfego, mas ninguém consegue arcar com esse nível de custo/benefício. Já vi algo parecido trabalhando em OpenZFS: o código em si parecia correto, mas o problema apareceu num edge case de dados gravados 10 anos antes. Quando um sistema fica complexo o suficiente, testar todas as variações se torna impossível, então na prática só dá para decidir com base no custo versus utilidade. Para constar, sou de SRE no Google, mas de uma equipe sem relação com este incidente, e isso é uma opinião pessoal

  • Quase todas as falhas globais do Google se desenrolam de forma parecida: um sistema customizado implantado globalmente e rápido demais acaba recebendo uma configuração incorreta. Em rollouts normais de binário ou pushes de configuração, o normal é haver rollout gradual. No Google Cloud, vários sistemas já foram ligados globalmente no passado, mas hoje estão muito mais regionalizados e confiáveis. Antes também havia falhas globais com certa frequência, mas elas não eram divulgadas, então a maioria dos usuários achava que era problema no próprio ISP. Não acho que a situação esteja especialmente pior agora. Também tenho experiência com SRE

  • Pensando como alguém de fora, depois das grandes demissões e dos comentários do CEO sobre “preguiça”, todo mundo passou a priorizar velocidade e resultados visíveis acima da qualidade. Aos poucos, surgiu um ambiente em que apontar esse tipo de cultura passou a fazer com que a pessoa fosse rejeitada

  • Eu gostaria que houvesse mais detalhes. Pelo que entendi, não é que não tenham testado, e sim que não havia teste para um campo vazio na política, que foi a entrada problemática. Também não diz que não havia testes em staging; a observação é que, se houvesse uma flag, isso teria sido pego. Opinião pessoal

  • Isso me lembra um relatório de paiol de pólvora de 1864: “até a ferramenta mais perigosa, quando se torna familiar, faz a pessoa perder a cautela e passar a considerar as diretrizes desnecessariamente rígidas”

• Sou de outra equipe dentro da Cloud. Em geral, todo código tem testes unitários e de integração. Mudanças em binários ou configurações são feitas gradualmente por tarefa e por região ao longo de vários dias, com análise de canário. Até rollback, se for apressado demais, pode piorar a situação, então também é feito devagar. Por exemplo, pode-se considerar melhor 40 minutos de indisponibilidade do que 4 horas de incidente, em vez de sobrecarregar um banco de dados global de uma vez. Não estive diretamente envolvido neste incidente, mas pelo PM parece que o código foi testado, só que esse edge case ficou de fora. O problema foi que a política de cotas foi aplicada como atualização de banco de dados, e não como binário ou arquivo de configuração, então a mudança se espalhou para todos os bancos no mundo em segundos. O problema de ponteiro nulo provavelmente poderia ter acontecido com assert() em outras linguagens também. Faz mais sentido colocar flag guards em todas as verificações de política, fazer a checagem de política de cotas falhar em aberto e espalhar mudanças de banco gradualmente por região do que assumir o risco de reescrever esse serviço crítico em outra linguagem. Opinião pessoal

  • assert é um tipo de estrutura muito mais fácil de proibir por política

  • O contra-argumento é que, se o código foi testado mas esse edge case ficou de fora, então no fim das contas ele não foi testado

  • O fato de uma mudança no banco não ser uma mudança de binário ou configuração não muda o problema. Se a mudança em si se propaga globalmente ao mesmo tempo, qualquer que seja o tipo, isso já é semente de desastre. É o mesmo padrão do caso Crowdstrike

  • Se a opinião é que “reescrever em outra linguagem traz risco demais”, então isso levanta a dúvida: será que os requisitos do serviço não foram entendidos direito, ou o serviço não é importante o suficiente para justificar uma migração cuidadosa?

• O texto diz que o binário caiu por causa de um ponteiro nulo sem tratamento de erro adequado. A essa altura, já cabe a piada do “erro de um trilhão de dólares”

  • Fico pensando quantos SLAs este incidente deve ter consumido no ano inteiro

  • Dá vontade de dizer que talvez exista uma linguagem que impediria esse tipo de problema /s

• O Service Control (Chemist) é um serviço bem antigo e desempenha papéis centrais em várias APIs do GCP, como autenticação, autorização, observabilidade e cotas. No fluxo das requisições, a maioria das APIs do GCP passa pelo Chemist, por isso não acho que a mitigação de fail open seria eficaz. Tanto o Chemist quanto o proxy foram escritos em C++, e muito código legado se acumulou ao longo dos anos. As equipes têm análise estática, testes, deploy gradual, feature flags, red button e sistemas fortes de monitoramento e alerta. A equipe de SRE, em especial, é excelente. Como o Chemist valida várias políticas, como IAM e cotas, muitas equipes contribuem para o codebase. Para evitar passar pela aprovação do Chemist a cada mudança, foi surgindo muito desenvolvimento por caminhos curtos. Recentemente também houve muita reorganização e offshore, e o foco passou para projetos novos e vistosos liderados por níveis L8/L9, enquanto qualidade, manutenção e confiabilidade ficaram em segundo plano; foi por essa mudança cultural que saí da Cloud. Muitas vezes as boas práticas gerais de servidores e serviços do Google não são seguidas ali. Este problema parece estar mais do lado de código e code review fracos: aprovaram um código defeituoso e fizeram com que a mudança de configuração fosse refletida imediatamente no Spanner, ampliando o problema

• Um campo vazio não intencional foi incluído nos dados de política do serviço, e o Service Control lançou uma exceção ao ler esse campo vazio (null) durante a checagem de cota em cada região. É mais um exemplo do “erro de um bilhão de dólares” de Hoare se repetindo em vários sistemas do Google. O problema começa no fato de terem permitido esse tipo de “campo vazio” (null) em primeiro lugar; deveriam ter declarado NOT NULL no schema. Infelizmente, no Spanner o padrão é nullable, então isso precisa ser especificado à parte. Também houve outra chance, no nível do código da aplicação, de projetar o sistema para tornar estados inválidos impossíveis por meio do sistema de tipos ou da linguagem de schema. Outra opção seria adicionar validação forçada de schema ao desserializar objetos da aplicação a partir do datastore. Como o problema do texto apareceu num novo code path, parece plausível que ele não tenha sido barrado na camada de dados. Também é um problema o próprio programa do Service Control ter sido escrito numa linguagem que permite dereferência de ponteiro nulo. Se eu fosse o responsável, pensaria num plano de intervenção mínima para mudar as políticas no código da aplicação para uma estrutura como “tagged enum type”, em que não seja possível representar null. O proto3 não tem essa restrição, mas há este exemplo

• Fala-se muito de multirregião como mecanismo de resiliência e disponibilidade, mas é interessante ver que, na prática, até grandes provedores de nuvem continuam fortemente acoplados entre regiões em situações de falha

  • Isso é particularmente marcante no GCP, que trata regiões de forma diferente dos concorrentes. Do ponto de vista de resiliência, é melhor enxergar o GCP como uma única região composta por várias zonas

  • Ainda assim, não dá para subestimar demais o efeito do sharding por região/zona, porque ainda podem existir “falhas que não conhecemos”

  • Também houve muitos casos em que implantações multirregião evitaram incidentes, então o ideal é entender esses casos antes de tirar conclusões

• Sempre me surpreendo com o nível de detalhe dos postmortems do Google, tanto de dentro quanto de fora da empresa. Eles aprendem para não repetir os erros, reforçam protocolos e tratamento de erros, e evoluem para sistemas mais robustos. Em um lugar do tamanho do Google, sempre há algo dando errado, mas o principal é conter o impacto para que não afete clientes, usuários e outros sistemas. Mesmo estando dentro da empresa, dependendo da equipe, há muitos problemas que você nem vê. Considero isso uma das classes de sistemas mais complexas já feitas por humanos. A menos que exista AGI, não é uma área em que humanos consigam fazer muito melhor

  • Mas, neste incidente, houve uma sequência de erros de nível júnior. Não tratar dados nulos, falta de testes, ausência de cobertura de testes para uma funcionalidade nova e não validar em pequena escala em produção antes de um rollout total — tudo isso é problema. Tenho certeza de que, no Google de 10 anos atrás, todo mundo zombaria desses erros

  • Pelo que entendi, a causa desta falha foi: 1) uma funcionalidade global implantada para tudo de uma vez, 2) uma dereferência de ponteiro nulo, 3) ausência de política de retry adequada, causando problema de “thundering herd”. Tudo isso são erros familiares para quem trabalha no setor. Não foi uma lógica distribuída nova ou complexa; foi uma combinação de erros típicos de iniciante

  • Dizem “não repetimos o mesmo erro duas vezes”, mas na prática fizeram rollout da mudança sem feature flag, não implementaram backoff exponencial no cliente nem load shedding no servidor. Tudo isso já está nos livros de SRE do Google há anos

  • Esse erro foi um problema de ponteiro nulo que passou despercebido. Ver uma empresa com a escala e a qualidade do Google derrubar boa parte da stack desse jeito pode ser lido como sinal de que faltam medidas sérias para evitar recorrência

  • Esse é o mesmo erro repetido inúmeras vezes. “Implantamos novos recursos com cuidado, mas os bugs só aparecem quando chegam dados novos” resume a maioria das falhas globais. Sistemas perfeitos não existem; os únicos infalíveis nas discussões sobre incidentes em FAANG são os “especialistas de poltrona” do HN

• Na maioria das vezes, ao ver o downtime dos outros, é fácil criticar e chamar de “erro de nível júnior”, mas no próprio trabalho sempre sobra a desculpa de que foi inevitável ou imprevisível. Erros humanos são inevitáveis, e a expectativa em si é alta demais. Se uma loja física fecha de repente, no máximo se ouve um “desculpe”. Só o setor de TI entra em estresse excessivo por um incidente de algumas horas; queria que todo mundo levasse isso um pouco mais na boa