Resumo

  • O GitHub abriu um incidente crítico do Actions às 23:34 UTC de 19 de julho. Novos workflows podiam atrasar ou falhar ao iniciar, enquanto execuções já em andamento podiam falhar.
  • A interrupção se alargou para API Requests, Pages e Issues. O GitHub disse posteriormente que o tempo de inatividade prolongado do Actions causou efeitos em cascata e incorporou um incidente separado de Git LFS/API na mesma investigação.
  • O CircleCI relatou pipelines que não iniciaram ou ficaram travados, enquanto a OpenAI relatou falhas ou atrasos em workflows de codificação dependentes do GitHub. Ambos os registros confirmam independentemente que a falha ultrapassou os limites da empresa.
  • O GitHub disse que a causa foi identificada, restaurou o Actions às 04:43 UTC e fechou o incidente um minuto depois. Prometeu uma análise detalhada da causa raiz, mas não a publicou até o fechamento deste relatório.

A primeira falha apareceu no local que executa o trabalho. O sinal mais importante veio depois, quando os sistemas que descrevem, acionam e observam esse trabalho começaram a falhar também.

O GitHub relatou desempenho degradado do Actions às 23:34 UTC de 19 de julho. Em minutos, alertou que novos workflows podiam atrasar ou falhar ao iniciar e que execuções já em andamento podiam falhar. Às 23:57, a empresa disse que havia identificado a causa e estava trabalhando para restaurar o serviço, sem descrever essa causa.

O incidente então cruzou o limite da frota de runners. API Requests entrou em interrupção parcial às 00:07 UTC. Pages e Issues degradaram-se. Um segundo registro relatou falhas em algumas operações Git LFS e no carregamento de arquivos via API. Às 01:11, o GitHub forneceu a ponte causal: o tempo de inatividade prolongado do Actions começara a produzir efeitos em cascata em outros serviços, e um incidente aberto separadamente estava relacionado.

Essa declaração transforma uma coleção de luzes vermelhas de status em um único evento operacional.

O plano de controle tornou-se o raio de explosão

O Actions não é apenas computação alugada. Um workflow é definido em um repositório, acionado por um evento, dividido em jobs e atribuído a runners. A execução ainda depende do GitHub para aceitar eventos, ler o estado do repositório, criar jobs, comunicar o status e reter o histórico usado por pessoas e outros sistemas.

É por isso que um problema de runner pode se espalhar sem que todos os repositórios ou operações Git fiquem offline. Um push pode existir enquanto o pipeline acionado por ele não inicia. Um job pode estar em execução enquanto o status consumido por uma regra de merge ou serviço externo está desatualizado. Um arquivo grande pode estar presente no LFS enquanto uma solicitação de API necessária para carregá-lo falha. Um site estático pode permanecer acessível enquanto uma nova compilação do Pages não avança.

A linha do tempo do GitHub mostra essa separação. Pages foi relatado como recuperado às 01:37. Issues seguiu às 02:20. O GitHub disse que Issues, API Requests e Pages se recuperaram até às 02:43, mas ainda estava restaurando jobs do Actions que usavam runners auto-hospedados ou maiores. API Requests foram declarados normais às 03:03. Actions passou para monitoramento às 03:34 e foi descrito como totalmente recuperado às 04:43.

A sequência importa mais do que um único número de duração total. Cada cliente entrou no incidente através de uma combinação diferente de eventos, APIs, runners e verificações downstream. O GitHub não publicou o número de execuções, repositórios, organizações ou regiões afetadas, portanto os timestamps públicos não podem ser convertidos em tempo de inatividade universal do cliente.

Registros downstream mostram divergência de estado

O registro de serviço do CircleCI torna a consequência concreta. Ele atribuiu workflows travados em estado de execução ou com falha ao iniciar a erros da API do GitHub. Também relatou erros ao processar webhooks de eventos push. Depois que as taxas de erro da API do GitHub se recuperaram, o CircleCI aconselhou os clientes a reacionar pipelines que nunca iniciaram e a cancelar e reexecutar pipelines ainda mostrados como em execução.

Isso é mais do que um aviso genérico de dependência. Descreve um estado divergente: um evento ocorreu em um sistema, mas o sistema esperado para agir sobre ele não começou ou não atingiu um estado terminal confiável.

