Close

El camino hacia una mejor gestión de incidentes empieza aquí

¿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 nos indica que los acuerdos de nivel de servicio (SLA) nunca deben prometer un tiempo de actividad del 100 %, ya que 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 se deberían tener en cuenta problemas tales como los retrasos provocados por los clientes.

A continuación
DevOps