hotfix/service-quality-is-green-but-my-soul-is-not #298
Description
hotfix/service-quality-is-green-but-my-soul-is-not
- Introdução leve, irônica ou autozoada
Tem dia que a gente abre o Azure DevOps só pra ver se é a gente que tá quebrado ou se o universo colaborou.
Hoje foi aquele clássico:
pipeline travado ontem por causa de VM que não nasce,
de manhã um “Availability Degradation in WEU” em Artifacts,
e agora o status dizendo, com toda serenidade corporativa:
“The issue is now fully mitigated. Some requests may still fail; retries will succeed.”
Ou seja:
não tá funcionando, mas confia e aperta o botão de novo.
DevOps moderno é isso: F5 como filosofia de vida.
- Apresentação das notícias (versão “dev que já viu coisa demais”)
Vamos organizar o caos como se fosse um board de Kanban.
2.1. O incidente dos agentes zumbis (02/02/2026)
No evento de Global Queuing Delays for Hosted Pipeline Agents, o roteiro foi assim:
Hosted pools e managed pools foram pro saco, porque a criação de VM em Microsoft Azure resolveu tirar um dia de folga.
O problema veio de uma mudança de configuração que afetou o acesso a storage accounts gerenciadas pela Microsoft, usadas pra extensão de VM. Quando o storage fecha a porta, metade da nuvem fica na calçada.
Resultado: agentes que não sobem, jobs parados em “Waiting for an agent to pick up this job…”, fila global de dor e sofrimento.
Aí vem o final update:
“Issue fully mitigated. There may be a long tail of existing agent requests which could still fail; retries will succeed.”
Traduzindo pro dialeto Slack:
“Arrumamos, mas se quebrar você finge que não viu, dá retry e finge que sempre foi assim.”
Eles ainda prometem investigar pra reduzir risco de recorrência. É o “vamos marcar um café” do pós-mortem.
2.2. Mini-incêndio em WEU – Artifacts (03/02/2026)
Enquanto você ainda tava xingando agente hospedado, aparece outro card no status:
“Availability Degradation in WEU”
Serviço: Artifacts
Geografia: Europa
Estado: começou 07:36, acabou 08:03, nível Advisory (que é o “não foi tão grave assim, mas a gente admite que doeu um pouco”).
No final update:
“Service back to healthy state. We will analyze the root cause and address this.”
É aquele clássico “foi nada não, só tropecei”… com o repositório de pacotes que seu pipeline depende pra compilar.
2.3. O manual oficial de como chamar isso de “qualidade”
O mais irônico é que a própria documentação do Azure DevOps Service Status explica com toda calma a diferença entre Healthy, Degraded e Advisory, e ainda linka orgulhosamente um post antigo do Brian Harry sobre “How do you measure quality of a service?”.
Nesse post, ele define “qualidade de serviço” basicamente como disponibilidade + responsividade e critica o modelo clássico de medir tudo com transações sintéticas — aqueles testezinhos que batem em meia dúzia de endpoints e dizem que tá tudo bem enquanto o usuário real tá pegando fogo.
Resumo: você pode ter dash verde no monitor e cliente vermelho no Twitter ao mesmo tempo.
Spoiler: adivinha qual dos dois tá certo?
2.4. Flashback 2018 – o déjà vu oficializado em postmortem
Não é como se fosse a primeira vez.
Em 2018 rolou um postmortem enorme dos “Azure DevOps Service Outages in October 2018”, contando como uma instabilidade rápida em dependências (networking, autenticação, etc.) jogava alguns scale units num tailspin, com fila de requisição lá em cima mesmo depois do serviço dependente ter se recuperado.
Os SREs descrevem:
pequenos espasmos de rede →
auth mais lenta →
scale unit entra em modo pânico →
fila cresce →
reciclam app tiers na marra →
downtime prolongado por algo que começou com poucos segundos.
Eles prometem aprender, melhorar circuit breakers, aumentar resiliência, tudo bonito, tudo certo.
Corta pra 2026:
globais delays pra criar VM de agente, storage bloqueando extensão, hosted runner parado, GitHub Actions sofrendo junto… e nós, no meio, olhando pro gráfico igual em 2018, só que com mais microserviço e menos paciência.
- Opinião pessoal / Filosofia de terminal sobre “qualidade de serviço”
Vamos falar a real:
“Qualidade de serviço” virou um eufemismo educado pra “como a gente conta a história do desastre sem parecer tão feio assim”.
O post do Brian Harry já avisava em 2013:
Se você mede só o que o robô de teste vê, você não está medindo o que o usuário sente.
É perfeitamente possível o painel estar todo verde enquanto metade dos clientes está travada na fila.
O postmortem de 2018 reforça:
O problema não é só o incidente em si, mas como a arquitetura reage a ele — alguns segundos de problema viram 75 minutos de caos graças a filas, timeouts, retries e cascatas.
Agora chega 2026 e a gente tá exatamente nesse ponto nebuloso:
O status diz “fully mitigated”
Você ainda tem job falhando porque caiu na “long tail”
A recomendação oficial é: “tenta de novo”
Isso não é exatamente resiliência.
Isso é observabilidade passiva + fé ativa.
- Parallelo com o dev comum (vulgo: nós ferrados no meio)
Imagina se o seu sistema interno fizesse isso com o cliente final:
O Pix não cai, ele tá Degraded.
A conta não some, ela tá momentaneamente com latência elevada.
A TED não falha, ela só precisa de novas tentativas para ter sucesso.
Você escreve isso num postmortem interno e o time de risco te come vivo.
Mas quando é plataforma de CI/CD, virou normal.
A gente aprende a conviver com:
Status “Degraded” crônico: não é incidente, é clima.
“Advisory”: o jeito educado de dizer “talvez você tome um tapa, talvez não”.
Pós-mortem prometendo aprendizado eterno: tipo retro de time que nunca fecha action item.
E no meio disso o dev fica:
tentando explicar pro gestor por que o deploy atrasou,
ouvindo “mas a nuvem não era pra resolver isso?”,
e abrindo mais uma aba do status.dev.azure.com como quem confere o horóscopo do dia.
- O componente humano que a SLO não enxerga
SLA fala de nove de uptime.
SLO fala de erro budget.
O dev fala de outra coisa: cansaço acumulado.
Cada “small incident”, “short degradation”, “advisory em WEU” entra na conta invisível:
mais um retry manual,
mais um pipeline que não começa,
mais uma daily que vira sessão de terapia,
mais uma madrugada “esperando agente”.
No papel, você ainda tem 99,9% de disponibilidade.
Na vida real, você tem 100% de irritação.
- O loop infinito: medir, publicar, pedir desculpa, repetir
Tem um padrão aqui que é quase um design pattern:
-
Serviço sofre incidente global/regional.
-
Status page sobe com Degraded / Advisory.
-
Devs xingam no Twitter, Stack Overflow, MS Q&A, GitHub Issues.
-
Sai postmortem bonito, com gráfico, timeline, root cause e ação corretiva.
-
Blog de SRE reforça compromisso com resiliência e aprendizado contínuo.
-
O tempo passa.
-
Novo incidente, novo card de Availability Degradation in <alguma região>.
É quase um cron job de humildade operacional.
E aí entra a pergunta incômoda:
Se você mede qualidade como disponibilidade + latência,
mas não mede desgaste cognitivo do dev,
será que você tá medindo a coisa certa mesmo?
- O que um dev razoável tira disso tudo?
Alguns insights meio amargos, mas úteis:
Hosted agent é fabuloso… até o dia que todo mundo precisa dele ao mesmo tempo.
Ter pelo menos um plano B com self-hosted runners não é luxo, é seguro de renda emocional.
Status “Fully Mitigated” não significa “sua pipeline vai rodar agora”.
Significa “a partir daqui, estatisticamente deve doer menos”.
Postmortem público é ótimo — mas ele não substitui arquitetura de defesa em profundidade.
É bonito ver transparência, mas mais bonito ainda é não precisar ler.
Medir só health check sintético é um convite pro autoengano.
Sinais reais de qualidade: fila de job, tempo pra conseguir agente, taxa de retry por minuto, gente xingando no canal #devops do Slack.
- Fechamento – o PR filosófico que ninguém vai aprovar
Um dia, quem sabe, teremos uma métrica honesta na página de status:
Developer Sanity Index (DSI): 0 a 100
0 = todo mundo escrevendo script de workaround
100 = ninguém lembra onde fica a página de status
Enquanto isso não chega, a gente segue aqui:
olhando pro “Healthy” desconfiando,
lendo blog de 2013 sobre medir qualidade real do serviço,
revisitanto postmortem de 2018 que parece roteiro de hoje,
e recebendo final update dizendo que “retries will succeed”.
Talvez a verdadeira definição de DevOps sênior não seja saber Kubernetes, Terraform ou observabilidade avançada.
Talvez seja olhar pra mais um “Availability Degradation in WEU”, dar um gole no café frio e pensar:
“Ok, qual é o próximo plano de mitigação que eu vou ter que escrever…?”
DevOpsComputaria™
Na teoria, tudo é SRE.
Na prática, é você dando retry.