Ask HN: Funcionários do GitHub, o que está acontecendo? Por quê?

As interrupções cada vez mais frequentes do GitHub estão sendo associadas a uma convergência de fatores: uma migração dolorosa de sua infraestrutura legada para o Microsoft Azure, um aumento no uso de programação gerada por IA que, segundo relatos, fez os commits crescerem 14x em um ano, e uma carga pesada de recursos como Actions e Copilot. Os comentaristas debatem se a posse pela Microsoft e a confiabilidade do Azure são os problemas centrais ou se qualquer grande plataforma teria dificuldade para escalar um sistema maduro e complexo tão rapidamente. Muitos esperam que o GitHub responda com limites mais rígidos ou nova precificação para uso gratuito e de alto volume, mas temem que a instabilidade crônica já esteja corroendo a confiança em uma infraestrutura essencial para desenvolvedores.

Diagnóstico de Alto Nível

  • Duas explicações principais dominam:
    • Crescimento massivo de tráfego impulsionado por IA (commits, Actions, webhooks) pressionando uma plataforma madura.
    • Uma migração difícil de vários anos do stack legado do GitHub e de seus próprios datacenters para Azure, expondo novos modos de falha.
  • Muitos acreditam que ambas estão interagindo: novos padrões de carga atingindo uma arquitetura em transição.

Aquisição pela Microsoft e Migração para Azure

  • Gráficos históricos de uptime mostram estabilidade antes da aquisição e mais incidentes depois.
  • Alguns argumentam que isso se deve a:
    • Mais recursos (Actions, Copilot, Codespaces, segurança, packages) e uma área de superfície muito maior para falhar.
    • Migração em andamento para Azure, incluindo ambientes parciais/duplos, descrita como “dolorosa”.
  • Outros veem a correlação como evidência de que a Microsoft e/ou o Azure são o problema raiz; defensores rebatem que o Azure opera com sucesso muitos serviços enormes.

Crescimento Impulsionado por IA e “Slop”

  • Liderança do GitHub é citada afirmando um crescimento de ~14x em commits e rápido crescimento de usuários, atribuído à programação por IA e agentes.
  • Muitos suspeitam de volumes enormes de tráfego de baixo valor ou de bots:
    • Repositórios com milhares de commits minúsculos.
    • Bots criando repositórios automaticamente, instalando apps e disparando webhooks.
    • Ataques de scraping e uso excessivo de CI/Actions.
  • Debate sobre se isso é uma desculpa válida ou uma falha de planejamento, já que o crescimento impulsionado por IA é visível há mais de um ano.

Escala, Arquitetura e Limites

  • Discussão sobre:
    • GitHub como um sistema de estado compartilhado (repositórios, PRs, issues) versus APIs LLM em grande parte sem estado, o que torna a escala mais difícil.
    • Rails vs. stacks “modernos”; alguns culpam Ruby, outros dizem que arquitetura e design importam mais do que a linguagem.
    • Falta de limites agressivos e rate-limiting vista como causa raiz; pedidos por throttling por usuário ou por repositório e por precificação.
  • Um comentário detalhado em tom de insider enquadra isso como um evento de escala de uma vez por geração em um sistema já enorme, não mera incompetência.

Negócio, Organização e Impacto no Usuário

  • A infraestrutura é vista como um centro de custo competindo com iniciativas de IA e outras prioridades.
  • Múltiplas demissões são apontadas como causa da perda de expertise e da recuperação lenta.
  • Usuários sugerem:
    • Encerrar ou apertar repositórios privados gratuitos e ilimitados.
    • Cobrar de usuários intensivos ou abusivos, ou limitar commits diários.
  • Outros temem que cobrar mais não resolva a qualidade e que os custos de troca mantenham as empresas presas apesar do uptime ruim.

Postmortem do Incidente Recente (17 de ago de 2026)

  • O relatório oficial (citado no thread) atribui uma grande interrupção a:
    • Novo pico de tráfego saturando os load balancers.
    • Autoescalonamento do sidecar Istio configurado incorretamente.
    • Exaustão de fluxos do HAProxy e tempestades de retries, especialmente da lógica de tokens do VS Code/Copilot.
  • Os acompanhamentos incluem correções nas políticas de autoescalonamento, no comportamento de retry e na amplificação do cliente, mas os participantes veem isso como evidência de lacunas sistêmicas de confiabilidade e operação.