SLIs e SLOs mal definidos: por que geram alertas falsos

O custo oculto do monitoramento sem contexto#

Em muitos times, o problema não é a falta de métricas, dashboards ou ferramentas de observabilidade. O problema é mais profundo: ninguém definiu com precisão o que significa o serviço estar “bem”.

Quando isso acontece, o resultado é previsível: alertas que não importam, ruído constante, um time de plantão (on-call) sobrecarregado e, o mais grave, incidentes reais que passam despercebidos no meio de tanto ruído.

A raiz quase sempre é a mesma: SLIs e SLOs mal definidos. Confunde-se telemetria interna com experiência do usuário e acaba-se construindo um sistema de alertas que reage a sintomas irrelevantes enquanto ignora os que realmente afetam o negócio.

A fadiga de alertas não é um problema cultural nem de disciplina do time. É um problema de design dos indicadores. Se todo page que chega às 3 da manhã termina em “não havia nada a fazer”, o time aprende a ignorá-los, e um dia ignora justamente o que importava. Este guia explica como quebrar esse ciclo, da definição dos indicadores até a regra de alerta.

Documentação: Google SRE Book · Monitoramento de sistemas distribuídos ↗ · Google SRE Book · Service Level Objectives ↗

SLI, SLO e error budget em dois minutos#

Um SLI (Service Level Indicator) é uma medida quantitativa de algum aspecto do nível de serviço que o usuário recebe. A forma mais útil de expressá-lo é como proporção: eventos bons divididos por eventos válidos. Por exemplo, a porcentagem de requisições de checkout que respondem sem erro.

Um SLO (Service Level Objective) é a meta para esse indicador em uma janela de tempo. Por exemplo: 99,9 % das requisições de checkout bem-sucedidas em uma janela móvel de 30 dias.

O error budget é o complemento do SLO: 1 − SLO. Com um SLO de 99,9 %, o orçamento de erro é 0,1 %. Em 30 dias, isso equivale a cerca de 43 minutos de indisponibilidade total, ou ao equivalente distribuído em erros parciais. Essa margem não é um fracasso: é o espaço que o time pode “gastar” com deploys, experimentos e falhas inevitáveis.

Essa mudança de foco é o que torna os SLOs úteis. Você deixa de perseguir 100 % de disponibilidade, o que é caro e desnecessário para quase qualquer produto, e passa a buscar um equilíbrio explícito entre confiabilidade e velocidade de entrega. E, acima de tudo, o error budget define quando um problema realmente importa.

Documentação: Google SRE Book · Service Level Objectives ↗ · Google SRE Workbook · Implementando SLOs ↗

O erro de base: medir o que é fácil, não o que importa#

Até aqui, tudo parece razoável. O problema começa quando o SLI é mal escolhido. Muitos times monitoram CPU alta, uso de memória, número de pods ou erros internos que o usuário nunca vê. Isso não é confiabilidade do ponto de vista do usuário: é telemetria interna, útil para diagnosticar, mas não para decidir se alguém precisa acordar.

Um bom SLI responde a uma única pergunta: o usuário conseguiu fazer o que precisava, corretamente e a tempo? Se o indicador não responde a isso, você está medindo a coisa errada. O usuário não se importa com a sua CPU; ele se importa se conseguiu pagar.

Os SLIs centrados no usuário costumam se encaixar em quatro famílias: disponibilidade (funciona?), latência (é rápido?), qualidade ou correção (a resposta está certa?) e completude ou atualização (o fluxo terminou, os dados estão em dia?). Para latência, use percentis como p95 ou p99 em vez de médias: a média esconde a cauda lenta, que é justamente onde estão os usuários com a pior experiência. Para calcular percentis com Prometheus, você precisa de histogramas bem definidos, com buckets próximos do limite do seu SLO.

Documentação: Google SRE Book · Service Level Objectives ↗ · Prometheus · Histogramas e summaries ↗

Por que surgem os alertas falsos#

Alertas falsos não são um problema de limite: são um problema de significado. Eles surgem quando a métrica não representa impacto real, quando o SLO não reflete a experiência do usuário ou quando o sistema alerta sobre causas em vez de consequências.

O exemplo clássico: a CPU sobe e um alerta dispara, mas o sistema continua respondendo perfeitamente. Ninguém deveria acordar por isso. O livro de SRE do Google formula isso como a diferença entre sintomas (o que está quebrado para o usuário) e causas (por quê). Alerte por sintomas; investigue as causas com dashboards.

Por isso vale separar duas funções que muitos times misturam: monitorar e alertar. Nem tudo o que é medido deve gerar um alerta.

