Resumo

  • O GitHub ampliou de forma material o incidente qcvjkzcs7j74 em 11 de agosto; a indisponibilidade ocorreu entre 15h05 UTC de 6 de agosto e 0h14 UTC do dia 7.
  • No pico, 71% das execuções tiveram falhas de infraestrutura e 75% das execuções restantes atrasaram mais de cinco minutos.
  • A troca de pods em uma implantação comum expôs uma fragilidade anterior de capacidade e concorrência e provocou efeito cascata entre clusters e serviços dependentes.
  • A primeira recuperação combinou expansão de capacidade, limitação temporária de entradas disparadas por webhook e aumento do processamento do acúmulo.
  • Um bug latente manteve runners tentando jobs que já não eram válidos; alguns runners ARC exigiram recuperação manual e certos eventos não puderam ser reproduzidos automaticamente.
  • As salvaguardas e a recuperação automática prometidas ainda precisam de versão, implantação e evidência operacional antes de serem tratadas como controles efetivos.

O atraso que permaneceu depois da tela verde

Alguns eventos de push e pull request não foram processados e não podiam ser reproduzidos automaticamente. Uma mitigação também deixou runners do Actions Runner Controller travados até intervenção manual.

Isso desloca o fim do incidente para o ambiente do cliente. O serviço pode estar saudável enquanto um repositório ainda carece de uma compilação, uma verificação ou uma implantação que deveria ter sido disparada.

As duas porcentagens medem grupos diferentes

Os 71% representam falha de infraestrutura sobre todas as execuções. Os 75% medem atraso superior a cinco minutos somente entre o restante. Não são pontos percentuais adicionais e não provam que o grupo remanescente terminou com sucesso.

Separar falha de demora permite distinguir um job que precisa ser repetido de outro que apenas perdeu uma janela de entrega.

A implantação usou a própria margem de segurança

O serviço interno afetado recebe eventos e cria jobs do Actions. A substituição de pods retirou capacidade durante a implantação; o que ficou não suportou a carga, saturou e falhou, propagando impacto para vários clusters e componentes dependentes.

Uma operação desse tipo precisa de folga calculada para a mudança, não só para o tráfego normal. A fila formada durante a transição também passa a disputar a mesma capacidade.

Mais vazão não corrigiu o significado dos jobs

O GitHub adicionou capacidade, reduziu a entrada por webhook e acelerou o processamento do acúmulo. Em seguida, apareceu o defeito de atribuição: runners recebiam jobs inválidos, tentavam adquiri-los outra vez e não avançavam para os válidos.

Foi necessário bloquear esse ciclo antes que as filas baixassem. O problema passou de quantidade para integridade de estado: cada item precisava continuar representando trabalho executável.

A data da explicação não altera a data da falha

O incidente operacional acabou em 7 de agosto. A atualização de 11 de agosto trouxe causa, métricas e ações de recuperação. Ela é um avanço de transparência, não uma nova interrupção nem quatro dias adicionais de indisponibilidade.

Manter esses relógios separados permite avaliar a restauração e o tempo de publicação do diagnóstico.

O plano anunciado ainda é uma hipótese de controle

O GitHub pretende reforçar proteções de implantação e capacidade, monitoramento de sinais precursores, resiliência de filas, atribuição de runners, contenção de cascatas e recuperação automática. O escopo corresponde ao mecanismo descrito.

Faltam datas, limiares e resultados. Uma versão futura de Runner e ARC, acompanhada de testes ou métricas, será evidência mais forte do que a lista de intenções.

A empresa precisa de um livro-razão de execução

Registrar eventos esperados, IDs de workflow, estados finais e artefatos produzidos permite encontrar disparos ausentes e evitar reexecuções duplicadas. Esse inventário pode ser conferido mesmo depois do encerramento do incidente público.

A disponibilidade do provedor responde se é possível executar agora. A conciliação local responde se tudo o que deveria ter sido executado durante a falha recebeu um resultado confiável.

Fontes