¿Qué es la ingeniería de fiabilidad?

¿Qué es la ingeniería de fiabilidad (reliability engineering)?

La ingeniería de fiabilidad es la práctica de diseñar, operar y mejorar sistemas para que cumplan un objetivo de fiabilidad medible, como el porcentaje de peticiones correctas o un percentil de latencia. El objetivo se escribe y se mide, y el equipo toma decisiones frente a él, por ejemplo entregar más rápido o corregir antes la estabilidad. La Site Reliability Engineering (SRE) es su versión de software más conocida.

Ingeniería de fiabilidad, SRE y DevOps

Los términos se solapan, pero apuntan a cosas distintas. La ingeniería de fiabilidad es la meta: que el sistema cumpla sus objetivos. SRE es el modelo operativo de Google para lograrlo. Según el libro de SRE, Benjamin Treynor Sloss lo puso en marcha en Google en 2003, y define SRE como «what happens when you ask a software engineer to design an operations team». Google limita el trabajo operativo al 50 % del tiempo de un SRE para que el resto vaya a ingeniería. DevOps es una cultura y un conjunto de herramientas que acorta la distancia entre desarrollo y operaciones.

Una prueba práctica: si tu equipo tiene una cifra de fiabilidad que defiende, está haciendo ingeniería de fiabilidad, digan lo que digan los cargos.

Los componentes básicos

• SLI (indicador de nivel de servicio). Una medida cuantitativa bien definida de algún aspecto del servicio, como la latencia de las peticiones o la tasa de errores.
• SLO (objetivo de nivel de servicio). Un valor o rango objetivo para un SLI, por ejemplo «el 99,9 % de las peticiones tiene éxito».
• SLA (acuerdo de nivel de servicio). Un contrato con consecuencias si no se cumplen los objetivos. Si no hay una consecuencia explícita, lo más probable es que sea un SLO. Consulta la gestión de SLA.
• Presupuesto de errores. Uno menos el objetivo de disponibilidad. Con un objetivo del 99,99 % queda un presupuesto del 0,01 % que se puede gastar en lanzamientos y experimentos. En el modelo de Google, los lanzamientos se detienen cuando el presupuesto se agota.
• Respuesta a incidentes y postmortems sin culpables. Los postmortems se centran en las causas que contribuyeron, sin culpar a una persona o equipo, y se redactan para los incidentes importantes.
• Reducción del toil. El toil es trabajo manual, repetitivo y automatizable que crece con el servicio. El objetivo de SRE es mantenerlo por debajo del 50 % del tiempo de cada ingeniero.
• Capacidad y arquitectura. Redundancia, aislamiento de dependencias y degradación controlada, comprobadas con pruebas de capacidad.

Ejemplo: un SLO y su presupuesto

Las cifras son ilustrativas. Supón que el SLI es el porcentaje de peticiones a /checkout que tienen éxito en menos de 1.500 ms y que el SLO es del 99,9 % en 30 días. El presupuesto de errores es del 0,1 %. Con 1.000.000 de peticiones de pago en la ventana, eso permite 1.000 peticiones fallidas. Si la mitad del presupuesto se gasta en la primera semana, el equipo frena los lanzamientos arriesgados y trabaja en la estabilidad. Si apenas se toca, puede entregar más rápido o endurecer el SLO.

El libro de SRE da consejos útiles para elegir las cifras: parte de lo que importa a los usuarios, usa pocos indicadores, prefiere percentiles a medias (por qué los percentiles superan a las medias, en inglés), no copies tu rendimiento actual como SLO y empieza con un objetivo más laxo que puedas endurecer. Léelo en el capítulo sobre objetivos de nivel de servicio (en inglés).

Métricas que siguen los equipos de fiabilidad

