Operações e Gerenciamento → Auditoria de métricas e SLA

Auditoria de métricas e SLA

1) Por que é necessário

Se as métricas estiverem erradas, as decisões não serão corretas, a SLA será quebrada em papel ou vice-versa. A auditoria de métricas e a SLA garantem que as promessas são comparáveis, confiáveis e legais aos usuários e parceiros.

• Forneça uma única «origem da verdade» (SSOT) e cálculos reproduzidos.
• Reduzir a discrepância entre dashboards/relatórios/arquivos.
• Tornar o SLA viável e verificável (evidence-based).
• É tão cedo para identificar a degradação nas dimensões quanto nos serviços.

2) Conceitos básicos e limites de responsabilidade

Metric (métrica): valor a ser medido (RPS, p95, CR, GGR, Sucess Rate).
KPI/OKR: alvos a que as métricas estão ligadas.
SLO: serviço de qualidade de destino (por exemplo, "p99 ≤ 400 ms 99. 9% do tempo").
SLA: promessa externa; legalmente importante, baseado no SLO.
OLA: Acordo interno entre equipes/vendedores, suporta SLA.
SSOT: sistema/armazenamento cujos dados são considerados de referência para relatórios.

3) Taxonomia métricas (camadas)

1. Infraestrutura: CPU/Memory/IO/Net, pos/nós, HPA/VPA.
2. Plataforma: filas/striptease (lag, throughput), BD/cachê (conectórios, hit), API (p95/p99, 5xx).
3. Fluxo de negócios: depósitos/conclusões, apostas, lançamento de jogos, autorizações, KYC.
4. Produto/marketing: conversões, ARPU/LTV, campanhas.
5. Qualidade de processo: MTTA/MTTR, Mudança Failure Rate, cobertura de folha de cheque.

Regra: Cada métrica deve ter uma camada, um dono e uma fórmula.

4) Fontes de dados e «verdade»

Telemetria online: Prometheus/OTel, logs (ELK/ClickHouse), traçados.
Eventos e contabilidade: Kafka/Outbox, DWH/assinaturas (BigQuery/ClickHouse).
Artefactos manuais, pós-mortem, tíquetes, registos de incidentes.
Registros externos: relatórios de provedores (PSP/KYC/estúdios).

Solução de conflito: As diferenças entre «online vs DWH» têm um regulamento de prioridade (por exemplo, as unidades SLA são de DWH com rastreabilidade de origem).

5) Processo de auditoria de métricas (contorno de controle)

1. Inventário: catálogo de métricas/SLO/SLA (nome, proprietário, camada, fórmula, origem, taxa de cálculo).
2. Comprovação de fórmulas: Compactuação de solicitações SQL/prom com definição (testes de cálculo unit).
3. Sampling e recontagem: amostra de linhas de eventos/logs e confecção manual.
4. Mapeamento de contornos: comparação entre os relatórios online e DWH.
5. Controle de alterações: revirando fórmulas em lançamentos de padrão/lógica.
6. Auditoria da SLA: Verificação da correção de montagens e exceções (planned maintenance, força maior).
7. Relatório e melhorias: lista as divergências encontradas e os registos com deadline.

6) Definições e fórmulas (amostras)

• `success = requests - (5xx + timeouts + circuit_open)`
• `success_rate = success / requests`

• O SSOT registra uma única definição de janela (rolling 5m/1h) e agregação (HDR/TDigest).

• 'SLO _ availability _ month = (tempo de trabalho - permissões _ exceções )/tempo _ total'

