La esperanza no es una estrategia: 7 principios de ingeniería de fiabilidad del sitio (SRE)

La ingeniería de fiabilidad del sitio (SRE) es un enfoque que trata los problemas operativos como si fueran problemas de software. Fue nombrado y descrito originalmente en 2003 por Ben Treynor Sloss, ingeniero de Google. Como disciplina, la SRE tiene como objetivo mantener la disponibilidad, el rendimiento y la eficiencia de un sistema en particular.

La SRE puede ser difícil de concretar. Es un enfoque o disciplina más que un conjunto prescriptivo de tareas, y adopta diferentes formas en función de las necesidades de una organización determinada. Afortunadamente, hay siete principios de ingeniería de fiabilidad del sitio que pueden ayudar a guiar a un equipo de SRE hacia el éxito.

Gran parte del desarrollo de software se centra, con razón, en la creación, incluido DevOps, un campo relacionado pero distinto, que se ocupa más del ciclo de vida completo de un producto. Sin embargo, el trabajo no termina con el lanzamiento del sistema. En el prefacio de la guía de Google sobre SRE, los autores señalan que "entre el 40 % y el 90 % de los costes totales de un sistema se producen después de su creación". La SRE se ocupa de lo que ocurre después del lanzamiento con el objetivo de ayudar a garantizar que el producto siga siendo lo más útil posible.

El elemento más importante de la SRE es la fiabilidad y el tiempo de actividad del sistema. Por muy bueno que sea el servicio, no sirve de nada si no está operativo. Por lo tanto, la SRE se centra en minimizar el tiempo de inactividad y crear sistemas fiables.

Los equipos de SRE también se encargan de que todos los elementos del producto estén actualizados mediante una gestión cuidadosa de las actualizaciones de software y seguridad. Las normas y regulaciones están sujetas a cambios y los equipos de ingeniería se encargan de garantizar el cumplimiento continuo.

Las prácticas de SRE también pueden generar ahorros económicos. Muchos de los principios básicos de la SRE se centran en la eficiencia, lo que puede traducirse en un ahorro significativo de costes y esfuerzos mediante la automatización y la gestión de recursos, entre otras cosas.

Los siete principios de la SRE incluyen:    

• Aceptación del riesgo
• Objetivos de nivel de servicio
• Eliminación del trabajo pesado
• Supervisión
• Automatización
• Ingeniería de versiones
• Simplicidad

Aunque la SRE se preocupa mucho por gestionar y limitar el tiempo de inactividad, esta tendencia no implica que el objetivo sea que los servicios tengan una fiabilidad y una disponibilidad perfectas y del 100 %. De hecho, uno de los principios fundamentales de la SRE es que la fiabilidad del 100 % no solo es poco realista, sino que tampoco es necesariamente el resultado deseado.

En la SRE, el riesgo se concibe como un continuo, en el que reducirlo se vuelve exponencialmente más difícil y costoso a medida que se aproxima al 100 % de fiabilidad. Intentar pasar de una fiabilidad del 99,99 % a una del 99,999 % es mucho más difícil que pasar del 80 % al 99 %. Los recursos necesarios para acercarse cada vez más al 100 % reducen la capacidad del equipo de desarrollo para llevar a cabo otras tareas, como la innovación de nuevas características y actualizaciones. En su lugar, el equipo cuenta con presupuestos de error que representan la cantidad adecuada de fallos.

Otro punto en contra de la fiabilidad total, por muy contradictorio que parezca, es que los clientes no suelen apreciar las mejoras en la fiabilidad más allá de un cierto umbral. No solo es costoso, sino que la recompensa es escasa. Lo ideal es fijar un objetivo y alcanzarlo sin excederse.

En su lugar, SRE utiliza métricas para medir la aceptabilidad del riesgo de tiempo de inactividad. Según una métrica, un año con una fiabilidad del 99,99 % incluiría 52,6 minutos de tiempo de inactividad. Las métricas más complejas tienen en cuenta la posibilidad de que haya tiempo de inactividad en una ubicación o en un elemento de un servicio mientras otros permanecen activos.

Un equipo de SRE debe evaluar cada servicio y determinar un nivel aceptable de falta de fiabilidad. ¿Cuánto tiempo de inactividad se puede permitir? ¿Los diferentes tipos de fallos, derivados de diferentes causas raíz, tienen diferentes efectos en la experiencia del usuario? ¿Cuánto costará superar ese límite en términos de mano de obra y finanzas? ¿Dónde está el equilibrio?

Elegir objetivos y medir la eficacia con la que se alcanzan es fundamental para un equipo de SRE. Un objetivo de nivel de servicio (SLO) es una meta específica y cuantificable que representa un nivel de calidad que el equipo de SRE se ha propuesto alcanzar. Estos SLO pueden adoptar la forma de diversas métricas, pero las más comunes son la disponibilidad, la tasa de consultas, la tasa de errores y el tiempo de respuesta.

