SLOs que não mentem: medir o que os utilizadores realmente sentem

A maioria dos dashboards de fiabilidade está verde enquanto os utilizadores praguejam contra o ecrã. O SLO diz 99,95%, os gráficos de CPU estão calmos — e o checkout está a falhar há dez minutos. Essa folga é o sinal: o SLO está a medir o sistema, não a pessoa que o usa. Um SLO só diz a verdade quando mede aquilo que o utilizador realmente sente.

Mede o que o utilizador sente, não a máquina

CPU, memória e uptime do host não são experiência do utilizador. Uma máquina pode estar a 30% de CPU enquanto todos os pedidos dão timeout; pode correr a 95% e servir toda a gente na perfeição. O único juiz de se o teu serviço funciona é o utilizador — por isso o indicador tem de vir do lado dele do fio. Constrói SLOs sobre o percurso (o pedido teve sucesso, foi suficientemente rápido, a resposta estava correcta e actual), nunca sobre a infra-estrutura por baixo.

Um service level indicator (SLI) é um desses números: a proporção de eventos bons sobre o total de eventos. A maioria dos serviços precisa só de três:

Disponibilidade — a fracção de pedidos válidos que tiveram sucesso.
Latência — a fracção servida mais depressa do que um limiar que os utilizadores notam, p. ex. 95% abaixo de 300 ms.
Qualidade ou frescura — para dados e trabalho assíncrono, quão correcto ou quão recente é o resultado.

Dois hábitos mantêm isto honesto. Usa percentis, não médias — uma média saudável esconde a cauda lenta onde os utilizadores reais aterram, por isso cita p95/p99. E mede o mais perto do utilizador que conseguires — o load balancer, a edge, o monitoramento de utilizador real — porque as métricas do lado do servidor nunca vêem falhas de DNS, problemas de CDN, ou o pedido que nunca chegou.

Se os percentis parecem difusos: a latência p95 é o tempo de resposta abaixo do qual ficam 95% dos pedidos — ou seja, 1 em cada 20 utilizadores espera mais — e p99 é o 1% mais lento. Uma média mistura a maioria rápida e os poucos lentos num único número que ninguém de facto experimenta; um percentil mantém essa cauda à vista.

Os mesmos pedidos, duas histórias: a média senta-se no meio confortável enquanto p95/p99 vivem lá fora na cauda longa — que é exactamente onde está uma fatia de utilizadores reais. Cita os percentis e mede-os o mais perto do utilizador que conseguires.

As médias escondem utilizadores avariados tão facilmente como os lentos. Uma taxa de sucesso de 99,5% lê-se como um arredondamento longe da perfeição — mas, ao longo do tráfego real, essa fracção é um fluxo constante de pessoas a bater em falhas, normalmente amontoadas num segmento que o número global não consegue ver. Tens de conseguir sempre decompor um SLI por percurso, plataforma e região.

0,5% de erros parece inofensivo até contares os utilizadores por trás — e reparares que as falhas não estão distribuídas por igual. Decompor o SLI por segmento é o que faz aparecer a parte do produto que está mesmo a arder.

Um SLO por percurso — com dono e etiquetado

Os SLOs seguem percursos do utilizador, não o teu organigrama nem serviços individuais. Define um por percurso — checkout, login, pesquisa — e resiste a juntá-los num único número para todo o site: um SLO global fica verde enquanto o checkout está partido, porque os assets estáticos saudáveis abafam as falhas que importam. E dá a cada percurso o objectivo que merece; um caminho de pagamento e um widget de recomendações não precisam da mesma fiabilidade.

Cada percurso tem o seu próprio SLO e o objectivo de que realmente precisa. O orçamento de erro é o crédito da equipa dona, e etiquetas consistentes (serviço · equipa · percurso) agregam cada SLI até quem pode agir sobre ele.

O orçamento de erro — a folga entre o teu objectivo e os 100% — torna-se então a moeda da equipa dona. As equipas são em larga medida isoladas, e algumas superfícies absorvem muito mais falha do que outras, por isso deixa cada equipa deter e gastar o seu próprio orçamento: compra velocidade quando há margem e obriga a focar na fiabilidade quando se esgota. Nada disto funciona sem etiquetagem disciplinada — cada métrica, recurso e alerta rotulado com serviço, equipa e percurso — para que cada SLI agregue ao dono certo e um orçamento a arder aponte directamente para a equipa que o pode corrigir.

Define um objectivo que consigas defender

Não saltes para os 99,99% por reflexo. Cada nove a mais é exponencialmente mais caro, e um objectivo que não vais realmente financiar é só mais uma mentira no dashboard. Escolhe o número de que o percurso genuinamente precisa — e mantém o teu SLO interno mais rigoroso do que qualquer SLA que tenhas assinado, para descobrires antes do cliente.

