Gestión de incidentes para equipos de alta velocidad
¿Qué es un presupuesto de errores y por qué es importante?
Todos los equipos de desarrollo, de operaciones y de TI saben que a veces se producen incidentes.
Incluso las empresas más grandes con el talento más brillante y una reputación de casi el 100 % de tiempo de actividad ven con frustración cómo sus sistemas también caen a veces. Basta con mirar a Apple, Delta o Facebook, que han perdido decenas de millones en incidentes en los últimos cinco años.
Esta realidad significa que los acuerdos de nivel de servicio (SLA) nunca deben prometer un tiempo de actividad del 100 %, porque es una promesa que ninguna empresa puede cumplir.
También significa que, si tu empresa es muy buena evitando o resolviendo incidentes, cabe la posibilidad de que arrases sistemáticamente con tus objetivos de tiempo de actividad. Tal vez prometas un 99 % de tiempo de actividad y en realidad te acerques al 99,5 % o quizás augures un 99,5 % de tiempo de actividad y en realidad alcances el 99,99 % en un mes normal.
Cuando esto ocurre, los expertos del sector recomiendan que, en lugar de poner las expectativas de los usuarios demasiado altas con una superación constante de tus promesas, debes tomar ese 0,99 % adicional como un presupuesto de errores, es decir, como tiempo que tu equipo puede usar para asumir riesgos.
¿Qué es un presupuesto de errores?
Un presupuesto de errores es el plazo máximo que un sistema técnico puede fallar sin que haya consecuencias contractuales.
Por ejemplo, si tu acuerdo de nivel de servicio (SLA) especifica que los sistemas funcionarán el 99,99 % del tiempo antes de que la empresa tenga que compensar a los clientes por la interrupción del servicio, eso significa que tu presupuesto de errores (o el tiempo que tus sistemas pueden estar caídos sin que haya consecuencias) es de 52 minutos y 35 segundos al año.
Si tu SLA promete un tiempo de actividad del 99,95 %, tu presupuesto de errores es de 4 horas, 22 minutos y 48 segundos. Y con una promesa del SLA de un tiempo de actividad del 99,9 %, tu presupuesto de errores es de 8 horas, 46 minutos y 12 segundos.
¿Por qué los equipos técnicos necesitan presupuestos de errores?
De primeras, los presupuestos de errores no parecen demasiado importantes; son solo otra métrica que los equipos de TI y DevOps deben controlar para asegurarse de que todo funcione sin problemas, ¿verdad?
Afortunadamente, la respuesta es “No”. Los presupuestos de errores no son solo una forma cómoda de asegurarte de que cumples las promesas contractuales, sino también una oportunidad para que los equipos de desarrollo innoven y asuman riesgos.
Como explicamos en nuestro artículo de SRE:
“El equipo de desarrollo puede ‘gastar’ este presupuesto de errores como prefiera. Si el producto está funcionando sin problemas, con pocos o ningún error, podrá lanzar lo que quiera, cuando quiera. Por el contrario, si el equipo ha cumplido o superado el presupuesto de errores y está funcionando conforme al SLA definido o por debajo de este, se interrumpirán todos los lanzamientos hasta reducir el número de errores a un nivel que permita que estos lanzamientos puedan continuar”.
La ventaja de este enfoque es que anima a los equipos a minimizar los incidentes reales y a maximizar la innovación asumiendo riesgos dentro de unos límites aceptables. También acorta distancias entre los equipos de desarrollo, cuyos objetivos son la innovación y la agilidad, y de operaciones, que se preocupa por la estabilidad y la seguridad. Mientras el tiempo de inactividad sea bajo, los desarrolladores podrán seguir siendo ágiles e impulsar cambios sin desavenencias con el equipo de operaciones.
Cómo usar un presupuesto de errores
En primer lugar, deberás consultar tus SLA y SLO. ¿Qué objetivos has establecido para el tiempo de actividad o las solicitudes exitosas del sistema? ¿Qué promesas ha hecho tu empresa a los clientes? Las respuestas a estas preguntas dictarán tu presupuesto de errores.
Presupuestos de errores basados en el tiempo de actividad
La mayoría de los equipos supervisan el tiempo de actividad mensualmente. Si la disponibilidad es superior a la cifra prometida por el SLA/SLO, el equipo podrá publicar nuevas funciones y asumir riesgos. Por el contrario, si la cifra está por debajo del objetivo, las publicaciones se detendrán hasta que las cifras objetivo vuelvan a estar en orden.
Para utilizar este método con eficacia, tendrás que convertir tu objetivo de SLO (generalmente un porcentaje) en cifras reales con las que los desarrolladores puedan trabajar. Esto significa calcular en cuántas horas y minutos se convierten realmente tu 1 %, 0,5 % o 0,1 % del tiempo de inactividad permitido. Los objetivos más habituales son los siguientes:
SLA target | Tiempo de inactividad anual permitido | Tiempo de inactividad mensual permitido | |
|---|---|---|---|
| Tiempo de actividad del 99,99 % | Tiempo de inactividad anual permitido 52 minutos, 35 segundos | Tiempo de inactividad mensual permitido 4 minutos, 23 segundos | |
| Tiempo de actividad del 99,95 % | Tiempo de inactividad anual permitido 4 horas, 22 minutos, 48 segundos | Tiempo de inactividad mensual permitido 21 minutos, 54 segundos | |
| Tiempo de actividad del 99,9 % | Tiempo de inactividad anual permitido 8 horas, 45 minutos, 57 segundos | Tiempo de inactividad mensual permitido 43 minutos, 50 segundos | |
| Tiempo de actividad del 99,5 % | Tiempo de inactividad anual permitido 43 horas, 49 minutos, 45 segundos | Tiempo de inactividad mensual permitido 3 horas, 39 minutos | |
| Tiempo de actividad del 99 % | Tiempo de inactividad anual permitido 87 horas, 39 minutos | Tiempo de inactividad mensual permitido 7 horas, 18 minutos | |
Presupuestos de errores basados en solicitudes exitosas
Los SLO tienen menos detractores que los SLA, pero pueden dar lugar a los mismos problemas si son poco precisos, demasiado complicados o imposibles de cuantificar. La clave para que los SLO no hagan que los ingenieros se tiren de los pelos es la simplicidad y la claridad. Solo las métricas más importantes deberían considerarse SLO, los objetivos deberían exponerse con un lenguaje sencillo y, al igual que con los SLA, siempre deberían dar cuenta de incidencias tales como los retrasos provocados por los clientes.
Mantente al tanto de los SLA para resolver las solicitudes en función de las prioridades y usa reglas de escalación automatizadas para notificar a los miembros adecuados del equipo y evitar incumplimientos de SLA con Jira Service Management.
Descubre la comunicación de incidentes con Statuspage
En este tutorial, te mostraremos cómo utilizar plantillas de incidentes para comunicarte eficazmente durante las interrupciones. Puedes aplicarlo a muchos tipos de interrupciones del servicio.
Leer el tutorialLa importancia de un proceso de análisis retrospectivo de los incidentes
El análisis retrospectivo de un incidente, también conocido como "revisión posincidente", es la mejor manera de repasar lo sucedido durante un incidente y plasmar las lecciones aprendidas.
Leer el artículo