Um apagão generalizado no último domingo (27/07) em Newark, Nova Jersey – USA, deixou servidores, roteadores e até mesmo os sistemas de refrigeração offline. E, como um dominó, levou junto diversos serviços da comunidade open source, como o LWN.net.
O incidente, que começou como uma simples falha de energia, rapidamente se transformou em um pesadelo logístico para a Linode, uma das principais provedoras de hospedagem em nuvem utilizada por projetos open source. Sem refrigeração, os servidores tiveram que ser desligados para evitar danos permanentes e, como se não bastasse, a interrupção em Newark afetou outros data centers da empresa espalhados pelo mundo, de Dallas a Tóquio.
Data centers modernos são projetados para resistir a falhas de energia—geradores entram em ação, baterias garantem tempo para desligamentos controlados, e sistemas redundantes evitam que um único ponto de falha derrube tudo. Mas, como bem sabemos, a teoria nem sempre sobrevive ao contato com a realidade.
No caso de Newark, a energia voltou, mas o resfriamento não. E servidores sem refrigeração são como humanos em um deserto: podem até aguentar por um tempo, mas eventualmente entram em colapso. Resultado? Os técnicos tiveram que desligar tudo manualmente e religar gradualmente, evitando um efeito dominó de superaquecimento.
E aqui entra uma lição valiosa: não basta ter um plano de recuperação de desastres, é preciso testá-lo em condições realistas. Porque, como descobriram algumas empresas, há uma grande diferença entre “simular” um desligamento emergencial e realmente enfrentar um data center inteiro offline, com equipes correndo para religar sistemas em uma sequência que não cause mais problemas do que solução.
O efeito borboleta na Linode
Outro detalhe curioso desse incidente foi como um problema localizado em Newark conseguiu afetar servidores em outros continentes. A explicação? Interdependência.
Muitos serviços modernos, especialmente em ambientes de nuvem, dependem de sistemas distribuídos. Se um nó crítico em Newark parar de responder, serviços em Tóquio ou Sydney podem ficar incapazes de sincronizar dados ou validar autenticações. Ao custo de muito prejuízo, ficaram algumas lições para todos nós:
“Nunca aconteceria comigo” é uma frase perigosa
Muitas empresas tratam backups (não apenas de dados, mas de infraestrutura) e recuperação de desastres como um checklist burocrático. O problema é que, quando a crise chega, ninguém quer ser a pessoa que descobre que o gerador não tem combustível ou que o sistema de portas eletrônicas depende do data center que está offline.
Comunicação é tecnologia
Enquanto a Linode trabalhava nos reparos, usuários ficaram no escuro, e isso incluiu o LWN.net, que só conseguiu avisar os leitores depois que um servidor de backup entrou em ação.
E aqui entra outra lição: se seu serviço cai, avisar é uma prioridade. Mesmo que não haja informações detalhadas, um simples “estamos cientes do problema e trabalhando nisso” já evita que usuários fiquem achando que o problema está no próprio computador.
Diversificação é a chave
O incidente também levantou discussões sobre a dependência excessiva de um único provedor. Se sua empresa roda inteiramente na AWS, Azure ou Google Cloud, um problema grave (como um incêndio ou erro de configuração global) pode deixar você offline por horas, ou até dias.
A solução? Não coloque todos os ovos no mesmo data center. Se possível, distribua serviços críticos entre diferentes provedores ou, pelo menos, entre regiões geograficamente distantes.
E agora?
Enquanto a Linode se recupera e prepara seu relatório pós-incidente (que, sem dúvida, será estudado por administradores de sistemas do mundo inteiro), o episódio serve como um lembrete: a infraestrutura de serviços em nuvem pode ser mais frágil do que parece.
E se tem uma coisa que aprendemos com esse apagão, é que até os serviços mais resilientes podem ter um dia ruim. A diferença entre o caos e a recuperação rápida está no preparo e, claro, em nunca subestimar o poder dos imprevistos.
Fique por dentro das principais novidades da semana sobre tecnologia e Linux: assine nossa newsletter!
