Queda de nuvem: como manter a empresa funcionando

Resposta direta: uma queda de nuvem, como a que derrubou Outlook, Teams e Copilot em 12 de novembro de 2026, não é problema do fornecedor apenas. A empresa que depende de um único serviço, sem plano de continuidade, sem metas de recuperação (RTO e RPO) e sem teste periódico, para de trabalhar junto. O caminho é mapear processos críticos, definir quanto tempo e quantos dados a empresa tolera perder, criar alternativas de comunicação e testar tudo antes da próxima falha.

O que aconteceu em 12 e 13 de novembro

Na quinta-feira, 12 de novembro de 2026, por volta do início da tarde no horário dos Estados Unidos, milhares de usuários passaram a relatar falhas no Microsoft 365. Segundo a CNBC, que se baseou em dados do Downdetector, a instabilidade atingiu o Outlook e o Teams, em várias regiões.

A área de tecnologia da Universidade de Illinois publicou um aviso oficial listando os serviços confirmados como afetados: Exchange Online (Outlook), Teams, SharePoint Online e Copilot 365. O texto deixa claro que o incidente não ficou restrito a uma instituição: atingiu milhares de empresas e organizações no mundo.

Pelo que foi noticiado até a publicação deste artigo, a Microsoft informou que não havia indício de ação maliciosa e prometeu um relatório após o incidente com a causa raiz. Duração total e número de usuários afetados ainda não tinham sido divulgados. Por isso, este texto não trata de culpados. Trata do que a sua empresa controla: o quanto o seu negócio sofre quando um serviço essencial sai do ar.

Por que isso importa para quem não é de TI

E-mail, reunião, arquivos e assistente de IA ficaram concentrados em uma única plataforma na maioria das empresas médias e grandes. Isso traz ganho de custo e de padronização. Traz também um ponto único de falha: quando a plataforma para, param juntos o comercial, o financeiro, o atendimento e a diretoria.

O erro comum é tratar o fornecedor de nuvem como se fosse infalível. Nenhum é. A pergunta correta para a diretoria não é "isso vai acontecer de novo?", e sim "quando acontecer, quanto tempo conseguimos operar e como avisamos clientes e equipe?".

O que é continuidade de negócios e como ela se diferencia de backup

Continuidade de negócios é o conjunto de decisões, processos e tecnologias que mantém a operação funcionando, ainda que de forma reduzida, durante uma falha. Backup é apenas uma peça: guarda cópias dos dados. Já a continuidade responde a perguntas mais amplas: quem decide, por qual canal a equipe se comunica, qual processo volta primeiro e em quanto tempo.

Para aprofundar a parte de cópias de segurança, leia nosso artigo sobre backup corporativo contra ransomware. Aqui o foco é outro: a disponibilidade do serviço em si.

Conceito	Pergunta que responde	Exemplo prático
Backup	Consigo recuperar meus dados?	Cópia diária dos arquivos e do banco de dados
Disaster recovery (recuperação de desastres)	Consigo reativar sistemas em outro ambiente?	Réplica de servidores em outra região
Continuidade de negócios	Consigo seguir atendendo clientes durante a falha?	Canal alternativo de comunicação e processos manuais de emergência
Gestão de incidentes	Quem faz o quê nos primeiros minutos?	Lista de contatos, responsáveis e mensagem pronta ao cliente

RTO e RPO: as duas metas que toda diretoria precisa conhecer

A documentação de confiabilidade da Microsoft, no Azure Well-Architected Framework, define as duas metas de forma objetiva. O RTO (recovery time objective) é o tempo máximo aceitável de indisponibilidade após um incidente. O RPO (recovery point objective) é a duração máxima aceitável de perda de dados.

• RTO: se o e-mail ficar fora, quantas horas a empresa tolera antes de o prejuízo ser relevante?
• RPO: se o sistema voltar com dados de algumas horas atrás, o que se perde e quanto custa refazer?

A mesma documentação recomenda derivar essas metas de conversas com as áreas de negócio e refiná-las com monitoramento e testes. Ou seja, quem define RTO e RPO é o negócio, e a TI projeta a solução para cumpri-los. Metas sem dono e sem teste viram texto de apresentação.

