Redundância não basta: o que incidentes recentes de nuvem ensinam sobre confiabilidade

Redundância só aumenta a confiabilidade quando as alternativas não compartilham o mesmo ponto de falha, conseguem absorver a carga e são exercitadas em condições próximas da realidade. Duplicar servidores, links ou regiões pode criar segurança aparente. O teste decisivo é outro: quando uma dependência falha, o sistema inteiro — tecnologia, procedimentos, pessoas e comunicação — consegue continuar ou se recuperar dentro do tempo necessário?

Dois incidentes recentes ajudam a observar essa diferença. Em 15 de julho de 2026, uma oscilação elétrica afetou uma instalação da Google Cloud em us-west2. O relatório publicado em 25 de julho descreve uma sequência que foi além da perda inicial de energia: equipamentos de distribuição foram desligados, bombas não reiniciaram automaticamente, a refrigeração perdeu circulação de água e partes da restauração exigiram intervenção manual. Serviços permaneceram afetados por quase quinze horas.

Em 23 de julho, clientes da Microsoft Azure enfrentaram falhas de conectividade e aumento de latência na região West US. O relatório preliminar registra impacto entre 14h44 e 19h41 UTC sobre o tráfego que entrava ou saía da região, atingindo uma lista extensa de serviços. O tráfego que permanecia inteiramente dentro da região não foi afetado. Esse detalhe é importante: a aplicação podia estar saudável, mas indisponível para quem dependia do caminho externo.

Os episódios têm causas e arquiteturas diferentes. Não devem ser reduzidos a uma explicação única. Ainda assim, ambos mostram que confiabilidade não reside apenas na quantidade de componentes duplicados. Ela depende das relações entre energia, rede, refrigeração, capacidade, automação, controle, operação humana e caminhos usados pelos clientes.

Redundância pode compartilhar a mesma fragilidade

É comum desenhar dois componentes e chamá-los de redundantes. A afirmação só é verdadeira se eles forem suficientemente independentes diante dos eventos que a empresa pretende suportar. Dois links que atravessam o mesmo equipamento, duas aplicações que usam o mesmo provedor de identidade ou duas zonas que dependem do mesmo serviço de controle continuam expostas a uma causa comum.

No incidente da Google Cloud, existiam alimentações e mecanismos de proteção. A perturbação elétrica, porém, acionou uma sequência de efeitos que alcançou distribuição, refrigeração e restauração. O relatório oficial mostra que alguns elementos responderam como previsto, enquanto outros precisaram de atuação manual ou apresentaram comportamento diferente do esperado. É justamente isso que uma análise de modos de falha procura revelar: não apenas qual componente pode parar, mas quais dependências e consequências aparecem depois.

Para uma empresa SaaS, a dependência comum nem sempre está na infraestrutura física. Pode ser uma credencial administrativa, um DNS, uma fila, uma integração de pagamento, o ERP do cliente, um processo de aprovação ou uma única pessoa capaz de executar a recuperação. A análise de riscos de integração precisa considerar esses caminhos compartilhados antes do go-live, quando ainda existe espaço para alterar o desenho.

Failover não resolve falta de capacidade

Ter um destino alternativo não significa que ele conseguirá receber toda a demanda. A recuperação pode falhar porque o ambiente secundário está subdimensionado, porque limites de conexão foram atingidos, porque dados ainda não estão consistentes ou porque o aumento abrupto de tráfego cria um novo gargalo.

Essa distinção muda a pergunta feita em projetos. Em vez de “há backup?”, vale perguntar “quanto da operação o backup sustenta, por quanto tempo e em quais condições?”. Em vez de “podemos trocar de região?”, é melhor perguntar “o que permanece dependente da região original durante a troca?”. A resposta pode revelar que o plano atende uma indisponibilidade parcial, mas não o cenário usado na promessa comercial.

O mesmo vale fora da nuvem. Uma operação pode ter dois fornecedores, mas ambos dependerem do mesmo distribuidor. Um time pode nomear um substituto, mas ele não ter acesso, contexto ou autoridade. Um projeto pode manter uma planilha de contingência que não suporta o volume real. Confiabilidade exige capacidade utilizável, não apenas alternativa registrada.

O caminho do cliente importa tanto quanto o sistema

O relatório da Azure separa o tráfego interno da região do tráfego que entrava ou saía. Isso lembra que uma aplicação pode continuar executando internamente enquanto o usuário não consegue alcançá-la. Monitorar apenas o servidor ou o processo principal produz uma visão incompleta da experiência.

