Google Cloud jun/2025: ponteiro nulo replicado globalmente via Spanner

01 · CONTEXTO

Uma checagem no caminho de toda requisição

As APIs do Google e do Google Cloud são servidas por planos de gerenciamento e controle distribuídos por região. Eles garantem que cada requisição seja autorizada e passe pelas checagens de política e cota. O binário central desse sistema de verificação chama-se Service Control.

O Service Control é um serviço regional e lê informações de cota e política de um datastore regional. Os metadados desse datastore são replicados quase instantaneamente pelo mundo para gerenciar as políticas de cota do Google Cloud e dos clientes.

1. A requisição de API passa pelo plano de gerenciamento, que a submete às checagens de política e cota do Service Control.

2. O Service Control é regional e lê as informações de cota e política do datastore regional.

3. Os metadados do datastore são replicados quase instantaneamente para as outras regiões.

02 · A MUDANÇA LATENTE

Um caminho de código que ninguém exercitou

Em 29 de maio de 2025, uma nova funcionalidade foi adicionada ao Service Control para checagens adicionais de política de cota.

A mudança passou pelo lançamento região a região, mas o caminho de código que falhou nunca foi exercitado nesse lançamento, porque exigia uma mudança de política para acioná-lo.

Como precaução, a mudança veio com um botão vermelho para desligar aquele caminho de serviço de política. Mas ela não tinha tratamento de erro adequado nem proteção por feature flag, e, sem o tratamento de erro, o ponteiro nulo derrubou o binário.

Segundo o relatório, feature flags servem para habilitar a funcionalidade gradualmente, região por região e projeto por projeto, começando por projetos internos, para pegar problemas. Com proteção por flag, o problema teria sido pego em staging.

03 · 12 DE JUNHO

Dados em branco, replicados para o mundo

Em 12 de junho de 2025, por volta das 10h45 PDT, uma mudança de política foi inserida nas tabelas Spanner regionais que o Service Control usa para políticas. Pela natureza global da gestão de cota, esses metadados foram replicados globalmente em segundos. Os dados da política continham campos em branco não intencionais.

O Service Control puxou os campos em branco e exercitou o caminho de código com o ponteiro nulo, o que levou os binários a um crash loop. Isso ocorreu globalmente, porque cada implantação regional foi afetada.

O resultado foi um aumento de erros 503 em requisições externas de API de produtos do Google Cloud, do Google Workspace e do Google Security Operations.

1. Uma mudança de política é inserida nas tabelas Spanner regionais. Os dados da política trazem campos em branco não intencionais.

2. Como a gestão de cota é global, os metadados são replicados para as demais regiões em segundos.

3. Em cada região, o Service Control puxa os campos em branco e aciona o caminho de código com o ponteiro nulo; os binários entram em crash loop.

4. As requisições externas de API passam a receber mais erros de servidor.

04 · RESPOSTA E RECUPERAÇÃO

O botão vermelho e o efeito manada

Em algumas das regiões maiores, como us-central-1, o reinício das tarefas do Service Control criou um efeito manada sobre a infraestrutura de que elas dependem, a tabela Spanner, e a sobrecarregou. O Service Control não tinha backoff exponencial randomizado para evitar isso.

A resolução completa em us-central-1 levou até cerca de 2h40, com limitação da criação de tarefas e roteamento de tráfego para bancos multirregionais para reduzir a carga.

1. O botão vermelho desliga o caminho de serviço de política, e a recuperação começa pelas regiões menores.

2. Em algumas das regiões maiores, o reinício das tarefas cria um efeito manada sobre a tabela Spanner de que elas dependem, sobrecarregando-a.

3. O Service Control não tinha backoff exponencial randomizado para evitar o efeito manada.

4. O Google limitou a criação de tarefas e roteou tráfego para bancos multirregionais para reduzir a carga.

Logo após a recuperação, todas as mudanças na pilha do Service Control e os envios manuais de política foram congelados até a remediação completa do sistema.

05 · COMUNICAÇÃO E LIÇÕES

Quando o monitoramento cai junto

O primeiro relatório no Cloud Service Health saiu cerca de 1 hora após o início dos crashes, porque a própria infraestrutura do Cloud Service Health estava fora do ar por causa da falha. Para alguns clientes, o monitoramento que rodavam no Google Cloud também falhou, deixando-os sem sinal do incidente.