La esperanza no es una estrategia: siete principios de ingeniería de confiabilidad de sitios (SRE)

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

la ingeniería de confiabilidad de sitios (SRE) puede ser difícil de precisar. 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. Por suerte, existen siete principios de ingeniería de confiabilidad del sitio que pueden ayudar a guiar a un equipo de ingeniería de confiabilidad de sitios (SRE) hacia el éxito.

Gran parte del desarrollo de software se centra legítimamente en la creación, incluido DevOps, un campo relacionado pero distinto, que se preocupa más por todo el ciclo de vida de un producto. Pero el trabajo apenas está completo cuando se inicia el sistema. En el prefacio de la guía de Google para ingeniería de confiabilidad de sitios (SRE), los autores señalan que "entre el 40 y el 90 % de los costos totales de un sistema se incurre después del nacimiento". La ingeniería de confiabilidad de sitios se preocupa por lo que sucede después del lanzamiento, con el objetivo de ayudar a garantizar que un producto siga siendo lo más utilizable posible.

El elemento más importante de la ingeniería de confiabilidad de sitios (SRE) es la confiabilidad y el tiempo de actividad. El mejor servicio del mundo no puede hacer mucho bien a nadie si no está operativo. Por lo tanto, ingeniería de confiabilidad de sitios (SRE) se centra en minimizar el tiempo de inactividad y crear sistemas confiables.

Los equipos de ingeniería de confiabilidad de sitios (SRE) también garantizan que todos los elementos del producto estén actualizados, mediante una gestión cuidadosa del software y las actualizaciones de seguridad. Los estándares y regulaciones pueden cambiar, y los equipos de ingeniería aseguran el cumplimiento continuo.

Las prácticas de ingeniería de confiabilidad de sitios (SRE) también pueden conllevar un ahorro económico. Muchos de los principios básicos de la ingeniería de confiabilidad de sitios (SRE) tienen que ver con la eficiencia, que puede suponer un importante ahorro de costos y esfuerzos, entre otras cosas mediante la automatización y la gestión de recursos.

Los siete principios de SRE incluyen:    

• Abrazar el riesgo
• objetivos de nivel de servicio
• Eliminando la herramienta
• Supervisión
• Automatización
• Ingeniería de versiones
• Simplicidad

Si bien la ingeniería de confiabilidad de sitios (SRE) está muy preocupada por gestionar y limitar el tiempo de inactividad, esta tendencia no significa que el objetivo sea que los servicios mantengan una confiabilidad de servicio perfecta y disponible al 100 %. De hecho, uno de los pilares clave de la ingeniería de confiabilidad de sitios (SRE) es que el 100 % de confiabilidad no solo es poco realista, sino que ni siquiera es necesariamente un resultado preferido.

En ingeniería de confiabilidad de sitios (SRE), el riesgo se entiende como un continuo, donde reducir el riesgo se vuelve exponencialmente más difícil y costoso a medida que se acerca al 100 % de confiabilidad. Intentar mover de un 99.99 % de confiabilidad a un 99.999 % de confiabilidad es mucho más difícil que mover del 80 % al 99 %. Los recursos necesarios para acercarse cada vez más al 100 % reducen la capacidad de un equipo de desarrollo para realizar otras tareas, como innovar nuevas características y actualizaciones. En su lugar, un equipo tiene presupuestos de error para representar las cantidades adecuadas de falla.

Otro punto en contra de la confiabilidad total, por contradictorio que parezca, es que los clientes generalmente no notarán mejoras en la confiabilidad más allá de cierto umbral. No solo es costoso; también hay poca recompensa. Idealmente, se establece un objetivo y se cumple, pero no se excede en exceso.

En cambio, la ingeniería de confiabilidad de sitios (SRE) utiliza métricas de disponibilidad para medir la aceptabilidad del riesgo de tiempo de inactividad. En una métrica, un año 99.99 % confiable incluiría 52.6 minutos de tiempo de inactividad. Métricas más complejas consideran el potencial del tiempo de inactividad en una ubicación o en un elemento de un servicio, mientras que otras permanecen activas.

Un equipo de ingeniería de confiabilidad de sitios (SRE) debe evaluar cada servicio y determinar un nivel aceptable de falta de confiabilidad. ¿Cuánto tiempo de inactividad se permite? ¿Los diferentes tipos de fallas, que surgen de diferentes causas raíz, tienen diferentes efectos en la experiencia del usuario? ¿Cuánto costará (en términos de mano de obra y finanzas) superar esa cifra? ¿Dónde está el saldo?

