Datadog (2023): como um patch de segurança do systemd derrubou 5 regiões simultaneamente

Na manhã de 8 de março de 2023, o Datadog começou a receber alertas de degradação severa em múltiplos produtos — ingestão de métricas, logs, APM e sintéticos. A característica mais perturbadora do incidente não era a falha em si, mas sua simultaneidade: cinco regiões de produção independentes começaram a apresentar problemas ao mesmo tempo, o que imediatamente descartou hipóteses de falha localizada e apontou para uma causa comum transversal.

A investigação revelou que o Ubuntu, sistema operacional dos nós de computação, havia aplicado automaticamente uma atualização de segurança para o pacote systemd. Especificamente, a atualização afetava o systemd-networkd, o daemon responsável pelo gerenciamento de interfaces de rede no nível do sistema operacional. Ao ser atualizado, o systemd-networkd foi reiniciado — comportamento esperado e documentado para aplicação de patches de segurança em componentes de rede.

O problema crítico estava na interação entre essa reinicialização e o Cilium, o CNI plugin (Container Network Interface) usado pelo Datadog para gerenciar a rede dos pods Kubernetes. O Cilium opera no espaço de kernel via eBPF e mantém estado de conectividade que depende de interfaces de rede estáveis. Quando o systemd-networkd reiniciou e reconfigurou as interfaces, o Cilium perdeu o estado de conectividade dos pods — efetivamente cortando a comunicação entre workloads em execução, sem que os pods em si tivessem sido reiniciados ou reportado falha.

O resultado foi uma falha silenciosa e difusa: pods rodando, nós aparentemente saudáveis, mas sem capacidade de se comunicar. Pipelines de ingestão pararam de receber dados. Serviços internos de controle perderam conectividade entre si. O plano de controle do Kubernetes continuava funcionando, mas o plano de dados estava efetivamente partido.

A remediação imediata envolveu três frentes paralelas. Primeiro, a equipe bloqueou novos auto-updates em todos os nós remanescentes para evitar que o problema se espalhasse para nós que ainda não haviam sido afetados. Segundo, iniciou-se o processo de recuperação dos nós já afetados: em alguns casos, reiniciar o agente Cilium era suficiente para restaurar a conectividade após o systemd-networkd ter se estabilizado; em outros, os nós precisaram ser drenados e substituídos via rolling replacement, o que é um processo inerentemente lento quando se fala em dezenas de milhares de nós.

A escala foi o principal obstáculo à recuperação rápida. Em um incidente localizado — digamos, uma única região com centenas de nós — o procedimento de drain e replace seria concluído em minutos. Com dezenas de milhares de nós distribuídos em cinco regiões, o mesmo procedimento levou horas. Isso ilustra um ponto importante: o blast radius de uma mudança não afeta apenas a severidade do impacto inicial, mas também o tempo de recuperação. Quanto maior o raio de explosão, mais lenta e custosa é a remediação.

No médio prazo, o Datadog implementou um conjunto de controles estruturais. O auto-update irrestrito foi substituído por um pipeline de atualização de SO gerenciado, com rollout progressivo por região e observação de métricas de saúde entre cada etapa. A interação entre systemd-networkd e Cilium foi documentada e adicionada aos critérios de validação de patches de SO. Testes de compatibilidade entre atualizações de sistema operacional e o CNI plugin passaram a ser executados em ambiente de staging antes de qualquer rollout para produção. Adicionalmente, foram implementados mecanismos de detecção mais rápida de falhas de conectividade de rede em nível de nó — especificamente para capturar o padrão de 'pod running, node Ready, mas sem conectividade', que é um falso positivo do ponto de vista do kubelet.

Um dos princípios fundamentais de resiliência em sistemas distribuídos é o isolamento de domínios de falha. Regiões geográficas distintas existem exatamente para que uma falha em uma não se propague para as demais. O Datadog, como empresa de observabilidade, certamente tinha esse princípio incorporado na arquitetura de seus produtos. O problema foi que o pipeline de atualização de infraestrutura não respeitava esses mesmos limites.

Isso revela uma assimetria comum em organizações de engenharia maduras: investe-se muito em isolamento de falhas no plano de aplicação — circuit breakers, bulkheads, retry com backoff, multi-region deployments — mas o plano de infraestrutura subjacente pode ter acoplamentos globais que não são tratados com o mesmo rigor. O unattended-upgrades não sabia que estava operando em um sistema multi-região com requisitos de blast radius. Era apenas um daemon de sistema fazendo seu trabalho.

A lição aqui é que qualquer mecanismo que possa modificar estado em múltiplos nós de produção precisa ser tratado como um deployment, com todas as garantias que isso implica: canary release, progressive rollout, health gates entre etapas, e capacidade de rollback. Isso vale para patches de SO, atualizações de agentes, mudanças de configuração via Ansible/Chef/Puppet, e qualquer outra forma de mudança de infraestrutura em escala. A distinção entre 'mudança de aplicação' e 'mudança de infraestrutura' é operacional, não arquitetural — do ponto de vista do risco, ambas precisam dos mesmos controles.

Há também um aspecto de observabilidade do próprio processo de mudança que merece atenção. O Datadog é uma empresa de observabilidade — seus produtos são usados por outras empresas para detectar exatamente esse tipo de problema. A ironia do incidente é que a detecção da causa raiz levou tempo porque o próprio sistema de monitoramento estava parcialmente degradado pela falha. Isso reforça a importância de ter observabilidade out-of-band — mecanismos de monitoramento que não dependem da infraestrutura que estão monitorando.