Blog/Artigos · Operações
Os quatro sinais de ouro, os métodos RED e USE e a boa métrica medida onde o cliente sente, com Prometheus e Datadog.
Yeshayahu usa o prumo do pedreiro como imagem de justiça: o prumo não discute, ele mostra se a parede está reta ou torta, sem opinião. Confiabilidade precisa do mesmo prumo. Um serviço não é confiável porque o time acha que está bom; é confiável quando uma métrica honesta, medida do lado de quem usa, diz que está. O SLI, Service Level Indicator, é esse prumo: o número que reflete a experiência real do usuário, e não o conforto do dashboard interno.
O erro mais comum de monitoramento é medir o que é fácil de coletar, não o que importa. CPU a 90% não diz se o cliente está sofrendo; um checkout que responde em oito segundos diz. O SLI, definido no livro de SRE do Google, é a razão entre eventos bons e o total de eventos válidos, medida no ponto mais próximo possível da experiência do usuário: a latência que ele espera, o erro que ele recebe, a disponibilidade que ele percebe.
A distinção é entre métrica de causa e métrica de sintoma. Uso de disco é causa, útil para diagnóstico; taxa de erro na API é sintoma, o que o usuário sente. SLI é sempre sintoma, porque é a experiência que define confiabilidade. Medir do lado do servidor pode enganar: a requisição que o servidor considera bem-sucedida pode ter chegado tarde demais para o cliente, e é por isso que o melhor ponto de medição é o mais perto possível de quem usa.
O livro de SRE do Google condensou décadas de operação em quatro sinais de ouro que cobrem quase qualquer serviço voltado ao usuário: latência (quanto tempo leva), tráfego (quanta demanda), erros (quanto falha) e saturação (quão cheio está o recurso). Se você só puder instrumentar quatro coisas, instrumente essas, porque juntas elas contam a história da saúde do serviço do ponto de vista de quem usa.
A latência tem uma sutileza que separa o operador maduro do iniciante: nunca use média. A média esconde a cauda, e é a cauda que dói. Meça percentis, p50, p95, p99, porque o p99 de um segundo significa que um a cada cem usuários espera mais que isso, e num serviço grande isso é muita gente sofrendo enquanto a média sorri. O sinal de erro também precisa distinguir erro do usuário de erro do sistema, senão você se alarma com o que não é seu problema.
Dois métodos práticos organizam a instrumentação. O RED, de Tom Wilkie na Weaveworks, é para serviços que atendem requisição: Rate (taxa de requisições), Errors (taxa de erros) e Duration (distribuição de latência). É o que você mede em cada microsserviço para saber se ele está servindo bem. Três números por serviço, e você tem o pulso da malha inteira.
O USE, de Brendan Gregg, é o complemento para recursos: Utilization (quanto do recurso está em uso), Saturation (quanto trabalho está na fila esperando) e Errors (falhas do recurso). RED olha o serviço do lado de quem pede; USE olha o recurso do lado de quem serve. Juntos, cobrem os dois ângulos: quando o RED de um serviço piora, o USE dos seus recursos costuma explicar por quê, e é assim que o SLI vira ponto de partida do diagnóstico, não só do alarme.
| Método | Para | As três medidas | Autor |
|---|---|---|---|
| RED | serviços que atendem requisição | Rate, Errors, Duration | Tom Wilkie |
| USE | recursos (CPU, disco, fila) | Utilization, Saturation, Errors | Brendan Gregg |
| Golden Signals | serviço voltado ao usuário | latência, tráfego, erros, saturação | Google SRE |
Definir bons SLIs é o trabalho de base que sustenta tudo que vem depois. Sem um SLI honesto, o SLO é um alvo sobre areia e o alerta grita pelo motivo errado. Ferramentas como Prometheus, com sua linguagem de consulta, e Datadog, com métricas e traces integrados, coletam e calculam o SLI, mas a escolha de qual medir e onde é decisão de engenharia, não de ferramenta. Instrumentar a coisa errada com a ferramenta certa continua medindo a coisa errada.
O padrão que eu aplico é começar pela jornada crítica do usuário, não pela topologia do sistema. Qual é a ação que, se falhar, o cliente reclama? O login, o pagamento, a busca. Para cada uma, defino o SLI do lado do usuário, meço o percentil que dói e só então penso em objetivo. Foi essa disciplina que, na CRDC, transformou monitoramento de infraestrutura com centenas de falsos positivos em nove SLOs com base em SLI que refletem o que o cliente de fato sente.
A cada nova jornada crítica, o ciclo recomeça. SLI não é projeto que acaba, é a fundação que se mantém.
O SLI é o prumo da confiabilidade: a métrica honesta, medida do lado do usuário, que diz se o serviço está reto ou torto sem opinião. Os quatro sinais de ouro dão o essencial, RED cobre o serviço, USE cobre o recurso, e a jornada crítica define o que medir. Prometheus e Datadog coletam; a engenharia decide o quê e onde. Sem SLI honesto, SLO é alvo sobre areia. A IA propõe o indicador, reduz o falso positivo e liga sintoma a causa, mas escolher o prumo certo continua sendo trabalho de quem opera.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Operaçõesקָו
Buscar 100% de disponibilidade é caro e inútil. O SLO define quanto de confiabilidade basta, e o error budget transforma isso em decisão: quando inovar e quando frear.
Operaçõesנֵר תָּמִיד
Por que AIOps sem SLO vira mais ruído, como o burn rate decide quando acordar alguém e onde o modelo entra na correlação e no diagnóstico.
