O que diabos aconteceu com a Cloudflare na semana passada?

O que diabos aconteceu com a Cloudflare na semana passada?

Cloudflare no telefone

Em 2 de novembro de 2023, as interfaces voltadas para o cliente da Cloudflare, incluindo o site e as APIs, juntamente com o registro e análise, pararam de funcionar corretamente. Isso foi ruim.

Mais de 7,5 milhões de sites usam a Cloudflare, e 3.280 dos 10.000 sites mais populares do mundo dependem de seus serviços de rede de distribuição de conteúdo (CDN). A boa notícia é que o CDN não caiu. A má notícia é que o Painel da Cloudflare e suas APIs relacionadas ficaram fora do ar por quase dois dias.

Também: Os melhores serviços de VPN (e como escolher o certo para você)

Isso tipo de coisa simplesmente não acontece – ou pelo menos não deveria – com as grandes empresas de serviços de internet. Então, a pergunta de vários milhões de dólares é: ‘O que aconteceu?’ A resposta, de acordo com o CEO da Cloudflare, Matthew Prince, foi um incidente relacionado à energia em um trio dos principais centros de dados da empresa em Oregon, que são gerenciados pela Flexential, que causou uma série de problemas. Trinta e seis horas depois, a Cloudflare finalmente voltou ao normal.

Prince não rodeou o problema:

Para começar, isso nunca deveria ter acontecido. Acreditávamos que tínhamos sistemas de alta disponibilidade em funcionamento que deveriam ter impedido uma interrupção como essa, mesmo quando um de nossos principais provedores de centro de dados falhasse catastróficamente. E, embora muitos sistemas continuassem online conforme planejado, alguns sistemas críticos tinham dependências não óbvias que os tornavam indisponíveis. Sinto muito e estou envergonhado por este incidente e pela dor causada aos nossos clientes e à nossa equipe.

Ele está certo – esse incidente nunca deveria ter acontecido. O painel de controle e os sistemas de análise da Cloudflare funcionam em servidores em três centros de dados ao redor de Hillsboro, Oregon. Mas, eles são independentes uns dos outros; cada um possui várias fontes de alimentação elétrica e várias conexões de internet redundantes e independentes.

O trio de centros de dados não está tão perto um do outro a ponto de um desastre natural causar a queda de todos eles de uma vez. Ao mesmo tempo, eles ainda estão próximos o suficiente para que todos possam executar clusters de dados ativos e redundantes. Então, por design, se qualquer uma das instalações ficar offline, as restantes devem assumir a carga e continuar operando.

Parece ótimo, não é mesmo? No entanto, não foi isso que aconteceu.

O que aconteceu primeiro foi que uma falha de energia nas instalações da Flexential causou uma interrupção inesperada do serviço. Portland General Electric (PGE) foi forçada a desligar uma das fontes de alimentação elétrica independentes do prédio. O centro de dados possui várias fontes com algum nível de independência que podem alimentar as instalações. No entanto, a Flexential ativou seus geradores para complementar a alimentação que estava inoperante.

Essa abordagem, aliás, para aqueles de vocês que não conhecem as melhores práticas dos centros de dados, é um erro. Você não usa energia externa e geradores ao mesmo tempo. Para piorar a situação, a Flexential não avisou a Cloudflare que eles meio que, tipo assim, mudaram para a energia do gerador.

Também: 10 maneiras de acelerar sua conexão com a internet hoje

Então, houve um defeito de terra em um transformador da PGE que estava indo para o data center. E, quando digo defeito de terra, não quero dizer um curto-circuito, como aquele que faz você descer para o porão para consertar um fusível. Quero dizer um “bad boy” de 12.470 volts que derrubou a conexão e todos os geradores em menos tempo do que você levou para ler esta frase.  

Em teoria, um banco de baterias UPS deveria manter os servidores funcionando por 10 minutos, o que por sua vez deveria ser tempo suficiente para ligar os geradores novamente. Em vez disso, as UPS começaram a falhar em cerca de quatro minutos, e os geradores nunca foram ligados a tempo de qualquer maneira.

Opa.

Talvez não houvesse ninguém capaz de salvar a situação, mas quando a equipe presente durante a noite “consistia de segurança e um técnico não acompanhado que estava no trabalho há apenas uma semana”, a situação era desesperadora.

Também: Os melhores serviços de VPN para iPhone e iPad (sim, você precisa usar um)

Enquanto isso, o Cloudflare descobriu da pior maneira possível que alguns sistemas críticos e serviços mais recentes ainda não estavam integrados à sua configuração de alta disponibilidade. Além disso, a decisão do Cloudflare de manter os sistemas de registro fora do cluster de alta disponibilidade, porque os atrasos nas análises seriam aceitáveis, acabou se mostrando errada. Como a equipe do Cloudflare não conseguiu obter uma boa visão dos registros para ver o que estava dando errado, a queda de energia persistiu. 

Acontece que, embora os três data centers fossem “na maioria das vezes” redundantes, eles não eram totalmente. Os outros dois data centers em funcionamento na área assumiram a responsabilidade pelo cluster de alta disponibilidade e mantiveram os serviços críticos online. 

Até aí tudo bem. No entanto, um subconjunto de serviços que deveriam estar no cluster de alta disponibilidade dependia de serviços que estavam sendo executados exclusivamente no data center inativo. 

Especificamente, dois serviços críticos que processam logs e alimentam a análise do Cloudflare — Kafka e ClickHouse — só estavam disponíveis no data center offline. Portanto, quando os serviços no cluster de alta disponibilidade solicitaram o Kafka e Clickhouse, eles falharam.

O Cloudflare admite que foi “muito relaxado” ao exigir que novos produtos e seus bancos de dados associados se integrassem ao cluster de alta disponibilidade. Além disso, muitos dos seus serviços dependem da disponibilidade de suas infraestruturas principais. 

Muitas empresas fazem as coisas dessa maneira, mas Prince admite, isso “não é a especialidade do Cloudflare. Somos bons em sistemas distribuídos. Durante esse incidente, nossa rede global continuou a funcionar conforme o esperado, mas muitas falharam se o núcleo estivesse indisponível. Precisamos usar os produtos de sistemas distribuídos que disponibilizamos para todos os nossos clientes em todos os nossos serviços, para que eles continuem a funcionar quase normalmente mesmo se nossas infraestruturas principais forem interrompidas.”

Também: Cybersecurity 101: Tudo sobre como proteger sua privacidade e se manter seguro online

Horas depois, tudo finalmente estava funcionando novamente – e não foi fácil. Por exemplo, quase todos os disjuntores de energia estavam queimados, e o Flexentail teve que comprar mais para substituí-los todos.

Acreditando que havia ocorrido várias sobretensões, o Cloudflare decidiu que o “único processo seguro de recuperação era seguir uma inicialização completa de toda a instalação.” Esse método significava reconstruir e reiniciar todos os servidores, o que levou horas. 

O incidente, que durou até 4 de novembro, foi finalmente resolvido. Olhando para o futuro, Prince concluiu: “Temos os sistemas e procedimentos corretos para suportar até mesmo a sequência cascata de falhas que vimos em nosso provedor de data center, mas precisamos ser mais rigorosos em exigir que eles sejam seguidos e testados quanto a dependências desconhecidas. Isso terá minha atenção total e a atenção de uma grande parte de nossa equipe pelo restante do ano. E a dor dos últimos dias nos tornará melhores.”