Relatórios uptime e auditoria SLA

1) Por que precisa de um processo formal de relatórios uptime

Confiança do cliente e transparência contratual - uma única metodologia de medição, cálculos repetitivos.
Gerenciamento de SLO e orçamento de erros - conecta a disponibilidade com lançamentos e incidentes.
Créditos SLA corretos - fórmulas objetivas, pagamentos previsíveis/créditos.
Sustentabilidade legal - base de provas, auditoria independente, Legal Hold.

2) Termos e limites

O SLI Availability é a proporção de verificações/transações bem sucedidas durante o período.
O SLO é um alvo interno (por exemplo, 99. 95% em 28 dias).
O SLA é uma obrigação externa (por exemplo, 99. 9 %/mês + prestações de serviço).
Janela de medição - Mês de calendário (SLA) e janelas de rolling (SLO).
Scope - Quais componentes são incluídos no cálculo (edge, API, pagamentos) e quais não são (portal não-prod).

3) Fontes da verdade (e quando qual o principal)

1. Sintético (blackbox/headless) é um SLI primário para «acessibilidade pelos olhos do usuário».
2. Logs/métricas - confirmam a escala e a natureza da falha.
3. Eventos empresariais - «êxito de transação» (por exemplo, pagamento autorizado).
4. Página de status - comunicação pública; a verificar os factos nº1-3.

Em divergências: Prioridade por sintética com quorum correto de ≥2 regiões.

4) Metodologia de cálculo de disponibilidade

4. 1 Fórmula básica

Availability = Успешные проверки / Все проверки
ErrorBudget = 1 − SLO
Downtime(m) = (1 − Availability) × Длительность_периода(в мин)

4. 2 Quorum muito regional

O incidente é contabilizado se ≥N regiões independentes/ASN registrarem uma rejeição simultânea.
Recomendado: N = 2 de 3 (EU/NA/APAC).

4. 3 Tipos de SLI

HTTP SLI: код 2xx/3xx, latency ≤ T.
DNS/TLS SLI: NXDOMAIN/SERVFAIL/expiry.
Negócios SLI: transações bem sucedidas/todas as tentativas (com exclusão de recusas de clientes).

4. 4 Exceções (documented)

Janelas maintenance programadas anunciadas com antecedência N relógio e cumpridas.
Force majeure da SLA (por exemplo, o provedor de desastres IX) - somente se houver provas e notificação pública.
Erros de cliente/limitação (quota exceeded, 4xx).

5) Política de janelas maintenance

Slots temporários acordados no contrato (por exemplo, vs 02: 00-04: 00 em UTC + 0).
Os marcadores 'maintenance = true' em alertas/painéis → uma exceção ao SLI.
Limite de notificação de pelo menos 5 dias úteis (ou como contrato).
Fora da janela - considerado influência SLA.

6) Mala Edge e regras de arredondamento

Brownout (deterioração parcial): conta a proporção de falhas (weighted downtime) em vez de «0/1».
Flapping: unidade de contabilidade mínima - intervalo de amostra (por exemplo, 30-60 segundos) + hysteresis (para: 2-5 min).
Clock drivt: todos os tempos em UTC e ISO-8601; sincronização NTP.

7) Exemplos de PromQL (sintético → farmácia)

promql probe_success{job="blackbox-http"} == 1

promql histogram_quantile(0.95, sum by (le, target) (rate(probe_http_duration_seconds_bucket[5m])))

promql sum_over_time((probe_success==1)[30d]) / (30246060)

promql sum by (target) (max_over_time((probe_success==0)[3m])) >= 2

8) Exemplos de SQL (agregação de relatório)

sql with checks as (
select target, ts, success -- success: 1/0 from synthetic_checks where ts >=:from and ts <:to
),
agg as (
select date_trunc('month', ts) m, target,
sum(success)::float / count() as availability from checks group by 1,2
)
select m, target, availability,
(1-availability) extract(epoch from (date_trunc('month', m) + interval '1 month' - date_trunc('month', m))) / 60 as downtime_minutes from agg;

sql select a.m, a.target, a.downtime_minutes, s.incident_id, s.start_utc, s.end_utc from monthly_downtime a left join statuspage_incidents s on a.m = date_trunc('month', s.start_utc)
and tstzrange(s.start_utc, s.end_utc) && daterange(a.m, a.m + interval '1 month');

9) Modelo de relatório mensal (Customer-friendly)

