Post Mortem no plano de controle da Cloudflare e interrupção de análise de dados

Na quinta-feira, 2 de novembro de 2023, às 11h43 UTC, o plano de controle e os serviços de análise de dados da Cloudflare sofreram uma interrupção. O plano de controle da Cloudflare consiste principalmente na interface voltada para o cliente para todos os nossos serviços, incluindo nosso site e APIs. Nossos serviços de análise de dados incluem registro de logs e relatórios de análise de dados.

O incidente durou de 2 de novembro às 11h44 UTC até 4 de novembro às 04h25 UTC. Conseguimos restaurar a maior parte do nosso plano de controle em nossas instalações de recuperação de desastres em 2 de novembro às 17h57 UTC. Muitos clientes não tiveram problemas com a maioria dos nossos produtos depois que o recurso de recuperação de desastres ficou on-line. No entanto, outros serviços demoraram mais para serem restaurados e os clientes que os utilizaram podem ter enfrentado problemas até resolvermos totalmente o incidente. Nossos serviços de log bruto ficaram indisponíveis para a maioria dos clientes durante o incidente.

Agora os serviços estão restaurados para todos os clientes. Durante todo o incidente, os serviços de rede e segurança da Cloudflare continuaram funcionando conforme esperado. Embora tenha havido períodos em que os clientes não conseguiram fazer alterações nesses serviços, o tráfego através da nossa rede não foi afetado.

Este post descreve os eventos que causaram esse incidente, a arquitetura que implementamos para evitar problemas como esse, o que falhou, o que funcionou e por quê, e as mudanças que estamos fazendo com base no que aprendemos nas últimas 36 horas.

Para começar, isso nunca deveria ter acontecido. Acreditávamos que tínhamos sistemas de alta disponibilidade que deveriam ter impedido uma interrupção como essa, mesmo quando um de nossos principais provedores de data center falhou catastroficamente. E, embora muitos sistemas tenham permanecido on-line conforme projetados, alguns sistemas críticos tinham dependências não óbvias que os tornaram indisponíveis. Lamento e estou envergonhado por este incidente e pelos problemas que causou aos nossos clientes e à nossa equipe.

O plano de controle e os sistemas de análise de dados da Cloudflare são executados principalmente nos servidores de três data centers em Hillsboro, Oregon. Os três data centers são independentes entre si, cada um possui várias fontes de energia de concessionárias públicas e várias conexões de rede redundantes e independentes.

As instalações foram intencionalmente escolhidas para ficarem a uma distância que minimizaria as chances de um desastre natural afetar todas as três, ao mesmo tempo em que ainda estavam próximas o suficiente para que todas pudessem executar clusters de dados redundantes ativo-ativo. Isso significa que elas sincronizam continuamente os dados entre as três instalações. Por design, se alguma das instalações ficar off-line, as demais são capazes de continuar operando.

Este é um projeto de sistema que começamos a implementar há quatro anos. Embora a maioria dos nossos sistemas críticos de plano de controle tenham sido migrados para o cluster de alta disponibilidade, alguns serviços, especialmente para alguns produtos mais recentes, ainda não haviam sido adicionados ao cluster de alta disponibilidade.

Além disso, nossos sistemas de registros de logs não faziam parte intencionalmente do cluster de alta disponibilidade. A lógica dessa decisão era que os registros de logs já eram um problema distribuído, onde os logs ficaram em fila na extremidade da nossa rede e depois enviados de volta ao núcleo em Oregon (ou outra instalação regional para clientes que usam serviços regionais para registro). Se nosso recurso de registros de logs estivesse off-line, os logs de análise de dados seriam enfileirados na borda de nossa rede até que ela voltasse a ficar on-line. Determinamos que o atraso na análise de dados era aceitável.

A maior das três instalações em Oregon é administrada pela Flexential. Nós nos referimos a essa instalação como “PDX-DC04”. A Cloudflare aluga espaço no PDX-04, onde abrigamos nosso maior cluster de análise de dados, bem como mais de um terço das máquinas para nosso cluster de alta disponibilidade. É também o local padrão para serviços que ainda não foram integrados ao nosso cluster de alta disponibilidade. Somos um cliente relativamente grande da instalação, consumindo aproximadamente 10% de sua capacidade total.

