Na noite de 31 de agosto de 2026 começou uma ampla queda no Microsoft 365, registrada no centro de administração como EX1464935 e depois ampliada sob MO1465074. O impacto não se limitou ao e-mail. O Exchange Online caiu junto com o Teams, o SharePoint Online e o OneDrive for Business, e com eles as ferramentas de governança e segurança do Purview e do Defender XDR. Uma empresa que falava com seus clientes por e-mail, se coordenava internamente por chat, guardava seus arquivos na nuvem e monitorava sua segurança por um painel perdeu as quatro coisas no mesmo instante.

A Microsoft descreveu a causa como um problema na configuração central de autenticação usada por vários serviços internos dentro da infraestrutura do Exchange Online, e aplicou uma mitigação em etapas que reaplicou os componentes de autenticação em uma amostra da infraestrutura antes de expandi-la. O fluxo de e-mails e a pesquisa foram restabelecidos em 1 de setembro, com impacto limitado em um pequeno subconjunto de usuários que persistiu até 2 de setembro. A interrupção completa passou de um dia, e a cauda chegou a dois.

Este não é um artigo sobre a Microsoft. Todo grande provedor tem quedas, e já cobrimos interrupções em outros serviços de IA. É um artigo sobre aquilo que esta queda em particular expôs, que é mais perigoso do que parece à primeira vista.

O que você conta como seis sistemas pode ser um só

Peça a qualquer gestor que liste seus sistemas e você recebe uma lista: um sistema de e-mail, um sistema de chat, um sistema de arquivos, um sistema de segurança. Quatro nomes, quatro ícones, geralmente quatro linhas no contrato. A suposição natural é que a queda de um não leva os outros junto, porque são coisas diferentes.

Mas nomes não são fronteiras de sistema. A fronteira real é o que esses serviços compartilham por baixo: quem verifica sua identidade, onde as sessões ficam guardadas, por qual rede eles trafegam. Quando quatro serviços compartilham uma única camada de autenticação, do ponto de vista do risco eles são um único serviço, por mais separados que pareçam na fatura.

O incômodo é que esse compartilhamento nunca aparece em tempos normais. Muito pelo contrário, é exatamente ele que oferece o login único conveniente e a integração suave entre e-mail e arquivos. Você compra a conveniência todos os dias e paga por ela uma vez a cada poucos anos, em um único dia longo.

Isso vale tanto para uma empresa saudita de médio porte quanto para uma corporação global. Pense em quantos dos seus serviços dependem de uma única conta do Google, ou de um único número de WhatsApp, ou de um único provedor de hospedagem, ou de um único funcionário que guarda as senhas. Cada um desses é um ponto único de falha. A diferença é que os seus são menores e muito mais fáceis de corrigir.

Mapeie suas dependências em uma hora

Você não precisa de ferramenta nem de consultor. Precisa de uma folha de papel, uma hora e respostas honestas. Na primeira coluna, escreva cada operação sem a qual sua empresa não consegue passar um dia inteiro: receber pedidos, emitir notas fiscais, atender clientes, rodar a folha de pagamento, entregar o serviço. Depois faça três perguntas sobre cada uma:

  • De qual serviço externo esta operação depende? Escreva o nome comercial sem rodeios: este provedor de e-mail, aquela plataforma de loja virtual, aquele gateway de pagamento, aquele provedor de mensagens.
  • Com qual conta ou identidade você faz login? Geralmente é aqui que aparece a surpresa. Você vai encontrar quatro serviços diferentes acessados por uma única conta, ou três serviços ligados a um único número de celular para os códigos de verificação.
  • Se isto parasse agora, qual é a alternativa em até uma hora? Se a resposta for nenhuma, você encontrou um ponto único de falha real, e não teórico.

Ao terminar, uma ou duas entradas vão se repetir na maioria das linhas. Essas são as suas dependências compartilhadas. Não tente eliminar todas, o que não é realista nem econômico. Pegue a linha que interrompe a receita e cuide dela primeiro.

O tipo de queda mais evitável: datas de vencimento

Nem todas as quedas são iguais. Algumas vêm de uma complexidade que você não controla. Outras vêm de uma data escrita em algum lugar que ninguém lê. O segundo tipo é o mais fácil de evitar e o que mais se repete, porque tudo o que ele exige é acompanhamento.

