GitHub segue sofrendo danos colaterais do boom de IA

O incidente de 13 de setembro

Lorin Hochstein analisa o relatório de incidente do GitHub ocorrido em 13 de setembro, notando que a empresa segue sofrendo danos colaterais do boom de IA: mais desenvolvedores usando IA significam mais carga sobre seus sistemas - e o foco em desenvolvedores faz com que a empresa publique detalhes técnicos úteis.

O relatório oficial, intitulado genericamente "Incident with several GitHub Services", explica que um trabalho interno de limpeza de dados começou a escrever, às 07:33 UTC, em um cluster de banco de dados compartilhado que armazena dados de permissão lidos em quase toda requisição autenticada. O mecanismo de segurança que controlava a velocidade do trabalho acompanhava apenas um sinal de saúde - o atraso das réplicas (replica lag) - que permaneceu baixo o tempo todo. O mecanismo não considerava a carga acumulando no nó primário, que seguiu silenciosamente em direção ao seu limite.

Quando o primário esgotou as conexões disponíveis, as chamadas ao banco não tinham timeout rápido: os handlers de requisição ficaram esperando em vez de falhar rápido, e requisições bloqueadas se acumularam até saturar os servidores web, degradando a capacidade compartilhada em erros no site inteiro. Um loop de retentativas na criação de tokens reenviava escritas que já falhavam, mantendo o banco saturado e dificultando a recuperação. O monitoramento declarou o incidente às 08:50 UTC; os respondentes mitigaram descartando carga interna e pausando o trabalho, com recuperação total às 10:44 UTC. Hochstein levanta questões técnicas sem resposta, como o papel de pools de conexão e quão próximo do limite o banco estava antes do trabalho começar.

Falha cinzenta e fronteira de segurança

O autor classifica o caso como um exemplo de gray failure: os sistemas internos de monitoramento indicavam incorretamente que tudo estava saudável - as métricas estavam boas, mas os usuários estavam insatisfeitos. Em termos de engenharia de resiliência, o sistema julgou mal a localização da fronteira de segurança. Como nunca se sabe de fato onde essa fronteira está até cruzá-la - e cruzá-la é muito ruim -, é preciso estimá-la e manter distância, mas há tantos limites no sistema que a chance de não monitorar todos é, tragicamente, alta.

Hochstein observa também que, embora o ideal fosse não rodar jobs offline contra bancos online, às vezes não há alternativa: o objetivo do trabalho era justamente modificar os dados online. E note um padrão recorrente em incidentes: limpeza é risco dos dois lados - limpar algo ainda em uso pode causar incidentes, mas a ausência de limpeza também pode, quando elementos não usados interagem inesperadamente. É tudo tradeoff de risco.

Timeouts, retentativas e resposta

Há uma assimetria nos problemas de timeout: timeouts curtos demais se manifestam na operação normal e são corrigidos; os longos demais são difíceis de detectar e frequentemente só aparecem durante um incidente, ao aumentar requisições em voo e esgotar recursos. O autor adverte: seu sistema provavelmente tem timeouts longos demais que ninguém notou ainda.

Retentativas seguem lógica parecida: são essenciais para mascarar falhas transitórias, mas aumentam a carga e podem piorar cenários de saturação - o caso da criação de tokens ilustra o padrão que a indústria chama de retry storm.

Na resposta a incidentes, a prioridade é devolver o sistema ao estado saudável. Em falhas de saturação, frequentemente se identifica qual serviço sobrecarregou (muitas vezes um banco), mas não a causa. Por isso os respondentes precisam de ferramentas para identificar rapidamente fontes de carga e descartá-las manualmente - ferramentas que precisam existir antes do incidente. "Seus sistemas eventualmente ficarão sobrecarregados", adverte Hochstein; a hora de se preparar é agora.

As correções e o custo em complexidade

Para prevenir recorrência, o GitHub planeja limitar por padrão jobs em segundo plano contra bancos compartilhados que atendem clientes, adicionar pausa automática e paging baseados na carga do primário (não apenas no lag de replicação), exibir trabalhos em segundo plano junto aos sinais de saúde do banco, limitar retentativas no caminho de emissão de tokens, adicionar timeouts por requisição e fragmentar o cluster para eliminar o ponto único de falha, movendo dados específicos de serviços - incluindo os de autorização - nas duas semanas seguintes.

Hochstein considera as intervenções boas, mas ressalva: todas aumentam a complexidade. Como ele já argumentou antes, aumentar complexidade para melhorar confiabilidade é inevitável - elimina-se modos de falha conhecidos ao custo de introduzir modos de falha novos.