Métricas, SLI, SLO e SLA

Transforma “o serviço está confiável?” em números: o SLI mede o que o cliente sente (o PIX deu certo? respondeu em menos de 500 ms?), o SLO fixa a meta (99,9% em 30 dias), o error budget diz quanto de falha ainda cabe, e o alerta dispara pela velocidade com que esse budget está sendo gasto (burn rate), em duas janelas. O SLA é o contrato derivado do SLO, com penalidade.

passos: 6
arquivos: 4
testes: 0
tecnologias: 4

Lógica puraTypeScriptBunElysiaStryker

Cenário Relações Comparar

Baixar cartão

Cenário

A API de PIX tem dois SLOs: 99,9% das requisições com sucesso e 99% com sucesso em menos de 500 ms. Numa simulação de duas horas (20 PIX por minuto), uma queda do SPI faz 1 em cada 4 PIX falhar por 10 minutos: o burn rate chega a 250x e o on-call é acionado. Dez minutos depois da recuperação, a janela de 5 minutos limpa e o page some, mas o ticket fica — a queda precisa de análise. Uma degradação de latência depois aciona o SLO de latência sem tocar o de disponibilidade.

Planta

Fluxo

8/8

8 passos — reproduza para seguir o fluxo

chamada
resposta ou assíncrono
falha
passo
toque num nó para focar
Outras plantas de fluxo

Como funciona

6 passos

Indicador, meta e contrato de serviço.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

/metrics+3

01
apiPixCreate registra cada requisição como evento (quando, sucesso, latência) e expõe contadores e buckets de latência em /metrics
02
sliRatio calcula a fração boa de cada SLI; latência boa exige sucesso e menos de 500 ms
03
errorBudgetMinutes: 99,9% em 30 dias deixa 43,2 minutos de falha; budgetSpent mostra quanto já foi
04
burnRate = fração ruim ÷ fração permitida: 1x esvazia o budget no fim da janela, 14,4x em dois dias
05
alertsFiring exige a janela longa (falha sustentada) e a curta (ainda acontecendo): page em 1h/5m ≥ 14,4, ticket em 6h/30m ≥ 6
06
O relógio é injetadoA demo simula horas de tráfego real em segundos

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

Confiabilidade medida pelo que o cliente sente
Burn rate multi-janela: page rápido para incidente real, silêncio para pico passado
Error budget vira regra: budget gasto congela deploy arriscado
SLA derivado de um SLO medido

Custos

SLI de infraestrutura (CPU, memória) não entra, e engana quem só olha para ele
Janelas e limiares precisam de calibração
Exige acordo entre produto e engenharia sobre o que fazer com ele
O SLO não pode prometer mais que as dependências (BACEN) sustentam

apps/observability/metrics-sli-slo-sla

4 arquivos

src/

slo_math.tsSLIs, SLOs, error budget, burn rate e alertas multi-janela
api_pix.tsAPI de PIX com registro dos eventos, /metrics e comportamento em runtime
config_slo.tsConfiguração validada do ambiente
demo.tsdemoDuas horas simuladas: normal, queda, recuperação e lentidão

Executar · só Bun

$ bun install# dependências
$ bun run demo# roda o cenário
$ bun run test# testes unitários
$ bun run test:mutation# mutação com Stryker
$

Requisitos: Bun

Por que se relacionam

Vem antes

Próximo passo

OTel + OpenObserveTrês sinais num só backend.

Combina com

Teste rápido

Qual é o próximo passo depois de Metrics / SLI / SLO / SLA?

Próximo projeto · Observabilidade & OperaçõesSidecar (Observabilidade)

Contatos

Métricas, SLI, SLO e SLA