Quase todo time que começa a falar de confiabilidade escolhe um número que soa bem (99,9%) e cola num dashboard. O problema aparece na primeira reunião difícil: ninguém consegue explicar por que é 99,9% e não 99,5% ou 99,99%, nem o que muda na prática quando esse número é furado. Um SLO assim não orienta decisão nenhuma. É enfeite.
Um bom objetivo de confiabilidade faz o oposto: ele dá ao time permissão para errar dentro de um limite e clareza para frear quando esse limite é ultrapassado. Veja como chegar nele.
Comece pelo que o usuário sente
Antes do SLO vem o SLI (o indicador). E a regra de ouro é medir o que reflete a experiência de quem usa o sistema, não a saúde da máquina. CPU a 80% não é problema se as requisições continuam rápidas e corretas. Latência alta no checkout é problema, mesmo com a CPU tranquila.
Escolha indicadores ligados a uma jornada real: disponibilidade do endpoint que importa, latência no percentil 99, taxa de erros nas requisições que o cliente de fato faz. Se o indicador sobe e o usuário não sente nada, ele está medindo a coisa errada.
O SLO é uma promessa, não um troféu
O alvo deve sair da tolerância do negócio, não da vaidade. Perseguir 100% é o erro mais caro que existe: cada "nove" adicional multiplica o custo e congela a velocidade de entrega. A pergunta certa não é "qual o maior número possível?", e sim "quanto de indisponibilidade o nosso usuário tolera sem que isso vire um problema de negócio?".
Um bom SLO te dá permissão para errar dentro de um limite, e clareza para parar quando passou dele.
Error budget: a peça que falta
Definido o SLO, o error budget (orçamento de erro) é o complemento dele: 100% − SLO. É aqui que o número vira decisão. Enquanto há orçamento, o time pode acelerar, arriscar deploys, experimentar. Quando o orçamento acaba, a prioridade muda automaticamente para estabilidade: sem reunião, sem briga, sem achismo.
Um SLO de 99,9% em 30 dias equivale a cerca de 43 minutos de orçamento de erro por mês. Se um incidente consumiu 30 desses minutos, sobram 13: hora de segurar mudanças arriscadas e proteger o resto do ciclo, em vez de empurrar mais um deploy "rápido".
Quanto cada "nove" custa em tempo
O SLO fica concreto quando você traduz o número em tempo fora do ar. É aí que se entende por que cada "nove" adicional pesa tanto:
| Disponibilidade | Fora do ar / mês | Fora do ar / ano |
|---|---|---|
| 99% | ~7h18 | ~3,65 dias |
| 99,9% | ~43 min | ~8,8 h |
| 99,95% | ~22 min | ~4,4 h |
| 99,99% | ~4,3 min | ~52,6 min |
Subir de 99,9% para 99,99% parece pequeno no papel, mas corta o tempo fora do ar em quase 10× e quase sempre exige redundância, automação e prontidão que custam caro. Escolha o nível que o negócio precisa de verdade, não o maior possível.
Burn rate: o alerta que importa
Em vez de disparar alarme a cada erro isolado, alerte pela velocidade de consumo do orçamento (o burn rate). Gastar 2% do budget em uma hora é ruído; gastar 20% em uma hora é incidente. Alertar por burn rate reduz o ruído e acorda o time só quando a trajetória realmente ameaça o SLO do mês.
Os erros mais comuns
- Copiar o SLO de outro time. O alvo só faz sentido para o contexto e a jornada daquele serviço.
- Medir infraestrutura em vez de experiência. Métrica de máquina não conta a história do usuário.
- Alertar em tudo. Alerta que não exige ação vira ruído, e ruído treina o time a ignorar alerta.
- Definir e esquecer. SLO é vivo: revise quando o produto, a carga ou a expectativa do cliente mudarem.
Onde a IA entra
Com SLO e error budget bem definidos, dá para ir além do gráfico: em projetos de observabilidade, conectamos um agente de AIOps que observa esses sinais, detecta anomalias e remedia incidentes automaticamente (self-healing), agindo antes de alguém ser acordado. O SLO deixa de ser um número no painel e passa a ser o gatilho de uma operação que se defende sozinha.
É exatamente esse tipo de fundação que montamos junto ao time do cliente e deixamos rodando sem depender da gente. Se faz sentido para o seu cenário, vamos conversar.