Em 2 de novembro às 08h50 UTC, a Portland General Electric (PGE), a concessionária que atende o PDX-04, teve um evento de manutenção não planejado afetando uma de suas alimentações independentes de energia no prédio. Esse evento desligou uma alimentação no PDX-04. O data center possui várias alimentações com algum nível de independência que podem alimentar a instalação. No entanto, a Flexential ligou seus geradores para complementar efetivamente a alimentação que estava inativa.

Contrariando as práticas recomendadas, a Flexential não informou à Cloudflare que havia feito failover na energia do gerador. Nenhuma das nossas ferramentas de observabilidade foi capaz de detectar que a fonte de energia havia mudado. Se eles tivessem nos informado, teríamos formado uma equipe para monitorar a instalação de perto e transferir os serviços do plano de controle que dependiam daquela instalação enquanto ela estava degradada.

Também é incomum que a Flexential tenha executado tanto a alimentação restante da concessionária quanto os geradores ao mesmo tempo. Não é incomum que as concessionárias solicitem que os data centers sejam desligados da rede quando a demanda de energia é alta e funcionem exclusivamente com geradores. A Flexential opera 10 geradores, inclusive unidades redundantes, capazes de suportar a instalação em plena carga. Também teria sido possível para a Flexential operar a instalação apenas a partir da alimentação restante da concessionária. Não obtivemos uma resposta clara por que eles usaram a energia elétrica da concessionária e a energia do gerador.

Desta decisão em diante, a Flexential ainda não esclareceu sobre a causa raiz ou algumas das decisões que tomaram ou sobre os eventos. Atualizaremos este post à medida que tivermos mais informações da Flexential, bem como da PGE, sobre o ocorrido. Parte do que se segue são especulações informadas baseadas na série de eventos mais prováveis, bem como no que funcionários individuais da Flexential compartilharam conosco extraoficialmente.

Uma possível razão pela qual eles deixaram a linha de serviços da concessionária pública funcionando é porque a Flexential fazia parte de um programa da PGE chamado DSG. O DSG permite que a concessionária local opere os geradores de um data center para ajudar a fornecer energia adicional à rede. Em troca, a companhia de energia ajuda a manter os geradores e fornece combustível. Não conseguimos localizar nenhum registro da Flexential nos informando sobre o programa DSG. Perguntamos se o DSG estava ativo no momento e não recebemos resposta. Não sabemos se isso contribuiu para as decisões tomadas pela Flexential, mas poderia explicar por que a linha da concessionária continuou on-line após os geradores serem iniciados.

Aproximadamente às 11h40 UTC, ocorreu uma falha à terra em um transformador da PGE no PDX-04.Acreditamos, mas não conseguimos obter confirmação da Flexential ou da PGE, que este foi o transformador que reduziu a energia da rede para a segunda alimentação que ainda estava funcionando quando entrou no data center. Parece provável, embora não tenhamos conseguido confirmar com a Flexential ou a PGE, que a falha à terra foi causada pela manutenção não planejada que a PGE estava realizando e que impactou a primeira alimentação. Ou foi uma coincidência muito infeliz.

Falhas à terra em linhas de energia de alta tensão (12.470 volts) são muito graves. Os sistemas elétricos são projetados para desligar rapidamente para evitar danos quando ocorrerem. Infelizmente, neste caso, a medida protetiva também desligou todos os geradores do PDX-04. Isto significava que as duas fontes de geração de energia da instalação, tanto as linhas redundantes da concessionária pública quanto os 10 geradores, ficaram off-line.

Felizmente, além dos geradores, o PDX-04 também contém um banco de baterias UPS. Essas baterias são, supostamente, suficientes para alimentar a instalação por aproximadamente 10 minutos. Esse tempo deve ser suficiente para preencher a lacuna entre a falta de energia e a inicialização automática dos geradores. Se a Flexential conseguisse restaurar os geradores ou a alimentação da concessionária em 10 minutos, não haveria interrupção. Na realidade, as baterias começaram a falhar após apenas 4 minutos com base no que observamos na falha dos nossos próprios equipamentos. E a Flexential levou muito mais de 10 minutos para restaurar os geradores.

