Curso Kubernetes 27 — SLO/SLI, on-call y postmortem sin culpa

"Está en el aire" no es SLO. SLO es un compromiso numérico con el usuario, con ventana y consecuencia. Sin eso, toda discusión de confiabilidad se convierte en opinión.

Este capítulo cierra la parte de operación: qué prometer, cómo medir, cuándo despertar a alguien y cómo aprender sin buscar culpables.

Sello del curso: aplicado en un entorno con SLO del 99,5% mensual.

SLI, SLO y SLA

Término	Definición	Ejemplo
SLI	indicador medido	% de solicitudes con estado < 500 y latencia < 500 ms
SLO	meta para el SLI	99,5% en 30 días
SLA	contrato con consecuencias	99,5% con crédito/penalización
Presupuesto de error	margen de error	0,5% = ~3h36min al mes

SLO es interno y orienta las decisiones. SLA es externo e implica dinero. Nunca prometas un SLA mayor que el SLO que mides.

Elegir el SLI

Pocos y buenos. Para un portal:

1. Disponibilidad: proporción de solicitudes exitosas.
2. Latencia: proporción de solicitudes por debajo del límite (no la media).
3. Calidad de datos (cuando sea crítico): trabajos que procesaron sin errores.

Evita:

• tiempo de actividad del pod como SLI (el usuario no ve el pod);
• media de latencia;
• métrica que nadie puede medir en este trimestre.

Definir el SLO

slo: disponibilidad-api
target: 99.5
window: 30d
sli:
  good: http_requests_total{status!~"5.."}
  total: http_requests_total

Cálculo en PromQL:

sum(rate(http_requests_total{job="portal-backend",status!~"5.."}[5m]))
/
sum(rate(http_requests_total{job="portal-backend"}[5m]))

Presupuesto de error quemado:

1 - (
  sum(rate(http_requests_total{job="portal-backend",status!~"5.."}[30d]))
  /
  sum(rate(http_requests_total{job="portal-backend"}[30d]))
) / 0.005

99,5% en 30 días = 3h36min de indisponibilidad total equivalente.

Burn rate: alerta que vale la pena despertar a alguien

Alertar por "1 error" genera fatiga. Una buena alerta mira la velocidad de consumo del presupuesto:

Burn rate	Ventana	Acción
14,4x	1h	página (despierta)
6x	6h	ticket urgente
1x	3d	backlog

(
  sum(rate(http_requests_total{job="portal-backend",status=~"5.."}[1h]))
  /
  sum(rate(http_requests_total{job="portal-backend"}[1h]))
) > (14.4 * 0.005)

Esto reduce el ruido: 0,1% de error en 5 minutos no despierta a nadie; 5% durante una hora sí.

Guardia que funciona

• Rotación semanal, con handoff escrito.
• Runbook por alerta: qué verificar, qué hacer, cómo escalar.
• Acceso listo: VPN, kubectl, dashboards, logs — probado antes de la guardia.
• Una alerta, una acción. Alerta sin acción es ruido.
• Página solo para síntoma del usuario, no para CPU alta aislada.

Lista de verificación de handoff:

- Incidentes abertos e estado
- Deploys na janela
- Alertas silenciados e por quê
- Riscos conhecidos (disco, capacidade, certificado)

Postmortem sin culpa

Premisa: las personas actúan con la información que tienen. El objetivo es corregir el sistema, no a la persona.

Estructura:

1. Resumen (5 líneas).
2. Impacto: usuarios, duración, SLO quemado.
3. Línea de tiempo (minuto a minuto).
4. Causa raíz y factores contribuyentes.
5. Qué funcionó (detección, rollback, comunicación).
6. Qué falló.
7. Acciones con responsable y plazo.

Reglas:

• Escrito en un plazo de 72 h, con quienes participaron.
• Sin "fallo humano" como causa final. La pregunta es: ¿por qué el sistema lo permitió?
• Una acción sin responsable y fecha no existe.
• Compartido con todo el equipo.

Ejemplo de causa mal redactada: "el operador eliminó el PVC equivocado". Versión útil: "no había protección contra la eliminación de PVC de producción; el comando era destructivo y sin confirmación; no había una copia de seguridad reciente del volumen".

Vinculando SLO a la decisión

• Presupuesto sobrando: puede acelerar los cambios.
• Presupuesto quemándose: prioriza la confiabilidad, congela funciones arriesgadas.
• Presupuesto agotado: revisión de arquitectura, no "trabajar más".

Esto transforma la confiabilidad en una conversación de producto, y saca al SRE del papel de bombero eterno.

Laboratorio

1. Instrumenta la API con un contador de solicitudes por estado.
2. Crea las reglas de SLI y un panel de SLO en Grafana.
3. Calcula el presupuesto restante del mes.
4. Configura una alerta de burn rate 14,4x/1h.
5. Inyecta errores 500 durante 10 minutos y observa cómo se dispara la alerta.
6. Escribe un postmortem simulado con línea de tiempo y tres acciones.
7. Haz un handoff de guardia en 10 líneas.

Errores comunes

Síntoma	Causa
Alerta ignorada	umbral sin burn rate
SLO nunca cumplido	meta copiada de una empresa más grande
Postmortem se convierte en culpa	enfoque en la persona, no en el sistema
Acción no ejecutada	sin responsable/plazo
SLI no mide al usuario	métrica interna (pod up)
Presupuesto infinito en la práctica	nadie mira el panel
Guardia sin runbook	conocimiento solo en la cabeza de uno

Lista de verificación

• [ ] SLI definido a partir de la experiencia del usuario.
• [ ] SLO con ventana y target explícitos.
• [ ] Presupuesto de error calculado y visible.
• [ ] Alertas por burn rate, no por evento aislado.
• [ ] Runbook por alerta crítica.
• [ ] Rotación y handoff documentados.
• [ ] Postmortem en 72 h, sin culpa, con acciones rastreadas.
• [ ] Revisión mensual de SLO y presupuesto.

Glosario

• SLI: indicador medido.
• SLO: meta del indicador.
• SLA: contrato con consecuencias.
• presupuesto de error: margen de error permitido.
• burn rate: velocidad de consumo del presupuesto.
• blameless: análisis sin culpa individual.
• handoff: traspaso de guardia.

Próximo

Último capítulo: DR y capstone. RPO/RTO en la práctica, simulacros de restauración y el cierre del curso con lo que llevar a producción.

Próximo: Curso Kubernetes 28 — DR y capstone