Pular para o conteúdo

Incidente · Sênior

Datadog mar/2023: update automático do systemd apaga rotas

Incidente real. Pontos centrais: deploy progressivo.

14 min de leitura · Incidente em 2023-03, durou · Fonte: Datadog · Conteúdo revisado em 23 de outubro de 2026

Resposta curta

Incidente real. Pontos centrais: deploy progressivo. Em 8 de março de 2023, a Datadog teve uma queda que afetou todos os serviços em várias regiões. O post de engenharia da empresa é a fonte deste caso. Ele conclui que um comportamento novo do systemd no Ubuntu 22.04 desconectou da rede mais de 60% das instâncias.

01 · CONTEXTO

Regiões isoladas e mudanças em sequência

Em 8 de março de 2023, a Datadog teve uma queda que afetou todos os serviços em várias regiões. O post de engenharia da empresa é a fonte deste caso. Ele conclui que um comportamento novo do systemd no Ubuntu 22.04 desconectou da rede mais de 60% das instâncias.

A empresa considerava esse tipo de queda rara: as regiões não têm conexões diretas entre si e as mudanças saem uma região por vez. A troca de nós segue um processo gradual, orquestrado entre regiões e clusters, com a mudança em observação de uma semana a um mês entre as etapas.

  1. A troca de nós é orquestrada para avançar progressivamente entre regiões e clusters.

    Diagrama da arquitetura: Dois caminhos de mudança nos nós
    CPTroca gradual de nós
    DBRepositório de pacotes do Ubuntu
    CPNós da região Atroca gradual
    CPNós da região B
  2. Entre as etapas, a mudança fica em observação para evitar uma regressão.

    Diagrama da arquitetura: Dois caminhos de mudança nos nós
    CPTroca gradual de nós
    DBRepositório de pacotes do Ubuntu
    CPNós da região A
    CPNós da região B
  3. Os servidores também usavam o padrão do Ubuntu para atualizações automáticas, e todos os hosts rodavam essa atualização na mesma janela diária.

    Diagrama da arquitetura: Dois caminhos de mudança nos nós
    CPTroca gradual de nós
    DBRepositório de pacotes do Ubuntuatualização automática
    CPNós da região A
    CPNós da região B

02 · A REDE DOS PODS

Pods com IPs da nuvem dependem de regras no host

Os pods recebiam IPs da própria rede da nuvem (VPC), e o Cilium gerenciava a rede deles. O agente do Cilium em cada nó cuida de rotas e regras, porque os pods precisam interagir com o ambiente por regras de roteamento do host para falar com o resto da rede.

  1. O pod recebe um IP da própria rede da nuvem (VPC).

    Diagrama da arquitetura: Rede dos pods e regras de roteamento do host
    CPPod
    CPAgente Cilium
    CPRegras de roteamento do nó
    NWRede da nuvem (VPC)
  2. O agente do Cilium em cada nó mantém as rotas e regras do host.

    Diagrama da arquitetura: Rede dos pods e regras de roteamento do host
    CPPod
    CPAgente Cilium
    CPRegras de roteamento do nó
    NWRede da nuvem (VPC)
  3. Para falar com o resto da rede, o pod depende das regras de roteamento do host.

    Diagrama da arquitetura: Rede dos pods e regras de roteamento do host
    CPPod
    CPAgente Cilium
    CPRegras de roteamento do nóregras do host
    NWRede da nuvem (VPC)

03 · O GATILHO

Uma atualização de segurança que apaga regras

O systemd-networkd, componente do systemd que gerencia a configuração de rede dos hosts, apaga todas as regras de IP que não conhece quando inicia. Quando um patch do systemd é instalado, todos os componentes dele são reiniciados, incluindo o systemd-networkd.

O Ubuntu 22.04 usa a versão 249 do systemd, com a configuração padrão que gerencia regras de roteamento externas. O comportamento de apagar regras só se manifesta quando o systemd-networkd inicia, o que na infraestrutura da empresa só acontecia na criação de um host novo, quando ainda não havia regras específicas.

Em 7 de março de 2023, um patch de CVE do systemd ficou disponível nos repositórios do Ubuntu, e os hosts rodavam o apt-upgrade todos os dias entre 06:00 e 07:00 UTC. O novo comportamento afeta só os nós com 22.04, que eram mais de 90% da frota em 8 de março.

  1. O patch do systemd é instalado e reinicia todos os componentes dele, inclusive o systemd-networkd.

    Diagrama da arquitetura: Reinício do systemd-networkd apaga as regras
    CPAtualização automática
    CPsystemd-networkdreiniciado
    CPRegras de roteamento do nó
    CPTráfego dos pods
    CPTráfego do próprio nó
  2. Ao iniciar, o systemd-networkd apaga as regras de IP que não conhece, e as regras do Cilium estão entre elas.

    Diagrama da arquitetura: Reinício do systemd-networkd apaga as regras
    CPAtualização automática
    CPsystemd-networkd
    CPRegras de roteamento do nóregras apagadas
    CPTráfego dos pods
    CPTráfego do próprio nó
  3. Na AWS e no Azure, sem as regras de origem, o tráfego dos pods deixa de usar a interface correta.

    Diagrama da arquitetura: Reinício do systemd-networkd apaga as regras
    CPAtualização automática
    CPsystemd-networkd
    CPRegras de roteamento do nó
    CPTráfego dos podssem conectividade
    CPTráfego do próprio nó
  4. Em todos os provedores, sem a regra local original, o tráfego para o IP do nó não é mais tratado como local e o nó perde a rede.

    Diagrama da arquitetura: Reinício do systemd-networkd apaga as regras
    CPAtualização automática
    CPsystemd-networkd
    CPRegras de roteamento do nó
    CPTráfego dos pods
    CPTráfego do próprio nósem conectividade
