A GitHub revelou, em seu relatório de disponibilidade de setembro de 2026, dois incidentes que afetaram o desempenho de seus serviços, paralelamente ao progresso na redistribuição da infraestrutura e na melhoria da capacidade dos bancos de dados de suportar pressão. A empresa afirma que os trabalhos de correção ainda não foram concluídos, apesar da implementação de mudanças destinadas a reduzir os riscos de falhas quando a carga aumenta ou quando um componente compartilhado falha.
Até 7 de outubro, 120 dos 160 serviços de produção estavam publicados na região Central US, enquanto 13 dos 51 bancos de dados MySQL principais haviam sido transferidos. O Azure lidava com 65,4% do tráfego de leitura do aplicativo principal do GitHub, 48,3% do tráfego de leitura do Git e 80,2% do tráfego de processamento de fluxos. A empresa ressalta que essas porcentagens se referem a cargas diferentes e não devem ser somadas.
Progresso na transferência da infraestrutura, mas com atraso em relação ao cronograma
A GitHub interrompeu as implantações e o aumento do tráfego na Central US em 11 de setembro devido à disparidade de capacidade entre as zonas de disponibilidade. Os aumentos permanentes foram retomados em 18 de setembro após a disponibilização de capacidade temporária, mas os trabalhos de capacidade de longo prazo ainda estão em andamento, com a meta de disponibilizar toda a capacidade disponível até o fim de outubro. A empresa não atingiu sua meta ambiciosa de publicar todos os serviços de produção nessa região até 30 de setembro.
Durante uma conversão planejada de banco de dados, um procedimento automatizado de emergência desconectou as réplicas dos bancos de dados na Central US, causando impacto aos clientes da região. A GitHub desativou esse procedimento durante as entregas planejadas até que os mecanismos de recuperação fossem aprimorados.
Redução da pressão sobre os bancos de dados e contenção de falhas
A GitHub transferiu 24 tabelas do sistema principal de autenticação para fora de seu banco de dados compartilhado mais antigo, removendo cerca de um milhão de consultas por segundo das réplicas. Também foram excluídos cerca de 980 milhões de registros desnecessários do histórico de alterações no cluster que dá suporte a Issues e Pull Requests, liberando aproximadamente 1,8 terabytes de armazenamento recuperável. Os conflitos entre transações semanais diminuíram cerca de 77% em comparação com o pico de junho.
Metade do tráfego de Pull Requests incluído na amostra passou a conseguir continuar com funcionalidade limitada quando uma dependência compartilhada falha. O roteamento do tráfego dos bancos de dados também pode adicionar capacidade automaticamente durante picos; um dos grupos aumentou de 14 para 19 réplicas durante um aumento na atividade de Pull Requests em 23 de setembro. A GitHub adicionou um mecanismo de controle de carga que permite rejeitar solicitações de menor prioridade antes que os serviços atinjam uma saturação mais ampla.
Os dois incidentes de setembro
Em 13 de setembro, uma tarefa de limpeza de dados em segundo plano provocou um aumento da carga em um banco de dados compartilhado. O mecanismo de proteção monitorava o atraso das réplicas, mas não monitorava a carga acumulada no servidor principal, que atingiu o limite de conexões disponíveis. A ausência de um tempo limite curto para as consultas fez com que os processadores de solicitações permanecessem aguardando, enquanto um loop de novas tentativas continuava enviando operações de escrita malsucedidas. O incidente durou uma hora e 28 minutos e terminou após a redução da carga interna e a interrupção da tarefa.
Em 28 de setembro, uma mudança no serviço que executa as revisões de código do Copilot fez com que uma versão limitada dos resultados da revisão fosse enviada a alguns clientes, em vez da versão completa que inclui os comentários. Com isso, as tarefas pareciam concluídas, embora as revisões não aparecessem nas pull requests. O incidente durou 52 minutos e foi resolvido pela GitHub com a reversão da mudança, enquanto os clientes foram orientados a solicitar novamente as revisões afetadas.
O que muda na prática?
Os dois incidentes mostram que as melhorias de capacidade, por si só, não são suficientes; a confiabilidade também depende da detecção precoce de falhas, da interrupção de novas tentativas inúteis e da garantia de que uma tarefa não seja declarada como concluída antes que seus resultados sejam efetivamente entregues. A GitHub está trabalhando para adicionar controles ao processamento em segundo plano, melhorar o comportamento de inicialização dos serviços e reforçar o monitoramento e a entrega dos resultados do Copilot code review.
A GitHub também registrou uma melhoria na infraestrutura do GitHub Actions: as operações de Redis medidas diminuíram cerca de 28% e o uso relativo do processador, cerca de 30%. Uma camada de cache separada reduziu em 84% a largura de banda utilizada pelo Redis, em 66% o tempo médio de resposta, em 96% o tempo de resposta mediano da solicitação do inventário principal e em 95% as solicitações em espera. As questões em aberto continuam relacionadas à capacidade da empresa de concluir os trabalhos de capacidade e impedir a repetição de falhas em dependências compartilhadas sob condições reais de produção.