Uma implantação deve observar a jornada ponta a ponta: autenticação, rede, integrações, processamento, confirmação, notificações e suporte. Quando existe um problema, o cliente precisa saber o que ainda funciona, quais alternativas estão disponíveis e quando haverá nova atualização. A confiabilidade percebida inclui a capacidade de explicar a situação sem prometer um prazo que a equipe ainda não consegue sustentar.

Isso também muda os indicadores. Disponibilidade média pode esconder falhas concentradas em uma funcionalidade crítica, em uma região ou em um grupo de clientes. Métricas por jornada e dependência ajudam a localizar onde o valor foi interrompido, e não apenas onde um alerta técnico disparou.

Procedimento documentado não é procedimento testado

Runbooks e planos de continuidade são necessários, mas envelhecem. A arquitetura muda, acessos expiram, equipes são reorganizadas e comandos deixam de produzir o mesmo resultado. Uma documentação que nunca foi exercitada descreve uma intenção, não uma capacidade comprovada.

A orientação de confiabilidade da AWS é direta: depois de projetar uma carga resiliente, o teste é a forma de verificar se ela realmente se comportará como esperado. Os chamados game days simulam falhas para testar sistemas, processos e respostas das equipes com as pessoas que participariam de um incidente real. O objetivo não é criar espetáculo nem derrubar produção. É encontrar, em ambiente controlado, as lacunas que apareceriam sob pressão.

Para operações menores, o exercício pode ser simples. Desabilite uma integração em homologação, simule a indisponibilidade do responsável principal, processe um lote acima do normal ou execute a recuperação a partir de um backup recente. Observe quanto tempo a equipe leva para detectar, decidir, comunicar e normalizar. Registre as diferenças entre o procedimento previsto e o que realmente aconteceu.

Essa prática conversa com o artigo sobre prontidão operacional e go-live em fases. Testar antes da ampliação não elimina todos os riscos; reduz a chance de descobrir, com toda a base de clientes exposta, que a contingência dependia de uma premissa falsa.

Perguntas que valem mais que “temos redundância?”

Uma revisão de confiabilidade não precisa começar com uma nova ferramenta. Pode começar com uma conversa objetiva entre Produto, Engenharia, Operações, Suporte e o dono do processo:

• Quais serviços e jornadas são realmente críticos para o cliente?
• Que componentes aparentemente independentes compartilham energia, rede, identidade, dados, controle ou pessoas?
• Quanto de carga o ambiente alternativo suporta sem intervenção improvisada?
• Quais funções continuam disponíveis em modo degradado?
• Quem possui acesso e autoridade para executar a recuperação?
• Quando foi a última vez que o procedimento completo foi testado?
• Como clientes e áreas internas serão informados durante a incerteza?
• Que aprendizado de incidentes anteriores ainda não virou mudança concluída?

As respostas devem produzir decisões proporcionais. Nem toda empresa precisa operar em várias regiões ou construir uma infraestrutura de grande provedor. Em muitos casos, backups testados, limites de capacidade conhecidos, fornecedores alternativos, monitoramento da jornada e comunicação preparada geram mais valor do que uma arquitetura sofisticada mal compreendida.

Confiabilidade é uma propriedade da operação inteira

O erro mais fácil é tratar confiabilidade como responsabilidade exclusiva da infraestrutura. O desenho técnico importa, mas a recuperação atravessa decisões de negócio. Alguém precisa escolher quando interromper uma função, aceitar modo degradado, redirecionar usuários ou comunicar um prazo. Suporte precisa reconhecer o incidente; Produto precisa saber quais jornadas priorizar; lideranças precisam evitar mudanças concorrentes durante a estabilização.

Depois do incidente, a análise também deve olhar além da causa inicial. Uma boa revisão distingue o evento que começou o problema, as condições que ampliaram o impacto e as barreiras que funcionaram ou falharam. A documentação viva ajuda quando decisões, dependências e procedimentos são atualizados como parte do trabalho, e não apenas depois de uma auditoria.

Redundância continua sendo importante. O ponto é não confundi-la com garantia. Sistemas confiáveis são construídos quando alternativas são independentes o suficiente, possuem capacidade real e são acompanhadas por pessoas que já praticaram a recuperação. Os incidentes recentes lembram que o teste mais valioso não é contar quantos recursos foram duplicados, mas observar o que acontece quando a primeira proteção deixa de funcionar.