• Cumplimiento del SLO: la parte del objetivo del SLO alcanzada por servicio en la ventana.
• Ritmo de consumo del presupuesto de errores: a qué velocidad se gasta y cuándo se agota a ese ritmo.
• MTTD (tiempo medio de detección): desde el inicio de un incidente hasta la primera alerta.
• MTTR (tiempo medio de recuperación): desde el inicio de un incidente hasta la recuperación visible para el usuario.
• Tasa de fallos de cambios: el porcentaje de despliegues que provocan un incidente o una reversión.
• Proporción de toil: la fracción del tiempo de un ingeniero que se va en trabajo manual y repetitivo.

Errores habituales

• Apuntar al 100 %. El libro de SRE dice que el 100 % probablemente nunca es el objetivo de fiabilidad correcto: los usuarios no notan la diferencia y el coste se dispara.
• Demasiados indicadores. Un puñado de indicadores representativos basta para juzgar la salud de un sistema.
• Juzgar por medias. Una buena media puede ocultar una cola lenta que los usuarios sí notan.
• Un presupuesto de errores al que nadie hace caso. Solo funciona si agotarlo cambia lo que hace el equipo.
• SLO que nunca se revisan. Contrástalos con el comportamiento real de los usuarios y los planes de producto.
• Postmortems sin seguimiento. Asigna cada acción a una persona y síguela hasta cerrarla.
• No probar nunca bajo carga. Un SLO de latencia que solo has visto en horas tranquilas es una conjetura.

Dónde encajan las pruebas de carga y la monitorización

No puedes defender un SLO de latencia sin pruebas de que el sistema responde con una concurrencia realista. Las pruebas de carga antes de los lanzamientos y tras cambios grandes aportan esa prueba. Con las pruebas de carga de LoadFocus puedes fijar umbrales de éxito o fallo para el tiempo de respuesta P95 y P99, la tasa de errores y el rendimiento, de modo que cada ejecución recibe un veredicto, y una GitHub Action puede bloquear un despliegue si se supera un umbral. Así tu SLO se convierte en una puerta de entrada a producción.

En producción, la monitorización de API comprueba tus endpoints según un calendario desde varias regiones y te avisa cuando fallan las aserciones. La monitorización de API de LoadFocus tiene un plan gratuito con comprobaciones cada 5 minutos. Las páginas de estado pueden mostrar la disponibilidad calculada a partir de esas comprobaciones y publicar incidentes. Las métricas, los logs y las trazas se tratan en observabilidad, y nuestra guía de buenas prácticas de monitorización (en inglés) recoge los hábitos que las rodean.

Preguntas frecuentes

¿Qué diferencia hay entre ingeniería de fiabilidad y SRE?

La ingeniería de fiabilidad es la disciplina de lograr que un sistema cumpla objetivos de fiabilidad medibles. SRE es una forma concreta de hacerlo, nacida en Google, en la que ingenieros de software operan la producción con SLO, presupuestos de errores y un límite al trabajo operativo.

¿Qué es un presupuesto de errores?

Es uno menos el objetivo de disponibilidad. Con un objetivo del 99,99 % el presupuesto es del 0,01 %. Los equipos lo gastan en lanzamientos y experimentos, y frenan o detienen los cambios arriesgados cuando se agota.

¿Qué diferencia hay entre un SLO y un SLA?

Un SLO es un objetivo interno para un nivel de servicio que mide un SLI. Un SLA es un contrato con los usuarios que incluye consecuencias si no se cumplen los objetivos. Si no hay una consecuencia explícita, lo más probable es que sea un SLO.

¿Es el 100 % de disponibilidad un buen objetivo?

Normalmente no. El libro de SRE sostiene que el 100 % probablemente nunca es el objetivo correcto, porque los usuarios rara vez notan la diferencia y cada nueve adicional cuesta más. Elige un objetivo acorde con lo que necesitan los usuarios y con lo que puedes permitirte.

¿Cómo empiezo?

Elige un recorrido crítico para el usuario, define un SLI para él, fija un SLO laxo y mídelo con datos de producción. Calcula el presupuesto de errores, acordad qué ocurre cuando se agota y haz un postmortem sin culpables tras cada incidente importante.