feature/agent-queueing-infinite-loop #296
Description
feature/agent-queueing-infinite-loop
- Introdução leve, irônica ou autozoada
Era 16h de uma segunda-feira que já tinha cara de sexta mal-resolvida.
Eu estava naquele momento sagrado do dia: café frio, Slack piscando, Jira aberto em abas que ninguém mais respeita, e um pipeline “quase verde”. Quase. Sempre quase.
Aí o Azure DevOps resolveu me lembrar de uma verdade universal da vida moderna: o build nunca falha sozinho. Ele chama a infra, chama a nuvem, chama o storage, chama o karma.
O pipeline ficou Queued.
Depois Queued for longer than expected.
Depois silêncio.
Nenhum erro. Nenhum log. Só aquele vazio existencial que só um agente hospedado que nunca nasce consegue causar.
- Apresentação da(s) notícia(s)
O comunicado veio com aquele tom corporativo zen-budista:
“Global Queuing Delays for Hosted Pipeline Agents”
Traduzindo para o idioma nativo de quem já quebrou produção às 3h da manhã:
👉 o Azure DevOps não consegue criar VMs
👉 sem VM, sem agente
👉 sem agente, sem pipeline
👉 sem pipeline, sem deploy
👉 sem deploy, sem paz
O evento começou às 16:03, horário perfeito para destruir qualquer esperança de entrega no mesmo dia.
Afetou Hosted Pools e Managed DevOps Pools, ou seja: não importa se você pagou, confiou ou rezou — todo mundo foi para a mesma fila.
A raiz do problema?
Um clássico instantâneo da engenharia moderna:
“uma mudança de configuração que afetou o acesso público a storage accounts Microsoft-managed”
Ou, na tradução DevComputaria certificada:
🧨 alguém mexeu numa permissão de storage que sustenta metade do Azure
🧨 ninguém percebeu no teste
🧨 o impacto escalou mais rápido que microserviço sem observabilidade
Resultado:
VMs não criam
VMSS tropeça
Azure DevOps trava
GitHub Actions entra em fila existencial
Copilot entra em modo contemplativo
Codespaces falha em nascer
E você… você fica olhando um pipeline parado, tentando explicar isso numa daily.
Sim, Azure DevOps, Microsoft Azure e GitHub caíram juntos, de mãos dadas, num belo balé distribuído da indisponibilidade.
- O efeito dominó que ninguém assume
O que mais me encanta nesse tipo de incidente não é o erro.
É a coreografia.
Um storage account — invisível, ignorado, nunca documentado no ADR — decide negar acesso.
Isso impede a VM de baixar extensão.
Sem extensão, a VM não sobe.
Sem VM, não existe agente.
Sem agente, não existe pipeline.
Sem pipeline, não existe entrega contínua.
Sem entrega, não existe “DevOps”.
Só “Ops”. E sofrimento.
E aí surgem as mensagens:
“Pipeline ficou muito tempo em fila”
“Tentamos novamente mais tarde”
“Estamos trabalhando com o time do Azure”
Tradução honesta:
“A nuvem está em crise existencial e você é só um espectador.”
- A simetria do caos: Azure e GitHub caindo juntos
O detalhe poético é que o GitHub Actions caiu pelo mesmo motivo.
Hosted runners também dependem de VM.
VM depende de storage.
Storage depende de configuração.
Configuração depende de humanos.
Humanos dependem de café.
Café depende de esperança.
E quando a esperança falha, a nuvem cobra juros.
O status do GitHub foi claro como um stacktrace truncado:
“Self-hosted runners are not impacted.”
Essa frase dói mais do que qualquer erro 500.
Ela basicamente diz:
👉 “Se você tivesse assumido a responsabilidade pela sua própria infra, estaria trabalhando agora.”
- Opinião pessoal / interpretação filosófica-dev
Esse incidente não é sobre VMs.
É sobre a ilusão do infinito.
A promessa implícita do DevOps moderno é:
“Não se preocupe, a plataforma cuida disso.”
Mas a plataforma é feita de:
storage accounts
permissões
scripts
extensões
pipelines
humanos cansados
Nada ali é infinito.
Nada ali é imune a erro.
Nada ali é “serverless” no sentido espiritual da palavra.
Esse tipo de falha expõe um pecado arquitetural comum:
a fé cega no hosted.
Hosted agent é conforto.
É praticidade.
É produtividade… até não ser.
No dia que dá errado, você descobre que:
não controla o pool
não controla a VM
não controla o storage
não controla o tempo
Você controla só a frustração.
- O mito da abstração perfeita
A gente abstraiu tanto que esqueceu o que tem embaixo.
Pipeline virou YAML mágico.
Agente virou entidade mística.
VM virou detalhe irrelevante.
Até o dia que o detalhe resolve parar.
E aí o Slack vira um museu de mensagens como:
“Mais alguém com pipeline travado?”
“Aqui também.”
“Aqui idem.”
“Não é só comigo então…”
O incidente vira coletivo.
O sofrimento vira distribuído.
A culpa… sempre “upstream”.
- A lição que ninguém quer escrever no ADR
Esse é o tipo de evento que deveria gerar um documento chamado:
ADR-042: Sobre não confiar cegamente em agentes hospedados
Mas ninguém vai escrever.
Vai ficar implícito.
Vai virar lore.
Vai virar piada interna.
Até o próximo outage.
Porque no fundo, a verdade incômoda é:
🔹 DevOps não elimina a infra — ele só esconde
🔹 Nuvem não remove risco — ela redistribui
🔹 Alta abstração cobra juros em dias de falha
- O fechamento (pull request filosófico)
Quando o status finalmente ficar verde,
quando os agentes voltarem a nascer,
quando o pipeline rodar como se nada tivesse acontecido…
…ninguém vai lembrar.
Mas você vai.
Na próxima vez que alguém disser:
“Ah, usa hosted agent, é mais simples”
Você vai ouvir, em silêncio, o eco desse incidente.
E talvez — só talvez — você abra um PR pequeno, tímido, quase envergonhado:
pool:
name: self-hosted
E ninguém vai entender.
Mas você vai dormir melhor.
Tudo certo.
Nada resolvido.