Monitoramento, para entender e investigar o sistema:

• CPU, memória e uso de recursos.
• Logs e traces.
• Retentativas, timeouts e comportamento interno.
• Filas, throughput e saturação.

Alertas, para provocar uma ação humana:

• Queda real de disponibilidade em uma jornada crítica.
• Degradação sustentada de latência que afeta usuários.
• Consumo acelerado do error budget.

Quando essa separação não existe, tudo se mistura. E quando tudo dispara alerta, nada é realmente importante.

Documentação: Google SRE Book · Monitoramento de sistemas distribuídos ↗

A solução: alertar por burn rate, não por limites estáticos#

Os alertas tradicionais do tipo “latência > X”, “erros > Y” ou “CPU > Z” não consideram contexto nem impacto acumulado. Eles disparam por picos de um minuto, por eventos irrelevantes e por situações que não exigem ação.

O burn rate mede a velocidade com que você consome o error budget em relação ao SLO. Um burn rate de 1 significa que, nesse ritmo, você gastaria exatamente todo o orçamento no fim da janela. Um burn rate de 14,4 sustentado por uma hora consome 2 % do orçamento mensal e, se continuar, o esgota em pouco mais de dois dias. Isso, sim, merece um page.

O Google SRE Workbook recomenda combinar várias janelas e vários burn rates: uma janela longa para confirmar que o problema é significativo e uma curta para que o alerta pare de disparar rapidamente quando o problema acaba. Os valores iniciais que ele propõe para um SLO de 30 dias são 14,4 em 1 hora (com janela curta de 5 minutos) e 6 em 6 horas (com 30 minutos) como pages, e 1 em 3 dias (com 6 horas) como ticket. Assim você detecta tanto quedas graves quanto degradações lentas, mas perigosas.

groups:
  - name: slo-checkout-recording
    rules:
      # SLI de disponibilidade expresso como taxa de erros: 5xx / total.
      - record: job:slo_errors_per_request:ratio_rate5m
        expr: |
          sum by (job) (rate(http_requests_total{job="checkout-api",code=~"5.."}[5m]))
          /
          sum by (job) (rate(http_requests_total{job="checkout-api"}[5m]))
      # Repita a mesma regra trocando a janela: 30m, 1h, 6h e 3d.
      - record: job:slo_errors_per_request:ratio_rate1h
        expr: |
          sum by (job) (rate(http_requests_total{job="checkout-api",code=~"5.."}[1h]))
          /
          sum by (job) (rate(http_requests_total{job="checkout-api"}[1h]))

  - name: slo-checkout-alerts
    rules:
      # SLO 99,9 %: orçamento de erro = 0,001.
      - alert: CheckoutErrorBudgetBurnFast
        expr: |
          (
            job:slo_errors_per_request:ratio_rate1h{job="checkout-api"} > (14.4 * 0.001)
            and
            job:slo_errors_per_request:ratio_rate5m{job="checkout-api"} > (14.4 * 0.001)
          )
          or
          (
            job:slo_errors_per_request:ratio_rate6h{job="checkout-api"} > (6 * 0.001)
            and
            job:slo_errors_per_request:ratio_rate30m{job="checkout-api"} > (6 * 0.001)
          )
        labels:
          severity: page
        annotations:
          summary: "O checkout está consumindo o error budget rápido demais"
      - alert: CheckoutErrorBudgetBurnSlow
        expr: |
          job:slo_errors_per_request:ratio_rate3d{job="checkout-api"} > 0.001
          and
          job:slo_errors_per_request:ratio_rate6h{job="checkout-api"} > 0.001
        labels:
          severity: ticket

Repare em dois detalhes que costumam falhar em implementações copiadas: cada janela usada em um alerta precisa da sua própria recording rule (se faltar uma, a expressão simplesmente nunca dá match) e o limite é expresso como burn rate multiplicado pelo orçamento, não como uma porcentagem fixa de erros.

Para se aprofundar: Como reduzir a sua fatura do Datadog com OpenTelemetry

Documentação: Google SRE Workbook · Alertas baseados em SLOs ↗ · Prometheus · Recording rules ↗ · Prometheus · Alerting rules ↗

Como redefinir seus SLIs e SLOs passo a passo#

