SLA / SLO & Política de Soporte¶
Read in your language: English · Português · Español
audit-v6 DOCS-OPS: la suite de gobernanza cubre cadencia de release y EOL, pero nada comprometía disponibilidad ni tiers de soporte para clientes. Este documento define los objetivos de servicio y la política de soporte para el control plane SaaS comercial (
app.tlsstress.art,admin.tlsstress.art) y el producto on-prem. Es un template a finalizar con los términos comerciales (verLICENSE+ el Subscription Agreement) antes de ser contractualmente vinculante.
1. Alcance¶
- Control plane SaaS — signup, billing, emisión de licencias, ingestión de uso,
dashboards alojados en
app.tlsstress.art/admin.tlsstress.art. - Test bed on-prem — corre en el entorno del cliente; la disponibilidad es responsabilidad del cliente. Nos comprometemos con objetivos de respuesta de soporte, no uptime, para on-prem.
- Fuera del alcance — dependencias de terceros (Stripe, AWS, Cloudflare) llevan sus propios SLAs; una outage de destino compartido allí queda excluida de los nuestros.
2. Service Level Objectives (metas internas)¶
| SLO | Meta | Medición |
|---|---|---|
| Disponibilidad del control-plane | 99.5% mensual | probe sintética + status del edge |
| Tasa de éxito de signup/login | ≥ 99.9% (excl. error de usuario) | ratio de éxito de auth-events |
| Procesamiento de webhooks de billing | ≥ 99.9% eventualmente-procesados | outcome de stripe_webhook_events (consciente de retry) |
| Ingestión de usage-report | ≥ 99.9% aceptados (firmados válidos) | ratio de aceptados en usage_tickets |
| Latencia p95 de API (control) | < 500 ms | server timing |
Estos son objetivos, no SLAs contractuales, hasta que los tiers de la §4 se acuerden.
3. Error budget & alerting¶
- Error budget de disponibilidad: 0.5%/mes (~3h39m). Alertas de burn-rate a 2%/1h y 5%/6h alimentan el on-call.
- La salud se observa con el stack de observabilidad cloud self-hosted (Prometheus +
el uptime de 30 días de la status page); los objetivos de DR viven en
DR-RESTORE-RUNBOOK.md.
4. Tiers de soporte (template)¶
| Tier | Audiencia | Canales | Objetivo de primera respuesta | Cobertura |
|---|---|---|---|---|
| Community | free / eval | email, docs | best-effort | horario laboral |
| Standard | Pro | email, ticketing | 1 día hábil | horario laboral |
| Enterprise | Enterprise / on-prem | ticketing + escalation | 4 horas hábiles (Sev-1: 1h) | extendida; 24/7 para Sev-1 cuando haya equipo |
Reality check (2026-07): la cobertura 24/7 de Sev-1 aún NO tiene equipo (operación single-founder). No comprometa 24/7 en un contrato hasta que la rotación de on-call exista. Venda el soporte Enterprise como "horario laboral extendido + escalation best-effort" hasta entonces. Esto se alinea con el go/no-go de lanzamiento.
5. Definiciones de severidad¶
| Severidad | Definición | Ejemplo |
|---|---|---|
| Sev-1 | Control plane caído / billing roto / riesgo de integridad de datos | signup caído, pérdida de webhooks, quiebre del audit-chain |
| Sev-2 | Feature principal degradada, existe workaround | panel del dashboard fallando, aprovisionamiento retrasado |
| Sev-3 | Menor / cosmético | gap de doc, polish de UI |
6. Mantenimiento & comunicación de cambios¶
- Mantenimiento planificado anunciado ≥ 48h antes en la status page.
- Los breaking changes siguen
DEPRECATION_POLICY.mdy la cadencia de release. - Comunicaciones de incidente + postmortems según el proceso de incident-response.
7. Checklist de finalización (antes de ser contractual)¶
- % de disponibilidad y tiempos de respuesta acordados con el cliente.
- Rotación de on-call con equipo para la cobertura comprometida.
- Créditos/remedios definidos para SLA incumplido.
- Referenciado desde el Subscription Agreement / MSA.