Estos objetivos se miden mediante un indicador de nivel de servicio, o SLI, que es una medida bruta del rendimiento, como la latencia. En este caso, el SLI sería la métrica de latencia y el SLO indicaría que dicha métrica debe mantenerse por debajo de un umbral determinado. Los SLO, a su vez, pueden formar parte de un acuerdo de nivel de servicio, o SLA, que es un contrato entre el proveedor y el usuario que establece los SLO, así como las consecuencias de no cumplirlos.

Elegir los SLO puede resultar complicado. Lo ideal es que los SLO se estructuren en torno a lo que es más importante para los usuarios. Por ejemplo, en el caso de un servicio de juegos en la nube, el SLO podría girar en torno a una baja latencia, pero este factor no sería tan importante para un servicio de contabilidad.

Lo ideal sería que un ingeniero de fiabilidad del sitio utilizara relativamente pocos SLO para centrarse en alcanzar esos objetivos, ya que lo más importante es realizar correctamente la tarea principal. También es importante establecer objetivos realistas, como hemos comentado anteriormente: la perfección no es un objetivo realista ni deseable.

Los creadores de la SRE definen el "trabajo pesado" como una categoría de labor que se solapa con el trabajo, pero que no es lo mismo. Se refiere a aquellas tareas manuales que se pueden escalar de forma lineal, que suelen ser repetitivas y manuales, y que a menudo se pueden automatizar.

El trabajo que debe realizarse una y otra vez se clasifica como trabajo pesado. Lo ideal es que una tarea individual solo requiera una o dos revisiones. El trabajo que no mejora el producto también es esfuerzo. "Si tu servicio permanece en el mismo estado después de haber terminado una tarea, es probable que la tarea haya sido inútil", escribe Vivek Rau de Google. Corregir errores, mejorar características y optimizar no es una tarea ardua, pero descargar métricas manualmente sí lo es. La respuesta ante incidentes, que puede requerir una importante coordinación entre ingenieros y equipos de operaciones, no es una tarea ardua y las tácticas de gestión de incidentes deben planificarse antes del lanzamiento.

También existe el esfuerzo cognitivo. ¿Tiene alguna receta básica que utiliza de vez en cuando, pero tiene que buscar los ingredientes y las medidas cada vez que la prepara? Eso es esfuerzo cognitivo: es una pérdida de tiempo y energía tener que volver a aprender algo una y otra vez. En cambio, la SRE promueve la creación de más guías y estándares que eliminan la necesidad de recordar o volver a aprender continuamente metodologías y tareas.

Una de las partes más importantes de la ingeniería de fiabilidad del sitio es la monitorización: el uso de herramientas para medir, analizar y mejorar continuamente las características principales y el rendimiento del sistema. Esas características principales suelen incluir lo que se conoce como las "cuatro señales de oro" de la monitorización:

Latencia: en su forma más básica, ¿cuánto tiempo se tarda en atender una solicitud? Tenga en cuenta que esto puede variar en función de si la solicitud se ha realizado correctamente o no; a veces, un mensaje de error puede tardar mucho más en atenderse.

Tráfico: ¿qué carga o demanda se ejerce sobre el servicio? Las unidades específicas variarán; pueden ser visitas a la página, transacciones o solicitudes HTTP.

Errores: los errores, que suelen medirse en forma de tasa, pueden incluir la obtención de datos incorrectos, la obtención de datos más lentamente de lo establecido en un SLA o la imposibilidad de obtenerlos.

Saturación: básicamente, la saturación mide cuán cerca está un servicio de alcanzar su capacidad máxima. Es importante comprender el concepto de saturación, ya que algunos servicios pueden empezar a fallar, ralentizarse o generar más errores a medida que se acercan al 100 % de saturación.

Existen muchas herramientas de monitorización que pueden recopilar datos, establecer puntos de referencia, depurar y analizar problemas, proporcionar paneles de control de observabilidad útiles y alertar a las SRE sobre posibles interrupciones u otros problemas. También es importante proporcionar informes post mortem sólidos una vez resuelto el incidente, en los que se explique el contexto del mismo, las causas raíz y los factores desencadenantes, el impacto, la metodología de resolución y las enseñanzas para el futuro. Una autopsia objetiva y detallada puede tener un valor incalculable para evitar el mismo error dos veces.

Al igual que con muchos otros elementos de la tecnología moderna, el objetivo de incorporar la automatización en un flujo de trabajo es liberar a los ingenieros de tener que lidiar con tareas repetitivas que no aportan valor. Gracias a este nuevo tiempo libre, los ingenieros pueden dedicarse a tareas que la automatización no puede realizar: creación, ideación, orientación a gran escala, etc.

La automatización puede ser especialmente valiosa para los siguientes objetivos:

Coherencia: la desventaja de las tareas manuales repetitivas no es solo que pueden ser aburridas y pueden restar tiempo a acciones más valiosas. Si esas tareas, como la creación de cuentas de usuario, se realizan mediante herramientas de automatización, los errores y las incoherencias pueden eliminarse casi por completo. Un empleado nuevo puede hacer las cosas de manera diferente a un empleado antiguo; un usuario puede introducir accidentalmente un valor en el campo equivocado. Un proceso automatizado (generalmente) no lo hará.