A OpenAI relatou separadamente falhas ou atrasos em workflows de codificação que dependiam do GitHub e vinculou o impacto à interrupção parcial da API e ao serviço degradado do Actions. O registro não quantificou usuários, jobs ou perda comercial. Seu valor é mais restrito: confirma que o incidente atingiu um workflow externo cuja interface com o cliente não pertencia ao GitHub.

Esses avisos downstream são evidências de propagação, não evidências de que o CircleCI ou a OpenAI causaram o incidente. Também não provam que todos os serviços conectados falharam. Mostram por que um status upstream verde é apenas o início da recuperação para clientes cujo estado do workflow está armazenado em mais de uma plataforma.

Possuir o runner não removeu a dependência de orquestração

A documentação do GitHub diz que um runner auto-hospedado é uma máquina que o cliente implanta e gerencia para executar jobs do Actions. O cliente controla o hardware, o sistema operacional e o software instalado e paga para mantê-lo.

Esse controle pode ser valioso para segurança, localidade, capacidade e hardware especializado. Não é o mesmo que possuir todo o plano de controle do workflow.

O GitHub disse especificamente que continuou trabalhando para restaurar jobs do Actions usando runners auto-hospedados ou maiores depois que Issues, APIs e Pages se recuperaram. A declaração não prova que as máquinas dos clientes estavam quebradas. Mostra que a computação disponível do cliente ainda podia esperar pelo caminho de orquestração do GitHub.

A lição de resiliência é, portanto, precisa. Auto-hospedar um runner pode diversificar a capacidade de execução, mas não fornece por si só um gatilho, fila, atribuição de jobs, registro de status ou caminho de aprovação independentes. Equipes que precisam de uma rota de entrega de emergência devem decidir antecipadamente quais dessas funções podem operar sem o GitHub e como preservarão um rastro de lançamento auditável quando as verificações normais estiverem indisponíveis.

A recuperação requer reconciliação, não apenas repetição

Uma reexecução geral pode criar uma segunda falha. Um job de implantação pode ter concluído seu efeito colateral externo antes que sua atualização de status fosse perdida. Repeti-lo pode publicar o mesmo lançamento duas vezes, reaplicar alterações de infraestrutura, reenviar notificações ou sobrescrever um artefato.

Portanto, a primeira pergunta não é “O botão verde pode ser executado novamente?” É “O que aconteceu no sistema de destino?” Uma equipe deve reconciliar o evento do repositório, o histórico de execução do GitHub, os logs do runner, o estado do pacote ou artefato e o destino da implantação antes de repetir o trabalho. Jobs idempotentes e identificadores de lançamento verificáveis externamente reduzem esse risco; não eliminam a necessidade de verificar.

O conselho do CircleCI de cancelar pipelines travados e reexecutá-los é apropriado para o estado observado, mas cada cliente ainda possui as consequências do trabalho dentro do pipeline. Uma compilação falhada pode muitas vezes ser repetida com segurança. Uma alteração de produção parcialmente concluída pode exigir um caminho de recuperação diferente.

A evidência ausente é o mecanismo

O GitHub fechou o incidente às 04:44 UTC e disse que uma análise detalhada da causa raiz viria. A linha do tempo pública estabelece as superfícies afetadas e a ordem de recuperação. Não divulga o componente que falhou primeiro, por que a interrupção atingiu APIs e outros serviços, se uma ou várias mitigações os restauraram ou qual mudança de design evitará a recorrência.

Não há base pública aqui para alegar uma violação de segurança, perda de código-fonte, falha de implantação do cliente, perda de dados, uma geografia específica ou um crédito de SLA. A classificação “critical” do GitHub descreve seu nível de impacto do incidente; não é uma medida da perda de cada cliente.

A próxima divulgação útil deve explicar a dependência que permitiu que um incidente de runner do Actions afetasse os caminhos de API, LFS, Issues e Pages, e deve separar a falha inicial dos efeitos de backlog e recuperação. Até lá, a conclusão defensável é operacional: o GitHub restaurou a cadeia de serviços, mas os clientes precisam testar se seus próprios registros de eventos, jobs e implantações concordam antes de considerar o incidente encerrado.

Fontes