Um bug latente transformou a manutenção de rotina do data center do Gmail em uma interrupção global de 3 horas

Em 24 de fevereiro de 2009, o Gmail ficou fora do ar para usuários no mundo todo. O relatório de incidente do Google para seus clientes do Apps situou a interrupção entre aproximadamente 9h e 12h GMT — cerca de três horas —, com a recuperação escalonada, de modo que usuários individuais perderam o acesso por períodos variados. Nenhum dado foi perdido.

A mecânica foi uma interação entre duas decisões recentes. O Google havia implantado um novo software para otimizar onde os dados dos usuários ficavam armazenados. Naquela manhã, engenheiros iniciaram uma manutenção de rotina em um data center europeu — uma operação projetada para ser invisível, já que o tráfego é desviado automaticamente para outro local. Mas o desvio acionou um bug latente no novo código de localidade: o destino ficou sobrecarregado e, à medida que o tráfego era automaticamente redirecionado, as sobrecargas se propagaram em cascata de data center em data center. Os engenheiros levaram cerca de uma hora para controlar a cascata e mais tempo para reequilibrar tudo.

O Google tratou o desdobramento com uma transparência incomum para a época: Acacio Cruz, gerente de Site Reliability do Gmail, explicou a cascata no blog oficial do Gmail no mesmo dia, e o Google publicou um relatório formal de incidente para clientes do Apps. A empresa também se comprometeu a construir algo que ainda não existia para o serviço — um painel público de status —, reconhecendo que um provedor de nuvem deve aos clientes informações rápidas durante uma interrupção, e não apenas silêncio e uma correção.

Gmail inacessível por até três horas em 24 de fevereiro de 2009, com recuperação escalonada por data center; nenhum dado perdido

O caminho de failover — o desvio de tráfego para um segundo data center — não havia sido testado contra o novo software de localidade de dados, então o bug latente só se manifestou durante a manutenção.

A resposta à sobrecarga amplificou a falha: à medida que os usuários eram automaticamente redirecionados, cada destino atingia a mesma condição de sobrecarga, propagando-a adiante.

O projeto da manutenção pressupunha transferências limpas entre data centers, mas o novo código de otimização mudou as premissas sobre as quais o failover havia sido construído.

A comunicação ficou atrás do incidente: a própria análise postmortem do Google admitiu que era preciso reconhecer interrupções rapidamente, o que levou diretamente ao painel de status do Apps.

Caminhos de failover merecem tanto teste quanto os caminhos primários: um novo código que reorganiza a localização dos dados transformou uma manutenção de rotina em uma cascata. E uma interrupção na nuvem exige um relatório de incidente publicado.

O Google corrigiu o bug e enviou mudanças, publicou o relatório de incidente e lançou o Google Apps Status Dashboard semanas depois, institucionalizando a comunicação pública de interrupções. O episódio do 'gfail' tornou-se um modelo inicial para relatórios de incidentes na nuvem — um relato formal, voltado ao cliente, da causa e da remediação — numa época em que a maioria dos serviços web de consumo não oferecia explicação alguma.