A GitHub revelou que a interrupção que afetou sua plataforma em 17 de agosto e durou 7 horas e 47 minutos foi causada pela falha de um componente crítico de infraestrutura em acompanhar a expansão do tráfego, que atingiu um nível recorde dentro de seu centro de dados na região central dos Estados Unidos. A pressão resultante sobre a capacidade fez com que os problemas se espalhassem por vários sistemas, afetando o github.com, a autenticação, o GitHub Actions, as APIs, as solicitações de pull e as issues, além do Copilot, enquanto o impacto da interrupção alcançou desenvolvedores e organizações em todo o mundo.
O incidente representa o segundo grande evento enfrentado pela GitHub durante agosto, após uma falha que afetou o Actions em 6 de agosto. A empresa explicou que a investigação não encontrou relação entre nenhum dos dois incidentes e uma alteração no código ou nas configurações; o ponto central de ambos foi uma insuficiência de capacidade, já que componentes essenciais não foram ampliados antes que a demanda ultrapassasse sua capacidade. O número de operações de push mensais, segundo a GitHub, aumentou de 1,4 bilhão em abril para 2,9 bilhões desde então, mas a empresa reconheceu que o crescimento do uso não a isenta da responsabilidade de evitar interrupções.
Como os serviços se recuperaram?
O processo de recuperação exigiu o redirecionamento do tráfego, o isolamento da infraestrutura afetada e a restauração dos serviços em etapas. A maioria dos serviços da GitHub voltou a funcionar no mesmo dia, mas alguns serviços do Copilot levaram mais tempo. Erros nesses serviços provocaram um ciclo de novas tentativas por parte do cliente, o que aumentou o tráfego durante a recuperação e obrigou as equipes a limitar esse comportamento antes de redirecionar o tráfego com segurança.
A GitHub afirma que o relatório completo de análise da causa raiz inclui uma linha do tempo técnica detalhada, enquanto a empresa continua cumprindo os compromissos anunciados anteriormente para melhorar a disponibilidade e a confiabilidade.
O que muda na prática?
O plano da GitHub concentra-se no aumento da capacidade, na elevação da eficiência e na eliminação de gargalos arquiteturais. A empresa anunciou que adicionou mais de 3 milhões de núcleos de CPU e 120 petabytes de armazenamento de alta velocidade, além de capacidade de rede adicional. Também instalou o máximo possível de hardware dentro da energia disponível em seus centros de dados atuais, paralelamente à aceleração de sua migração para o Azure.
Atualmente, o Azure opera cerca de 58% da carga da plataforma da GitHub e metade das operações do Git, em comparação com 12% da carga da plataforma em maio. Essa expansão também ajudou a sustentar o crescimento das operações de execução de tarefas do GitHub Actions. A empresa está trabalhando em uma nova arquitetura para ampliar linearmente a capacidade de leitura em repositórios enormes conforme o número de leitores, permitindo, teoricamente, operações de leitura ilimitadas; sua implementação começará gradualmente nos maiores monorrepositórios.
Reduzir o alcance das falhas e evitar tempestades
A GitHub não considera que a expansão, por si só, seja suficiente; a empresa direcionou equipes e recursos adicionais para a disponibilidade e investiu em testes mais robustos, processos de implementação mais seguros, monitoramento aprimorado e alertas mais eficazes. Também está isolando sistemas críticos e removendo as dependências compartilhadas entre eles para reduzir a probabilidade de uma interrupção e limitar seu impacto caso ela ocorra.
Com base nos incidentes de 6 e 17 de agosto, a empresa aplicará limites e orçamentos uniformes para novas tentativas, além de tempos limite variáveis nas comunicações entre serviços, com o objetivo de evitar tempestades de novas tentativas e cargas em cascata. Ela também está revisando alertas de CPU e memória de baixa prioridade para detectar componentes que possam falhar durante aumentos repentinos no tráfego. Essas medidas são diretamente importantes para desenvolvedores e organizações que dependem da GitHub para criar, entregar e operar software, pois a recuperação da plataforma não depende apenas da restauração do serviço, mas também de evitar a repetição da falha e limitar seu alcance quando ela ocorrer.