SLA, SLO e KPI confiabilidade

1) Termos e diferenças

O SLI (Service Level Indicator) é um indicador de qualidade medido (por exemplo, proporção de pedidos bem-sucedidos, p95 latência).
SLO (Service Level Objectiva) - Destino SLI por janela de tempo (por exemplo, "sucesso ≥ 99. 9% em 28 dias").
Erro de orçamento - taxa de não cumprimento do SLO: '1 - SLO'.
SLA - obrigações contratuais com multas/empréstimos (externos).
KPI de confiabilidade - métricas operacionais de processo (MTTD/MTTA/MTTR/MTBF,% de mitigates automáticos, revestimento de alertas etc.).

2) Como escolher o SLI (baseado em Golden Signals)

1. Latency - p95/p99 para endpoints-chave.
2. Traffic - RPS/RPM/fluxo de mensagens.
3. Errors - 5xx/erros de negócios (por exemplo, pagamentos «decline por culpa PSP» excluir).
4. Saturation - Saturação de recursos (CPU/RAM/IO/lag).

• Correlaciona com a experiência do usuário (user-perceived).
• Está tecnicamente disponível e estável na medida.
• Controlando (pode haver melhorias).
• Baixo custo de recolha.

3) Fórmulas e exemplos

3. 1 Disponibilidade (availability)

Availability = Успешные запросы / Все запросы
Error Budget (за период) = 1 − SLO

Exemplo: SLO 99. 9% para 30 dias → orçamento de erros = 0. 1%, o equivalente a 43 min 12 segundos de indisponibilidade.

3. 2 Latitude

Latency SLI = доля запросов с duration ≤ T
SLO пример: 99% запросов ≤ 300 мс (rolling 28d)

3. 3 Pagamentos (nível de negócios)

Payment Success SLI = (успешные проводки — внешние отказы PSP) / все попытки

4) Orçamento errado e burn-rate

Erro de orçamento - seu «tanque de combustível» para inovação (lançamentos, experiências).

• canal rápido (detecção por £1 h),
• canal lento (tendência por £6-12 h/24 h).

• Se o burn-rate> 14. 4 em 1 hora - SEC-1 (comemos o orçamento diurno por £100 min).
• Se o burn-rate> 6 em 6 horas é o V-2 (degradação rápida).

5) Alerting por SLO (multi-window, multi-burn)

Indicador de erro: 5xx ou distúrbios de latência.

promql
Доля ошибок за 5 минут sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Быстрый burn (1m окно)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14.4

Медленный burn (30m окно)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

promql p95 latency histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) Exemplos de SLI/SLO sobre domínios

6. 1 passarela API/Edge

SLI-Errors: proporção de respostas 5xx <0. 1% (28d).
SLI-Latency: p95 ≤ 250 ms (dia).
SLO: Availability ≥ 99. 95% (quarteirão).

6. 2 Pagamentos

O SLI-Sucess: Um recuo de sucesso (excluindo as falhas de clientes) ≥ 99. 8% (28d).
SLI-Latency: autorização ≤ 2 segundos para 99% (dia).
SLO: Time-to-Wallet p95 ≤ 3 мин (24h).

6. 3 Bancos de dados (PostgreSQL)

SLI-Lag: liga de replicação p95 ≤ 1 segundo (dia).
SLI-Errors: taxa de erro de solicitação ≤ 0. 05% (28d).
SLO: disponibilidade do cluster ≥ 99. 95%.

6. 4 Filas/Streaming (Kafka)

SLI-Lag: classe de consumo p95 ≤ N mensagens (hora).
SLI-Durability: confirmação de registro ≥ 99. 99% (28d).
SLO: disponibilidade de corretores ≥ 99. 9%.

7) KPI processo de confiabilidade

MTTD (Mean Time To Detect)

MTTA (… To Acknowledge)

MTTR (… To Restore)

MTBF (… Between Failures)

% dos incidentes de mitigação automática

Revestimento SLO/alertas de alta circulação (≥ de destino de 95%)

Proporção de lançamentos em fase canária

Consumo de orçamento errado por comandos/fichas

8) Como colocar SLO realista

