O Que É um Incidente de Runner Hospedado? Quando a Frota Cai
Um incidente de runner hospedado é uma indisponibilidade ou degradação da frota de runners compartilhada do provedor de CI - provisionamento lento, filas travadas ou jobs falhando - que você não pode resolver do seu lado.
Quando você usa runners hospedados, a frota é responsabilidade do provedor. Isso é conveniente até quebrar: um incidente que afeta toda a frota trava a CI de todo mundo de uma vez, e não há nada no seu workflow que você possa mudar para se recuperar.
Como é um incidente
- Jobs presos na fila porque nenhum runner está sendo provisionado.
- Inicialização de runners lenta ou falhando em todos os repositórios.
- Falhas intermitentes de jobs sem relação com o seu código.
Por que você não pode consertar
A frota é totalmente gerenciada pelo provedor, então durante um incidente você não tem alavancas - nenhum retry dos seus próprios runners, nenhum failover. Você espera a página de status ficar verde, enquanto a CI da sua equipe fica bloqueada.
Reduzindo sua exposição
Diversificar de onde vêm seus runners limita o raio de impacto: se uma frota tiver um incidente, os jobs que podem rodar em um provedor diferente continuam avançando. Depender de uma única frota significa um ponto único de falha para toda a CI.
Resiliência com runners gerenciados
Rodar em uma frota gerenciada independente significa que um incidente na frota hospedada do GitHub não precisa parar seus builds - seus jobs rodam em infraestrutura separada. O Latchkey é independente da frota hospedada do GitHub.
Incidente vs sua própria configuração errada
Antes de culpar um incidente, confirme que ele afeta toda a frota: verifique a página de status do provedor e se outros repositórios e organizações também são afetados. Se apenas seus jobs estão presos, a causa é mais provavelmente um problema de label, quota ou permissão no seu lado do que uma queda do provedor.
Principais conclusões
- Um incidente de runner hospedado é uma queda da frota do provedor que você não pode consertar.
- Ele trava filas e faz jobs falharem em todos os seus repositórios de uma vez.
- Depender de uma única frota é um ponto único de falha para a CI.
- Uma frota gerenciada independente reduz o raio de impacto do incidente.