SLA/OLA com provedores

1) Termos e limites

O SLI é um indicador medível (disponibilidade, latência p99, webhooks processados com sucesso, RPO/RTO).
SLO - Destino SLI por janela de medição (por exemplo, 99. 9 %/30 dias).
O SLA é um documento legalmente vinculante (SLO + procedimentos + reembolso).
OLA - Objetivos internos e processos que garantem o cumprimento da SLA.
OUC (Underpinning Contract) - «suprimento» com terceiros (canais, centros de dados, CDN, etc.).

Limites: separe claramente a área de responsabilidade do provedor (nuvem/WAF/CDN/gateway/provedor KYC) da sua área (código, config, configurações de clientes).

2) Matriz de criticidade e seleção de modelo

A matriz depende da profundidade do SLA, da quantidade de verificações e dos requisitos de OLA/UC.

3) Métricas e janelas de medição

Disponibilidade (Availability): proporção de tempo em que o serviço executa solicitações de permissões.
Latência: p95/p99 para operações-chave; «sucesso lento» é considerado.
Dados confiáveis: RPO (perda máxima de dados permitida) e RTO (tempo de recuperação).
Largura de banda/limite: quotas garantidas (RPS/MBps).
Qualidade de integração: proporção de webhooks entregues ≤ X min, proporção de respostas 2xx, repetições e dedução.
Janela de medição: 30 dias mensais/deslizantes, exceções (trabalho programado) com limites.

• `Availability_ext = 1 − (Downtime_confirmed_outages / Total_minutes_in_window)`
• Onde o outage é um estado não disponível confirmado por monitoramento externo e não apenas pelo status do provedor.

4) Conteúdo SLA (modelo de seção)

1. Objeto e área (serviços, regiões, versões API).
2. Definições (SLI/SLO, «incidente», «trabalho de planejamento», «força maior»).
3. Metas do serviço (SLO) por categoria de solicitação e região.
4. Monitorização e base de provas, de que forma, sensores de quem, com que frequência.
5. Incidentes e escalações: canais, prazos de resposta/atualizações, funções.
6. Reembolso: empréstimos/multas/bônus, liminares, fórmulas.
7. Segurança e privacidade: DPA, criptografia, revistas, notificações de violações.
8. Alterações no serviço: deprekates, janela de notação, compatibilidade.
9. Continuidade e DR.: RPO/RTO, testes de recuperação.
10. Auditoria e complicação, direito a auditoria, relatórios, avaliações.
11. Exit Place: exportação de dados, prazos, formato, ajuda para migração.
12. As disposições legais são jurisdição, força maior, privacidade, prazo de validade.

5) Exemplos de formulação (fatias)

5. 1 Disponibilidade e medição

"O provedor fornece 99. 95% de disponibilidade em cada mês do calendário. A disponibilidade é medida pelo Monitoramento Sintético Externo do Cliente das Regiões com espaçamento de min. A indisponibilidade registrada em regiões é considerada simultaneamente um incidente de nível SEV2 e é contabilizada no Downtime"

5. 2 Latitude API chave

"p99 tempo de resposta 'POST/payments/autorize' ≤ 450 ms em 95% dos dias do mês. Para a proporção de solicitações acima do limite, é fornecido um relatório analisando as causas"

5. 3 Incidentes e escalações

"S1: ack ≤ 15 min, updates a cada ≤ 30 min, recuperação de destino ≤ 2 h; S2: ack ≤ 30 min, updates ≤ 60 min; S3, o próximo dia de trabalho. Canais: 24 x 7, chat bridge, e-mail

5. 4 Reembolsos (empréstimos)

If Availability_ext <99. 95% → credit 10% monthly fee
< 99. 9% → 25%
< 99. 5% → 50%

Os empréstimos não excluem outras formas de reparação por negligência grave.

5. 5 Deprekates e compatibilidade

"Pelo menos 180 dias de notificação para alterações de compatibilidade. Suporte paralelo ao e ao menos 90 dias

5. 6 Saída (Exit)

"No prazo de 30 dias após o cancelamento, o provedor fornece gratuitamente a exportação completa de dados nos formatos Parquet/JSON + esquema; serviços adicionais de migração - sob a tarifa X. A destruição de cópias é confirmada pelo ato"

6) OLA: suporte interno para SLA externo

• Alvos: p99 gateway ≤ 200 ms, error rate ≤ 0. 3%, DR.: RPO 0, RTO 30 min.
• Responsabilidade: SRE-on-call, 24 x 7; dashboards e alertas comuns.
• Processos: caos-smook em lançamentos, perf-smook em PR, euristics de shading.
• Gates: unidade de deploy quando o teste SLO/xaoc falhou; a atualização obrigatória do runbook.

7) Monitoramento e provas

Sintético: amostras externas (HTTP/TCP), caminho do usuário, «sucesso lento».
RUM: monitoramento real do usuário para confirmar o impacto.
Correlação: rótulos de 'corretor', 'region', 'api _ method', 'invident _ id'.
Artefactos: capturas de tela/trailers/logs, exportação de KPI, cronologia de escalações.