1. Mede a confiabilidade básica atual (3-4 semanas).
2. Defina os caminhos «sensíveis» do usuário (login, depósito, jogo).
3. Leve em conta o custo de cada desvantagem (tempo, dinheiro, reputação).
4. Escolha uma meta ambiciosa, mas alcançável (uma melhora de 10% a 30% para a meta básica).
5. Reveja trimestralmente.

• «Cinco donzelas» sem justificativa.
• SLO por métricas não visíveis para o usuário (por exemplo, CPU sem vínculo com UX).
• Há muito SLO → pulverizar o foco.

9) Relatórios SLO e orçamentos

• Execução de cada SLO: alvo vs, tendências, confidence.
• Resumo do consumo de erros: quanto orçamento «queimado» do que, quem (lançamento/incidente).
• Top cinco causas de degradação, plano CAPA e status de tarefas.
• Impacto no negócio de conversão, ND, retenção, LTV.

10) Conexão com política de lançamento

Orçamento de erro <50% → lançamentos livres.
50-80% → «modo cauteloso» - apenas low-risk/canários.

11) SLA (contratual) - modelos de itens

Obrigação de disponibilidade, por exemplo, 99. 9 %/mês.
Exceções (Force Majeure): DDoS fora de controle razoável, provedores de terceiros.
Janela de medição e área de responsabilidade: fontes de métricas, método de cálculo.
Créditos/multas: tabela de níveis (por exemplo, indisponibilidade de 60-120 min → crédito X%).
Procedimentos de escalação e notificação: prazos, canais.
Dados e privacidade, camuflagem, armazenamento, Legal Hold.
Plano de trabalho para evitar repetições (CAPA) em caso de violação.

12) Ferramentas de medição

Métricas passivas: Prometheus/Mimir/Thanos, exportadores.
Logi: Loki/ELK para contagem de sucesso/erro no nível de negócios.
Sintético: amostras ativas (login/depósito/jogo) por cron.
Traçado: Tempo/Jaeger para «estreitos» p99.
Pagamento/finanças: fontes de ground truth para SLI de pagamento.

13) Exemplos de solicitação (modelos)

promql
1 - (
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)

yaml slo:
name: "API Availability"
window: "28d"
target: 0.999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14.4}
slow_burn: {window: "6h", factor: 6}

success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

14) FinOps e confiabilidade

Vale por 9: o custo de adicionar nove aumenta exponencialmente.
A curva de benefícios é ideal onde o aumento de receita/redução de perdas ≥ o custo de «9» adicionais.
Portfólio SLO: diferentes níveis para diferentes caminhos (pagamentos críticos «mais caros», relatórios «mais baratos»).

15) Qualidade SLO/alertas - folha de cheque

• O SLI está correlacionado com o UX e as métricas de negócios.
• A janela e a agregação estão alinhadas (rolling 28d/trimestre).
• Alertas multi-window, sem flapping, com roda de rolo.
• Documentação: proprietário, fórmula, fontes, runbook.
• Painel demo SLO com orçamento errado e indicadores burn.
• Revisão regular de metas (trimestral).
• Testes de sintética em cenários essenciais.

16) Plano de implementação (4 iterações)

1. Semana 1: inventário de caminhos personalizados, rascunhos de SLI, dashboards básicos.
2. Semana 2: formalização do SLO, orçamento, alertas (fast/slow burn).
3. Semana 3: integração com o processo de incidentes/lançamentos, regras freeze.
4. Semana 4 +: SLA contratual, reviravolta trimestral, modelo finups «per 9».

17) Mini-FAQ

Você precisa ter um SLO para o serviço?
Melhor 2-3 chave (sucesso + latência) em vez de dezenas secundárias.

E se o orçamento estiver esgotado?
Congelamento de lançamentos, foco de estabilização e CAPA, remoção de fichas experimentais.

Como evitar o conflito entre velocidade de lançamento e confiabilidade?
Planeje lançamentos de orçamento, implemente canários e feições-flags.

Resultado

A confiabilidade não é controlada por um conjunto de métricas soltas, mas por um sistema: SLI → SLO → erro de orçamento → burn-alerting → processo de incidentes → CAPA → SLA. Normalize as definições, as fontes de dados e os relatórios, vincule os objetivos à experiência e economia do usuário e reveja regularmente o nível de «devaneio» de acordo com o ROY real.