yaml period: "2025-10-01..2025-10-31 (UTC)"
services:
- name: "API Edge"
sla: "99.90%"
measured_availability: "99.93%"
downtime:
total: "30m 14s"
windows:
- start: "2025-10-12T03:12Z"
end:  "2025-10-12T03:38Z"
impact: "EU+NA, HTTP 5xx spike, p95>2s"
root_cause: "DB connection pool exhaustion"
rca_link: "INC-20251012-0312"
slo_budget:
period_target: "0.10%"
consumed: "0.07%"
- name: "Payments API"
sla: "99.95%"
measured_availability: "99.97%"
summary:
sla_breaches: 0 service_credits: 0 maintenance:
announced: 2 total_duration: "48m"
signatures:
generated_at: "2025-11-01T10:00Z"
report_id: "SLA-2025-10-API"

10) Créditos SLA: cálculo e aplicação

Tabela de créditos, por exemplo, 99. 0–99. 5% → 5% MRR; 98. 0–99. 0% → 10% etc.
True-up: o crédito é aplicado como credit note para a conta seguinte.
Automação: regra "se 'measured _ availability <SLA' → 'credit _ note. create()`».
A vitrine para o cliente é «SLA credits balance».

11) Auditoria, provas e Legal Hold

Auditoria trailer: quem/o/quando calculou, versão da metodologia, quantias de controle.
Os dados raw são imutáveis (append-only); ajustes - registros individuais.
Legal Hold: congelamento da faixa de dados (amostras, logs, cartões de incidente, alertas).
Réplica de arquivos: Armazenamento independente (WORM/S3 Object Lock).

12) Confecção com página pública

O incidente no status da página deve ter timeline e componentes.
A discrepância de tempo/escala → é criada por discrepance-record e realizada por RCA.
O resultado do relatório contém a seção «Recordation Note».

13) Incidentes e relatórios

Cada janela de downthame corresponde a um cartão INC (ID, SEC, proprietário, RCA, CAPA).
Relatório: Referência INC, Breve Motivo de root, Status CAPA.
Para o SEV-1: volume póstumo ≤ 48 h do encerramento.

14) Controle de qualidade de dados

Higiene de amostras:> 99% dos craps bem sucedidos dos agentes, falta de omissão> 5 minutos.
Anti-ruído: quorum + multi-window, debounce.
O sampleamento de trilhos/logs é capturado e documentado.
Testes de metodologia, testes de cálculo unit, arquivos golden em dados históricos.

15) Segurança e privacidade

TLS/mTLS para ingest, assinatura de pacotes (HMAC).
Redação PII em logs/relatórios; O relatório SLA não deve revelar dados pessoais.
RBAC/ABAC para relatórios; Os vestígios de acesso são escritos na auditoria.

16) Dashboards e widgets SLO (que mostrar)

Overall availability para serviços por mês/trimestre.
Downtime windows com severity e canal de detecção.
Error budget burn (fast/slow) e tendências.
Releases overlay - anotações de notas.
SLA credits forecast - na tendência atual.

17) Plano de implementação (3 iterações)

1. Modelo e dados (2 semanas): fixar o SLI/SLO/SLA, incluir o quorum-sintético, recolher a «matéria-prima» em DWH.
2. Cálculo e relatório (2-3 semanas): fórmulas, SQL/PromQL, modelos YAML/PDF, portal do cliente, crédito automático.
3. Auditoria e automação (3-4 semanas): Legal Hold, recepção com status de página, webhooks assinados, regulamentos de displicência.

18) Folha de cheque de qualidade do relatório

• Definidos como scope, SLI, metodologia e janela de medição.
• Há quorum e multi-window; o flapping é suprimido.
• As exceções (maintenance/force majeure) estão documentadas.
• Cada janela de downthame está ligada a INC e RCA.
• Os créditos SLA foram computados e estão refletidos no billing.
• Relatório reproduzido (versões de fórmulas/dados).
• O trailer de auditoria e o Legal Hold estão incluídos.
• Página de status pública concordada.

19) Mini-FAQ

Porque é que o sintético é a fonte principal?
É o mais próximo do caminho do usuário e inclui um perímetro (DNS/CDN/WAF). Métricas/logs especificam a causa.

Como contamos as degradações parciais?
Downthaim ponderado: proporção de inconvenientes x duração da janela, em vez de «tudo ou nada».

É preciso guardar os testes crus?
Sim, sim. Para auditar e voltar a calcular na disputa - raw é necessário.

Resultado

Relatórios uptime e auditoria da SLA não são um «número no final do mês», mas sim um sistema reproduzível de medição, regras e provas: SLI correto, quorum, fórmulas transparentes, conexão com incidentes e billets, controle de exceções e Legal Hold. Mantenha a metodologia, automatize o cálculo e os créditos, mantenha o trailer auditado, e seu SLA será gerenciado, compreensível e protegido.