Embora não tenhamos obtido uma confirmação oficial, os funcionários nos disseram que três coisas dificultaram a reativação dos geradores. Primeiro, eles precisavam ser acessados fisicamente e reiniciados manualmente devido à forma como a falha à terra havia desarmado os circuitos. Em segundo lugar, o sistema de controle de acesso da Flexential não era alimentado pelas baterias reserva, portanto estava off-line. E terceiro, o pessoal noturno no local não incluía um especialista em operações ou eletricidade experiente, o turno noturno consistia em segurança e um técnico desacompanhado que estava no trabalho há apenas uma semana.

Entre 11h44 e 12h01 UTC, com os geradores não totalmente reiniciados, as baterias do UPS ficaram sem energia e todos os clientes do data center perderam a energia. Durante esse período, a Flexential nunca informou à Cloudflare que havia algum problema nas instalações. Fomos notificados pela primeira vez sobre problemas no data center quando os dois roteadores que conectam a instalação ao resto do mundo ficaram off-line às 11h44 UTC. Quando não conseguimos acessar os roteadores diretamente ou por meio do gerenciamento fora de banda, tentamos entrar em contato com a Flexential e enviamos nossa equipe local para ir fisicamente até as instalações. A primeira mensagem da Flexential informando que eles estavam enfrentando um problema foi às 12h28 UTC.

No momento, estamos enfrentando um problema de energia em nosso [PDX-04] que começou aproximadamente às 5h PT [12h UTC]. Os engenheiros estão trabalhando ativamente para resolver o problema e restaurar o serviço. Comunicaremos o progresso a cada 30 minutos ou à medida que mais informações estiverem disponíveis sobre o tempo estimado para restauração. Agradecemos pela sua paciência e compreensão.

Embora o projeto do PDX-04 tenha sido certificado como Tier III antes da construção e deva fornecer SLAs de alta disponibilidade, planejamos a possibilidade de que ele pudesse ficar off-line. Mesmo instalações bem administradas podem ter dias ruins. E planejamos isso. O que esperávamos que acontecesse nesse caso é que nossas análises de dados ficariam off-line, os logs ficariam em filas e atrasados, e certos serviços de prioridade mais baixa, que não estavam integrados em nosso cluster de alta disponibilidade, ficariam off-line temporariamente até que pudessem ser restaurados em outra instalação.

Os outros dois data centers em execução na área assumiriam a responsabilidade pelo cluster de alta disponibilidade e manteriam os serviços críticos on-line. De maneira geral, isso funcionou conforme planejado. Infelizmente, descobrimos que um subconjunto de serviços que deveriam estar no cluster de alta disponibilidade tinha dependências de serviços executados exclusivamente no PDX-04.

Em particular, dois serviços críticos que processam logs e potencializam nossas análises de dados, Kafka e ClickHouse, estavam disponíveis apenas no PDX-04, mas tinham serviços que dependiam deles e que estavam em execução no cluster de alta disponibilidade. Essas dependências não deveriam estar tão interligadas, deveriam ter falhado de maneira mais suave, e nós deveríamos tê-las identificado.

Realizamos testes em nosso cluster de alta disponibilidade colocando cada uma das outras duas instalações do data center (e ambas) totalmente off-line. E também testamos colocar off-line a parte de alta disponibilidade do PDX-04. No entanto, nunca testamos totalmente a colocação off-line de todas as instalações do PDX-04. Como resultado, perdemos a importância de algumas dessas dependências em nosso plano de dados.

Também fomos muito negligentes em exigir que novos produtos e seus bancos de dados associados fossem integrados ao cluster de alta disponibilidade. A Cloudflare permite que várias equipes inovem rapidamente. Como tal, os produtos muitas vezes seguem caminhos diferentes em direção ao seu alfa inicial. Embora, com o tempo, nossa prática seja migrar o back-end desses serviços para nossas práticas recomendadas, não exigimos isso formalmente antes que os produtos fossem declarados como disponibilidade geral (GA). Isso foi um erro, pois significava que as proteções contra redundância que tínhamos em vigor funcionavam de forma inconsistente, dependendo do produto.

