Se você trabalha com operações de TI ou proteção de dados, a semana passada pareceu um teste de estresse em condições reais — mesmo que seus próprios servidores tenham continuado funcionando normalmente.
Em um intervalo de 48 horas, duas interrupções em grande escala e não relacionadas paralisaram o comércio e o setor de viagens modernos. Primeiro, uma falha global no Microsoft 365 impediu que milhões de profissionais do conhecimento acessassem o Outlook, o Teams e o Copilot. Quase imediatamente depois, uma falha nas comunicações paralisou os voos em todo o território dos Estados Unidos, quando a Administração Federal de Aviação (FAA) emitiu uma ordem de suspensão de voos em todo o país.
No papel, esses dois ambientes não poderiam ser mais diferentes. Um é uma plataforma SaaS nativa da nuvem, em escala global, construída com base em microsserviços modernos; o outro depende fortemente de hardware legado e ultrapassado e de uma infraestrutura de telecomunicações com décadas de idade. No entanto, ao analisar ambos os eventos pela perspectiva de um administrador sênior de backup, as lições fundamentais são surpreendentemente idênticas.
Nenhuma das interrupções foi causada por um sofisticado grupo de ransomware patrocinado por um Estado-nação. Uma decorreu da complexidade da infraestrutura moderna em nuvem e de sua configuração; a outra se resumiu à sobrecarga de tráfego e a inconsistências nos dados dos roteadores em linhas legadas. Juntas, elas expõem os pontos cegos mais perigosos na resiliência empresarial atual.
A lição do M365: a disponibilidade do SaaS não é sinônimo de recuperabilidade de dados
Durante anos, os administradores de backup travaram uma batalha difícil contra um mito persistente entre a alta administração: “Mudamos para o Microsoft 365, então agora a Microsoft cuida dos nossos backups.”
A Microsoft opera uma das arquiteturas de nuvem mais resilientes do planeta, com georedundância nativa em todas as regiões globais. No entanto, a disponibilidade da plataforma não é o mesmo que continuidade operacional ou capacidade de recuperação independente.
Quando um grande cliente de SaaS fica fora do ar, as organizações sem backups independentes de SaaS de terceiros percebem que não têm nenhum acesso alternativo à sua própria infraestrutura operacional essencial. Se o Exchange ou o SharePoint ficarem inacessíveis por horas, suas equipes jurídica, financeira ou de resposta a incidentes ainda poderão pesquisar, exportar e acessar e-mails e contratos históricos críticos? Se seus dados estiverem exclusivamente dentro do ecossistema do fornecedor, a resposta é não.
Essa é exatamente a lacuna que o SaaSRecover da Commvault preenche para o M365 — proteção independente e de terceiros para o Exchange Online, OneDrive, SharePoint e Teams, com opções flexíveis de restauração, incluindo restauração a um ponto no tempo, no local, fora do local e exportação para PST/CAB. Os backups são executados a cada 8 horas com agendamento incremental contínuo, e o bloqueio de conformidade garante a imutabilidade, de modo que os dados não possam ser excluídos nem sua retenção reduzida.
Pior ainda, esta semana trouxe à tona uma armadilha operacional clássica: armazenar seus planos de Resposta a Incidentes (IR) na própria plataforma que acabou de ficar fora do ar. Se seus manuais de Recovery, números de contato dos fornecedores e esquemas de comunicação de emergência estiverem no SharePoint ou no Teams, você não conseguirá acessar o manual que orienta o que fazer quando o M365 estiver offline.
A lição da FAA: dívida técnica e a armadilha do gerenciamento de mudanças
Enquanto a interrupção do M365 revelou os limites da abstração da nuvem em hiperescala, a suspensão dos voos pela FAA demonstrou o extremo oposto: o risco crescente da modernização adiada.
Todo administrador sênior de infraestrutura reconhece o ciclo orçamentário de “manter as luzes acesas”. Quando o capital escasseia, as organizações aplicam patches em sistemas obsoletos em vez de reestruturá-los. No mundo do backup, isso significa manter matrizes de discos sem suporte, servidores de mídia sem patches ou rotas de rede frágeis por “apenas mais um ano fiscal”. Eventualmente, a dívida técnica chega ao fim — geralmente no pior momento possível.
Além disso, ambos os eventos destacam uma verdade incômoda que todo administrador experiente conhece: o gerenciamento rotineiro de mudanças representa uma ameaça estatística maior à disponibilidade do que os ataques cibernéticos. Seja uma atualização sutil do roteador, uma configuração incorreta de DNS ou um pico de tráfego não isolado que se propaga por caminhos redundantes, as mudanças internas contornam rotineiramente as proteções de alta disponibilidade projetadas para evitá-las. Se um único gargalo de rede ou erro de configuração pode derrubar tanto seu caminho primário quanto o secundário, você não tem isolamento verdadeiro — você tem apenas duas maneiras de falhar ao mesmo tempo.
É por isso que o Commvault AirGap é importante. Ele garante um isolamento verdadeiro: comunicação de saída unidirecional apenas a partir do cluster AirGap, replicação baseada em pull, exposição mínima de portas e isolamento imediato após a conclusão da replicação. A lógica de controle reside dentro do cluster AirGap, não no CommServe — portanto, uma falha no lado de produção não pode se propagar para sua camada de Recovery.
Nenhuma das falhas desta semana envolveu IA, e vale a pena deixar isso bem claro. Mas veja o que realmente as causou: uma alteração que alguém fez propositalmente, dentro de um sistema complexo demais para que uma única pessoa consiga compreender sozinha. Agora pense em quem estará fazendo alterações em seu ambiente no ano que vem. Os agentes já estão modificando configurações, concedendo acesso e movimentando dados, e fazem isso mais rápido do que qualquer comitê de consultoria de mudanças consegue analisar. O tipo de falha desta semana é aquele que veremos novamente, só que a alteração será aplicada em segundos e ninguém terá aberto um ticket para ela. É por isso que a detecção e a reversão precisam ser contínuas, em vez de programadas.
Como está a Recovery contínua nesta manhã de segunda-feira.
Você não precisa fazer uma grande reformulação no orçamento para colocar em prática as lições aprendidas com as duas interrupções desta semana. Use esses eventos como um catalisador para avaliar quatro áreas críticas da sua postura de resiliência. Não se trata de precauções; é assim que a Recovery contínua aparece no console:
- Mude seus manuais de procedimentos para fora da rede— Retire seus planos de recuperação de desastres, diagramas de rede, contatos de suporte de fornecedores e credenciais de emergência do M365 e do SharePoint. Mantenha uma cópia imutável e offline — ou armazene-os em um repositório totalmente independente que não dependa do seu locatário principal na nuvem. O bloqueio de conformidade e o Commvault AirGap fornecem essa camada de armazenamento imutável e isolada.
- Desacoplar a autenticação de backup do SSO de produção— Ter um backup independente de terceiros para o M365 é ótimo, a menos que o portal de backup dependa exclusivamente do Single Sign-On do Entra ID (Azure AD) para permitir que você faça login. Certifique-se de que seus administradores de backup tenham credenciais locais de emergência dedicadas e protegidas por MFA, para que você ainda possa acessar e exportar dados durante uma interrupção do provedor de identidade.
- Verifique o isolamento do raio de impacto— Analise cuidadosamente os planos de rede e de gerenciamento que conectam seu ambiente de produção ao seu armazenamento de backup. Verifique se um erro de roteamento em cascata, uma falha de DNS ou uma tempestade de broadcast no ambiente de produção não pode saturar ou interromper o acesso à sua camada de recuperação. É aqui que o Commvault Cleanroom agrega valor — ele oferece um ambiente de recuperação isolado, seja na nuvem (AWS/Azure) ou no local, com um cofre Commvault Grid (anteriormente HyperScale X) fisicamente isolado, onde você pode recuperar e validar dados sem correr o risco de reinfecção do ambiente de produção.
- Elimine sua “dívida de backup da era da FAA”— Identifique o hardware ou software legado mais antigo e vulnerável em sua pilha de proteção de dados. Use as notícias desta semana para elaborar um argumento de negócios claro para a liderança: saldar a dívida técnica agora é muito mais barato do que ter que explicar uma interrupção prolongada mais tarde. A consolidação em uma plataforma unificada e integrada reduz a dívida técnica e diminui o risco de erro humano.
Considerações finais
Até mesmo gigantes da tecnologia e órgãos federais com engenheiros de nível mundial se deparam com casos extremos de arquitetura. A questão não é atribuir culpa. É que os momentos mais difíceis vêm depois do alarme, quando você está tentando descobrir o que mudou e em que ainda pode confiar. Resiliência é ser capaz de responder a essa pergunta rapidamente, sempre, porque você já estava atento.
