Um corte de energia tornou-se uma contagem regressiva de sete minutos
Por volta das 07:08 BST de uma terça-feira, uma falha na rede local atingiu a zona europe-west2-b do Google Cloud em Londres. As baterias de UPS foram ativadas imediatamente, uma resposta padrão. No entanto, nem o controlador do gerador primário nem o de backup iniciaram os geradores a diesel, deixando a instalação dependente da energia das baterias.
Essa janela de sete minutos provou ser crítica. O data center funcionou com baterias por aproximadamente sete minutos antes que a energia acabasse, mergulhando toda a zona na escuridão. Criticamente, as baterias não falharam; os sistemas de partida dos geradores falharam, criando uma cascata de interrupções inesperadas.
O Revolut, uma gigante fintech que atende milhões, sentiu o impacto imediatamente. Usuários relataram problemas generalizados:
- Falhas no login
- Transferências de dinheiro bloqueadas
- Pagamentos com cartão recusados
O Revolut inicialmente citou uma "interrupção de serviço" antes de atribuir o tempo de inatividade extensivo ao Google Cloud. O incidente rapidamente destacou a fragilidade de depender até mesmo da infraestrutura de nuvem mais sofisticada quando um único ponto de falha — como um controlador de gerador — pode desencadear uma interrupção tão significativa.
As duas zonas saudáveis não eram saudáveis o suficiente
Regiões com múltiplas zonas prometem resiliência: se uma zona falha, as cargas de trabalho são transferidas para as outras. A região europe-west2 do Google Cloud em Londres possui três dessas zonas (a, b e c). Quando a zona b ficou offline, o sistema deveria ter feito o failover perfeitamente para a e c, mantendo o serviço.
Em vez disso, o aumento repentino de tráfego sobrecarregou a infraestrutura restante. Isso não foi uma simples troca; foi um problema de capacidade e um pesadelo de coordenação. As dependências entre zonas significaram que alguns serviços nas zonas a e c permaneceram travados, aguardando componentes ou estados ainda associados à zona b offline.
A lição de engenharia é clara: a redundância só é eficaz se as zonas forem verdadeiramente independentes e possuírem margem suficiente para absorver uma tempestade de failover realista. Limites de taxa, degradação graciosa e planos de recuperação rigorosamente testados são fundamentais para evitar que um efeito de "manada" derrube uma região inteira.
O Google se recuperou antes do Revolut
A rápida recuperação da infraestrutura do Google não se traduziu na restauração imediata do serviço para seus clientes. O Google relatou que a maioria dos clientes estava online novamente cerca de seis a oito horas após o início do incidente, entre 13:00 e 15:00 BST. O Revolut, no entanto, não anunciou a restauração total do serviço até as 18:40 BST, um atraso significativo de várias horas.
Essa disparidade revela uma distinção crítica: restaurar a capacidade da nuvem não limpa instantaneamente o backlog operacional de um cliente. Mesmo com computação e armazenamento disponíveis, uma instituição financeira como o Revolut enfrenta desafios complexos. Conciliar estados de transação, limpar backlogs de pagamento e normalizar cada dependência de aplicativo — desde pagamentos com cartão até serviços de login — leva tempo e um sequenciamento cuidadoso.
A interrupção estendeu-se além do Revolut. Relatórios indicaram uma interrupção mais ampla em outras instituições e serviços do Reino Unido, incluindo:
- Lloyds
- Halifax
- Links de vídeo para audiências judiciais remotas
Este impacto mais amplo ressalta uma vulnerabilidade fundamental da infraestrutura de nuvem compartilhada. Uma falha de zona única em europe-west2-b transformou-se em um problema de serviço generalizado, demonstrando como dependências interconectadas podem transformar um evento de energia localizado em uma dor de cabeça nacional. Para mais detalhes sobre o status do incidente, consulte o Google Cloud Service Health Dashboard. Curiosamente, os reguladores tomaram nota, com o Bank of England e a FCA recebendo consultas sobre o cronograma de notificação do incidente.
Gostando do artigo? Receba um assim na sua caixa de entrada toda manhã.
um e-mail por dia · cancele em dois cliques · sem rastreadores de terceiros
Uma interrupção na nuvem é agora um risco bancário
A designação do Google Cloud como um critical third party para o sistema financeiro do Reino Unido em julho muda fundamentalmente as apostas. Após a interrupção, o presidente do Treasury Committee buscou imediatamente respostas do Bank of England e da FCA sobre os cronogramas de notificação. Isso não é apenas uma falha técnica; é um risco sistêmico.
As empresas financeiras agora enfrentam uma questão clara: quanta resiliência é suficiente? Quando um provedor de nuvem, uma região inteira ou até mesmo a própria arquitetura de um aplicativo se torna um ponto de concentração, as empresas devem examinar sua exposição. Projetos multirregionais oferecem um caminho para reduzir o risco, mas introduzem compensações significativas em custo, latência e gerenciamento complexo de dados.
Para clientes e desenvolvedores, surgem lições práticas. Durante incidentes, verifique consistentemente o service health dashboard do Google Cloud—ele oferece as informações mais atuais. As equipes de engenharia devem ir além das suposições; testar a perda de zona, validar a capacidade de failover e simular modos de operação degradados. A implantação multizona por si só não garante a continuidade.
Perguntas Frequentes
Por que o Revolut ficou fora do ar durante a interrupção do Google Cloud?
Um data center em Londres perdeu energia após a falha dos controladores dos geradores primários e de backup. O tráfego foi transferido para as zonas restantes, que também foram afetadas por sobrecarga e dependências da zona offline.
Quanto tempo durou a interrupção do Google Cloud em Londres?
O Google informou que a maioria dos clientes afetados se recuperou cerca de seis a oito horas após o início do incidente. O Revolut informou que seus serviços retornaram mais tarde, por volta das 18:40 BST.
Por que as outras zonas do Google Cloud em Londres não impediram a interrupção?
As zonas restantes enfrentaram um aumento repentino de tráfego de failover, enquanto alguns serviços ainda dependiam de componentes vinculados à zona que falhou.
O que a interrupção significa para os serviços financeiros do Reino Unido?
Isso destaca como a interrupção em um grande provedor de nuvem pode afetar os serviços financeiros e por que os reguladores estão examinando provedores terceirizados críticos.