Além disso, muitos dos nossos serviços dependem da disponibilidade das nossas instalações principais. Embora essa seja a forma como muitos serviços de software são criados, isso não contribui para a força da Cloudflare. Somos bons em sistemas distribuídos. Ao longo deste incidente, a nossa rede global continuou a funcionar conforme esperado. Embora alguns de nossos produtos e recursos sejam configuráveis e utilizáveis através da borda de nossa rede sem a necessidade do núcleo, muitos hoje falham se o núcleo não estiver disponível. Precisamos usar os produtos de sistemas distribuídos que disponibilizamos a todos os nossos clientes para todos os nossos serviços, para que continuem a funcionar normalmente, mesmo que nossas instalações principais sejam interrompidas.

Às 12h48 UTC, a Flexential conseguiu reiniciar os geradores. A energia voltou a algumas partes da instalação. Para não sobrecarregar o sistema, quando a energia é restaurada em um data center, isso normalmente é feito gradualmente, ligando novamente um circuito por vez. Assim como os disjuntores de uma residência, cada cliente é atendido por disjuntores redundantes. Quando a Flexential tentou fazer backup dos circuitos da Cloudflare, descobriu-se que os disjuntores estavam com defeito. Não sabemos se os disjuntores falharam devido à falha à terra ou algum outro surto como resultado do incidente, ou se já estavam ruins antes, e isso só foi descoberto depois de terem sido desligados.

A Flexential iniciou o processo de substituição dos disjuntores com falha. Isso exigiu que eles adquirissem novos disjuntores porque havia mais disjuntores ruins do que os que tinham disponíveis nas instalações. Como mais serviços estavam off-line do que esperávamos e como a Flexential não pôde nos dar um prazo para restauração de nossos serviços, fizemos a ligação às 13h40 UTC para fazer failover nos sites de recuperação de desastres da Cloudflare localizados na Europa. Felizmente, só precisamos fazer failover em uma pequena porcentagem do plano de controle geral da Cloudflare. A maioria dos nossos serviços continuou a ser executada em nossos sistemas de alta disponibilidade nos dois data centers principais ativos.

Ativamos os primeiros serviços no site de recuperação de desastres às 13h43 UTC. Os sites de recuperação de desastres da Cloudflare fornecem serviços críticos de plano de controle em caso de desastre. Embora o site de recuperação de desastres não ofereça suporte a alguns de nossos serviços de processamento de logs, ele foi projetado para oferecer suporte a outras partes do nosso plano de controle.

Quando os serviços foram ativados lá, enfrentamos um problema thundering herd, onde as chamadas de API que falhavam sobrecarregavam nossos serviços. Implementamos limites de taxa para manter o volume de solicitações sob controle. Durante esse período, os clientes da maioria dos produtos observaram erros intermitentes ao fazer modificações por meio de nosso painel ou API. Às 17h57 UTC, os serviços que foram movidos com sucesso para o local de recuperação de desastres estavam estáveis e a maioria dos clientes não estava mais diretamente afetada. No entanto, alguns sistemas ainda exigiam configuração manual (por exemplo, Magic WAN) e alguns outros serviços, em grande parte relacionados ao processamento de logs e algumas APIs personalizadas, permaneceram indisponíveis até que conseguíssemos restaurar o PDX-04.

Alguns produtos não foram devidamente destacados em nossos sites de recuperação de desastres. Foram produtos mais recentes nos quais não havíamos implementado e testado totalmente um procedimento de recuperação de desastres. Isso incluiu nosso serviço Stream para fazer upload de novos vídeos e alguns outros serviços. Nossa equipe trabalhou em dois caminhos simultâneos para restaurar esses serviços: 1) reimplementá-los em nossos sites de recuperação de desastres; e 2) migrá-los para nosso cluster de alta disponibilidade.

A Flexential substituiu nossos disjuntores com falha, restaurou ambas as alimentações da concessionária e confirmou a energia limpa às 22h48 UTC. Nossa equipe estava toda ativa e havia trabalhado o dia todo na emergência, então tomei a decisão de que a maioria de nós deveria descansar um pouco e começar a voltar para o PDX-04 pela manhã. Essa decisão atrasou a nossa recuperação total, mas acredito que tornou menos provável que agravássemos esta situação com erros adicionais.

