Confiabilidad: SLOs, error budgets e incidentes

SLI, SLO y error budget

• SLI (service level indicator): una medición del servicio tal como lo perciben los usuarios, como la fracción de solicitudes que tienen éxito con suficiente rapidez.
• SLO (service level objective): la meta de un SLI en una ventana de tiempo, por ejemplo 99,9% de las solicitudes exitosas en menos de 300 ms durante 30 días.
• SLA (service level agreement): un contrato con consecuencias, normalmente más laxo que el SLO interno.
• Error budget: la falta de confiabilidad permitida (100% menos el SLO). Mientras quede budget, entrega rápido; cuando se agote, desacelera e invierte en confiabilidad.

Por qué cambia las decisiones

# SLI: proporción de solicitudes buenas en 5 minutos
sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

# consumo rápido para un SLO de 99,9%: tasa de errores por encima de 14,4x la permitida
(1 - (sum(rate(http_requests_total{status!~"5.."}[1h])) / sum(rate(http_requests_total[1h])))) > (14.4 * 0.001)

Respuesta a incidentes

• Declara temprano y nombra roles: un incident commander que coordina, alguien que investiga, alguien que comunica.
• Mitiga primero, diagnostica después: haz rollback, failover, apaga la flag.
• Comunica con una cadencia fija, incluso cuando no hay nada nuevo que decir.
• Lleva una línea de tiempo sobre la marcha; es la materia prima de la revisión.
• Haz un postmortem sin culpables: pregunta cómo permitió el sistema la falla, no quién se equivocó. Termina con acciones específicas y con responsable.

Reducir el riesgo antes de que ocurra

• Elimina el toil: automatiza las operaciones manuales repetitivas para que las personas tengan tiempo para ingeniería.
• Prueba el fallo a propósito con game days e inyección de fallas.
• Planificación de capacidad y pruebas de carga antes de que llegue el tráfico.
• Runbooks para fallas conocidas, mantenidos al día con el sistema.
• Degradación elegante: cuando una dependencia falla, haz menos, no nada.