Pods (AWS e Azure)Nó (todos os provedores)
O que sumiuRegras de origem dos podsRegra local de menor prioridade, sem a original recriada
Efeito no tráfegoDeixou de usar a interface corretaDeixou de ser considerado local
ResultadoPods perderam conectividadeNó perdeu conectividade

04 · AS NUVENS REAGIRAM DIFERENTE

Reiniciar numa nuvem, substituir na outra

No Google Cloud e no Azure, instâncias que perdem conectividade continuam em execução sem rede. Esses provedores reparam instâncias com problema de hardware ou hipervisor, mas não, por padrão, as com problema no nível do sistema operacional convidado. Como a empresa não habilita verificações de saúde HTTP, nada foi substituído, e as instâncias foram recuperadas reiniciando-as pelas APIs.

Na AWS, a instância de um Auto Scaling group que falha nas verificações de status é encerrada e substituída, e a AWS detectou as instâncias como não saudáveis. Às 08:00 UTC, ela tinha substituído cerca de 60% das instâncias da região, dezenas de milhares.

A empresa depende muito de discos locais para armazenamentos de dados, coordenação e caches. Na AWS, as instâncias foram encerradas e todos os dados dos discos locais foram perdidos.

  1. No Google Cloud e no Azure, a instância segue ligada sem rede, ninguém a substitui e o disco local continua lá.

    Diagrama da arquitetura: Reação de cada nuvem a nós sem rede
    CPInstância Google Cloud ou Azureligada, sem rede
    DBDados no disco local (Google Cloud e Azure)preservado
    CPVerificação de status e Auto Scaling (AWS)
    CPInstância AWS
    DBDados no disco local (AWS)
  2. Na AWS, a verificação de status acusa a instância sem rede e o Auto Scaling a encerra e substitui.

    Diagrama da arquitetura: Reação de cada nuvem a nós sem rede
    CPInstância Google Cloud ou Azure
    DBDados no disco local (Google Cloud e Azure)
    CPVerificação de status e Auto Scaling (AWS)
    CPInstância AWSencerrada e substituída
    DBDados no disco local (AWS)
  3. Com a instância encerrada, o que estava no disco local some junto.

    Diagrama da arquitetura: Reação de cada nuvem a nós sem rede
    CPInstância Google Cloud ou Azure
    DBDados no disco local (Google Cloud e Azure)
    CPVerificação de status e Auto Scaling (AWS)
    CPInstância AWS
    DBDados no disco local (AWS)dados perdidos
  4. A situação que parecia melhor, a da AWS, era a mais difícil de recuperar.

    Diagrama da arquitetura: Reação de cada nuvem a nós sem rede
    CPInstância Google Cloud ou Azure
    DBDados no disco local (Google Cloud e Azure)reinício basta
    CPVerificação de status e Auto Scaling (AWS)
    CPInstância AWS
    DBDados no disco local (AWS)recuperação difícil
Google Cloud e AzureAWS
DetecçãoNão detectou falhaDetectou instâncias não saudáveis
ReaçãoNada foi substituídoInstâncias encerradas e substituídas
Dados em disco localRecuperados ao reiniciar a instânciaPerdidos junto com a instância

05 · LIÇÕES

O que o desenho precisa isolar

O post mostra dois caminhos de mudança nos nós: a troca gradual, orquestrada entre regiões e clusters, e a atualização automática do sistema operacional, que rodava em todos os hosts na mesma janela diária.

A conclusão do post é que o novo comportamento do systemd no Ubuntu 22.04 desconectou mais de 60% das instâncias, em várias regiões e provedores, e que a queda também afetou as regiões que hospedam as ferramentas de CI/CD e automação.

Perguntas frequentes

O que é Datadog mar/2023: update automático do systemd apaga rotas?

Incidente real. Pontos centrais: deploy progressivo.

O que o design de Datadog mar/2023: update automático do systemd apaga rotas cobre?

Ele está organizado nestas seções: Regiões isoladas e mudanças em sequência, Pods com IPs da nuvem dependem de regras no host, Uma atualização de segurança que apaga regras, Reiniciar numa nuvem, substituir na outra e O que o desenho precisa isolar.

Quanto tempo leva Datadog mar/2023: update automático do systemd apaga rotas e qual é o nível?

Leva cerca de 14 minutos para ler e tem nível Sênior.

Agora projete você mesmo

Rode este caso como uma entrevista na escola de System Design: você toma as decisões, o tutor as questiona e você vê a nota do seu desenho.