A partir de 3 de novembro, nossa equipe começou a restaurar o serviço no PDX-04. Isso começou com a inicialização física de nossos equipamentos de rede e, em seguida, com a inicialização de milhares de servidores e a restauração de seus serviços. O estado dos nossos serviços no data center era desconhecido, pois acreditávamos que vários ciclos de energia provavelmente teriam ocorrido durante o incidente. Nosso único processo seguro de recuperação foi seguir um bootstrap completo de toda a instalação.

Isso envolveu um processo manual de colocar nossos servidores de gerenciamento de configuração on-line para iniciar a restauração das instalações. Essa reconstrução levou 3 horas. A partir daí, nossa equipe conseguiu iniciar a reconstrução do restante dos servidores que alimentam nossos serviços. Cada servidor levou entre 10 minutos e 2 horas para ser reconstruído. Embora tenhamos conseguido executar isso em paralelo em vários servidores, havia dependências inerentes entre os serviços que exigiam que alguns voltassem a ficar on-line em sequência.

Os serviços agora foram totalmente restaurados desde 4 de novembro de 2023, às 04h25 UTC. Para a maioria dos clientes, como também armazenamos análises de dados em nossos principais data centers europeus, não deverá ocorrer nenhuma perda de dados na maioria das análises de dados em nosso painel e APIs. No entanto, alguns conjuntos de dados que não são replicados na UE apresentarão lacunas persistentes. Para clientes que usam nosso recurso de envio de logs, seus logs não foram processados durante a maior parte do evento, portanto, tudo o que não foi recebido não será recuperado.

Temos uma série de perguntas que precisam ser respondidas pela Flexential. Mas também devemos esperar que data centers inteiros possam falhar. O Google tem um processo onde, quando há um evento ou crise significativa, eles podem acionar um Código Amarelo ou Código Vermelho. Nestes casos, a maioria ou todos os recursos de engenharia são transferidos para resolver o problema em questão.

Não tivemos esse processo no passado, mas hoje está claro que precisamos implementar nós mesmos uma versão dele: o Código Laranja. Estamos mudando todas as funções de engenharia não críticas para nos concentrarmos em garantir a alta confiabilidade do nosso plano de controle. Como parte disso, esperamos as seguintes mudanças:

• Remover as dependências de nossos principais data centers para configuração do plano de controle de todos os serviços e mudá-los para que, sempre que possível, sejam alimentados primeiro por nossa rede distribuída.

• Garantir que o plano de controle em execução na rede continue funcionando mesmo que todos os nossos data centers principais estejam off-line.

• Exigir que todos os produtos e recursos designados como Disponibilidade Geral dependam do cluster de alta disponibilidade (se dependerem de qualquer um de nossos data centers principais), sem ter nenhuma dependência de software em instalações específicas.

• Exigir que todos os produtos e recursos designados como Disponibilidade Geral tenham um plano de recuperação de desastres confiável e testado.

• Testar o raio de explosão das falhas do sistema e minimizar o número de serviços afetados por uma falha.

• Implementar testes de caos mais rigorosos em todas as funções do data center, incluindo a remoção completa de cada uma de nossas principais instalações de data center.

• Auditoria completa de todos os data centers principais e um plano de nova auditoria para garantir que estejam em conformidade com nossos padrões.

• Plano de recuperação de desastres de registro de logs e análise de dados que garante que nenhum registro seja perdido, mesmo no caso de falha de todas as nossas instalações principais.

Como disse anteriormente, sinto muito e estou envergonhado por este incidente e pelos problemas que causou aos nossos clientes e à nossa equipe. Temos os sistemas e procedimentos corretos implementados para resistir até mesmo à série de falhas em cascata que vimos em nosso provedor de data center, mas precisamos ser mais rigorosos ao garantir que eles sejam seguidos e testados para dependências desconhecidas. Isso terá toda a minha atenção e a atenção de grande parte da nossa equipe ao longo do balanço do ano. E os problemas dos últimos dias vão nos tornar melhores.