Elegir objetivos y medir la eficacia con la que se cumplen esos objetivos y por qué es vital para un equipo de ingeniería de confiabilidad de sitios (SRE). Un objetivo de nivel de servicio, o SLO, es un objetivo específico y medible que representa un nivel de calidad que un equipo de ingeniería de confiabilidad de sitios (SRE) ha establecido como meta. Estos SLO pueden tomar la forma de varias métricas, pero la disponibilidad, la tasa de consultas, la tasa de errores y el tiempo de respuesta son comunes.

Estos objetivos se miden mediante el uso de un indicador de nivel de servicio, o SLI, que es una medición sin procesar del rendimiento, como la latencia. Entonces, en ese caso, el SLI sería la métrica de latencia, y el SLO sería para que esa métrica se mantenga por debajo de un cierto umbral. Los SLO a su vez pueden ser parte de un acuerdo de nivel de servicio, o SLA, que es un contrato entre proveedor y usuario que establece los SLO, así como las consecuencias de no cumplirlos.

Elegir las SLO puede ser complicado. Lo ideal sería estructurar los SLO en torno a lo que es más importante para los usuarios. Para un servicio de juegos en la nube, por ejemplo, la SLO podría girar en torno a la baja latencia, pero la latencia no importaría tanto para un servicio de contabilidad.

Idealmente, un ingeniero de confiabilidad del sitio usaría relativamente pocos SLO para enfocarse en lograr esos objetivos; lo más importante es hacer bien la tarea principal. También es importante establecer objetivos realistas; como comentamos anteriormente, la perfección no es un objetivo realista ni deseado.

Los creadores de ingeniería de confiabilidad de sitios (SRE) se esfuerzan por definir el "trabajo duro" como una categoría de trabajo que se superpone con el trabajo, pero no es lo mismo. El trabajo es, en cambio, aquellas tareas de trabajo manual que escalan linealmente, que suelen ser manuales y repetitivas, y que a menudo se pueden lograr mediante la automatización.

El trabajo que debe hacerse una y otra vez se clasifica como trabajo duro; preferiblemente, una tarea individual solo debería necesitar uno o dos recorridos. El trabajo que no mejora el producto también es arduo. "Si su servicio permanece en el mismo estado después de haber terminado una tarea, probablemente la tarea fue difícil", escribe Vivek Rau de Google. Los arreglos de errores, las mejoras de característica y las optimizaciones no son un trabajo arduo, pero la descarga manual de métricas es un trabajo arduo. La respuesta a incidentes, que puede incluir una coordinación significativa entre ingenieros y equipos de operaciones, no es un esfuerzo, y las tácticas de gestión de incidentes deben planificarse antes del lanzamiento.

También existe el trabajo cognitivo. ¿Alguna vez ha tenido una receta básica que usa de vez en cuando, pero tiene que buscar los ingredientes y las medidas cada vez? Eso es trabajo cognitivo: es una pérdida de tiempo y esfuerzo tener que volver a aprender algo una y otra vez. En cambio, la ingeniería de confiabilidad de sitios (SRE) predica 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 confiabilidad del sitio es la supervisión: utilizando herramientas para medir, analizar y mejorar continuamente las características básicas y el rendimiento del sistema. Esas características principales a menudo incluyen lo que se conoce como las "cuatro señales doradas" del monitoreo:

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

Tráfico: ¿Cuánta carga o demanda se coloca en el servicio? Las unidades específicas variarán; tal vez sean páginas vistas, tal vez sean transacciones, tal vez sean solicitudes HTTP.

Errores: generalmente medidos por velocidad, los errores 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 en absoluto.

Saturación: esencialmente, la saturación es una medida de qué tan cerca de la capacidad está un servicio. Comprender la saturación es importante porque algunos servicios comenzarán a fallar, o a ralentizar o producir más errores, ya que se acercan al 100 % de saturación.

