A interrupção de 17 de agosto

Causa da interrupção e debate sobre escalabilidade

• Muitos veem os incidentes como clássicos abismos de capacidade: os sistemas funcionam bem e, então, um pequeno aumento de carga (por exemplo, 2,8 bilhões → 2,9 bilhões de commits/mês) dispara gargalos ocultos e falhas em cascata.
• Outros argumentam que o GitHub deveria ter percebido condições de “capacidade máxima” mais cedo e projetado para evitar esses abismos; “apenas adicionar mais hardware” (3 milhões de núcleos de CPU, 120 PB de armazenamento) é visto como insuficiente sem uma arquitetura e resiliência melhores.
• Alguns comentadores observam que esse tipo de falha é comum em hyperscale; outros dizem que o RCA do GitHub parece o de uma equipe que só agora está construindo práticas maduras de grande escala.

Explosão de tráfego impulsionada por IA

• O enorme crescimento de commits é amplamente atribuído a codificação com IA/agentes e fluxos de trabalho automatizados, não a mais desenvolvedores humanos.
• Muitos descrevem o GitHub como inundado por “AI slop”: commits, PRs e issues frequentes, de baixa qualidade e gerados automaticamente (Bun é repetidamente citado como um exemplo extremo).
• Há desacordo sobre se esse crescimento é “impressionante” (do ponto de vista de infraestrutura) ou mais parecido com “crescimento de câncer”, que degrada o serviço enquanto acrescenta pouco valor.

Azure, Microsoft e arquitetura

• Há forte ceticismo de que “migrar para Azure” seja uma solução quando o Azure é percebido (por alguns) como um grande problema de confiabilidade, especialmente para produtos historicamente baseados em colo como GitHub/LinkedIn.
• Outros contestam: qualquer plataforma grande (AWS, Azure, GitHub) terá interrupções; culpar apenas o Azure é visto como uma simplificação excessiva.

Retentativas, avalanches e resiliência

• As tempestades de retentativas (notavelmente de clientes do Copilot/VS Code) são vistas como um problema clássico de “thundering herd” / amplificação de retentativas.
• Há longa discussão sobre boas práticas: backoff exponencial com jitter, circuit breakers, limitação no lado do cliente, token buckets e diferenciação explícita entre erros passíveis de retentativa e erros não passíveis.
• Vários argumentam que a verdadeira causa raiz é a falta de degradação graciosa e de descarte de carga, e não apenas capacidade insuficiente.

Camada gratuita, AI slop e modelo de negócios

• Muitos suspeitam que a economia do GitHub esteja pressionada: hospedagem gratuita massiva (incluindo código gerado por IA e Actions) versus um orçamento finito de infraestrutura.
• Mitigações propostas: limites de commits por usuário ou por organização, limitação de taxa, planos mínimos pagos (por exemplo, US$ 1/mês), separação de pools de capacidade gratuita e paga.
• Contraponto: a Microsoft pode estar disposta a subsidiar o GitHub como um produto de perda para impulsionar a adoção de IA e colher código como dados de treinamento, mesmo que isso prejudique a confiabilidade.

Alternativas e auto-hospedagem

• Há forte interesse em GitLab auto-hospedado, Forgejo/Gitea, Codeberg, Sourcehut e novos forges “AI-native”.
• São discutidos compromissos:
  • Auto-hospedagem: custo administrativo contínuo modesto, mas melhor controle, isolamento da AI slop e ausência de um ponto único de falha.
  • GitLab: maduro, porém mais caro e “desajeitado”; menos interrupções, mas não imune.
  • Forgejo/Codeberg: FLOSS, mais leves, mas com ecossistema de CI/app mais fraco; a posição política do Codeberg preocupa alguns.
  • Sourcehut: fluxo de trabalho orientado por e-mail é elogiado, mas é pago e de nicho.

Experiência de produto e fluxos de trabalho do GitHub

• Alguns afirmam que o GitHub é o “mais sofisticado” para issues/PRs/CI integrados; muitos outros dizem que é “o pior em cada aspecto individual”, mas vence pela consolidação e pelos efeitos de rede.
• Hoje, muitas equipes sérias tratam o GitHub apenas como um host de git e executam planejamento/rastreamento de issues em outro lugar (por exemplo, Linear).
• Actions é repetidamente citado como pouco confiável sob carga e um ponto problemático para empresas.

Liderança, comunicação e confiança

• Há irritação perceptível com o fato de o post do blog do GitHub usar linguagem corporativa (“we let you down”) sem um “desculpem” explícito nem compromissos concretos de reembolso/compensação para clientes pagantes.
• Alguns se incomodam com o perfil público do CTO do GitHub não mostrar codificação visível no último ano; outros argumentam que o trabalho de um CTO é liderança, não codificação ativa.
• Usuários enterprise, em particular, estão frustrados porque as interrupções parecem afetar pagantes e gratuitos igualmente, e querem isolamento rígido ou infraestrutura separada para clientes pagantes.

Preocupações mais amplas: valor, meio ambiente e qualidade de software

• Vários tópicos questionam se o crescimento explosivo de commits produziu software ou experiências de usuário visivelmente melhores; muitos dizem que o software de consumo está piorando apesar de haver mais código.
• Outros contrapõem que a IA capacitou não programadores e permitiu que hobbyistas criassem ferramentas que nunca poderiam ter criado antes, embora esses ganhos sejam muitas vezes pessoais e não amplamente visíveis.
• O impacto ambiental da IA/data centers gera debate: alguns veem o uso de energia da IA como moderado e compensável por ganhos de eficiência; outros o veem como um sério retrocesso para as metas climáticas, especialmente diante de metas de CO₂ descartadas por grandes provedores.