SLIs e SLOs para times sem SRE
Contratar SRE não é pré-requisito para engenharia de confiabilidade. Três SLIs escolhidos com honestidade — disponibilidade, latência, correção — com metas SLO e orçamentos de erro dão a times pequenos o que um muro de dashboards não pode: uma definição compartilhada de «quebrado».
O muro do Grafana tem quarenta e sete painéis. Durante o incidente, ninguém sabia qual importava. A taxa de erro estava elevada em um endpoint não crítico. A latência p99 no checkout estava ok. Um job em background estava vermelho. On-call percorreu painéis por vinte minutos antes de alguém fazer a pergunta que deveria estar respondida antes da alerta disparar: como «quebrado» se parece para este produto? SLIs e SLOs sem time SRE não são headcount — são três números com os quais toda a org de engenharia concorda medir confiabilidade visível ao usuário, mais metas que transformam métricas em decisões.
Site Reliability Engineering popularizou o vocabulário. As práticas não exigem cargos SRE. Uma startup de cinco pessoas com clientes em produção precisa de SLOs mais que um time de cinquenta com plataforma de observabilidade que ninguém configurou. SLOs são decisões de produto expressas como matemática: quão confiável o checkout deve ser, quão rápida a busca deve parecer, com que frequência os dados podem estar errados antes dos usuários irem embora.
SLI, SLO e orçamento de erro em termos simples
| Term | Definition | Example |
|---|---|---|
| SLI (Service Level Indicator) | Proxy mensurável da experiência do usuário | Requests de checkout bem-sucedidos / total de requests de checkout |
| SLO (Service Level Objective) | Faixa alvo para um SLI em uma janela | 99,9% de sucesso no checkout por janela móvel de 30 dias |
| Error budget | Confiabilidade permitida abaixo de 100% | 0,1% = ~43 minutos de downtime/mês a 99,9% |
| SLA (Service Level Agreement) | Compromisso contratual com consequências | Geralmente SLO mais rígido + termos legais — não obrigatório para SLOs internos |
SLIs devem ser mensuráveis, centrados no usuário e honestos — não «CPU abaixo de 80%» mas «requests completando com sucesso abaixo de 500 ms».
SLOs devem ser atingíveis e com dono — um número que ninguém consegue cumprir treina todos a ignorar SLOs.
Orçamentos de erro conectam confiabilidade à velocidade de produto: orçamento restante → enviar features com agressividade. Orçamento esgotado → congelar deploys arriscados, focar em estabilidade. Sem orçamentos de erro, SLOs são pôsteres.
Um dashboard sem SLO é um teste de Rorschach durante incidentes.
Três SLIs com os quais a maioria dos times deveria começar
Não começar com quinze SLIs. Começar com três que mapeiem à dor do usuário.
1. Disponibilidade / taxa de sucesso
SLI = (successful requests) / (total valid requests)
Definir «bem-sucedido» por endpoint — HTTP 2xx/3xx para APIs, conclusão de job para async. Excluir erros de cliente (4xx) salvo quando indicarem má configuração do servidor.
Ponto de partida SLO: 99,9% para API core, 99,5% para caminhos não críticos. Ajustar com base no desempenho real — definir 99,99% quando o atual é 99,5% produz esgotamento permanente do orçamento.
2. Latência
SLI = proportion of requests completing under threshold T
Usar percentis alinhados à experiência do usuário — p95 ou p99, não média. A média esconde latência de cauda que impulsiona churn.
Exemplo SLO: 95% dos requests de busca completam abaixo de 300 ms por 30 dias.
Medir no load balancer ou edge — não só dentro do serviço — para incluir overhead de rede e gateway.
3. Correção / frescor (quando aplicável)
Mais difícil de medir de forma universal. Exemplos:
- Pipeline de dados: % de agregados horários publicados dentro de 15 minutos do fechamento da hora
- Pagamentos: taxa de divergência em reconciliação abaixo de 0,01%
- Índice de busca: % de queries retornando resultados de índice atualizado em 60 segundos
Omitir SLI de correção se ainda não existir contrato de dados claro visível ao usuário. Não inventar um para preencher template.
Implementar SLOs sem time de plataforma de observabilidade
Stack mínimo viável de SLO:
Fonte de métricas. APM existente, Prometheus, métricas do cloud provider ou logs estruturados agregados em séries temporais. Perfeição não é obrigatória — medição consistente sim.
Regras de gravação de SLI. recording_rules do Prometheus, monitores do Datadog ou SQL semanal contra log warehouse — calcular razão SLI sobre janela móvel.
Alertas de burn rate. Alertar quando o consumo do orçamento de erro acelera — não quando o SLO já está quebrado no mês.
| Alert type | When it fires | Purpose |
|---|---|---|
| Fast burn | 2% do orçamento mensal consumido em 1 hora | Página on-call — incidente ativo |
| Slow burn | 10% do orçamento mensal consumido em 6 horas | Ticket — investigar tendência |
| Budget exhausted | 100% consumido | Congelar releases arriscados |
Página de status única. Uma URL ou doc: status SLO atual por SLI, orçamento restante, impacto do último incidente. Atualizado automaticamente se possível.
Feature flags como infraestrutura de release integram com orçamentos de erro — quando o orçamento SLO de checkout está baixo, flags desabilitam caminhos não críticos antes do próximo deploy arriscar outro burn.
Cadência de revisão SLO substitui turismo de dashboards
Revisão SLO semanal ou quinzenal de 30 minutos:
- Orçamento restante por SLI
- Incidentes que consumiram orçamento — causa raiz, fix enviado?
- Correlação com deploys — releases precederam burns?
- Propostas de ajuste de meta SLO — só com dados
Mensal: ainda são os três SLIs certos? Mudanças de produto deslocam o que usuários sentem. SLOs que mediram o produto do ano passado podem não medir o deste ano.
Metas SLO não são permanentes. Apertar quando a confiabilidade melhora e usuários esperam mais. Afrouxar quando as metas eram fantasia — mas metas mais frouxas devem ser decisões de produto explícitas, não rendição silenciosa.
Como times pequenos devem escolher e fazer cumprir SLOs?
Essas perguntas evitam programas SLO que morrem após uma planilha.
Quantos SLIs são suficientes?
Três a cinco para todo o produto no início. Um SLI primário por jornada crítica do usuário — checkout, auth, read path core. Mais SLIs diluem atenção; menos perdem dor real.
Qual política de orçamento de erro times sem SRE devem adotar?
Regra simples: orçamento abaixo de 25% restante → sem deploys arriscados discricionários sem ack explícito. Orçamento esgotado → sprint de estabilidade até o orçamento se recuperar. Escrever a política antes do primeiro esgotamento — não durante a discussão.
SLOs substituem runbooks de on-call?
Não. SLOs dizem que está quebrado e quanto orçamento resta. Runbooks dizem o que fazer. Emparelhar alertas de burn SLO com árvores de decisão de estratégia de rollback — alertas sem ações desperdiçam páginas.
Uma visão oposta
Um argumento frequente sustenta que SLOs são overhead enterprise — que times pequenos deveriam mover rápido e corrigir incidentes quando acontecem em vez de medir confiabilidade matematicamente.
Times pequenos sentem incidentes com mais agudeza porque ninguém mais absorve a dor. SLOs não freiam velocidade — orçamentos de erro autorizam velocidade quando a confiabilidade permite. Sem eles, toda discussão de deploy é subjetiva («parece arriscado») e toda retrospectiva de incidente reinventa o que «quebrado» significa.
O overhead de três SLIs é uma tarde de definição e uma revisão recorrente de trinta minutos. O overhead de quarenta e sete painéis Grafana durante um incidente confuso se mede em confiança do cliente.
Key takeaways
- SLIs medem confiabilidade visível ao usuário; SLOs definem metas; orçamentos de erro conectam confiabilidade a decisões de release.
- Começar com três SLIs: disponibilidade, latência e correção/frescor quando aplicável.
- Alertas de burn rate disparam antes do orçamento mensal esgotar — fast burn pagina, slow burn abre ticket.
- Metas SLO devem ser atingíveis — metas fantasia treinam times a ignorar SLOs.
- Política de orçamento de erro bloqueia deploys arriscados com orçamento baixo — escrever a política antes do primeiro esgotamento.
- Revisar SLOs quinzenalmente; ajustar metas e seleção de SLI conforme o produto evolui.
Conclusion
Um time SRE é um modelo de staffing, não pré-requisito de confiabilidade. SLIs e SLOs são como times concordam o que quebrado significa antes do pager disparar — três indicadores honestos, metas ancoradas no desempenho atual e orçamentos de erro que fazem da confiabilidade um input para decisões de envio em vez de arrependimento pós-incidente.
O exercício da tarde: escolher a jornada do usuário cujo fracasso terminaria mal a semana. Definir seu SLI. Fixar um SLO com dados do mês passado. Configurar um alerta de burn rate. Todo o resto é iteração.