Um SLO de 99,9% ao longo de 30 dias permite cerca de 43 minutos de 'mau' por mês. Esse número é a questão toda: transforma 'somos suficientemente fiáveis?' de uma discussão numa conta de aritmética.

E não tentes acertar no número perfeito no primeiro dia — não consegues. Define-o demasiado alto e vives permanentemente fora do orçamento; demasiado baixo e não significa nada. Começa por medir onde realmente estás, define o objectivo logo acima da realidade de hoje, e trata-o como um chão móvel: em cada revisão semanal ou mensal a equipa de SRE olha para o que aguentou e, se o serviço melhorou, sobe a fasquia um nível. O SLO sobe ao ritmo de cada sprint — cada passo um nível que sustentaste genuinamente, não um que desejaste.

Define o objectivo logo acima de onde estás, e depois ergue-o em cada revisão. A fasquia sobe à medida que o serviço sobe — passo a passo ficas mensuravelmente melhor, e cada objectivo é um que realmente aguentaste.

Faz do orçamento uma regra de decisão

Um orçamento de erro só se justifica quando muda comportamentos, e a regra tem de ser acordada de antemão. Sobrou orçamento: lança, faz a migração arriscada, corre o teste de carga em produção. Orçamento gasto: congela alterações arriscadas e mete o próximo sprint em fiabilidade até voltares ao verde. Revisto semanalmente, transforma a fiabilidade de uma sensação numa decisão partilhada e com dono.

Alerta no percurso, navega até à causa

Como o SLO mede o percurso, é a única coisa por que vale a pena ser chamado. O alerta dispara num consumo de orçamento visível para o utilizador e abre o dashboard do percurso — taxa de sucesso, p95, orçamento restante. A partir daí navegas para baixo: para os dashboards de serviço dos componentes no caminho, e depois para os recursos dependentes — base de dados, cache, fila, API a montante. Ver essas dependências é valiosíssimo para o diagnóstico; nunca é motivo para chamar alguém. Etiquetas consistentes são o que torna essa descida possível — deixam um dashboard em template ligar ao seguinte, em vez de te deixarem com um monte de ecrãs desligados.

Alerta no SLO visível para o utilizador, no topo — a única coisa que deve acordar alguém. O alerta abre o dashboard do percurso, que liga para baixo aos serviços e depois aos recursos dependentes, onde fazes o diagnóstico.

O SLO é também a entrada do teu alerting: alimenta a taxa de consumo do orçamento em alertas multi-janela, para que um soluço breve seja um rodapé e um consumo sustentado seja uma chamada (abordo esse mecanismo em 'Desenhar alertas que ninguém ignora'). A cadeia de dashboards leva-te então da chamada à causa em três cliques, não trinta.

Calcula-o automaticamente

Nada disto deve ser mantido à mão. Calcula os SLIs a partir da telemetria que já tens — Prometheus, Datadog, logs do load balancer — como recording rules, e mostra um painel por percurso: SLI actual, objectivo, orçamento restante, taxa de consumo. Se produzir o número for manual, vai apodrecer; se for automático, torna-se a coisa que toda a gente verifica primeiro.

A telemetria que já recolhes alimenta recording rules que calculam o SLI por janela, mostradas como um mosaico ao vivo por percurso — SLI actual, objectivo, orçamento restante, taxa de consumo.

Por baixo do capô, o SLI é uma pequena query: conta os pedidos, conta os erros, divide. Define-o uma vez como recording rule e cada dashboard e alerta reutiliza o mesmo número.

# A — pedidos ao longo da janela
- record: checkout:requests:rate5m
  expr: sum(rate(http_requests_total{job="checkout"}[5m]))

# B — erros (HTTP 5xx) na mesma janela
- record: checkout:errors:rate5m
  expr: sum(rate(http_requests_total{job="checkout", code=~"5.."}[5m]))

# C — percentagem de erro = B / A  (a fatia "ma" do SLI)
- record: checkout:error_pct5m
  expr: 100 * checkout:errors:rate5m / checkout:requests:rate5m

# A = pedidos · B = erros · C = 100 * B / A  (% de erro)
100 * (
  sum:http.requests.errors{service:checkout}.as_count()
  / sum:http.requests.hits{service:checkout}.as_count()
)

Revê e faz evoluir

Os SLOs são promessas vivas, não uma folha de cálculo de uma vez. Revisita os objectivos à medida que o produto e as expectativas dos utilizadores mudam. Um orçamento que nunca gastas significa que o objectivo é demasiado baixo — ou que estás a investir de mais em fiabilidade que ninguém pediu; um orçamento que rebentas todos os meses significa que o objectivo é irrealista ou que o serviço precisa de trabalho a sério. O SLO certo fica onde, de vez em quando e de forma útil, dói.

Um SLO que mede o utilizador, definido num número que vais realmente financiar, com dono na equipa que o consegue mover, e ligado a alertas que descem directamente à causa — isso é um SLO que diz a verdade. Todo o resto é uma luz verde por cima de um edifício a arder.