SLO/SLA e métricas

SLO/SLA e métricas

1) Termos e hierarquias

O SLI (Service Level Indicator) é um indicador medível de «como o usuário nos vê»: proporção de pedidos bem sucedidos, p95 latência, frescor de dados, proporção de batches processadas com sucesso, etc.
SLO (Service Level Objectiva): destino SLI no intervalo de observação (28/30/90 dias). Exemplo: "99. 9% das solicitações/pay terminam ≤ 400 ms".
Error budget — 1 − SLO. No SLO 99. Orçamento de erro de 9% = 0. 1% de tempo/solicitação.
SLA - Nível de serviço legalmente relevante: inclui SLO, medição, exceções, compensações/multas.

2) Princípios de design

Sintomas> métricas internas. O SLI deve refletir a experiência real do usuário.
Um pequeno número de SLI-chave. Para o serviço - 2-5 principais: sucesso, latência, banda larga/frescura, correto.
Abrangência das vias críticas. Para cada cenário de negócios (checkout, login, webhook, download ETL) - seu conjunto SLI/SLO.
Uma semântica rigorosa de «sucesso». Não «código 200», mas «o usuário recebeu a resposta dentro do prazo e o resultado está valendo».
Separação entre SLO externo e interno. O interior é mais rigoroso; o SLA externo ≤ entre 1 e 2 metros abaixo.

3) Catálogo SLI (árbitro)

3. 1 API/serviços online

Sucesso: 'SLI _ sucess = 1 - (5xx + timeout + business _ erro )/all _ requests'

Latência: p95/p99 'http _ server _ duration _ segunds' sobre rotas/métodos/locatários

Largura de banda: 'RPS '/limites/quotas

Correto: proporção de respostas validadas (assinaturas, esquemas, invariantes)

3. 2 Webhooks/entregas asinhrônicas

Entrega: proporção de eventos confirmados em T segundos e ≤ N retrações

Clientes: proporção de assinantes sem atraso prolongado (para-tenante)

3. 3 Dados/ETL/DWH

Frescor (freshness): 'now - last _ sucessful _ ingest _ ts'

Íntegra em 'ingested _ rows/expected _ rows'

Correção: proporção de registros de qualidade

Pipline: proporção de DVDs concluídos até a deadline

3. 4 SDK móvel/cliente

Sucesso do cliente: proporção de sessões sem erros fatais

Latência round-trip: p95 de consulta a render

Sucesso em dinheiro: proporção de pessoas atendidas a partir de um cachê (como sintoma de performance)

4) Fórmulas e exemplos de metas

