A pane do Google Cloud prova que resiliência é uma decisão de negócio

Uma pane na nuvem já não é apenas uma manhã ruim para um engenheiro. Quando uma falha em um provedor interrompe serviços bancários, videoconferências de tribunais e serviços públicos, ela testa o quanto da infraestrutura digital de uma sociedade foi silenciosamente concentrado em um único lugar.

Em 20 de outubro, o Google Cloud sofreu uma interrupção na região europe-west2, com impacto especialmente perceptível na zona europe-west2-b. A Reuters informou que usuários relataram problemas envolvendo Lloyds, HSBC e Rightmove, enquanto outros relatos citaram Revolut, ING Germany e Halifax entre os serviços que enfrentaram dificuldades. A página de incidentes do Google informou que os serviços estavam indisponíveis na zona afetada e que alguns serviços em toda a região poderiam apresentar um volume maior de erros. A pane perdeu força desde então, mas a questão importante não é saber se o Google conseguiu restaurar o serviço. É entender por que tantas empresas ficaram expostas à mesma falha.

“A nuvem” não é uma estratégia quando todo mundo usa o mesmo provedor

A computação em nuvem costuma ser vendida como uma saída para a fragilidade da infraestrutura interna. Essa promessa é real: um grande provedor pode oferecer distribuição geográfica, recuperação automatizada e experiência operacional que muitas empresas não conseguiriam reproduzir de forma economicamente viável. As próprias orientações do Google para recuperação de desastres são explicitamente baseadas no projeto de cargas de trabalho capazes de resistir a panes na infraestrutura da nuvem.

Mas resiliência não é a mesma coisa que disponibilidade. Um cliente pode operar em uma região moderna da nuvem e ainda depender de um único provedor, uma única região, uma única zona ou um pequeno conjunto de serviços compartilhados. O resultado é um sistema que parece distribuído no diagrama de arquitetura, mas continua concentrado na prática.

Essa é a principal lição deste incidente. A falha não precisou derrubar todos os serviços do Google Cloud no mundo para causar uma interrupção ampla. Bastou alcançar clientes suficientes cujos aplicativos, fluxos de pagamento ou sistemas voltados ao público estavam vinculados à mesma infraestrutura regional. Uma plataforma de nuvem pode ser gigantesca e ainda assim criar um ponto estreito de falha para as empresas construídas sobre ela.

É por isso que a expressão “migrar para a nuvem” se tornou imprecisa demais para ser útil. A pergunta relevante não é se uma empresa usa infraestrutura de nuvem. É quantos caminhos independentes continuam disponíveis quando essa infraestrutura fica indisponível.

A redundância é cara — e fingir o contrário é pior

A parte desconfortável é que a solução não consiste simplesmente em marcar mais uma caixa em uma ferramenta de implantação. Uma resiliência genuína pode exigir um segundo provedor de nuvem, dados duplicados, sistemas de identidade independentes, rotas alternativas de pagamento, procedimentos de failover testados e equipes capazes de operar em condições degradadas. Essas medidas custam dinheiro e acrescentam complexidade.

Elas também podem tornar os sistemas mais difíceis de gerenciar. Uma arquitetura multinuvem pode reduzir a dependência de um fornecedor, mas introduzir serviços incompatíveis, monitoramento mais complicado e trabalho adicional de segurança. Replicar um banco de dados entre provedores não é automaticamente mais seguro se o processo de replicação, as credenciais ou o plano de recuperação ainda compartilharem uma dependência comum.

Portanto, a resposta correta não é exigir, por reflexo, que toda empresa abandone o Google Cloud. Isso seria tão simplista quanto presumir que um único provedor é sempre suficiente. A pergunta sensata é sobre proporcionalidade: o que acontece se este serviço ficar indisponível por horas, e qual é o custo financeiro ou público dessa interrupção?

Para uma ferramenta interna de baixo risco, aceitar a concentração pode ser perfeitamente racional. Para o acesso bancário ou um serviço público, a resposta deveria ser diferente. O cliente — e não apenas o provedor de nuvem — precisa decidir se a economia e a conveniência justificam a exposição.

Uma falha regional pode se transformar em um problema de infraestrutura pública

A interrupção nos bancos torna a questão especialmente visível porque os clientes não vivenciam a arquitetura da nuvem como uma escolha técnica abstrata. Eles a vivenciam como um cartão que não funciona, uma conta que não conseguem acessar ou um serviço que para de responder. A BBC informou que a pane afetou tribunais, bancos e outras empresas que operam online — uma combinação que transforma um incidente de fornecedor em uma questão de resiliência institucional.

Isso não significa que o Google seja o único responsável por todas as falhas decorrentes. As empresas escolhem como arquitetar seus sistemas, e a documentação disponível não comprova que todos os bancos europeus dependiam do mesmo projeto. A conclusão mais defensável é mais restrita — e mais séria: uma interrupção regional do Google Cloud foi capaz de afetar vários serviços essenciais porque muitas organizações aceitaram uma dependência comum.

Há também um alerta contra tratar o tempo de atividade do passado como substituto para um plano de recuperação. O Google Cloud já enfrentou outros incidentes, incluindo uma interrupção no Cloud Storage em us-central1, em 8 de outubro de 2026, quando uploads e gravações apresentaram latência e erros elevados por 12 horas e 30 minutos. O relato da IncidentHub afirma que a explicação preliminar do Google envolvia o esgotamento de recursos após uma otimização na distribuição do tráfego, além de um problema separado no banco de dados. Regiões e causas diferentes não provam que todas as cargas de trabalho estejam sujeitas ao risco da mesma forma, mas enfraquecem a ideia reconfortante de que uma grande plataforma pode ser tratada como um serviço público invisível.

Os clientes deveriam pagar pela independência quando a falha importa

A grande conveniência do setor de nuvem também é sua fraqueza política e econômica: ela permite que milhares de organizações terceirizem decisões difíceis de infraestrutura para poucos provedores. Isso é eficiente até que a decisão terceirizada se transforme em um modo compartilhado de falha.

Nossa opinião é que reguladores e conselhos de administração deveriam parar de perguntar apenas se um provedor apresenta números impressionantes de disponibilidade. Eles deveriam perguntar se um serviço crítico consegue operar quando sua região principal, seu provedor ou seu plano de controle compartilhado fica indisponível. A resposta deveria ser documentada, testada e financiada — não deixada em um slide de apresentação sobre recuperação de desastres.

O Google Cloud continua sendo uma plataforma poderosa, e essa pane não o torna excepcionalmente irresponsável. Ela mostra, sim, que a resiliência tem um preço — e que esse preço não desaparece só porque chamamos a infraestrutura de “nuvem”. Para cargas de trabalho não críticas, a concentração ainda pode ser um acordo inteligente. Para bancos e serviços públicos, porém, independência não é duplicação desperdiçada. Ela faz parte do próprio serviço.