Escalabilidad: la escalabilidad es uno de los principales beneficios a largo plazo de la automatización. Tomemos nuestro ejemplo anterior de creación de cuenta de usuario. Si la creación de cuentas aumenta exponecialmente, la carga de trabajo para el humano responsable de la configuración de cuentas también aumenta exponecialmente, y aparta a este empleado de otros aspectos del trabajo potencialmente más valiosos. Un sistema automatizado no tendrá este problema.

Velocidad: ciertas tareas, como encontrar y corregir errores en el código, pueden llevar mucho tiempo a un humano. Los sistemas de software automatizados tienen la capacidad de monitorizar enormes cantidades de datos y, a menudo, pueden detectar errores más rápido que los humanos mediante el reconocimiento avanzado de patrones y otras herramientas. Las correcciones se pueden aplicar con la misma rapidez y, a menudo, sin intervención humana.

Por supuesto, también existen peligros que acechan junto a cualquier proceso de automatización. Entre ellos figuran:

Costes iniciales: las automatizaciones deben crearse antes de poder implementarse. Esto puede conllevar una cantidad significativa de tiempo, esfuerzo e incluso costes de hardware. El valor de la automatización debe considerarse como un equilibrio entre el esfuerzo por crearla y los recursos reales que ahorrará una vez lanzada.

Mantenimiento: puede parecer que las tareas automatizadas pueden ejecutarse indefinidamente, pero normalmente no es así. El código de automatización debe mantenerse actualizado y sincronizado con otras actualizaciones del código y del sistema. Si se añaden nuevas características, puede que el código de automatización también tenga que actualizarse mediante la intervención humana para incluir nuevas acciones o evitar errores.

La inteligencia artificial ofrece algunas posibilidades nuevas y emocionantes para la SRE, sobre todo en el ámbito de la automatización. En teoría, tanto los costes iniciales como el mantenimiento pueden modularse mediante nuevos modelos de IA. Dicho esto, la IA también aporta nuevos puntos débiles potenciales: alucinaciones, seguridad y privacidad, sobre todo.

La ingeniería de lanzamiento es una subdisciplina de la ingeniería de software enfocada específicamente en los pasos necesarios para lanzar software. Estos pasos incluyen el control de versiones, los calendarios de lanzamiento, las compilaciones continuas o periódicas, la selección y recopilación de métricas de lanzamiento y mucho más. En la SRE, la ingeniería de versiones se integra desde el principio, en lugar de añadirse posteriormente; el objetivo es evitar la asignación aleatoria de tareas de ingeniería de lanzamiento en el último momento.

La ingeniería de versiones, como disciplina, incluye varios principios clave. Entre ellos figuran:

Automatización y autoservicio: idealmente, muchos procesos de lanzamiento pueden automatizarse y requieren una interacción mínima o nula por parte de los ingenieros. Esto garantiza lanzamientos rápidos y estables.

Velocidad: en la ingeniería de versiones, se prefiere una filosofía de versiones rápidas y frecuentes. Al lanzar versiones rápidamente, incluso cada hora durante el lanzamiento, hay menos cambios entre ellas. Esta velocidad permite realizar pruebas y solucionar problemas con mayor facilidad.

Compilaciones herméticas: los procesos de compilación deben ser totalmente independientes de la propia máquina de compilación, utilizando los compiladores, bibliotecas y herramientas más populares. "Si dos personas intentan crear el mismo producto con el mismo número de revisión en el repositorio de código fuente en máquinas diferentes, esperamos resultados idénticos", escribe Dinah McNutt de Google.

Normas y políticas: por razones de seguridad, es vital que existan controles sobre determinadas tareas, como la implementación, los cambios en el código fuente, las nuevas versiones y los cambios en la configuración de la compilación.

Gran parte de la ingeniería de fiabilidad del sitio está al servicio de la simplicidad. El software es, escribe Max Luebbe de Google, "inherentemente dinámico e inestable". Teniendo esto en cuenta, la simplicidad es clave para minimizar los posibles problemas e intentar controlar esa inestabilidad inherente.

Para ello, la ingeniería de fiabilidad del sitio promueve diversas tareas que pueden simplificar y aclarar un proyecto.

1. Seleccionar cuidadosamente qué características incluir es útil, pero también lo es eliminar todas las que no aporten nada significativo a la utilidad del producto. A mayor número de características, mayor complejidad.
2. Las versiones más pequeñas y frecuentes permiten una depuración y resolución de problemas mucho más sencillas. Una nueva versión con decenas de nuevas características podría introducir errores que podrían ser excesivamente difíciles de localizar. ¿Un lanzamiento con una nueva característica? Cualquier problema potencial solo puede provenir de un lugar.
3. Del mismo modo, puede ser tentador añadir complejidad a las API mediante el uso de múltiples endpoints, microservicios y más. Esto debe evitarse. Las API más sencillas son más rápidas de configurar, requieren menos documentación y reducen el tiempo y los costes de integración.