Resumo
- A interrupção começou em 24 de julho às 16:04 UTC; a explicação detalhada foi adicionada em 29 de julho às 02:36:25 UTC.
- Em uma das três zonas físicas, uma gaiola perdeu os links entre seus switches spine e a camada de agregação.
- Os caminhos ativos restantes saturaram após a perda de 25% da capacidade de interconexão disponível.
- Falharam 10% dos jobs de Actions; 5% começaram atrasados; 27% das interações em Issues ficaram lentas ou expiraram; Copilot e git push tiveram 4% de impacto cada.
- A GitHub desviou conexões para fibras de expansão futura, eliminou a perda de pacotes às 17:07, restaurou todos os caminhos às 17:36 e acelerará a mudança de 100 para 400 Gbps.
O dado central não é um percentual geral de indisponibilidade. Cada número mede uma ação diferente. O valor do relatório está em mostrar como uma restrição comum de capacidade atravessou produtos com filas, tentativas e efeitos externos próprios.
A novidade de 29 de julho foi a evidência
O incidente ocorreu e foi encerrado no dia 24. Cinco dias depois, a GitHub atualizou o mesmo registro com a camada topológica, a parcela de capacidade perdida, as taxas por serviço, o desvio emergencial e o plano de infraestrutura.
Chamar isso de nova queda em 29 de julho criaria uma recorrência inexistente. Também seria incorreto combiná-la com avisos dos dias 25 ou 27. O identificador oficial yjysg0xrl67m mantém a cronologia separada.
Há ainda uma incerteza importante. A GitHub descreve a perda de conectividade e a saturação consequente, mas não informa qual dispositivo, manutenção ou mudança iniciou a perda. O mecanismo de propagação está explicado; o primeiro gatilho, não.
Uma gaiola afetou produtos com semânticas diferentes
Cada gaiola usa uma malha leaf-spine ligada à agregação da zona. Quando os links de uma gaiola desapareceram, workloads dependentes daquela computação sofreram perda intermitente de pacotes. A redução correspondeu a 25% da capacidade de interconexão disponível.
Em Actions, 10% dos jobs falharam e 5% tiveram início tardio, embora tenham terminado. Em Issues, 27% das interações ficaram lentas ou deram timeout. Copilot teve erros em 4% das requisições, com repetição automática na maioria. Quatro por cento dos pushes foram afetados. A autenticação ganhou latência, mas manteve erros abaixo de 1%.
Somar esses percentuais seria fabricar um indicador. Eles têm denominadores distintos. Devem orientar verificações distintas: jobs a conciliar, mutações a confirmar, pushes a comparar e latência a medir.
A recuperação consumiu uma reserva para o futuro
A GitHub redirecionou as conexões para fibras reservadas a futuras expansões. Às 17:07 havia capacidade suficiente para acabar com a perda de pacotes; às 17:16 a maioria dos serviços indicava recuperação completa; às 17:36 todos os caminhos estavam restaurados.
Os três horários não são redundantes. A margem de rede voltou antes da maior parte das aplicações, e a recuperação da maioria ocorreu antes da recomposição total da topologia. Um único horário verde esconderia essas etapas.
A fibra de expansão funcionou como contingência. O registro não revela quanta folga restou durante o desvio nem quando o recurso voltou a ficar disponível para outra emergência.
Repetir tudo pode gerar uma segunda inconsistência
A documentação da GitHub permite repetir um workflow, apenas jobs que falharam ou um job específico. A repetição conserva privilégios do ator original, commit SHA e Git ref. Isso preserva o contexto, mas não transforma deploy, publicação ou migração em ação idempotente.
Um job atrasado pode ter terminado depois que uma execução nova começou. Um push com resposta interrompida pode já ter avançado a referência remota. Uma edição de Issue que expirou no cliente pode ter sido persistida. A primeira ação correta é ler o estado real, não reenviar a escrita.
As tentativas automáticas do Copilot podem esconder falha na primeira chamada. Erros de autenticação abaixo de 1% também não eliminam o impacto da latência. Cada classe precisa de um critério de encerramento próprio.
Quatrocentos gigabits respondem à saturação, não a todas as perguntas
Gaiolas antigas usam interfaces de 100 Gbps. A GitHub diz que acelerará a migração planejada para 400 Gbps, aumentando banda em todas as camadas quando um caminho ou equipamento for perdido. A medida conversa diretamente com a saturação observada.
Ainda não há prazo, quantidade de gaiolas antigas, margem mínima ou combinação de falhas que o desenho deverá suportar. Quadruplicar a taxa nominal não garante, sozinho, quatro vezes a resiliência. Detecção, isolamento e disponibilidade das ferramentas de incidente também importam.
O teste relevante acontece sob falha definida: perder um caminho entre gaiola e agregação sem saturar os sobreviventes, mantendo observabilidade e alertando antes do usuário.
Fechar o inventário físico e o transacional
Clientes podem preservar IDs de workflows, conferir referências Git remotas, procurar mutações duplicadas em Issues e distinguir a primeira tentativa do sucesso após retry. Recuperação segura reconcilia efeitos antes de repetir operações.
Um próximo documento da GitHub deveria informar o gatilho inicial, a folga depois do desvio, o cronograma de 400 Gbps e os controles que evitam saturação do restante. Também deveria dizer se a fibra de expansão voltou à condição de reserva.
A atualização de 29 de julho transforma dependência de nuvem em capacidade mensurável: um quarto da interconexão sumiu, os caminhos sobreviventes encheram e cada produto deixou uma fila diferente para o operador limpar.
