Resumo

  • O GitHub afirma que o incidente de 17 de agosto durou 7 horas e 47 minutos. Erros na web e na API chegaram a cerca de 20%; downloads de arquivos e conteúdo bruto alcançaram aproximadamente 50%. Issues, pull requests, Actions, identidade corporativa e Copilot foram afetados.
  • Um sidecar Istio atingiu seu limite de concorrência sem acionar a expansão correta. Quatro nós HAProxy esgotaram a capacidade de fluxos, e as retentativas elevaram o Copilot Token Service de 7 mil–9 mil para 70 mil–100 mil requisições por segundo.

O GitHub conseguiu atender na Northern Virginia parte do tráfego que falhava na Central US. Ainda assim, o tráfego que chegava ao destino de contingência não permanecia constante: respostas lentas geravam novas tentativas.

Na atualização detalhada do incidente zkxwbgr0cnmx, a empresa delimita o impacto entre 13h28 e 21h15 UTC de 17 de agosto. Issues, pull requests, APIs, Actions e Copilot registraram erros ou latência. No pico, a taxa de falhas ficou perto de 20% para web e API e de 50% para downloads de arquivos e conteúdo bruto de repositórios.

O alcance incluiu controles corporativos. O GitHub cita autenticação SAML e OIDC, SCIM e Team Sync. Workflows do Actions em GitHub Enterprise Cloud com residência de dados também foram afetados quando dependiam de definições públicas de etapas hospedadas no GitHub.com. Isso não demonstra saída de dados da região escolhida nem quebra de uma obrigação de armazenamento. O registro identifica uma dependência de execução entre superfícies do serviço.

Segundo o GitHub, a causa imediata foi a saturação da rede nos balanceadores de carga da Central US diante de um novo pico de tráfego. Um pod sidecar Istio chegou ao limite de concorrência. A política de autoscaling observava o serviço hospedeiro, mas não o limite do sidecar; por isso, a capacidade não cresceu no componente realmente restringido.

A falha se propagou até quatro nós HAProxy esgotarem seus limites de fluxo. A rota de autenticação do gateway perdeu capacidade, espalhando latência e falhas de login. O GitHub relata que pausar o HAProxy ao mesmo tempo nesses nós produziu uma recuperação ampla e imediata.

Parte das solicitações foi deslocada para Northern Virginia e atendida com sucesso enquanto a equipe investigava a Central US. A maioria dos serviços se recuperou por volta de 16h36 UTC. O Actions permaneceu degradado até aproximadamente 18h03.

O Copilot demorou mais porque uma resposta tardia podia criar várias outras. A demora em um único endpoint interno acionou um bug latente de retentativa no VS Code. Uma operação de token malsucedida gerava pedidos adicionais e podia entrar em loop. O volume do Copilot Token Service subiu das habituais 7 mil–9 mil requisições por segundo para 70 mil–100 mil.

Para estabilizar o serviço, o GitHub reduziu temporariamente as retentativas do gateway e passou a responder com HTTP 403 a determinadas solicitações de token nos balanceadores. Depois reintroduziu o tráfego gradualmente, site por site. O Token Service se recuperou por completo perto de 21h02 UTC; o registro foi encerrado às 21h15.

Ataques de scraping contra endpoints de codeload dificultaram o trabalho, segundo a empresa. O comunicado não quantifica sua participação na saturação e não os apresenta como gatilho original. A sequência divulgada começa no limite do sidecar, passa pela política de expansão incompleta e pelo esgotamento de fluxos HAProxy, e termina na amplificação pelas retentativas.

A documentação oficial ajuda a localizar as dependências. Configurações reutilizáveis de workflow podem chamar definições mantidas em repositórios públicos. A referência de runners hospedados lista GitHub.com, API, domínios do Actions e codeload.github.com entre os destinos necessários à execução e ao download de actions.

Identidade também é parte do caminho crítico. O GitHub documenta SAML SSO e SCIM como mecanismos centrais de acesso e ciclo de vida de contas. A apresentação do Enterprise Cloud com residência de dados descreve subdomínios GHE.com dedicados e opções regionais. Local de armazenamento, autenticação e obtenção de componentes de workflow são dimensões relacionadas, mas não idênticas.

O plano de prevenção do GitHub inclui autoscaling que considere a concorrência dos sidecars, auditoria de limites do Istio, revisão de retentativas e backoff nos gateways e clientes, correção do comportamento do VS Code, monitoramento mais forte dos balanceadores e salvaguardas de failover regional. São compromissos anunciados. O registro ainda não comprova sua implantação nem seu efeito.

Clientes podem testar a recuperação em trilhas separadas: leitura de repositório, API, SSO, mudança de equipe, download de definição pública, início de runner e emissão de token do Copilot. A volta do site principal não prova que todas essas operações retornaram na mesma ordem.

As boas práticas da API REST orientam integrações a respeitar Retry-After, o horário de reset do limite e esperas progressivamente maiores após falhas repetidas. O texto não descreve o código interno do incidente, mas exprime a mesma disciplina: retentar sem orçamento transforma atraso em carga nova.

Fonte