Post-mortem da interrupção do plano de controle e do sistema de analytics da Cloudflare
(blog.cloudflare.com)- A partir de 2 de novembro de 2023 às 11:43 UTC, o plano de controle e os serviços de analytics da Cloudflare sofreram uma interrupção, afetando alterações via dashboard/API e funcionalidades de logs e análise
- O ponto de partida da falha foi uma queda de energia no PDX-04, em Oregon, operado pela Flexential; essa instalação abrigava o maior cluster de analytics e mais de um terço dos equipamentos do cluster de alta disponibilidade
- Enquanto a recuperação de utility feed, gerador, UPS e disjuntores sofreu falhas em cascata, as dependências exclusivas do PDX-04 em Kafka e ClickHouse quebraram o desenho de alta disponibilidade
- Às 13:40 UTC de 2 de novembro, foi decidido fazer failover para o site europeu de recuperação de desastres, e às 17:57 UTC o impacto para os clientes já havia diminuído em grande parte, embora processamento de logs, algumas APIs bespoke, configurações manuais do Magic WAN e uploads do Stream tenham sido afetados por mais tempo
- A Cloudflare está conduzindo em Code Orange exigências de alta disponibilidade para produtos GA, planos de recuperação de desastres validados, chaos testing incluindo a remoção completa de datacenters críticos e um plano para evitar perda de logs
Escopo da falha e impacto para os clientes
- A partir de 2 de novembro de 2023 às 11:43 UTC, houve uma falha no plano de controle e nos serviços de analytics da Cloudflare
- O plano de controle se refere às interfaces voltadas ao cliente, incluindo website e APIs
- Os serviços de analytics incluem logging e relatórios analíticos
- Todo o incidente durou de 2 de novembro às 11:44 UTC até 4 de novembro às 04:25 UTC
- Às 17:57 UTC de 2 de novembro, a maior parte do plano de controle foi restaurada no ambiente de recuperação de desastres
- Depois que a instalação de recuperação de desastres entrou em operação, muitos clientes provavelmente não enfrentaram problemas na maioria dos produtos
- Alguns serviços levaram mais tempo para se recuperar, e clientes que usavam esses serviços ainda podiam ver problemas até a resolução completa
- O serviço de logs brutos não ficou disponível para a maioria dos clientes durante a maior parte do incidente
- Os serviços de rede e segurança da Cloudflare funcionaram como esperado durante todo o incidente
- Houve períodos em que os clientes não conseguiam alterar esses serviços
- O tráfego que passava pela rede da Cloudflare não foi afetado
Projeto original: alta disponibilidade baseada em 3 datacenters no Oregon
- O plano de controle e os sistemas de analytics da Cloudflare operam principalmente em servidores de 3 datacenters nos arredores de Hillsboro, Oregon
- Os 3 datacenters são independentes entre si e cada um possui múltiplos utility power feeds e múltiplas conexões de rede redundantes e independentes
- As instalações foram escolhidas para ficar suficientemente separadas para que um desastre natural dificilmente afetasse todas ao mesmo tempo, mas próximas o bastante para operar um cluster de dados redundante em active-active
- As três instalações sincronizam dados continuamente
- Pelo projeto, mesmo que uma instalação fique offline, as demais devem continuar operando
- Esse desenho de alta disponibilidade começou a ser implementado há 4 anos
- A maior parte dos sistemas centrais do plano de controle foi migrada para o cluster de alta disponibilidade
- Alguns serviços de produtos novos ainda não haviam sido incluídos no cluster de alta disponibilidade
- O sistema de logging foi intencionalmente deixado fora do cluster de alta disponibilidade
- Os logs são tratados como um problema distribuído: entram em filas no edge da rede e depois são enviados ao core do Oregon ou a instalações regionais de logging
- Se a instalação de logging ficar offline, os logs analíticos aguardam no edge, e o atraso na análise era considerado aceitável
Início da falha de energia no PDX-04
- A maior das 3 instalações do Oregon é o PDX-04, operado pela Flexential
- A Cloudflare mantém ali seu maior cluster de analytics
- Mais de um terço dos equipamentos do cluster de alta disponibilidade também fica nessa instalação
- Também é o local padrão para serviços que ainda não foram onboarded para o cluster de alta disponibilidade
- A Cloudflare é um cliente relativamente grande da instalação, usando cerca de 10% da capacidade total do local
- Em 2 de novembro às 08:50 UTC, ocorreu um evento de manutenção não planejado em um dos feeds independentes de energia da Portland General Electric (PGE) que alimentavam o PDX-04
- Esse evento interrompeu um dos feeds que chegavam ao PDX-04
- A Flexential acionou geradores para compensar o feed interrompido
- A Flexential não notificou a Cloudflare de que havia feito failover para energia de gerador
- As ferramentas de observabilidade da Cloudflare não detectaram a mudança na fonte de energia
- Se tivesse sido avisada com antecedência, a Cloudflare poderia ter monitorado a instalação de perto e movido para outro lugar os serviços do plano de controle que dependiam dela
- Também foi incomum o fato de a Flexential operar ao mesmo tempo o feed de utility remanescente e os geradores
- A Flexential opera 10 geradores, incluindo unidades redundantes, capazes de sustentar a carga total da instalação
- Também seria possível operar a instalação apenas com o feed de utility restante
- A Cloudflare não recebeu uma resposta clara sobre por que a Flexential operou utility power e energia de gerador em conjunto
Causa não confirmada e parada dos geradores
- A causa raiz dos eventos seguintes e algumas decisões tomadas não foram claramente confirmadas pela Flexential
- Uma das possibilidades é que a Flexential estivesse participando do programa DSG da PGE
- O DSG é um programa que permite à concessionária local usar geradores de datacenters para fornecer energia adicional à rede
- Em troca, a concessionária dá suporte à manutenção dos geradores e ao fornecimento de combustível
- A Cloudflare não encontrou registros de que a Flexential tivesse informado sobre o programa DSG
- Também não recebeu resposta sobre se o DSG estava ativo no momento do incidente
- Por volta de 11:40 UTC, ocorreu um ground fault no transformador da PGE no PDX-04
- A Cloudflare acredita que esse transformador provavelmente era o equipamento que reduzia a tensão do segundo feed que entrava no datacenter, mas isso não foi confirmado
- Também não foi confirmado se esse ground fault teve origem na manutenção não planejada da PGE que afetou o primeiro feed
- Um ground fault em uma linha de alta tensão de 12.470V é projetado para fazer o sistema elétrico desligar rapidamente, a fim de evitar danos
- Essa proteção também desligou todos os geradores do PDX-04
- Como resultado, a linha de utility e os 10 geradores ficaram offline
- O PDX-04 tinha um banco de baterias de UPS que supostamente conseguiria sustentar a instalação por cerca de 10 minutos
- Esse tempo serviria para cobrir o intervalo entre a falha de energia e o reinício automático dos geradores
- Pelos critérios de observação de falha dos equipamentos da Cloudflare, as baterias começaram a falhar após apenas 4 minutos
- A Flexential levou bem mais que 10 minutos para restaurar os geradores
Atraso na recuperação da energia e primeira notificação
- Embora a Cloudflare não tenha recebido confirmação oficial, funcionários da Flexential relataram três fatores que atrapalharam a recuperação dos geradores
- Pelo modo como os circuitos haviam desarmado com o ground fault, foi necessário acesso físico aos geradores para reinício manual
- O sistema de controle de acesso da Flexential não tinha energia de backup por bateria e estava offline
- A equipe do turno da noite não incluía operadores experientes nem especialistas elétricos; havia apenas seguranças e um técnico recém-contratado, sem acompanhamento, com uma semana de casa
- Entre 11:44 e 12:01 UTC, sem que os geradores conseguissem reiniciar totalmente, as baterias do UPS se esgotaram e todos os clientes do datacenter perderam energia
- A Flexential não informou a Cloudflare sobre o problema na instalação durante esse processo
- A Cloudflare percebeu o problema no datacenter pela primeira vez às 11:44 UTC, quando 2 roteadores que conectavam a instalação ao exterior ficaram offline
- Sem conseguir acessar os roteadores diretamente nem via out-of-band management, a empresa entrou em contato com a Flexential e enviou uma equipe local à instalação
- A primeira mensagem de falha enviada pela Flexential à Cloudflare chegou às 12:28 UTC
- A mensagem dizia que o problema de energia no PDX-04 havia começado por volta de 12:00 UTC, que engenheiros estavam trabalhando na recuperação e que atualizações seriam dadas a cada 30 minutos
Problemas de dependência revelados no desenho de alta disponibilidade
- O PDX-04 tinha um projeto com certificação Tier III antes da construção e se esperava que oferecesse um SLA de alta disponibilidade, mas a Cloudflare também planejou para a possibilidade de essa instalação ficar offline
- O impacto esperado era interrupção de analytics, enfileiramento e atraso de logs no edge e parada temporária de serviços de menor prioridade que não estavam integrados ao cluster de alta disponibilidade
- O comportamento esperado de os outros dois datacenters sustentarem o cluster de alta disponibilidade e manterem os serviços centrais online funcionou em grande parte como planejado
- O problema foi que alguns serviços que deveriam estar no cluster de alta disponibilidade dependiam de serviços executados apenas no PDX-04
- Kafka e ClickHouse, responsáveis por processamento de logs e analytics, só eram fornecidos no PDX-04
- Alguns serviços executados no cluster de alta disponibilidade dependiam deles
- Essa dependência deveria ser mais frouxa, deveria falhar de forma mais elegante e deveria ter sido descoberta antes
- A Cloudflare já havia feito testes de alta disponibilidade colocando cada uma das outras duas instalações e ambas completamente offline
- Também realizou testes que deixavam offline a parte de alta disponibilidade do PDX-04
- Porém, não testou o cenário de a instalação inteira do PDX-04 ficar completamente offline
- Os critérios que exigiam a integração de novos produtos e seus bancos de dados relacionados ao cluster de alta disponibilidade também eram permissivos demais
- As equipes de produto tinham caminhos diferentes até a fase alpha
- A ideia era migrar os backends para boas práticas com o tempo, mas isso não era uma exigência formal antes da declaração de GA
- Como resultado, a proteção por redundância funcionava de maneira inconsistente entre produtos
Migração para o site de recuperação de desastres
- Às 12:48 UTC, a Flexential reiniciou os geradores e parte da instalação voltou a ter energia
- A restauração da energia em datacenters normalmente ocorre de forma gradual, um circuito por vez
- Quando chegou a hora de religar os circuitos da Cloudflare, foi constatado que os disjuntores haviam falhado
- Não se sabe se os disjuntores falharam por causa do ground fault ou de um surge, ou se já havia um problema anterior
- A Flexential começou a substituir os disjuntores com falha
- Houve mais disjuntores danificados do que o estoque disponível na instalação, e foi preciso conseguir novos
- Como havia mais serviços offline do que o esperado e a Flexential não conseguia fornecer um prazo de recuperação, a Cloudflare decidiu às 13:40 UTC fazer failover para o site europeu de recuperação de desastres
- Apenas uma pequena parcela de todo o plano de controle precisou passar por failover
- A maioria dos serviços continuou rodando nos sistemas de alta disponibilidade dos dois datacenters core restantes
- Às 13:43 UTC, o primeiro serviço foi ativado no site de recuperação de desastres
- Esse site foi projetado para fornecer serviços centrais do plano de controle em caso de desastre
- Ele não oferece suporte a alguns serviços de processamento de logs
- Depois da ativação dos serviços, houve uma enxurrada de chamadas de API que vinham falhando, gerando um problema de thundering herd
- A Cloudflare aplicou rate limit para controlar o volume de requisições
- Durante esse período, clientes da maioria dos produtos podiam ver erros intermitentes ao fazer alterações via dashboard ou API
- Até 17:57 UTC, os serviços migrados para o site de recuperação de desastres já haviam se estabilizado, e o impacto direto para a maioria dos clientes diminuiu
- Alguns sistemas, como o Magic WAN, ainda exigiam configuração manual
- O processamento de logs e alguns serviços ligados a APIs bespoke continuaram indisponíveis até a recuperação do PDX-04
Recuperação atrasada de alguns produtos e reinicialização do PDX-04
- Alguns produtos não funcionaram corretamente no site de recuperação de desastres
- Em geral, eram produtos novos cujos procedimentos de recuperação de desastres ainda não estavam totalmente implementados nem testados
- Entre eles estavam o serviço Stream para novos uploads de vídeo e alguns outros serviços
- As equipes da Cloudflare seguiram dois caminhos em paralelo
- Reimplementar esses serviços no site de recuperação de desastres
- Migrá-los para o cluster de alta disponibilidade
- A Flexential substituiu os disjuntores com falha, restaurou os dois utility feeds e confirmou energia estável às 22:48 UTC
- Como as equipes passaram o dia inteiro em resposta de emergência, a Cloudflare decidiu que a maior parte do pessoal deveria descansar e que os trabalhos de retorno ao PDX-04 começariam na manhã seguinte
- Essa decisão atrasou a recuperação total, mas foi tomada para reduzir a chance de novos erros
- A recuperação dos serviços no PDX-04 começou na manhã de 3 de novembro
- Os equipamentos de rede foram inicializados fisicamente
- Milhares de servidores foram ligados e os serviços, restaurados
- Como pode ter havido vários ciclos de energia durante o incidente, o estado dos serviços dentro do datacenter era desconhecido
- O procedimento seguro de recuperação foi seguir um bootstrap completo de toda a instalação
- Os servidores de gerenciamento de configuração foram colocados online manualmente, e a reconstrução levou 3 horas
- Depois disso, os demais servidores foram reconstruídos via bootstrap
- A reconstrução de cada servidor levou de 10 minutos a 2 horas
- Isso foi executado em paralelo em vários servidores, mas algumas recuperações tiveram de ser sequenciais por causa das dependências entre serviços
- Todos os serviços foram completamente restaurados em 4 de novembro de 2023 às 04:25 UTC
- Para a maioria dos clientes, espera-se que não tenha havido perda de dados na maior parte dos analytics exibidos em dashboard e API, porque esses dados também eram armazenados no datacenter core europeu
- Alguns conjuntos de dados que não eram replicados para a UE ficaram com lacunas permanentes
- Clientes que usam Logpush não tiveram logs processados durante a maior parte do incidente, e os logs não recebidos não puderam ser recuperados
Code Orange e plano de melhorias
- A Cloudflare ainda tem muitas perguntas que precisam ser respondidas pela Flexential, mas concluiu que também precisa assumir a possibilidade de uma falha total de datacenter
- De forma semelhante ao Code Yellow e Code Red do Google, a empresa introduziu o Code Orange, um processo interno para concentrar recursos de engenharia na resolução de problemas durante incidentes graves ou crises
- Funções de engenharia não essenciais foram redirecionadas para trabalhos que garantam alta confiabilidade do plano de controle
- As mudanças planejadas incluem:
- Remover, da configuração do plano de controle de todos os serviços, dependências de datacenters core e, quando possível, migrar para que a rede distribuída da Cloudflare seja a primeira a entrar em operação
- Garantir que o plano de controle executado na rede continue funcionando mesmo se todos os datacenters core ficarem offline
- Exigir que produtos e funcionalidades GA que dependem de datacenters core dependam do cluster de alta disponibilidade, sem dependências de software ligadas a uma instalação específica
- Exigir que produtos e funcionalidades GA tenham planos de recuperação de desastres confiáveis e testados
- Testar o blast radius de falhas de sistema e minimizar a quantidade de serviços afetados por um incidente
- Implementar chaos testing mais rigoroso para todas as funções de datacenter, incluindo a remoção completa de cada instalação core
- Auditar profundamente todos os datacenters core e estabelecer um plano de reauditoria para garantir conformidade com os padrões
- Preparar planos de recuperação de desastres para logging e analytics de modo que logs não sejam perdidos mesmo em cenários de falha de todas as instalações core
- A Cloudflare conclui que, embora tivesse os sistemas e procedimentos necessários, faltou rigor para garantir seu cumprimento e para testar dependências desconhecidas
1 comentários
Comentários do Hacker News
Foi uma escolha estranha gastar a maior parte do texto citando um fornecedor específico para atribuir culpa e especular sobre a causa raiz
Também pareceu bem inadequado revelar que era um grande cliente da instalação e até incluir na análise pós-incidente diagramas elétricos marcados como Confidential pelo fornecedor
Entendo explicar o gatilho e o contexto do incidente, mas o foco da análise pós-incidente deveria ser o apagão da Cloudflare, não o fornecedor
A Flexential também deveria fazer sua própria análise pós-incidente, mas a Cloudflare não precisa especular no lugar dela e publicar isso abertamente
Também pode ter sido uma forma de a Cloudflare se antecipar e explicar a situação antes que outra pessoa criasse a narrativa primeiro
Numa situação em que três partes e vários sistemas conectados estão envolvidos, é razoável que a Cloudflare queira saber até o fim o que aconteceu para poder refletir esse modo de falha complexo no projeto daqui para frente
Pessoalmente, agradeço pelas informações que a Cloudflare compartilhou
99% da culpa está na Cloudflare por não ter conseguido cumprir sua função principal
Investigar um terceiro tão a fundo assim só mostra o quanto isso foi constrangedor para a Cloudflare
Também parece que nem fizeram a inspeção do disjuntor direito, e, embora seja uma instalação relativamente nova, não conseguiram garantir nem metade das 10 horas necessárias para carregar as baterias do gerador
Durante essa manutenção, deveriam ter mudado totalmente para os geradores, e é bem possível que não tenham feito isso para ajudar a PGE
Acho que o CEO da Cloudflare está certo. O serviço de datacenter é algo pelo qual se paga esperando redundância total, e, se há 18MW nesse local, nem está claro pelo que se vê se existem só dois feeds
Se um feed cair, a configuração 2N deveria assumir, e, se há geradores, não deveria haver problema
Nesse caso, faz sentido incluir a descrição dos eventos iniciais apurados até agora
Parece bem provável que venha uma análise posterior
https://twitter.com/eastdakota/status/1720688383607861442?t=...
Pelo trecho citado, a causa raiz do incidente foi a dependência de um único datacenter
A maioria dos principais sistemas do plano de controle já tinha sido migrada para clusters de alta disponibilidade, mas alguns produtos novos ainda não; alguns serviços que deveriam estar nesses clusters de alta disponibilidade dependiam de serviços rodando apenas no PDX-04; e alguns produtos não tinham sido implantados corretamente no site de recuperação de desastres
Para uma empresa como a Cloudflare, que sustenta uma parte importante da internet, isso é bem vergonhoso
A Cloudflare disse que, ao permitir inovação rápida por várias equipes, cada produto seguiu seu próprio caminho até os estágios iniciais de alfa, e que depois migraria para as melhores práticas com o tempo, mas isso não era exigido como pré-requisito antes do lançamento geral
Isso é uma completa falha de gestão. Na prática, não significa que venderam aos clientes software de qualidade alfa pelos padrões internos da própria Cloudflare?
https://news.ycombinator.com/item?id=38113503
Parece faltar autopercepção
Isso é amador, e é especialmente grave que novos serviços tenham sido lançados sem alta disponibilidade
Como alguém que foi ligeiramente afetado por esse incidente, acho que esta análise pós-incidente ficou aquém
75% do texto trata da falha de energia no PDX-04 e da responsabilidade da Flexential, o que é compreensível, porque, pelo texto, o que aconteceu ali parece ter sido quase um desastre
Mas, em 2 de novembro UTC, a energia já tinha sido totalmente restaurada, e o texto diz que depois disso a Cloudflare ainda levou cerca de mais 30 horas para se recuperar completamente
A recuperação levou mais tempo que o próprio incidente, mas o texto só diz que serviços demais dependiam uns dos outros. Eu gostaria de saber com mais detalhe por que a restauração operacional completa demorou tanto
Não houve lições tiradas do próprio processo de recuperação? Ou realmente foi só esse o tempo necessário para sincronizar novamente os dados da “inteligência” com a borda?
Outro ponto ausente é, em especial, a falta de comunicação com clientes enterprise. Fora a página de status, o suporte da Cloudflare ficou basicamente em silêncio e, mesmo que na prática não houvesse muito a ser feito, ainda assim era necessário ao menos tentar se comunicar
Ainda mais depois de culpar a Flexential pela falta de comunicação na análise pós-incidente; eu gosto dos produtos da Cloudflare, mas acho que deveriam tirar mais conclusões deste episódio
Ainda assim, chamar isso de análise pós-incidente fica um pouco deslocado. Uma análise pós-incidente completa precisaria do nível de detalhe mencionado acima
Se o logging cai, exatamente quais serviços falham? Isso foi criado assim sem intenção? Por que ninguém percebeu?
É bom ver que a análise pós-incidente da Cloudflare foi minuciosa
A explicação honesta e transparente é revigorante em comparação com a estratégia de comunicação vaga de quase todas as outras empresas
Também fomos afetados, mas textos assim acabam me fazendo querer menos sair deles. Todo mundo comete erros e pode ter dias ruins; o que faz diferença é como se reage depois
A falha de energia cabia em um parágrafo; depois disso, o foco deveria ter passado para o lado da Cloudflare. Falhas em data center podem acontecer
O verdadeiro aprendizado está na resposta da Cloudflare, que não considerou nem recuperou adequadamente essa situação
Dependemos muito do CloudFlare Images, e ele ficou fora do ar por mais de 67 horas nos últimos 30 dias
Foram 22 horas em 9 de outubro, 42 horas de 2 a 4 de novembro, além de interrupções de cerca de 1 hora no meio do caminho, e a disponibilidade no último mês foi de 90,6%
Transparência é um ótimo diferencial entre fornecedores que competem na faixa de 99,9% de disponibilidade, mas perde muito o valor quando mal se passa de um único 9
Isso não ajuda muito a melhorar o comportamento e pode até piorar os incentivos
Valorizo o fato de quererem corrigir os erros de processo aqui. Só que existe uma tensão entre agir rápido e agir com segurança
Normalmente essas coisas são tratadas como clima, geridas como quem compra capa de chuva depois de já ter se molhado
Fico curioso sobre como tornar a confiabilidade parte da cultura sem amarrar o desenvolvimento ao processo. Dá para modelar sistemas em software e validar esse modelo com análise de tráfego. Se for possível reduzir o custo de experimentos de confiabilidade com testes virtuais, talvez dê para detectar mais coisas antes do lançamento
É estranho que, depois de ler isso, eu tenha acabado confiando menos na Cloudflare
O texto pressiona bastante na ideia de que a Flexential agiu de forma pouco profissional, e isso pode até ser verdade
Mas o fato de todo o sistema do qual as pessoas dependem ter caído mostra uma enorme falha de redundância do lado da Cloudflare. Um data center desses deveria poder desaparecer sem derrubar o serviço
É especialmente preocupante que o desenho pretendido comece com “o plano de controle e o sistema de analytics da Cloudflare rodam principalmente em servidores de três data centers perto de Hillsboro, Oregon”
Para um plano de controle usado no mundo todo, seria necessária uma distribuição geográfica muito maior. O mais surpreendente é que isso parece ser uma etapa do projeto intencional, não uma implementação defeituosa
Se vão lançar um produto novo para consumidores, o desenho de redundância não deveria ser prioridade máxima? O fato de isso ser opcional já é surpreendente
Eu também uso Cloudflare em alguns sistemas, porque confiava que haveria um excelente failover mesmo em incidentes assim. Agora fico repensando se o Cloudflare Workers está realmente seguro dessas decisões de projeto
O fato de, ao ativar o site de recuperação de desastres, o serviço ter sido sobrecarregado por chamadas de API que vinham falhando, para mim também mostra que o desenho central da Cloudflare não tinha redundância suficiente
Fiquei decepcionado com a tentativa deste texto de jogar a culpa na Flexential. Como cliente, eu esperaria que, mesmo que a Flexential desaparecesse amanhã em um terremoto, a Cloudflare lidasse com isso de forma elegante
É uma boa ideia colocar todo um cluster tão importante em uma área conhecida de risco sísmico e de tsunami?
Nem a recuperação de desastres na Europa parece ter funcionado direito
A frase “nunca havíamos testado desligar completamente toda a instalação PDX-04” é uma lição dura
Mas, se você não desliga fisicamente a energia do data center ou ao menos corta a rede dele com o mundo externo, não testou um desastre real de verdade
Dá para culpar a operadora da instalação, mas no fim a recuperação precisa ser possível mesmo se um data center inteiro ficar totalmente offline e nunca mais voltar
Um desastre natural pode apagar aquela instalação do mapa
Gostei da parte que diz: “Como a equipe foi mobilizada por completo e ficou o dia inteiro em resposta de emergência, decidiu-se que a maioria descansaria e começaria de manhã o processo de retorno ao PDX-04. Acreditamos que essa decisão atrasou a recuperação completa, mas reduziu a chance de acumular mais erros”
Fadiga humana costuma ser subestimada nesses relatórios. Quando se tenta corrigir um grande incidente em estado de exaustão, só aumentam os erros evitáveis
Não sei como isso funciona em uma organização do porte da Cloudflare, mas nós também temos um plano para grandes incidentes em que os funcionários se revezam entre trabalhar e dormir
O problema é que você precisa de um jeito de passar o estado atual do incidente para o pessoal novo que acorda ou entra no sistema
Como dizia Mike Tyson, todo mundo tem um plano até levar um soco na cara
A estrutura do texto é bem surpreendente. Uns 75% do blog falam de um terceiro, e os esforços de recuperação da própria Cloudflare ficam em bem menos parágrafos
É positivo que tenham indicado um caminho adiante, mas fico me perguntando por que, em vez disso, não admitiram por enquanto apenas a falha e a situação, para depois, quando a poeira baixasse, publicar uma análise pós-incidente completa e sem especulação
Investidores podem ler isto ou só um resumo e tratar como um simples problema de fornecedor, em vez de um problema profundo que exigirá meses de retrabalho e milhões de dólares em custos
O documento é ruim
Havia uma configuração de alta disponibilidade com três data centers, e ela falhou completamente
Por que encher o começo do documento culpando a operadora do data center? A gestão da infraestrutura física do data center está fora do controle da Cloudflare
A Cloudflare apostou que não haveria problema em não testar adequadamente a configuração de alta disponibilidade que ela própria controla
Os problemas operacionais do data center devem ser discutidos com a operadora, mas isso é assunto entre as duas partes, não algo que deveria entrar nesta análise pós-incidente
Enterraram a parte importante bem no fundo. Tem que rolar bastante para chegar numa frase como esta
“Alguns serviços que deveriam estar em um cluster de alta disponibilidade dependiam de serviços executados apenas no PDX-04”
Esse é exatamente o ponto principal
Se você vai criar um site de “desastre”, parece que precisa encontrar algum jeito de testá-lo
Quando o serviço voltou, surgiu um problema de manada trovejante de chamadas de API que vinham falhando e de repente dispararam, e dizem que implementaram limitação de taxa para controlar o volume de requisições
Mas isso parece ter ficado de fora dos itens no fim do texto
Agora o que me deixa curioso é como se projeta um failover a frio quando o sistema é complexo o bastante para causar falhas metaestáveis[1] e não há folga para testar com tráfego real
Dá para imaginar as técnicas usadas na implementação, mas o problema é o projeto e os testes para confirmar que essas técnicas funcionam em situação real
Outra coisa que parece ter ficado totalmente de fora é que a falha começou em 2 de novembro às 11:43 UTC, mas a decisão de mudar para o site europeu de recuperação de desastre só veio às 13:40 UTC
Por que demorou tanto para tomar essa decisão? Entendo que não seja uma decisão leve, mas mesmo que durante boa parte do tempo esperassem que a energia voltasse logo, 2 horas parece hesitação demais
Seja qual for o compromisso assumido, deveria haver um critério prévio para apertar o interruptor. Esse critério estava mesmo tão distante assim?
[1] http://charap.co/metastable-failures-in-distributed-systems/
Muitas vezes, o que provoca a falha é o próprio sistema redundante