bugfix/availability-degraded-again-again #297
Description
bugfix/availability-degraded-again-again
- Introdução leve, irônica ou autozoada
Existe um momento específico na vida do dev em que ele para de perguntar “por que quebrou?”
e começa a perguntar “em qual região?”.
Esse momento geralmente acontece depois da terceira Availability Degradation da semana, quando o café já não esquenta mais, o Slack virou um feed de status pages e o Jira começa a parecer ficção científica.
Foi aí que eu abri a página de status do Azure DevOps.
Não por esperança.
Mas por hábito.
Como quem consulta horóscopo antes do deploy.
- Apresentação da(s) notícia(s)
O que encontrei não foi um incidente.
Foi um catálogo.
Janeiro, dezembro, novembro, outubro…
Europa, West Europe, Central US, UK, Australia, All Geographies™.
Boards. Repos. Pipelines. Test Plans. Artifacts. Core Services.
Tudo Degraded. Sempre Degraded. Nunca Down. Nunca Resolved.
É quase poético.
Porque “Degraded” não é falha.
“Degraded” é um estado de espírito.
Alguns destaques do museu:
VMSS Agent provisioning issues
Agent allocation failures for Windows 2019 images
Cross-region Availability Degradation
Linux clients intermittent failures running git commands
Npm audit commands timing out
Nada explode.
Nada cai totalmente.
Mas nada funciona como deveria.
É a instabilidade educada.
A falha com crachá.
O caos em conformidade.
- Tradução simultânea para o idioma do sofrimento
Vamos traduzir isso para a linguagem real:
Boards Degraded
→ O Jira da Microsoft resolveu filosofar.
Repos Degraded
→ Git clone funciona… às vezes… se você acreditar.
Pipelines Degraded
→ O build roda, mas não hoje. Talvez amanhã. Talvez nunca.
Test Plans Degraded
→ Os testes existem apenas como conceito.
Artifacts Degraded
→ O pacote foi publicado, mas não encontrado.
Schrödinger estaria orgulhoso.
E o mais bonito:
essas degradações não são exceção.
Elas são frequência.
- Opinião pessoal / interpretação filosófica-dev
Existe um mito perigoso no DevOps moderno:
o mito da plataforma estável por definição.
A ideia de que, se algo é “managed”, ele automaticamente é:
resiliente
observável
previsível
Mas o histórico conta outra história.
O que vemos aqui não é azar.
É acúmulo técnico em escala planetária.
Cada “Availability Degradation” é um micro-sintoma de algo maior:
dependências invisíveis
blast radius subestimado
mudança de configuração sem rollback emocional
arquitetura que confia demais no “global”
É o monolito distribuído.
O SPOF geograficamente replicado.
- A normalização do problema
O mais assustador não é a quantidade de incidentes.
É o fato de ninguém mais se assustar.
A conversa virou padrão:
“Tá degradado lá fora.”
“Ah, então é isso.”
“Bora esperar.”
Esperar virou estratégia.
Retry virou padrão arquitetural.
E “works on my machine” foi promovido a SRE.
- A ironia máxima: DevOps sem controle
DevOps nasceu para dar autonomia.
Mas em ambientes totalmente hospedados, você não controla:
quando o agente nasce
quando a VM sobe
quando o storage responde
quando o Git clona
quando o pipeline começa
Você controla só duas coisas:
-
O YAML
-
A ansiedade
Todo o resto é fé.
- O gráfico invisível do sofrimento
Se alguém fizesse um gráfico real, ele mostraria:
Mais degradações em Pipelines do que em qualquer outro serviço
Europa como personagem recorrente
“All geographies” aparecendo quando o problema perdeu o controle
Incidentes curtos, frequentes e distribuídos
Não são apagões.
São micro-cortes.
E micro-cortes constantes matam mais que um blackout.
- O que isso ensina (mas ninguém documenta)
Algumas verdades não escritas:
Hosted agent não é garantia, é conveniência
Global service não é imune, é mais frágil
Status “Degraded” não é neutro, é custo invisível
Retry não é solução, é negação
Esperar não é estratégia, é resignação
Mas isso não entra no README.
Não vira feature.
Não gera OKR.
Só gera atraso.
- O fechamento (commit que ninguém vai aprovar)
No fim do dia, o pipeline volta.
Sempre volta.
O status fica verde.
A memória apaga.
Até o próximo Availability Degradation in Europe.
Ou Central US.
Ou All Geographies, porque sim.
E você, dev cansado, fecha a aba de status e pensa:
“DevOps não falhou.
Ele só ficou degraded.”
E talvez, num momento de lucidez perigosa, você escreva num PR:
“Avaliar self-hosted runners como mitigação estrutural.”
Esse PR não será priorizado.
Mas será verdadeiro.
DevOpsComputaria
Alta disponibilidade é um conceito.
Degradação é uma certeza.