Passo a passo para montar o plano de continuidade

Passo 1: Liste os processos que não podem parar

Pergunte a cada área quais atividades geram receita, obrigação legal ou risco imediato se pararem por duas horas. Costumam aparecer faturamento, atendimento, expedição, folha e comunicação com clientes. Não comece pela tecnologia, comece pelo processo.

Passo 2: Mapeie de quais serviços cada processo depende

Para cada processo crítico, anote os sistemas, as integrações e os fornecedores envolvidos. É comum descobrir que o ERP, o CRM e o portal de clientes dependem do mesmo serviço de identidade ou de e-mail. Esse mapa mostra os pontos únicos de falha.

Passo 3: Defina RTO e RPO por processo

Atribua metas diferentes a cada processo. Atendimento ao cliente pode exigir retorno em minutos, enquanto um relatório mensal tolera um dia. Metas iguais para tudo encarecem a solução sem necessidade.

Passo 4: Crie canais alternativos de comunicação

Se o e-mail e o chat corporativo caírem, como a equipe se fala? Defina um canal independente da plataforma principal, como um aplicativo de mensagens de outro fornecedor ou uma lista telefônica atualizada, e combine com antecedência quando ele entra em uso.

Passo 5: Documente o modo de operação degradada

Escreva o que cada área faz sem o sistema: formulários de contingência, planilhas locais protegidas, procedimentos de atendimento por telefone. O objetivo é manter o essencial, não a operação completa.

Passo 6: Prepare a comunicação com clientes e parceiros

Tenha mensagens-modelo aprovadas, um responsável por publicá-las e um canal fora do ambiente afetado, como o site e as redes sociais. Quem informa rápido e com clareza preserva a confiança mesmo durante a falha.

Passo 7: Revise contratos e acordos de nível de serviço

Leia o SLA dos fornecedores críticos: percentual de disponibilidade, forma de compensação e prazo para relatório de causa raiz. Compare com as metas internas de RTO. Se o contrato promete menos do que o negócio exige, a diferença precisa ser coberta por arquitetura própria.

Passo 8: Teste, registre e corrija

Faça simulações ao menos uma vez por ano e após mudanças relevantes. Meça o tempo real de recuperação, registre o que falhou e atualize o plano. Um plano nunca testado é uma hipótese.

Arquitetura que reduz o impacto de uma queda

O pilar de confiabilidade do AWS Well-Architected Framework trata da capacidade de uma carga de trabalho desempenhar sua função de forma correta e consistente, inclusive recuperando-se de falhas. Os princípios se aplicam a qualquer fornecedor: testar procedimentos de recuperação, escalar horizontalmente e automatizar a resposta a falhas.

Na prática, para empresas brasileiras de médio e grande porte, isso se traduz em algumas decisões de arquitetura:

• Separar funções críticas: evitar que identidade, e-mail, ERP e atendimento dependam de uma única camada sem alternativa.
• Replicar o que não pode parar: dados e serviços essenciais com cópia em outra região ou ambiente.
• Automatizar o failover: a troca para o ambiente de reserva não deve depender de alguém lembrar de um procedimento durante a crise.
• Monitorar de fora: acompanhar a disponibilidade dos serviços por uma ferramenta independente, para saber da queda antes dos clientes.
• Integrar com cuidado: fluxos entre sistemas devem ter fila e reprocessamento, para que mensagens não se percam quando um lado cai.

Esse desenho é parte do trabalho de consultoria em cloud, que avalia dependências, custos e riscos antes de qualquer migração ou expansão. Para empresas que precisam de equipe dedicada na operação diária, o outsourcing de TI inclui monitoramento e resposta a incidentes. E, quando o objetivo é automatizar entregas e recuperação, a prática de DevOps reduz o tempo entre a falha e a correção.

Comparativo: três níveis de maturidade em continuidade

