SLA / SLO & Política de Suporte¶
Read in your language: English · Português · Español
audit-v6 DOCS-OPS: a suíte de governança cobre cadência de release e EOL, mas nada comprometia disponibilidade ou tiers de suporte para clientes. Este documento define os objetivos de serviço e a política de suporte para o control plane SaaS comercial (
app.tlsstress.art,admin.tlsstress.art) e o produto on-prem. É um template a ser finalizado com os termos comerciais (verLICENSE+ o Subscription Agreement) antes de se tornar contratualmente vinculante.
1. Escopo¶
- Control plane SaaS — signup, billing, emissão de licença, ingestão de uso,
dashboards hospedados em
app.tlsstress.art/admin.tlsstress.art. - Test bed on-prem — roda no ambiente do cliente; a disponibilidade é responsabilidade do cliente. Comprometemo-nos com objetivos de resposta de suporte, não uptime, para on-prem.
- Fora do escopo — dependências de terceiros (Stripe, AWS, Cloudflare) carregam seus próprios SLAs; uma outage de destino-compartilhado lá é excluída dos nossos.
2. Service Level Objectives (alvos internos)¶
| SLO | Alvo | Medição |
|---|---|---|
| Disponibilidade do control-plane | 99.5% mensal | probe sintética + status do edge |
| Taxa de sucesso de signup/login | ≥ 99.9% (excl. erro de usuário) | razão de sucesso de auth-events |
| Processamento de webhooks de billing | ≥ 99.9% eventualmente-processados | outcome de stripe_webhook_events (ciente de retry) |
| Ingestão de usage-report | ≥ 99.9% aceitos (assinados válidos) | razão de aceitos em usage_tickets |
| Latência p95 de API (controle) | < 500 ms | server timing |
Estes são objetivos, não SLAs contratuais, até que os tiers da §4 sejam acordados.
3. Error budget & alerting¶
- Error budget de disponibilidade: 0.5%/mês (~3h39m). Alertas de burn-rate em 2%/1h e 5%/6h alimentam o on-call.
- A saúde é observada pelo stack de observabilidade cloud self-hosted (Prometheus +
o uptime de 30 dias da status page); os objetivos de DR vivem em
DR-RESTORE-RUNBOOK.md.
4. Tiers de suporte (template)¶
| Tier | Público | Canais | Objetivo de primeira resposta | Cobertura |
|---|---|---|---|---|
| Community | free / eval | email, docs | best-effort | horário comercial |
| Standard | Pro | email, ticketing | 1 dia útil | horário comercial |
| Enterprise | Enterprise / on-prem | ticketing + escalation | 4 horas úteis (Sev-1: 1h) | estendida; 24/7 para Sev-1 quando houver equipe |
Reality check (2026-07): a cobertura 24/7 de Sev-1 ainda NÃO tem equipe (operação single-founder). Não comprometa 24/7 em contrato até a rotação de on-call existir. Venda o suporte Enterprise como "horário comercial estendido + escalation best-effort" até lá. Isso se alinha ao go/no-go de lançamento.
5. Definições de severidade¶
| Severidade | Definição | Exemplo |
|---|---|---|
| Sev-1 | Control plane fora / billing quebrado / risco de integridade de dados | signup fora, perda de webhook, quebra do audit-chain |
| Sev-2 | Feature principal degradada, workaround existe | painel do dashboard falhando, provisionamento atrasado |
| Sev-3 | Menor / cosmético | gap de doc, polish de UI |
6. Manutenção & comunicação de mudanças¶
- Manutenção planejada anunciada ≥ 48h antes na status page.
- Breaking changes seguem
DEPRECATION_POLICY.mde a cadência de release. - Comunicações de incidente + postmortems conforme o processo de incident-response.
7. Checklist de finalização (antes de ser contratual)¶
- % de disponibilidade e tempos de resposta acordados com o cliente.
- Rotação de on-call com equipe para a cobertura comprometida.
- Créditos/remédios definidos para SLA não cumprido.
- Referenciado a partir do Subscription Agreement / MSA.