• Identifique as jornadas críticas do usuário. Liste os fluxos que geram valor direto: login, checkout, busca, carregamento de relatórios. Não os processos internos do sistema, e sim os que o usuário final executa.
• Defina o que significa sucesso em cada fluxo. Não basta responder: é preciso responder corretamente e dentro de um tempo aceitável. Por exemplo, login bem-sucedido em menos de 500 ms.
• Expresse cada SLI como proporção. Eventos bons sobre eventos válidos: requisições não 5xx sobre o total, ou porcentagem de respostas abaixo do limite de latência. Proporções se encaixam direto na matemática do error budget e continuam estáveis mesmo quando o tráfego muda.
• Defina SLOs realistas a partir de dados históricos. Não escolha 99,99 % porque soa bem. Analise o comportamento real dos últimos meses e defina uma meta exigente, mas alcançável. Uma janela móvel de 30 dias suaviza picos pontuais.
• Alerte por burn rate, com várias janelas. Troque os limites estáticos por alertas de consumo do orçamento, como no exemplo anterior.
• Combine uma política de error budget. Defina o que acontece quando ele se esgota: congelar deploys não urgentes, priorizar trabalho de confiabilidade em vez de features, revisar o postmortem. Sem essa política, o SLO é só um número em um dashboard.
• Revise e ajuste periodicamente. Os SLIs evoluem junto com o produto. O que era crítico seis meses atrás pode não ser hoje; revise indicadores e metas com o time de produto, por exemplo a cada trimestre.

Documentação: Google SRE Workbook · Implementando SLOs ↗ · Google SRE Workbook · Política de error budget ↗

Sinais de que seus SLOs estão mal definidos#

Alguns sinais são óbvios; outros exigem honestidade técnica:

• Alertas constantes, mas poucos incidentes reais.
• Alertas fora do horário que, ao serem analisados, não têm impacto perceptível para os usuários.
• O time de plantão parou de ler os pages.
• Os dashboards estão verdes enquanto os tickets de suporte aumentam.
• Os postmortems revelam que nenhum monitor automático detectou o incidente: foram os usuários que avisaram.
• Há SLIs demais e nenhum tem prioridade.

O teste mais confiável é o do dashboard verde: se tudo aparece verde, mas os usuários relatam problemas no suporte ou nas redes sociais, seus SLIs estão desconectados da experiência real.

Também vale medir o seu próprio sistema de alertas. Três indicadores simples: que proporção de pages termina sem nenhuma ação, quanto tempo a pessoa de plantão leva para decidir se um alerta é real e quantos incidentes o monitoramento detecta primeiro, em comparação com os que os usuários relatam. Se os pages sem ação são frequentes, se decidir leva tempo demais ou se os usuários chegam antes dos seus alertas, o problema está nos indicadores, não nas pessoas.

Documentação: Google SRE Book · Monitoramento de sistemas distribuídos ↗

Checklist antes de ativar o seu próximo SLO#

Se o seu time está discutindo se aumenta o limite de CPU ou amplia a janela de avaliação, provavelmente está otimizando o indicador errado. Aplique esta verificação a cada serviço crítico antes de ativar novos alertas:

• O SLI mede um resultado, não um esforço: reflete uma ação concluída pelo usuário, por exemplo a porcentagem de checkouts com resposta bem-sucedida em menos de 500 ms.
• O SLO foi validado com dados reais: você analisou o cumprimento histórico do SLI e a meta é alcançável, mas exigente.
• Os alertas usam burn rate com janela longa e curta, para antecipar o esgotamento do orçamento sem reagir a picos isolados.
• Todo alerta que pode acordar alguém está atrelado a um SLO. Os que não estão vão para dashboard ou notificação informativa, ou são eliminados.
• Existe uma política de error budget combinada com o time de produto.

Regra prática para validar qualquer SLI: pergunte a si mesmo “se este indicador for cumprido, o usuário teve uma boa experiência?”. Se a resposta não for um sim claro e direto, substitua-o por um que meça o resultado de uma ação crítica: checkout concluído, login bem-sucedido, busca com resultados.

Documentação: Google SRE Workbook · Implementando SLOs ↗

Conclusão: o problema não é a quantidade de alertas#

O problema não é ter muitos ou poucos alertas; é ter alertas que não significam nada. Um bom sistema de confiabilidade não mede infraestrutura, mede experiência. E um bom sistema de alertas não detecta qualquer anomalia: detecta risco real.

Quando os SLIs e SLOs estão mal definidos, as consequências vão além do ruído: burnout do time de plantão, decisões baseadas em sinais errados, perda de confiança no monitoramento, incidentes mais longos e menos tempo para melhorar o produto. O mais perigoso é que o sistema pode parecer “bem” nas métricas internas enquanto os usuários já estão tendo uma experiência ruim.

Nem o autoscaling nem uma ferramenta nova resolvem isso. Tudo começa por definir com clareza o que significa o seu serviço funcionar.