A falha do GitHub: a carga de commits duplicada

Sete Horas E Quarenta E Sete Minutos, Atribuídas A Um Proxy Sobrecarregado

O relatório do GitHub, publicado no seu blogue de engenharia sob o título 'The August 17 outage, and the work ahead', atribui a falha a um proxy sidecar Istio no centro de dados Central US que atingiu a sua capacidade máxima de processamento concorrente. A política de escalonamento automático que vigiava essa capacidade avaliava apenas o próprio serviço de aplicação, não o estado de ligação e concorrência dos sidecars colocados à sua frente, pelo que nada escalou quando os sidecars atingiram o seu limite. Uma vez saturados esses proxies, os pedidos deslocaram-se para outros nós, que por sua vez atingiram os seus próprios limites de capacidade, e a lógica de repetição automática do GitHub agravou a espiral ao enviar novos pedidos para balanceadores de carga já sobrecarregados. Uma falha de repetição separada, segundo a The Register alojada numa extensão do VS Code usada para a autenticação do GitHub Copilot, agravou ainda mais a falha: continuava a pedir novos tokens de autenticação sem pausa, levando o serviço de emissão de tokens do GitHub de uma base normal de 7000 a 9000 pedidos por segundo até 70000 a 100000 pedidos por segundo, cerca de dez vezes a carga habitual.

Os Números Por Trás De Uma Má Tarde

A falha estendeu-se de 17 de agosto de 2026, das 13:28 às 21:15 UTC, e as próprias atualizações de estado do GitHub situaram as taxas de erro máximas em cerca de 20 por cento no tráfego web e API e cerca de 50 por cento nas transferências de ficheiros e conteúdo em bruto, precisamente o tipo de pedido de que dependem um pipeline de compilação ou a obtenção de uma dependência. Issues, pull requests, APIs, Actions e Copilot ficaram todos degradados, tal como a autenticação SAML e OIDC, o SCIM e o Team Sync; a maioria dos serviços recuperou por volta das 16:36 UTC, o Actions por volta das 18:03 UTC, e o serviço de tokens do Copilot em último, às 21:02 UTC. O GitHub deixou claro que nem este incidente nem a falha menor do Actions de 6 de agosto foram causados por uma alteração de código ou de configuração; ambos foram, nas palavras da própria empresa, falhas de capacidade na sua essência, ou seja, o sistema ficou sem margem em vez de falhar devido a um erro lançado.

O Volume De Commits Quase Duplicou Em Quatro Meses

Escondido no mesmo relatório está o número que transforma esta história de uma falha numa história de infraestrutura: o GitHub afirma que o volume mensal de commits cresceu de 1,4 para 2,9 mil milhões desde abril de 2026, praticamente duplicado em cerca de quatro meses, acompanhado de gráficos que mostram os pull requests integrados a aproximarem-se dos 130 milhões por mês e os novos repositórios a aproximarem-se dos 24 milhões por mês. O GitHub já tinha assinalado a causa no seu relatório de disponibilidade de maio de 2026, onde reconheceu que a programação assistida por IA e os fluxos de trabalho agênticos estavam a acrescentar pressão à sua infraestrutura, e a Microsoft declarou publicamente que a IA já escreve até 30 por cento do código em alguns dos seus próprios repositórios, sujeito a revisão humana. Uma plataforma dimensionada para um mundo em que os commits chegavam ao ritmo da escrita humana absorve agora um padrão de carga ditado por agentes de codificação que estão sempre a escrever, ramificar e publicar, e a resposta do GitHub até agora tem sido acrescentar capacidade: mais de 3 milhões de núcleos de CPU e 120 petabytes de armazenamento de alta velocidade, com a Azure a suportar já cerca de 58 por cento da carga da plataforma, face aos 12 por cento de maio.

O GitHub Actions Registou Treze Incidentes Em Dezassete Dias

A Tech Times, ao analisar o histórico de incidentes e os dados de estado do GitHub, relatou que o GitHub Actions sozinho registou 13 incidentes distintos num período de 17 dias este agosto, e que a disponibilidade a 90 dias caiu de 99,39 por cento antes da falha de 17 de agosto para 99,33 por cento depois, uma descida de cerca de 13 horas de tempo de inatividade acumulado em três meses para cerca de 14,5 horas. Essa publicação descreveu o incidente de 17 de agosto como tendo consumido sozinho quase um ano inteiro de orçamento de inatividade permitida face a um objetivo de três noves. O relatório do GitHub conta de forma diferente e chama ao 17 de agosto o seu segundo incidente significativo do mês, depois da falha do Actions de 6 de agosto, uma contagem justa dos grandes apagões a nível de plataforma, mas que nada diz sobre as interrupções do Actions mais pequenas e frequentes que ficam por baixo. Ambas as contagens podem ser verdadeiras ao mesmo tempo, e juntas descrevem um problema de fiabilidade em dois níveis: o serviço central do Git aguenta-se melhor do que o pipeline de CI/CD construído sobre ele, e é precisamente esse pipeline que suporta a maior parte da nova carga do desenvolvimento assistido por IA.

Uma Plataforma, Cada Pipeline: O Risco De Concentração

Para uma empresa que faz passar todo o seu fluxo de trabalho de engenharia pelo GitHub, ou seja, controlo de versões, CI através do Actions, o seu registo de pacotes e o Copilot para geração de código, nada disso é ruído de fundo; é um único fornecedor colocado no caminho crítico de cada lançamento. Uma equipa de desenvolvimento europeia sente isto tal como uma equipa dos EUA durante a própria janela da falha, mas carrega com uma camada adicional de exposição: prazos de entrega contratuais, compromissos de nível de serviço perante clientes da UE e obrigações de notificação de incidentes ao abrigo de quadros como a NIS2 não param porque a falha teve origem num centro de dados dos EUA fora do controlo da equipa. Tratar 'o GitHub está em baixo' como ruído de fundo deixa de fazer sentido assim que os números subjacentes mostram porque aconteceu: uma infraestrutura construída para um mundo mais lento e ao ritmo humano absorve agora um padrão de carga que quase duplicou em quatro meses, numa plataforma que, por admissão própria, passou agosto a corrigir duas vezes a mesma categoria de falha de capacidade.

Como É Realmente A Redundância

Nada disto é um argumento para abandonar o GitHub, que continua a ser a opção padrão por boas razões, mas é um argumento concreto para tratar a dependência de um único fornecedor como um risco planeado e não como uma ideia tardia descoberta a meio de uma falha. Isso significa manter uma cópia espelhada dos repositórios críticos num segundo anfitrião ou num servidor Git alojado internamente, uma configuração alternativa de executor de CI capaz de assumir compilações quando o Actions está degradado e não só quando está totalmente em baixo, e uma cache local ou alojada internamente para as dependências de pacotes, para que uma falha do registo não pare cada compilação do pipeline. Nenhuma destas medidas precisa de estar sempre a funcionar; precisam de existir, ser testadas de vez em quando e estar bem documentadas o suficiente para que uma equipa sob pressão durante o próximo incidente não esteja a improvisar uma solução pela primeira vez enquanto o relógio de um prazo com um cliente continua a correr.

Leia a seguir: O Seu Segundo Alojador Git Ligou-se Sozinho  |  Irlanda cancela o contrato com a Microsoft