• `SLA_month = 99. 90% do botequim da janela UTC, excluindo as janelas programadas (T-48 notificação), os acidentes comprovados nos operadores de trânsito (documentos). '

7) Qualidade dos dados: verificações e alertas

• Полнота (completeness): `received_events / expected_events ≥ 0. 99`.
• Timeliness (timeliness): lote de download ≤ N minutos.
• Exclusividade (uniqueness): sem suplementos de chave (idempotency-key).
• Coerência (consistency): valores/moeda/caracteres.
• Linetividade (monotonicity): os contadores não são «reversíveis».

ALERT MetricsIngestionLagHigh
IF dwh_ingest_lag_minutes > 15 FOR 10m

ALERT EventsCompletenessDrop
IF (events_received / events_expected) < 0. 99 FOR 15m

ALERT DuplicateEventsSpike
IF rate(events_duplicates_total[10m]) > baseline_7d 2

8) Auditoria SLA/OLA: metodologia

1. Selecione um calendário de exceções, como janelas programadas, degradações acordadas, atos de venda.
2. O cálculo da farmácia é através de uma única área temporal, com apoio para SSOT.
3. Acerto de incidentes, temporizações, bilhetes, emails.
4. Atribuição: falhas próprias, provedor, trânsito, DDoS, regulamentos.
5. Perímetro SLA: experiência do usuário (E2E) vs uma API específica.
6. Relatório mensal/trimestre: fato, desvios, compensações (se aplicável), medidas corretivas.

9) Verificar a reprodução dos cálculos

Versioning de fórmulas: repositório git com SQL/PromQL/Dock Especificações.
Testes unit de métricas em sintético de dados (edge-mala: omissões, duplicações, limites de data).
Data lineage: de dashbord para trás para tabelas e eventos de origem.
Szapshots: congelamento de dados para corte, para que os cálculos de pena sejam comparáveis.

10) Amostras de controle (sampling)

Diariamente: 10 a 20 eventos em fluxos-chave (depósito/taxa/CUS) - controle manual de rastreamento ↔ DWH.
Semanalmente: 1% sample para comparar «online vs DWH» por unidade.
Mensalmente: conjunto de incidentes com efeito SLA - reconstrução detalhada.

Date/Window: 2025-10-01.. 2025-10-07
Metric: SLO_api_p99
Source A: Prometheus (rolling 5m)
Source B: DWH snapshot (1h buckets)
Deviation: + 6. 2% (A above B)
Reason: different aggregation windows
Action: align window in both contours to 5m/rolling
Term/Owner: 2025-11-10/squad-observability

11) Auditoria de dashboards e alertas

Um único dicionário de métricas, um glossário, mesmo no dashbord.
Anotações de lançamentos/iventes para ver a causa dos desvios.
Comparação antes/depois do lançamento: painéis de regressão automáticos.
Duply/discrepância: identificação de «dois p99 diferentes» - edição de fórmulas/janelas.
Disponibilidade de painéis: permissões, reserva, controle de links/versões.

12) Gerenciamento de alterações de métricas

Processo RFC: alteração de fórmula/janela/origem - via RFC, com avaliação do impacto sobre SLA/relatórios.
Migração «expand → migrate → contract»: conduzindo as duas versões temporariamente, comparando e desligando a antiga.
Comunicações: notificar previamente o produto/negócio sobre alterações de valores «com a nova metodologia».

13) Especificidades do iGaming/fintech

Picos de demanda: as métricas devem resistir a cargas explosivas (as agregações não são «empanadas»).
Provedores: SLA depende da OLA vendedores → armazenar seus relatórios, estatais de incidentes e quotas.
O valor é: 'cost _ per _ 1k _ calls' e 'custo de sucesso' - painéis obrigatórios.
Antifrode/risco: Sensibilidade a atrasos e «falsos efeitos» das métricas.

14) Dashboards de auditoria (conjunto mínimo)

Metrics Health: completeness/timeliness/duplicates, ingest-lag, ошибки ETL.
SLO/SLA Evidence: SLO computado, SLA real, exceções, referências a incidentes/atos.
Online vs DWH Compare: p95/p99/Sucess Rate, desvios e tendências.
Vendor SLA: farmácia/quotas/tempo/valor em corte de provedores.
Release Impact: Regressão de métricas após postagem/ativação de fichas.

15) Folha de cheque de auditoria (operacional)

• O catálogo de métricas/SLO/SLA com proprietários e fórmulas é relevante.
• SSOT definido para cada relatório/painel.
• Os testes unit de fórmulas são verdes e os cálculos de pipas estão documentados.
• As alertas de qualidade de dados estão ativas (completeness/timeliness/duplicates).
• «Online vs DWH» discrepância ≤ limite permitido (por exemplo, ≤2%).
• As exceções SLA acordadas foram documentadas e anexadas ao relatório.
• Foram realizadas amostras de controle e acertos.
• Todas as alterações nas fórmulas foram RFC e migração.

16) Exemplos (fatias)

api_p99_ms:release:ratio =
(api_latency_p99_ms{release="after"} / api_latency_p99_ms{release="before"})

sql
SELECT event_date,
COUNT() AS received,
SUM(expected_count) AS expected,
COUNT()::decimal / NULLIF(SUM(expected_count),0) AS completeness
FROM events
JOIN expected_events USING (event_date, event_type)
WHERE event_type IN ('deposit','bet_placed','kyc_completed')
AND event_date BETWEEN:from AND:to
GROUP BY 1;

ALERT DwhVsOnlineDrift
IF abs(dwh_kpis{metric="api_p99"} - online_kpis{metric="api_p99"}) > 0. 02 online_kpis
FOR 30m
LABELS {severity="warning", team="observability"}

17) Anti-pattern

Duas fórmulas diferentes de «uma» métricas em painéis diferentes.
Altera a métrica sem migração ou notificação - «saltos» no OKR/SLA.
Relatórios no Excel local como «verdade» (impermeável).
Mistura de fusos horários e calendários em cálculos SLA.
As exceções de SLA não são documentadas.
Não há alertas para a qualidade das medidas.

18) KPI maturidade de medição

Draft Rate Online↔DWH (alvo ≤2%).
Metrics Health UpTime (tempo sem degradação ingest/ETL).
Time-to-Fix Fórmula (hora da resolução do erro na fórmula).
SLA Dispute Rate (frequência de malas disputadas com parceiros).
Coverage SLO/SLA (proporção de caminhos críticos com SLO/SLA).

19) Papéis e responsabilidades

O dono da métrica/serviço: fórmula, fonte, dashboard, alertas.
Observabilidade/SRE: plataforma SSOT/, testes de fórmulas, alertas de qualidade de dados.
Data/BI: DWH, reprodução de relatórios, lineage.
Advogados/sócios gerentes: acordos SLA e exceções.
Gerente de incidentes, atribuição e ligação de incidentes com a SLA.

20) Início rápido (30 dias)

Semana 1: Inventário de métricas/SLO/SLA e proprietários; atribuir SSOT.
Semana 2: incluir alertas de qualidade de dados e painel «Online vs DWH».
Semana 3: fazer amostras de controle, alinhar a janela p95/p99.
Semana 4: formalizar o processo RFC para fórmulas, produzir um relatório SLA mensal com aplicativos.

21) FAQ

Q: O que contar SSOT para SLA?
A: Armazenamento com processamento replicado (DWH) e lineage completo; painéis online para controle operacional, não para atos legais.

Como lutar contra «dois p99»?
A: Fixar a janela/método de agregação no catálogo de métricas, migrar painéis, adicionar alert à deriva.

Q: Como levar em conta o trabalho planeado?
A: Manter um calendário de exceções e deduzi-las automaticamente da SLA sob as regras do contrato; Guardar artefactos de confirmação.