Un diseño claro de SLA es más que una tabla con cifras: determina quién en la empresa es responsable de disponibilidad, seguridad, recuperación y reporting. Ya en la introducción de este artículo se utiliza deliberadamente la palabra clave de enfoque diseño de SLA, porque muchos conflictos, retrasos y costes innecesarios derivan de que los equipos (Desarrollo/Dev, Seguridad/Sec, Operaciones/Ops) tienen expectativas diferentes sobre la disponibilidad, los procedimientos de cambios y las obligaciones de evidencia. Este artículo ofrece un árbol de decisiones orientado a la práctica para gerentes, así como plantillas, listas de verificación y pautas concretas de gobernanza, para que los SLA se implementen de forma operativa, auditables y con control de costes.
Diseño de SLA: Por qué las responsabilidades claras entre Dev, Sec y Ops son decisivas
El diseño de SLA no solo trata de porcentajes (p. ej. 99,9% de disponibilidad), sino de las consecuencias operativas: ¿quién aplica parches, quién decide sobre los rollback, quién recopila métricas, quién genera evidencias para los auditores y quién asume los riesgos de reputación y contractuales frente a los clientes? Las responsabilidades poco claras provocan respuestas retardadas a incidentes, decisiones no documentadas y problemas en auditorías regulatorias.
Desde la perspectiva de la dirección y de Compliance son centrales tres puntos:
- Auditabilidad: las decisiones y las acciones deben ser demostrables (logs, runbooks, change-records).
- Viabilidad práctica: los objetivos del SLA deben alcanzarse con el personal, presupuesto y tecnología disponibles.
- Asignación de riesgo: las penalizaciones contractuales, pérdida de datos o incumplimientos regulatorios deben asignarse a un rol responsable.
Roles y términos: Qué significan concretamente Dev, Sec y Ops
Antes de entrar en un árbol de decisiones, una breve y clara descripción de roles:
- Dev (Desarrollo): Responsable del diseño, el código, las pruebas funcionales y las releases. En muchas organizaciones, Dev entrega el software y la automatización inicial (CI/CD).
- Sec (Seguridad): Encargado del diseño de seguridad, el threat‑modelling, las auditorías de seguridad (p. ej. PenTests), la definición de políticas y los controles de cumplimiento. Sec suele establecer requisitos mínimos, p. ej. cifrado, autenticación o audit‑logging.
- Ops (Operaciones): Responsable de la operación productiva: despliegue, monitoring, incidentes operativos, backup & RESTore, escalado y disponibilidad. Ops en muchas empresas mantiene la interfaz directa con proveedores de nube/infraestructura.
Importante: los roles pueden distribuirse de forma distinta según la organización (p. ej. SRE en lugar de Ops, equipos DevOps con responsabilidades compartidas). Lo decisivo es que cada tarea concreta tenga un rol responsable definido y que se generen evidencias.
Árbol de decisiones para gerentes: cuándo quién asume la responsabilidad
El siguiente árbol de decisiones está concebido como una guía práctica para la dirección de TI y Compliance. Ayuda a asignar responsabilidades para métricas de SLA, manejo de incidentes y tareas operativas.
- ¿Es la tarea parte de la arquitectura del producto (diseño/código) o parte de la operación (runtime/hosting)?
- Si es diseño/código → principalmente Dev.
- Si es runtime/hosting → principalmente Ops.
- ¿Tiene la tarea impacto directo en la confidencialidad, integridad o disponibilidad de datos protegidos? (protección de datos, regulación)
- Si sí → Sec está involucrado y tiene la obligación de definir requisitos mínimos y criterios de verificación.
- En casos límite es recomendable una responsabilidad compartida con una definición RACI clara.
- Operaciones de rutina → Ops con Runbook estandarizado.
- Cambios críticos → Dev ejecuta, Ops opera y Sec revisa previamente (Change Advisory Board o gates automatizados).
- Agudo → Ops inicia medidas inmediatas, Dev y Sec apoyan con Hotfixes y Forensics. Las vías de escalado deben estar documentadas.
- Planificado → Utilizar proceso de cambio con responsabilidades, pruebas y aprobaciones (Dev, Sec, Ops).
- Si es así → Aclarar responsabilidades para la generación de evidencia (logs, reports); Ops suministra datos operativos, Sec genera informes de cumplimiento, Dev aporta evidencias de los cambios.
Estas preguntas decisorias se pueden traducir en cláusulas SLA concretas. A continuación se ofrece un patrón práctico para la clasificación de la severidad de incidentes como plantilla para copiar.
# Incident Severity Matrix (Plantilla, adaptar a los plazos de la organización)
SEVERITY DESCRIPTION RESPONSIBILITY
P0 Caída de producción, datos críticos Ops (medida inmediata), Dev (Hotfix), Sec (Forensics)
P1 Fallo parcial con workaround Ops (Hotfix), Dev (Patch), Sec (revisión de seguridad)
P2 Funcionalidad afectada Dev (Bugfix), Ops (Deployment), Sec (review si es relevante para seguridad)
P3 Menor, cosmético Dev (planificación según roadmap)
Elegir correctamente las métricas SLA: SLO, RTO, RPO, MTTR
La selección de métricas determina el esfuerzo operativo y las responsabilidades:
- SLO (Service Level Objective): Concretiza el objetivo (p. ej. 99,9% HTTP‑200 en 30 días). Los SLO suelen negociarse conjuntamente: Dev determina la viabilidad, Ops mide el cumplimiento.
- RTO (Recovery Time Objective): Tiempo máximo de recuperación tras una caída. Implica calidad del Runbook, frecuencia de pruebas y disponibilidad de personal (Ops / SRE).
- RPO (Recovery Point Objective): Ventana máxima de pérdida de datos. Tiene implicaciones en la frecuencia de backups, el diseño de storage y la arquitectura de la aplicación (Dev+Ops).
- MTTR (Mean Time To Repair) y MTTD (Mean Time To Detect): Miden el rendimiento operativo. Ops es principalmente responsable de la detección y la primera respuesta; Dev de reducir el tiempo de reparación mediante un mejor release‑engineering.
Los responsables deben escoger SLOs que sean alcanzables con los recursos existentes y que, al mismo tiempo, cubran de forma adecuada el riesgo del negocio. SLAs desproporcionados generan costes elevados por On‑Call, infraestructura redundante y modelos operativos 24/7 costosos.
Asignación de responsabilidades (RACI) en concreto: plantilla y práctica
Una matriz RACI sencilla aporta claridad: Responsible (ejecutor), Accountable (decisor), Consulted (consultado), Informed (informado). Abajo hay una tabla HTML compacta como plantilla que puede ajustar directamente.
| Tarea | Dev | Sec | Ops | Observación |
|---|---|---|---|---|
| Publicación de un Hotfix | R | C | A | |
| Copia de seguridad y RESTauración | C | I | A/R | |
| Revisión de seguridad antes del Go‑Live | R | A/R | C | |
| Monitorización & Alertas | C | C | A/R | |
| Evidencia regulatoria | C | A/R | R |
Importante en la práctica: la matriz no es unidireccional. Debe incorporarse en procesos y herramientas: tickets de cambio, referencias en runbooks, informes de auditoría automatizados y reuniones de revisión periódicas (p. ej., revisión mensual de SLO). Documente también los «casos límite»: ¿quién decide en servicios compartidos o ante fallos de terceros?
Gobernanza, auditoría y evidencia: lo que esperan los auditores
Los auditores rara vez piden la bonita tabla RACI: quieren pruebas de la práctica diaria. Debe poder aportar la siguiente evidencia por cada SLA:
- Historial de monitorización e informes SLO (Ops proporciona métricas, paneles configurables para los auditores).
- Registros de cambios con aprobaciones (quién decidió y por qué).
- Postmortems de incidentes con análisis de causas, responsables y lecciones aprendidas (contribuciones de Dev/Ops/Sec).
- Runbooks y pruebas de recuperación (evidencia de ejercicios regulares de recovery).
- Informes de parches y vulnerabilidades, incluida la trazabilidad temporal de los hallazgos y las correcciones (evidencia de Sec).
Técnicamente eso significa: los logs deben ser inviolables, la política de retención debe cumplir los requisitos mínimos regulatorios y los informes deben poder exportarse en formato legible por máquina. Decida pronto qué datos se almacenan y dónde (p. ej., instancia central de logging, WORM‑Storage para evidencia crítica).
Ejemplo: Exportación mínima de evidencia (JSON) — Resumen del incidente
{
"incident_id": "INC-2026-0001",
"severity": "P0",
"start_time": "2026-07-01T09:12:00Z",
"resolved_time": "2026-07-01T10:03:00Z",
"responsible": {
"ops": "ops-team@example.com",
"dev": "dev-lead@example.com",
"sec": "sec-lead@example.com"
},
"summary": "Root cause: DB failover nicht abgeschlossen; Fix: config rollback",
"evidence_links": ["s3://evidence/INC-2026-0001/postmortem.pdf"]
}
Costes, riesgo y priorización: entender las compensaciones
Los SLAs altos son caros. Los responsables deben evaluar periódicamente:
- ¿Qué proceso de negocio justifica qué nivel de disponibilidad? (p. ej., Checkout frente a Reporting‑API).
- ¿Son las arquitecturas redundantes técnica y económicamente justificables (active‑active, Multi‑AZ, Multi‑Region)?
- ¿Qué medidas alternativas son aceptables (p. ej., modo de solo lectura en lugar de la caída completa del servicio)?
Un enfoque pragmático: priorice los servicios según el impacto empresarial y defina tres clases de SLA (crítico, importante, no crítico). Para cada clase establezca recursos estándar (p. ej., turno On‑Call, frecuencia de backups, periodicidad de pruebas de recuperación). De este modo, el diseño de SLAs se vuelve planificable y presupuestable.
Pasos de implementación y lista de verificación para gerentes
Para hacer obligatorio el diseño de SLAs, se recomienda un plan de implementación estandarizado:
- Crear catálogo de servicios y clasificar el impacto empresarial.
- Diseñar propuesta de SLO por servicio (Dev: verificar viabilidad, Ops: verificar medibilidad, Sec: verificar cumplimiento).
- Finalizar la matriz RACI por servicio e integrarla en el sistema de ticketing/cambios.
- Redactar runbooks y definir pruebas de recuperación; programar ejercicios regulares.
- Implementar monitorización, alertas y reporting; configurar el panel de SLO.
- Establecer una canalización de evidencias de auditoría (exportaciones automáticas, archivado WORM para los registros relevantes).
- Introducir un ritmo de revisión (p. ej. revisión trimestral de SLO, revisión mensual de incidentes).
Lista de comprobación (lista para copiar):
- ¿Existe para cada servicio una métrica SLO definida?
- ¿Está documentada la responsabilidad (R/A/C/I) y visible en las herramientas?
- ¿Existen runbooks para P0/P1 y están probados?
- ¿Se almacenan las evidencias (registros, tickets de cambio, postmortems) de forma centralizada y a prueba de manipulaciones?
- ¿Se han tenido en cuenta los costes para cada nivel de SLA en el presupuesto?
Trampas típicas y cómo evitarlas
Los errores en el diseño de SLA suelen ser organizativos, no técnicos:
- Demasiadas SLOs no verificables — evite métricas que no puedan medirse de forma automatizada.
- Vías de escalación poco claras — defina responsables concretos para cada turno y obligaciones de documentación.
- Falta de evaluación de costes — calcule el Total Cost of Ownership para cada nivel de SLA.
- Aspectos de cumplimiento ignorados — involucre a Sec y Compliance pronto en la definición de los SLO.
Ejemplo práctico: decisión sobre la responsabilidad de parches
Pregunta: ¿Quién asume la responsabilidad de los parches de seguridad en una aplicación web?
Lógica de decisión, en breve:
- ¿La vulnerabilidad está en una biblioteca de terceros (framework)? → Dev inicia el parche y las pruebas, Ops planifica el despliegue, Sec evalúa la urgencia y las consecuencias sujetas a notificación.
- ¿Es un parche de infraestructura (OS, Kernel, Hypervisor)? → Ops se responsabiliza del parche, Dev proporciona pruebas de compatibilidad, Sec exige la evidencia del cumplimiento.
- ¿Es el cambio crítico (exploit en libertad)? → Flujo P0: Ops realiza el despliegue de emergencia, Dev aporta el hotfix, Sec coordina la comunicación y la investigación forense.
SLA y proveedores externos: redacción de contratos y vías de escalación
En muchos entornos, los proveedores externos determinan la disponibilidad y la seguridad (Cloud‑Provider, CDN, Payment‑Gateway). Los responsables deben negociar en los contratos SLAs claros, vías de escalación y formatos de evidencia. Puntos concretos que deberían incluirse en los contratos:
- Metodología de medición: qué métricas se aplican, cómo se miden y qué ventanas de tiempo se utilizan?
- Verificabilidad: acceso a los logs del proveedor o mecanismos de exportación para los informes SLO.
- Subcontratistas: ¿puede el proveedor subcontratar partes del servicio y con qué obligaciones de notificación?
- Cláusula de salida: entrega de datos, ventanas de transferencia y plazo mínimo de retención en caso de incidente.
Cláusula contractual práctica (lista para copiar):
Cláusula: SLA del proveedor y evidencias
El proveedor se compromete a poner a disposición los SLOs acordados (Anexo A) durante 12 meses en informes automatizables. En caso de incumplimiento de los SLOs, se aplicarán los créditos definidos en el Anexo B. El proveedor facilitará exportaciones completas de logs (marca temporal ISO, fuente del evento) para incidentes P1+ en un plazo de 72 horas.
Personal, formación y costes de on‑call: modelos presupuestables
El cumplimiento de SLA exige mucho personal. Decisiones importantes afectan a los modelos de on‑call, al mix de competencias y al esfuerzo de formación. Recomendaciones prácticas:
- Forme pools de SRE o on‑call ajustados a las clases de SLA; calcule los recargos por turno y los costes de sustitución (backfill).
- Invierta en formación de runbooks y ejercicios de simulación de incidentes para reducir el MTTR.
- Implemente un modelo de costes por clase de SLA: costes mensuales de personal + costes de infraestructura + reserva para proveedores externos.
Un enfoque presupuestario sencillo: sume los costes mensuales de personal on‑call con la prima de infraestructura (p. ej., Multi‑AZ) y distribuya esos costes entre clientes/servicios según el impacto en el negocio.
Precisión métrica, tolerancias y falsos positivos
Además, debe definir la precisión de las métricas y los márgenes de tolerancia para evitar falsos positivos. Establezca ventanas temporales para la agregación (p. ej., 5m, 30m), filtros de valores atípicos y tolerancias de error. Definiciones claras reducen los conflictos en la facturación de SLA y en cuestiones de auditoría.
Conclusión: árbol de decisión como herramienta de gobernanza
El diseño de SLAs es un instrumento de gobernanza: correctamente planteado reduce los tiempos de respuesta, genera evidencias de auditoría y controla los costes. El árbol de decisión ayuda a definir responsabilidades operativas tangibles entre Dev, Sec y Ops. Los managers deberían vincular siempre la perspectiva de riesgo, costes y evidencia de auditoría: los SLAs sin un plan de implementación son contratos sin respaldo.
Sea pragmático: clasifique los servicios, defina SLOs mínimamente realistas, ancle RACI en sus herramientas y automatice las pipelines de evidencia. Revisiones periódicas y pruebas de recuperación garantizan que los SLAs no solo existan en el papel, sino que funcionen en la operación diaria.
Plantilla: cláusula SLA sencilla (lista para copiar)
Service: API de pagos
SLO: 99,9% de respuestas sin 5xx en 30 días (métrica: Prometheus http_requests_success ratio)
RTO: 1 hora
RPO: 15 minutos
Responsables: Ops (A), Dev (R en cambios de código), Sec (C por requisitos de seguridad)
Reporting: Informe SLO mensual automatizado por correo electrónico a las partes interesadas
Audit: Todos los incidentes con Severidad P1+ deben quedar documentados y versionados en el postmortem dentro de las 72 horas.
Siguientes pasos para managers
Recomendación: inicie un breve proyecto de gobernanza de SLAs (2–6 semanas) con entregables claros: catálogo de servicios, prototipos de SLO para los 10 principales servicios, plantillas RACI y una hoja de ruta de automatización para exportaciones de evidencia. Así se generan SLAs sólidos sin ciclos de coordinación prolongados.
Si lo desea, esta plantilla puede servir como punto de partida para un formato de taller interno en el que Dev, Sec y Ops negocien conjuntamente SLOs y redacten Runbooks. Tales talleres reducen notablemente los conflictos en caso de incidentes.
Para este tema también son importantes Devsecops e Incident Response. El artículo sitúa estos aspectos de forma comprensible y muestra en qué se debe incidir en la operativa diaria.