Existen muchas herramientas de monitoreo que pueden recopilar datos, establecer puntos de referencia, depurar y analizar problemas, proporcionar paneles de observabilidad útiles y alertar a los SRE sobre posibles interrupciones u otros problemas. También es importante proporcionar informes post mortem sólidos después de que se resuelva un incidente, explicando cualquier contexto en torno a un incidente, causas principales y desencadenantes, impacto, metodología de resolución y lecciones para el futuro. Una autopsia detallada y objetiva puede ser invaluable 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 agregan valor. Con el tiempo libre recientemente ampliado, los ingenieros pueden trabajar en tareas que la automatización no puede completar: creación, ideación, orientación a gran escala y más.

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 quitarle 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 nuevo empleado puede hacer las cosas de manera diferente a uno antiguo; un usuario podría ingresar accidentalmente un valor en el campo incorrecto. Un proceso automatizado (generalmente) no lo hará.

Escalabilidad: la escalabilidad es un beneficio importante a largo plazo de la automatización. Tomemos nuestro ejemplo anterior de creación de cuentas de usuario. Si la creación de cuentas aumenta exponencialmente, la carga de trabajo para el humano responsable de la configuración de la cuenta también aumenta exponencialmente, alejando 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 monitorear grandes cantidades de datos y, a menudo, pueden detectar errores más rápido que los humanos a través del reconocimiento avanzado de patrones y otras herramientas. Los arreglos se pueden aplicar con la misma rapidez, a menudo sin ninguna participación humana.

Por supuesto, también existen peligros que acechan a cualquier proceso de automatización. Estas incluyen:

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

Mantenimiento: puede parecer que las tareas automatizadas pueden ejecutarse para siempre, pero a menudo no es así. El código de automatización debe mantenerse actualizado y sincronizado con otros códigos y actualizaciones del sistema. Si se agregan nuevas características, es posible que el código de Automatización también deba actualizarse mediante la intervención humana para incluir nuevas acciones o evitar errores.

La inteligencia artificial ofrece algunas posibilidades nuevas y emocionantes para la ingeniería de confiabilidad de sitios (SRE), más obviamente en el ámbito de la Automatización. Teóricamente, tanto los costos iniciales como el mantenimiento pueden ser modulados por nuevos modelos de IA. Dicho esto, la IA también trae nuevos puntos débiles potenciales: alucinación, seguridad y privacidad, sobre todo.

La ingeniería de lanzamiento es una subdisciplina de la ingeniería de software centrada específicamente en los pasos necesarios para lanzar software. Esos pasos incluyen el control de versiones, los cronogramas de lanzamiento, las compilaciones continuas o periódicas, la selección y recopilación de métricas de lanzamiento, entre otros. En ingeniería de confiabilidad de sitios (SRE), la ingeniería de lanzamiento se incorpora al principio, en lugar de ser una ocurrencia tardía; el objetivo es evitar una asignación aleatoria de tareas de ingeniería de lanzamiento en el último minuto.

La ingeniería de versiones, como disciplina, incluye varios principios clave. Estas incluyen:

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

Velocidad: en la ingeniería de lanzamientos, se prefiere una filosofía de lanzamientos rápidos y frecuentes. Al implementar rápidamente los lanzamientos, tal vez incluso cada hora alrededor del lanzamiento, hay menos cambios entre versiones. Esta velocidad permite realizar pruebas y solucionar problemas de forma más sencilla.

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 diferentes máquinas, esperamos resultados idénticos", escribe Dinah McNutt de Google.

Estándares y políticas: Por razones de seguridad, es vital que se verifiquen ciertas tareas, incluido el despliegue, cambios en el código fuente, nuevas versiones y cambios en la configuración de compilación.

Gran parte de la ingeniería de confiabilidad del sitio está al servicio de la simplicidad. El software, escribe Max Luebbe de Google, “es inherentemente dinámico e inestable”. Con eso en mente, la simplicidad es clave para minimizar los problemas potenciales e intentar controlar esa inestabilidad inherente.

Con este fin, la ingeniería de confiabilidad del sitio promueve varias tareas que pueden simplificar y aclarar un proyecto.

1. Seleccionar cuidadosamente las características que se van a incluir es útil, pero también puede serlo eliminar todas las que no aporten una utilidad significativa a la Empresa de servicios públicos. Más características equivalen a más complejidad.
2. Las versiones más pequeñas y frecuentes permiten una depuración y una resolución de problemas mucho más sencillas. Una nueva versión con docenas de características nuevas podría introducir errores que podrían ser extremadamente difíciles de rastrear. ¿Un lanzamiento con una nueva característica? Cualquier problema potencial solo puede provenir de un lugar.
3. De manera similar, puede resultar tentador agregar complejidad a las API mediante el uso de múltiples puntos finales, 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 costos de integración.