Escrito em · 3 min de leitura
A Torre de Babel da observabilidade: por que três técnicos chegam a três diagnósticos
Painéis e alertas não dizem se um serviço está bom ou ruim. Sem uma régua combinada antes do incidente, cada pessoa mede de um jeito e a equipe discute opinião em vez de resolver.
Uma videoconferência importante começa a travar. Três técnicos são chamados para descobrir o motivo.
O primeiro vai até a sala, roda um teste e conclui: "O link está normal. Perdi só 3% dos pacotes e a latência ficou em 52 milissegundos. O problema deve estar do outro lado da chamada."
O segundo olha outros gráficos, de longe, e concorda: "A conexão está aceitável. Vamos esperar o retorno do outro participante."
O terceiro mede a variação no tempo de entrega dos pacotes, o jitter, até a nuvem do serviço de vídeo. Encontra 45 milissegundos e diz: "Com essa variação, vídeo em tempo real não funciona daqui. O problema é a nossa conexão."
Os três mediram coisas reais. Chegaram a conclusões opostas. E a equipe pode passar a próxima hora discutindo quem tem razão, enquanto a reunião continua travando.
O problema não é falta de dado
Os três tinham ferramentas: um terminal, um painel de alertas e dezenas de gráficos. O que faltava era uma resposta simples para a pergunta que importa: este serviço está conforme ou degradado?
A maioria das plataformas de observabilidade entrega visibilidade e transfere para quem usa a tarefa de definir o que é "saudável". Configurar alertas e painéis não responde a essa pergunta sozinho. Quem implementa costuma conhecer bem o software, mas raramente tem tempo para perguntar:
- Como medir isto do jeito certo?
- A partir de qual valor está ruim?
- Qual é a referência para esse limite?
- A medição da ferramenta A é comparável à da ferramenta B?
- Se eu precisar contestar um fornecedor, minha medição se sustenta?
Uma régua combinada antes do incidente
Pense no termômetro de casa. Ele mostra um número, mas é a regra combinada antes que diz o que fazer: acima de 37,8 °C, é febre. Ninguém discute na hora.
Em engenharia de confiabilidade, o número medido se chama SLI (indicador de nível de serviço) e a regra combinada se chama SLO (objetivo de nível de serviço). Quando o SLI sai da faixa do SLO, há um incidente. Quando está dentro, o serviço está saudável. A subjetividade sai da conversa.
Com a régua definida, um técnico júnior e um engenheiro sênior olham o mesmo alerta e chegam à mesma conclusão.
De onde vem a régua
Uma régua só tem valor se puder ser defendida. Por isso, cada limite precisa de uma origem conhecida, e não da preferência de quem configurou a ferramenta. Alguns exemplos de referência:
- Atraso e perda de pacotes medidos conforme as RFC 7679 e 7680 do IETF, que definem como fazer essas medições.
- Qualidade de links comparada ao contrato com a operadora e ao regulamento de qualidade da Anatel (Resolução nº 717/2019).
- Tensão elétrica comparada às faixas do Módulo 8 do PRODIST, da Aneel.
- Temperatura de entrada de ar dos servidores comparada à faixa recomendada pela ASHRAE, de 18 °C a 27 °C.
O que muda na prática
No caso da videoconferência, uma régua para jitter em serviços de tempo real teria mostrado "degradado" na primeira medição. O debate não começaria.
O mesmo vale para quem decide. Gestores recebem um estado claro em vez de um gráfico para interpretar. A área jurídica recebe medições com método conhecido, que podem embasar uma conversa com fornecedor. E a operação deixa de depender do "especialista herói" que sabe ler os painéis.
Este texto nasceu de um documento interno da Condor Labs, nosso núcleo de pesquisa e desenvolvimento, sobre como medir saúde operacional com base em normas.