Nível	Como a empresa age na queda	Risco principal	Próximo passo
Reativo	Espera o fornecedor resolver e improvisa por telefone	Perda de vendas e de confiança sem controle	Mapear processos críticos e definir RTO
Preparado	Tem plano escrito, canal alternativo e responsáveis definidos	Plano desatualizado ou nunca testado	Simular a falha e medir o tempo real
Resiliente	Opera em modo degradado, com failover testado e comunicação automática	Custo alto se aplicado a tudo sem critério	Revisar metas por processo a cada ciclo

Dados e IA: um ponto de atenção novo

O incidente afetou também o Copilot 365, segundo o aviso da Universidade de Illinois. Isso mostra que assistentes de IA entraram na lista de dependências do dia a dia. Se sua equipe usa IA para redigir propostas, resumir reuniões ou consultar dados, a continuidade precisa incluir a pergunta: o que fazemos quando o assistente não responde?

A resposta passa por manter os dados da empresa organizados e acessíveis fora de uma única ferramenta. Uma boa base de dados, tratada em projetos de consultoria de dados, permite alternar entre ferramentas sem perder histórico nem contexto. O artigo sobre IA e o futuro dos ERPs discute esse tema do ponto de vista dos sistemas de gestão.

Curiosidades e fatos úteis

• O Downdetector, citado pela CNBC, mede relatos de usuários. Ele indica tendência, mas não substitui o comunicado oficial do fornecedor nem a medição própria.
• Em quedas de grande porte, usuários de outras plataformas também costumam relatar problemas, em parte por dependências compartilhadas e em parte por falhas de conexão local. Nem todo relato é do mesmo incidente.
• Relatórios pós-incidente são uma fonte valiosa: mostram a causa raiz e as medidas de correção. Vale pedir e arquivar o relatório de cada fornecedor crítico.
• Rumores sobre ataque hacker aparecem quase sempre nas primeiras horas. Espere o comunicado oficial antes de tomar decisões ou repassar a informação.

Checklist rápido para a próxima segunda-feira

• Reunir TI e áreas de negócio por uma hora para listar os cinco processos mais críticos.
• Verificar se existe um canal de comunicação independente do e-mail e do chat atuais.
• Conferir o SLA dos três fornecedores de nuvem mais importantes.
• Agendar uma simulação de queda de e-mail e chat por duas horas, com observadores.
• Registrar RTO e RPO por processo e definir um responsável por cada um.

Perguntas frequentes

O que é um plano de continuidade de negócios?

É o documento e o conjunto de práticas que definem como a empresa mantém as atividades essenciais durante uma falha, quem decide, qual canal de comunicação usar e em quanto tempo cada processo deve voltar.

Qual a diferença entre RTO e RPO?

RTO é o tempo máximo aceitável de indisponibilidade após um incidente. RPO é a quantidade máxima de dados, medida em tempo, que a empresa aceita perder. Os dois são definidos pelo negócio e orientam a arquitetura de TI.

Ter tudo na nuvem aumenta o risco de queda?

Não necessariamente. A nuvem costuma oferecer alta disponibilidade, mas concentrar tudo em um único fornecedor, sem alternativa, cria um ponto único de falha. O risco está na falta de planejamento, não no modelo em si.

Com que frequência devo testar o plano?

Ao menos uma vez por ano e sempre que houver mudança relevante em sistemas, fornecedores ou estrutura da empresa. Testes parciais, como simular a queda do e-mail, podem ser feitos com mais frequência e custo baixo.

Backup basta para garantir a continuidade?

Não. O backup protege os dados, mas não mantém a operação durante a falha. A continuidade também exige canais de comunicação, processos alternativos, responsáveis definidos e ambientes de recuperação.

Por onde uma empresa de médio porte deve começar?

Pelo mapeamento dos cinco processos mais críticos e das dependências de cada um. Com isso, define-se RTO e RPO e escolhem-se as medidas de maior retorno, sem investir em proteção igual para tudo.

Como a DKP pode ajudar

A DKP atua com consultoria em tecnologia para empresas de médio e grande porte, incluindo avaliação de dependências, arquitetura em nuvem e operação de TI. Se a queda desta semana levantou dúvidas na sua diretoria, conheça nossa área de consultoria de TI e converse com um especialista para avaliar o nível de preparo da sua operação.