SLOs para sistemas de alta performance
· 8 min
É comum um time definir uma meta de performance, "p99 abaixo de 200ms", sem distinguir com clareza o que exatamente está sendo medido, prometido, ou orçado. Essa confusão entre termos parecidos é a raiz da maioria dos SLOs que ninguém consegue agir em cima.
SLI, SLO e SLA não são a mesma coisa
SLI é o indicador medido de fato, latência de requisição, por exemplo. SLO é a meta interna pra esse indicador, 99% das requisições abaixo de 200ms ao longo de 30 dias. SLA é a promessa externa, muitas vezes contratual, com consequência formal em caso de violação. Confundir os três leva ou a SLAs conservadores demais, ou a SLOs que ninguém consegue realmente usar pra decidir nada no dia a dia.
Error budget: a métrica que decide, não só descreve
Error budget é simplesmente 100% menos o SLO, a quantidade de falha que já está aceita de antemão. Isso transforma uma meta estática numa ferramenta operacional: com orçamento sobrando, o time pode assumir mais risco em releases; com o orçamento estourado, a prioridade vira estabilidade até ele se recompor.
Por que o percentil errado é pior que nenhum SLO
Escolher o percentil certo importa: p50 esconde exatamente os problemas de cauda que afetam desproporcionalmente uma fração real de usuários, enquanto p999 pode ser tão rígido que fica dominado por ruído e outliers sem relação com degradação real. A escolha certa depende do volume de requisições e de quanto uma requisição lenta isolada realmente custa pro negócio.
Definindo um SLO que sobrevive ao primeiro incidente
Um bom SLO é um que dá pra violar ocasionalmente sem virar emergência, está amarrado a uma consequência real pro usuário, e é revisado com dados de tráfego real em vez de escolhido uma vez e esquecido.