É bom manter a página de status em um domínio separado por causa da disponibilidade, mas não atualizar essa página quando o domínio principal cai não é muito legal
Esse tipo de página é atualizado manualmente com mais frequência do que parece. E muitas vezes isso fica a cargo de quem está de plantão e já tem muita coisa mais urgente para resolver
Talvez a infraestrutura que atualiza a página de status também tenha caído
Parece que esse tipo de falha acontece quase a cada 2 semanas. O que está acontecendo com o GitHub ultimamente?
Parece que estão adicionando novos recursos como o Copilot sem investir o suficiente na confiabilidade do site
Se não houver mudanças, costuma ser relativamente fácil manter a estabilidade apenas corrigindo bugs. Mudanças, ou seja, novos recursos, criam novos bugs e nova carga
Alguém deve ter esquecido de colocar node_modules no .gitignore
Talvez as pessoas que não se encaixavam na gestão ao estilo Microsoft tenham ido procurar outro emprego?
Estão testando o gpt4-ops?
Incompetência da Microsoft + DDoS?
Talvez concentrar todo o nosso open source em um só lugar não seja uma boa ideia >_<
Na prática, talvez a única diferença seja que em algum momento você deseje “estar do outro lado”
Entre 1% do todo fora do ar 100% do tempo e 100% do todo fora do ar 1% do tempo, intuitivamente uma opção parece melhor, mas não sei qual das duas é mais prática de verdade. Claro que dá para espelhar, se você quiser, mas isso já é possível hoje, então não é esse o ponto principal
A essência de um sistema de controle de versão distribuído é que toda pessoa que faz git clone tem uma cópia completa do repositório inteiro e pode fazer a maior parte do trabalho sem se comunicar com um servidor central
Um downtime curto afeta mais a infraestrutura ao redor do código em si, como workflow, issues etc.
Sinceramente, é melhor quando fica tudo reunido em um só lugar. Melhor a indústria inteira parar ao mesmo tempo do que cada pessoa aleatória em um momento aleatório
É parecido com quando a us-east-1 cai. Como todo mundo está no mesmo barco, todos param ao mesmo tempo e você ainda ganha uma desculpa legítima para relaxar um pouco
Colocar todo o código da empresa lá é uma ótima ideia. Você ganha uma pausa grátis
O principal atrativo do GitHub nunca foi a distribuição. Quando entrei em 2008, era mais parecido com uma rede social onde desenvolvedores se encontravam
Parece que voltou. Eu gostaria de ver uma análise aprofundada dessas falhas recentes e ouvir um compromisso de priorizar estabilidade acima de novos recursos
Conversei há alguns meses com alguém do suporte ao cliente, e a pessoa praticamente culpou os vários trabalhos customizados feitos para grandes clientes pela queda na estabilidade. No fim das contas, parece que há uma quantidade enorme de dívida técnica acumulada
Para rodar uma instância do GitHub Enterprise, você precisa de algo como 64 GB de RAM. É um monstro enorme
Esse tipo de customização pode levar a erros ou à indisponibilidade de algumas funcionalidades. Mas o site inteiro cair, especialmente conteúdo estático como o GH Pages, é totalmente um problema de SRE
É mais provável que isso seja roteamento de rede ou algum outro erro na camada 4 ou abaixo. A maioria das mudanças de aplicação sai por rollout gradual e canário, e se houver problema dá para fazer rollback bem rápido
Parece que essa falha também está afetando o GitHub Pages. As páginas .github.io estão mostrando a página 503 do unicórnio
We're having a really bad day.
The Unicorns have taken over. We're doing our best to get them under control and get GitHub back up and running.
Uau, nem a página de status carrega. Parece que a web inteira caiu, e nem me lembro da última vez que tudo caiu desse jeito
O que vocês usam para se isolar de problemas assim? Adicionar um cache para operações de leitura parece inteligente e ainda melhora o desempenho. Se alguém tiver um caso de sucesso em evitar o impacto, seria legal compartilhar
Em um setup de “GitOps” de uma organização num emprego antigo, espelhávamos o GitLab no AWS CodeCommit e usávamos isso como fonte única da verdade para a automação
Essa decisão se provou acertada várias vezes, e não me lembro de nenhum problema notável com o CodeCommit. Mas se você usa o GitHub como forge no processo real de desenvolvimento, com issue tracker, PRs para review etc., não sei se há uma boa forma de se isolar
No meu emprego anterior havia um GitHub Enterprise hospedado localmente, e toda vez que o pessoal no Twitter dizia “o github caiu! bora sair mais cedo hoje!”, eu sempre ficava frustrado :(
Claro, ainda era irritante quando alguma ferramenta exigia atualizar dependências que estavam no GitHub comum, mas pelo menos as coisas ligadas a deploy e afins continuavam funcionando
Pausa para o café
O git foi projetado desde o início para poder ser usado offline, então use o clone local que você já tem
A página de status acabou de mudar:
Investigating - We are currently experiencing an outage of GitHub products and are investigating.
Jun 29, 2023 - 17:52 UTC
Até leitura está em vermelho. Acho que é a primeira vez que vejo todos os itens vermelhos na página de status
1 comentários
Comentários do Hacker News
https://downdetector.com/status/github/
Se não houver mudanças, costuma ser relativamente fácil manter a estabilidade apenas corrigindo bugs. Mudanças, ou seja, novos recursos, criam novos bugs e nova carga
node_modulesno.gitignoreEntre 1% do todo fora do ar 100% do tempo e 100% do todo fora do ar 1% do tempo, intuitivamente uma opção parece melhor, mas não sei qual das duas é mais prática de verdade. Claro que dá para espelhar, se você quiser, mas isso já é possível hoje, então não é esse o ponto principal
git clonetem uma cópia completa do repositório inteiro e pode fazer a maior parte do trabalho sem se comunicar com um servidor centralUm downtime curto afeta mais a infraestrutura ao redor do código em si, como workflow, issues etc.
É parecido com quando a us-east-1 cai. Como todo mundo está no mesmo barco, todos param ao mesmo tempo e você ainda ganha uma desculpa legítima para relaxar um pouco
Conversei há alguns meses com alguém do suporte ao cliente, e a pessoa praticamente culpou os vários trabalhos customizados feitos para grandes clientes pela queda na estabilidade. No fim das contas, parece que há uma quantidade enorme de dívida técnica acumulada
É mais provável que isso seja roteamento de rede ou algum outro erro na camada 4 ou abaixo. A maioria das mudanças de aplicação sai por rollout gradual e canário, e se houver problema dá para fazer rollback bem rápido
.github.ioestão mostrando a página 503 do unicórnioEssa decisão se provou acertada várias vezes, e não me lembro de nenhum problema notável com o CodeCommit. Mas se você usa o GitHub como forge no processo real de desenvolvimento, com issue tracker, PRs para review etc., não sei se há uma boa forma de se isolar
Claro, ainda era irritante quando alguma ferramenta exigia atualizar dependências que estavam no GitHub comum, mas pelo menos as coisas ligadas a deploy e afins continuavam funcionando
gitfoi projetado desde o início para poder ser usado offline, então use o clone local que você já temInvestigating - We are currently experiencing an outage of GitHub products and are investigating.
Jun 29, 2023 - 17:52 UTC