Quando a nuvem cai: o apagão da Microsoft e o plano B que faltou

Segundo o Olhar Digital, uma falha global nos serviços da Microsoft 365 provocou transtornos em vários países: ambulâncias no Reino Unido com dificuldades, trens afetados na Europa, aeroportos em confusão e órgãos públicos do Japão voltando ao papel e à caneta. A notícia chama atenção pela dimensão, mas o que me interessa é o que ela revela sobre a forma como construímos nossas operações.

Quando um e-mail ou um editor de planilhas sai do ar, a primeira reação é achar que é só incômodo. O problema é que, hoje, essas ferramentas deixaram de ser acessórios. Elas sustentam autenticação, agenda, comunicação interna e, em muitos casos, o fluxo que mantém uma operação de pé.

Quando a nuvem vira ponto único de falha

A migração para a nuvem trouxe ganhos reais: menos servidores para manter, atualizações automáticas, acesso de qualquer lugar. Ninguém sério defende voltar ao servidor de e-mail empoeirado no armário. Mas existe um efeito colateral pouco discutido: concentramos muitos ovos na mesma cesta.

Se a identidade dos usuários, o e-mail, os arquivos e as reuniões dependem do mesmo provedor, uma única falha derruba tudo ao mesmo tempo. Não importa se a sua empresa tem a melhor equipe de TI do mercado. Se o problema está do lado do fornecedor, você só pode esperar e comunicar.

O caso do Japão é quase simbólico. Órgãos que voltam ao papel mostram que, quando o plano B não existe, ele acaba sendo improvisado. E improviso, em serviço crítico, custa caro em tempo, retrabalho e confiança.

O que isso significa para uma empresa de médio porte

Talvez você pense que isso é assunto de governo e de grandes companhias aéreas. Não é. A pequena e média empresa sente o mesmo impacto em escala menor: o vendedor sem acesso à proposta, o financeiro sem conseguir validar um pagamento, o atendimento sem histórico do cliente.

Em muitos projetos que acompanho, o risco só vira pauta depois do susto. Antes disso, a conversa costuma ser "a nuvem é da Microsoft, então está garantido". Disponibilidade alta não é o mesmo que disponibilidade total.

Perguntas que a gestão precisa fazer agora

Em vez de entrar em pânico ou culpar o fornecedor, vale usar o episódio como checklist. Algumas perguntas simples já ajudam a enxergar a fragilidade:

• Quais processos param completamente se o e-mail e o Teams ficarem fora do ar por algumas horas?
• Existe um canal alternativo de comunicação com equipe e clientes, fora da mesma plataforma?
• Os contatos críticos e procedimentos de emergência estão acessíveis offline?
• Há cópia independente dos dados mais importantes, que não dependa do mesmo provedor?
• Quem decide e como é comunicada uma contingência, quando a TI também está no escuro?

Essas respostas não exigem grande investimento para serem mapeadas. Exigem disciplina e vontade de olhar para o que normalmente se prefere ignorar.

Resiliência é processo, não produto

Há uma tentação de resolver tudo comprando mais uma ferramenta. Na prática, o que protege a operação são processos otimizados e bem documentados: quem faz o quê, com quais alternativas, em qual ordem. Uma empresa com rotinas claras atravessa uma indisponibilidade com menos prejuízo, e isso se traduz em redução de custo, porque cada hora parada deixa de virar perda silenciosa.

Na M3Solutions, a abordagem que defendo para resolução de problemas começa antes do problema: mapear dependências, classificar o que é crítico e testar o plano de contingência de verdade, não só deixá-lo guardado em um PDF que ninguém abre.

O apagão da Microsoft não é prova de que a nuvem falhou como conceito. É lembrete de que qualquer serviço, por maior que seja, pode ficar indisponível. A diferença entre o caos e o incômodo controlado está no que você preparou enquanto tudo funcionava.

E na sua empresa, se o Microsoft 365 saísse do ar amanhã de manhã, a equipe saberia exatamente o que fazer? Se a resposta for "mais ou menos", talvez seja hora de abrir essa conversa na próxima reunião de diretoria.