• `SLI_req_avail = 1 − (failed_requests / total_requests)`
• `SLO_req_avail = 99. 95% 'por 30 dias → error budget = 0. 05% das solicitações.

• `uptime = (obs_window − downtime) / obs_window`

• ' SLO _ latency = p95 (rota = »/pay») ≤ 400 ms' em cortes de 7 dias, com exclusão de aquecimento em dinheiro (1%)

• ' SLO _ freshness (datse =» orders») ≤ 10 min' p99 em 24 horas.

5) Erro budet e gerenciamento de alterações

Orçamento (B): 'B = 1 - SLO'.
Consumo de orçamento (burn): relação entre erros reais e erros válidos.

• Excesso (burn> 1) → fichfrime, foco de confiabilidade.
• Com burn rate> X em uma janela curta - incidente e cap. medidas.
• Planejamento: a participação do sprint na confiabilidade está correlacionada com o burn no período anterior.

6) Alerting: burn rate e regras de várias janelas

A ideia é apanhar fugas rápidas e uma deriva lenta.

• Crítica: «2% do orçamento em 1 hora» (fogo rápido).
• Aviso: «5% do orçamento em 6 horas» (degradação rasteira).

• Janela curta (minuto-hora) para incidentes rápidos.
• Janela longa (6-24 horas) para tendências.
• Latência: alert p99> limiar de ≥5 min, com supressão de flapping e ligação com exemplares de trilhos.

error_ratio_5m = errors[5m] / requests[5m]
error_ratio_1h = errors[1h] / requests[1h]
burn_5m     = error_ratio_5m / error_budget_fraction burn_1h     = error_ratio_1h / error_budget_fraction alert_critical if burn_1h > 14 and burn_5m > 14 alert_warning  if burn_6h > 6 and burn_30m > 6

7) Multiplicidade (multi-tenant) e segmentação

Os SLI/SLO são considerados como locadores/planos/regiões, ou a mediana «encobrirá» falhas.
Número mínimo de eventos de importância estatística (guard-rails).
O SLA pode variar de tarifas (por exemplo, "Pro 99. 9%, Free 99. 5%»).

8) Conexão com observabilidade e rastreamento

Métricas SLI - a partir de histogramas/contadores com exemplars → transição para «maus» trailers.
O logi é uma fonte de causa, temporizações, códigos de erros de negócios, limites.
Para os dados, ligou-se ao lineage, «Que dobro deteve a métrica de frescura».

9) Contratos e SLA

• Definições de SLI/método de medição/janela.
• Exceções (trabalho programado, força maior).
• Procedimento de incidentes e comunicações (página status, RFO/RCA).
• Compensações (service credits) e ordem de solicitação.
• Jurisdição, período de validade, termos de revisão.

• Nunca prometa publicamente SLO mais rigoroso do que a arquitetura e as práticas operacionais permitem.
• Separe o SLO interno e o SLA externo.

10) Custo e priorização

O preço das donzelas não aumenta linearmente. «99. 9% → 99. 99%" = outra classe de arquitetura (N + 1, multiisona, ativo-ativo).
Coloque o SLO nas ações mais valiosas do usuário.
Controle os custos de telemetria, como downsampling, quotas, réplica e armazenamento por classe.

11) Procedimentos e relatórios

Relatórios semanais: execução de SLO para serviços/locatários, consumo de orçamento, melhores razões, planos de melhorias.
RCA pós-insidentes: Associamos a pedaços de orçamento; estabelecemos metas para resolver as causas profundas.
Fichfreese: critérios de inclusão/retirada.

12) Modelos (para início rápido)

12. 1 Cartão SLO (exemplo)

Service: Checkout API
SLI:
success: 1 - (5xx+timeouts+biz_failures)/all latency_p95: p95(http_server_duration_seconds{route="/pay"})
SLO:
success: 99. 95% / 30d latency_p95: ≤ 400ms / 7d
Windows:
primary: 30d rolling secondary: 7d rolling
Burn Alerts:
critical: use 1h/5m > 14 warning: use 6h/30m > 6
Owner: Team Checkout
Tenancy: per-tenant (≥ 1k req/day threshold)
Dashboards: RED + trace exemplars

12. 2 Tabela «Maturidade SLO»

13) Exemplos de regras (fatias)

promql
Error rate (5xx + timeout) for the sum (rate (http_requests_total{route="/pay",code=~"5. route.    599"}[5m]))
/ sum(rate(http_requests_total{route="/pay"}[5m]))

p99 histogram_quantile latency (0. 99, sum(rate(http_server_duration_seconds_bucket{route="/pay"}[5m])) by (le))

promql error_budget_fraction = 0. 001 for 99. 9%
(err_rate_5m / 0. 001 > 14) and (err_rate_1h / 0. 001 > 14) # critical
(err_rate_30m / 0. 001 > 6) and (err_rate_6h / 0. 001 > 6)  # warning

promql
Data order lag (minutes)
(max(time()) - max(last_ingest_ts_seconds{dataset="orders"})) / 60

14) SLO para dados e ML (características)

Dados SLO de passagem: p99 frescor, p99 cheio, tempo de «reinstalação» após falha.
Contratos de dados: esquemas esperados, quantidades, deadline; violação → incidente de dados.
ML: SLO para latência da inferência, SLA para disponibilidade de fich store, monitoramento da deriva (qualidade do modelo é um tema separado, fora do SLA).

15) Integração com segurança e privacidade

Logi SLI sem PII/segredos; Toquenização/camuflagem.
Auditoria de alterações do SLO/SLA e publicações de relatórios em revistas imutáveis.
Para rotas regulatórias (pagamentos/PII) - SLO individuais, mais rigorosos.

16) Folhas de cheque

Antes de iniciar o serviço/fici

• Definidos pelo SLI «sucesso/latência/largura de banda/frescura».
• O SLO e as janelas foram definidos; O orçamento dos erros foi calculado.
• Alertas de burn-rate configurados (curto + longo).
• Dashboard RED + exemplars → pista; runibuki incidentes.
• Cortes múltiplos e liminares de importância.
• Processo de fichfrisagem e relatórios.

Operação

• Relatório semanal de SLO/burn, planos de hardening.
• Reavaliação do SLO ao alterar a arquitetura/carga.
• Exercícios «incidentes» e atualização de runibucos.
• Controle do custo da telemetria e da quantidade de SLI.

17) Runbook’и

Runbook: crescimento rápido p99/pay

1. Alert r99> limiar → abrir o dashboard → ir pelo exemplar para o trace.
2. Encontrar um CLIENTE/SERVER span estreito, comparar regiões/versões.
3. Incluir degradação (dinheiro/limite/folbeck), notificar o comando de dependência.
4. Após a estabilização - RCA, tarefas de otimização, atualização de medidas SLO.

Runbook: consumo de orçamento> 50% por semana

1. Congelar os fichas, priorizar a confiabilidade.
2. Clustering de erros em rotas/locatários/dependências.
3. Corrigir → confirmar a recuperação da tendência.
4. Retrospectiva e ajustamento de alertas/liminares.

18) FAQ

Quanto SLO precisa?
O mínimo para cenários críticos do usuário é sucesso + latência. Tudo o resto é necessário.

Em: O que é melhor - disponibilidade por tempo ou por solicitação?
Por solicitação, uma métrica mais personalizada. Hora útil para componentes de rede/infra.

Em: Porquê p95 e não a média?
O meio esconde a cauda; o usuário sente p95/p99.

Como não «enrolar» demasiado?
Comece com objetivos realistas (dados históricos) e depois endureça conforme a maturidade.

• Observabilidade: logs, métricas, traçados
• Traçados distribuídos
• «Auditar e Registos Imutáveis»
• «Garantia de entrega de webhooks»
• Criptografia In Transit/At Rest
• Origem dos dados