rego package policy. sla deny["Release blocked: provider SLO risk"] {
input. release. affects_providers[_] == p input. slo. forecast[p].breach == true
}

8) Incidentes e interação

1. Classificação do SEC, abertura do war-room, atribuição do IC.

2. Aviso do provedor por canal quente, transferência de artefactos.

3. Modos de contornação/bandeiras (stale, shading, rate-cap).

4. Timeline conjunta, restauração.

5. Atualização do config de limites, chaves, rotas de reserva.

6. Iniciação de crédito SLA, fixação em billing.

9) Segurança e DPA

DPA/privacidade: funções de controlador/processador, categorias de dados, base de dados de legalidade, prazos/objetivos de processamento, subprocessadores e seu SLA.
Criptografia: TLS1. 2+, PFS; dados «em paz», controle de chaves (KMS/HSM), rotação.
Auditoria: logs de acesso, notificações de violações de 72 h, relatórios pentest a pedido.
Localização: região de armazenamento, proibição de remoção sem consentimento.

10) Suply chain e compatibilidade

SBOM/vulnerabilidade: política de liminares CVSS e prazos de correção (criticou ≤ 7 dias, high ≤ 14).
API compatível: testes contratuais, «barras de areia» e ficstures estáveis.
As alterações do provedor são as primeiras notas de lançamento, o avanço/beta, a compatibilidade invertida.

11) Multiplicidade e feelover

Ativo/Ativo: mais difícil e mais caro, mas maior disponibilidade (leve em conta a consistência).
Ative/Passive: reserva fria/quente, treinos regulares de DR..
Abstrações/adaptadores: contrato único, rotação de saúde/custo/fator de carbono (se relevante).
Condições de licenciamento/comércio: portabilidade, limitação de saída de dados, custo de egress.

12) Plano exit e ensaios periódicos

Catálogo de dados/diagramas e volume.
Cenário de portabilidade SDK/API (mínimo de segundo fonte).
Teste de saída seca: exportação/importação, recuperação, verificação de invariantes.
Data legal de armazenamento/remoção após a saída.

13) Testes de contrato e conformance

Amostras de API: positivo/negativo, limites, erros e retraí.
Entrega de eventos/webhooks: assinatura/hora/deadup/repetições.
Perf basline: p99, largura de banda; Testes de registo do provedor.
A degradação de uma região não deve perturbar o SLO globalmente.

14) Anti-pattern

SLA «no status da página» sem dimensões externas.
Metas iguais para todas as regiões/endpoint.
Falta de direitos de auditoria e registros detalhados de incidentes.
Não há OLA/OUC → obrigações externas não há ninguém para cumprir internamente.
Plano exit incerto → refém do fornecedor.
«Multas apenas com crédito», sem direito a cancelamento em violações sistemáticas.
Deprekates sem janela de transição.

15) Folha de cheque do arquiteto

1. O SLI/SLO é definido para flow-chave e regiões?
2. A forma de monitoramento externo e a base de provas foram selecionadas?
3. A SLA estabelece incidentes, escalações, janelas de trabalho programadas e limites de exceções?
4. Há uma escala de crédito/multas e um direito de rescisão em infracções N?
5. DPA/segurança: criptografia, registros, notificações, subprocessadores, localização?
6. Testes contratuais e barras de areia no Pipeline?
7. O OLA/UC interno fornece SLO externo?
8. DR.: RPO/RTO declarados, treinos realizados, relatórios?
9. Plano exit: formatos de exportação, prazos, práticas de saída seca?
10. Gates em CI/CD bloqueiam lançamentos que aumentam o risco de violação da SLA?

16) Minicérebros (esquetes)

16. 1 Política de depload-gate de risco do provedor

yaml gate: provider-slo-risk checks:
- name: forecasted-slo-breach input: slo_forecast/providers. json deny_if: any(.providers[].breach == true)
action_on_deny: "block-release"

16. 2 Exportação de «provas de incidente»

bash curl -s https://probe. example. com/export? from=2025-10-01&to=2025-10-31 \
jq '.      {region, endpoint, status, latency_ms, trace_id, ts}' > evidence. jsonl

16. 3 Teste de webhook contratual (pseudocode)

python evt = sign(make_event(id=uuid4(), ts=now()))
res = post(provider_url, evt)
assert res. status in (200, 202)
assert replay(provider_url, evt). status = = 200 # idempotency

Conclusão

O SLA/OLA não é apenas um «papel legal», mas um mecanismo arquitetônico de gerenciamento de risco e qualidade. Métricas e janelas corretas, monitoramento externo, procedimentos claros de incidentes e reparação, OLA/UC interna, gates em pipas, fornecedores multi e um plano exit real transformam a dependência dos provedores em uma parte controlada, medida e economicamente previsível da sua plataforma.