Estas são as datas de vencimento que comandam silenciosamente o seu negócio, e cada uma delas deve estar em um único calendário com um responsável nomeado:

  • O certificado de criptografia do seu site. Quando ele expira, seu site não fica lento: ele mostra aos visitantes um aviso de segurança explícito que os impede de entrar. O efeito nas vendas é imediato e total.
  • O registro do domínio. Esquecer de renovar o domínio derruba o site e o e-mail juntos, porque o e-mail roda no mesmo domínio. É uma das piores quedas, porque corta justamente o canal que você usaria para se explicar.
  • O certificado do carimbo da nota fiscal eletrônica. As diretrizes técnicas detalhadas de faturamento eletrônico da Autoridade de Zakat, Impostos e Alfândega (ZATCA) estabelecem que os contribuintes renovem o identificador do carimbo criptográfico de suas unidades geradoras de notas antes que o atual expire, e que a renovação envolve revogar o identificador antigo e emitir um novo. Perca o prazo e você terá um problema de faturamento, não apenas uma notificação.
  • As chaves de integração entre seus sistemas. O token de acesso que liga sua loja ao seu sistema de estoque, ou seu sistema a um gateway de pagamento, tem um tempo de vida definido. O vencimento dele não para nenhum dos dois sistemas, para a ponte entre eles, de modo que os pedidos continuam chegando enquanto a sincronização para silenciosamente. É o tipo de falha descoberta tarde.
  • Certificados de assinatura de aplicativos e cartões cadastrados. Um certificado de assinatura vencido impede você de publicar uma atualização na loja, e um cartão vencido em uma assinatura interrompe o próprio serviço. Os dois costumam chegar no pior momento possível.

A regra prática é simples. Tudo o que tem data de vencimento precisa de três coisas: um alerta com sessenta dias de antecedência, um responsável com nome e não um departamento, e um substituto que saiba renovar caso o responsável esteja ausente. Faltando qualquer uma das três, você volta a depender da memória de alguém.

O que fazer no dia em que seu provedor sai do ar

Quando a queda acontece, a diferença entre uma empresa que parece profissional e outra que parece atrapalhada não é a velocidade do conserto, já que o conserto nem está nas suas mãos. A diferença são três coisas que você preparou antes:

  • Um canal de comunicação fora da camada que caiu. Se toda a sua coordenação interna vive em uma única ferramenta, você fica sem coordenação quando ela cai. Um grupo de reserva em um canal realmente diferente, mais uma lista de contatos guardada fora do sistema, é suficiente.
  • Um modo manual declarado para as operações críticas. Como você recebe um pedido, registra um pagamento e entrega um serviço sem o sistema? Escreva isso hoje em uma página e entregue à equipe. Empresas que escrevem essa página perdem horas. As que não escrevem perdem um dia.
  • Uma mensagem pronta para o cliente. Os clientes se irritam menos com a queda do que com o silêncio. Um aviso curto dizendo o que foi afetado, qual é a alternativa provisória e quando vem a próxima atualização transforma uma falha em uma situação sob controle. Não prometa um prazo de solução que você não controla.

Depois que terminar, faça uma única pergunta e nada mais: o que aprendemos hoje sobre nossas dependências que não sabíamos? A resposta vale mais do que qualquer relatório, e geralmente é uma única linha que merece uma única mudança.

A visão da Origami

No nosso trabalho, o que mais surpreende os donos de empresas raramente é a queda em si. É descobrir que sistemas que eles achavam independentes caíram juntos. Uma decisão baseada na crença de que temos alternativas desmorona quando se descobre que todas as alternativas passam pela mesma porta. É por isso que começamos qualquer conversa sobre continuidade mapeando dependências, e não comprando uma ferramenta, porque a ferramenta que você comprar pode muito bem estar na mesma camada e aumentar o risco em vez de reduzi-lo.

Também acreditamos que a resposta certa a uma queda como esta não é fugir da nuvem. A infraestrutura em nuvem de um provedor sério é mais confiável do que aquilo que a maioria das empresas consegue construir e operar sozinha, e uma interrupção rara não muda isso. A resposta certa é saber com precisão quais das suas operações param e quais continuam, e ter escolhido isso de forma deliberada em vez de descobrir em um dia ruim. Continuidade não é um sistema que se compra. É um conjunto de pequenas decisões que você toma enquanto não há nenhuma pressão para tomá-las.

Conclusão

Uma única falha em uma camada de autenticação compartilhada parou seis produtos por mais de um dia em empresas do mundo inteiro. A lição não é trocar de provedor, e sim saber o que seus sistemas realmente compartilham por baixo da superfície. Comece com uma tabela de três colunas que exponha suas dependências, coloque todas as datas de vencimento em um único calendário com um responsável nomeado e escreva a página do modo manual antes de precisar dela. São cerca de três horas de trabalho entre você e um dia inteiro de paralisia, o que faz disso o investimento em continuidade mais barato que existe.

Fontes