Incidente com Github.com [resolvido]

Artigo original ↗ Discussão no Hacker News ↗

Interrupções repetidas de várias horas no GitHub — afetando pull requests, issues, Actions e a interface web enquanto a página oficial de status atrasava ou permanecia “tudo verde” — estão levando muitos desenvolvedores a questionar sua confiabilidade como infraestrutura crítica. Os comentaristas debatem as causas, da migração da Microsoft para Azure e da geração agressiva de código por IA ao subinvestimento em operações centrais, e discutem se limites de taxa ou preços mais altos para uso pesado (muitas vezes baseado em LLM) já deveriam existir. Um número crescente de equipes relata migração ativa ou planejada para alternativas como GitLab auto-hospedado, Gitea/Forgejo ou forges federadas mais novas, destacando preocupações mais amplas sobre centralização, dependência de fornecedor e a fragilidade de uma plataforma dominante de hospedagem de código.

Sintomas e impacto da indisponibilidade

  • Muitos usuários relatam que o GitHub está inutilizável: páginas de erro com unicórnio, erros 500, 404, “cannot retrieve latest commit”, status de merge de PR não carregando, Actions falhando, webhooks não disparando.
  • As operações básicas de git muitas vezes ainda funcionam (clone, push), e a CLI (gh) ou a API às vezes funcionam onde a interface web não funciona, mas pipelines de CI/CD e fluxos de trabalho baseados na web ficam bloqueados.
  • A indisponibilidade dura várias horas, com alguns usuários observando incidentes semelhantes apenas dias antes; alguns tratam isso como uma pausa forçada, outros como uma interrupção séria nos negócios.

Página de status e tratamento do incidente

  • A página oficial de status inicialmente mostra “tudo verde”, depois mais tarde “desempenho degradado” e “~20% taxa de erro”.
  • Muitos sentem que isso subestima a situação: para eles, é efetivamente 100% fora do ar para PRs/issues.
  • Vários apontam que incidentes de “desempenho degradado” não parecem refletidos nas estatísticas de uptime; indisponibilidades antigas também estão ausentes ou foram inseridas depois como 100% de uptime, corroendo a confiança.

Causas suspeitas

  • GitHub/Microsoft atribuem problemas recentes de disponibilidade ao crescimento massivo, especialmente ao uso de código e Actions impulsionado por IA/LLM (aumento de uma ordem de grandeza ou mais em commits e minutos de CI).
  • Alguns comentaristas concordam que escala é realmente difícil; outros argumentam:
    • As interrupções precedem o boom da IA e se intensificaram após a aquisição pela Microsoft e a migração para Azure.
    • Outros serviços em escala web conseguem maior confiabilidade.
    • Excesso de recursos e mudanças “vibe-coded”/assistidas por IA podem estar prejudicando a robustez.

Negócios, confiabilidade e SLAs

  • Muitas organizações agora tratam o GitHub (incluindo Actions) como infraestrutura crítica; as interrupções bloqueiam hotfixes, lançamentos e receita.
  • Alguns argumentam que os usuários deveriam ter planos de contingência, espelhos e não tratar um SaaS de terceiros como ponto único de falha; outros respondem que o GitHub se vende explicitamente como infraestrutura corporativa confiável com SLA.
  • Há tensão entre “não fique irritado, vá sair” e “nós pagamos por isso; a frustração é legítima”.

Alternativas e migração

  • Menções frequentes a migração para:
    • Forges auto-hospedadas (GitLab, Gitea, Forgejo) mais CI auto-hospedado (Jenkins, Woodpecker, Buildkite, etc.).
    • Outras forges hospedadas (GitLab.com, Codeberg, opções federadas mais novas).
  • Trade-offs discutidos:
    • Efeitos de rede e visibilidade social mantêm as pessoas no GitHub.
    • Auto-hospedagem é vista como barata e confiável por alguns, mas operacionalmente onerosa por outros.
    • A migração de CI/Actions e a perda de integrações são as partes mais difíceis.

Centralização, comunidade e preços

  • Reflexão mais ampla de que a centralização do GitHub transformou o git distribuído em um ponto único de falha e uma rede social para desenvolvedores.
  • Alguns acolhem uma “diáspora” de volta para ferramentas mais distribuídas ou federadas; outros temem a perda de descoberta e de normas compartilhadas.
  • Muitos sugerem que o GitHub deveria limitar ou cobrar de forma mais agressiva o tráfego pesado/LLM e o uso do plano gratuito, priorizando usuários pagantes e humanos, mas observam que os incentivos de negócio podem desencorajar isso.