Notícias

Google explica falha global no Google Cloud

Depois de um apagão global que deixou fora do ar serviços como Spotify, Discord, Cloudflare e até ferramentas do próprio Google, como Gmail, Drive e Docs, a big tech explicou o que aconteceu. E, como destacou a TechRadar, o motivo é, no mínimo, constrangedor para uma gigante da nuvem.

De acordo com o relatório divulgado pela empresa, o problema começou com uma atualização no Service Control, sistema responsável por gerenciar políticas e cotas de uso das APIs do Google Cloud. A mudança introduziu um erro de código que não tinha os devidos controles para tratar falhas e teria sido implementada sem qualquer proteção de feature flag – mecanismo que permite ativar ou desativar funcionalidades rapidamente em caso de erro.

Leia mais: Impacto ambiental desafia data centers na ‘era da IA’

O resultado foi um efeito dominó que espalhou erros 503 (serviço indisponível) globalmente, não só dentro do próprio Google Cloud, mas também em qualquer serviço que dependa das APIs da empresa, como foi o caso do Spotify, que hoje soma mais de 678 milhões de usuários no mundo, além de partes da infraestrutura da Cloudflare e do Discord.

Resposta rápida, mas impacto pesado

O Google afirma que seu time de engenharia de confiabilidade (SRE) começou a atuar no problema apenas dois minutos após o início da pane, e identificou a causa raiz em 10 minutos. Segundo o relatório, o famoso “botão vermelho”, que desativa rapidamente uma rota de serviço, estava pronto para ser acionado 25 minutos após o início da falha e foi totalmente implementado em 40 minutos.

Ainda assim, o impacto foi significativo. Enquanto regiões menores se recuperaram relativamente rápido, data centers maiores, como o us-central-1 (um dos principais dos Estados Unidos), ficaram fora do ar por cerca de duas horas e 40 minutos, como reportou a TechRadar.

E agora?

No primeiro comunicado, emitido ainda no dia da falha, o Google se limitou a dizer que precisava “fazer melhor”. No relatório mais detalhado, a empresa prometeu uma série de medidas para evitar que algo semelhante volte a acontecer.

Entre elas melhorias nos testes e na análise de código antes da implantação; revisão na arquitetura do Service Control, tornando-o mais modular e menos propenso a gerar efeitos cascata; e reforço na comunicação externa, para garantir que clientes sejam informados com mais rapidez e clareza, inclusive mantendo os canais de comunicação on-line, mesmo durante apagões.

Siga o IT Forum no LinkedIn e fique por dentro de todas as notícias!

Recent Posts

SpaceX, Anthropic e OpenAI enfrentam riscos em possíveis IPOs

SpaceX, Anthropic e OpenAI estão no radar de Wall Street para possíveis aberturas de capital…

7 horas ago

Sistemas legados: como tomar decisões para garantir resiliência em setores críticos

por Eduardo Honorato Falar sobre infraestruturas críticas na Era Digital tem sua própria complexidade dentro…

10 horas ago

Sem equipes preparadas, IA não entrega transformação

A adoção de inteligência artificial (IA) nas empresas não depende apenas da disponibilidade de ferramentas.…

12 horas ago

Cohesity obtém patente para aplicar IA diretamente em dados de backup corporativos

A Cohesity anunciou a concessão da Patente Nº 12.619.501 pelo Escritório de Patentes e Marcas…

1 dia ago

Para Diogo Cortiz, maior desafio da IA é a falta de capacidade crítica para questionar suas respostas

Diogo Cortiz, professor da PUC-SP e doutor em Tecnologias da Inteligência e Design Digital, tem…

1 dia ago

Agentes de IA vão dar “superpoderes” a profissionais de TI, diz DJ Sampath, da Cisco

DJ Sampath chegou aos Estados Unidos há 30 anos com oito dólares no bolso e…

1 dia ago