Ingeniería de la observabilidad

Capítulo 4. Cómo se relaciona la observabilidad con DevOps, SRE y Cloud Native

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Hasta ahora, nos hemos referido a la observabilidad en el contexto de los sistemas de software modernos. Por lo tanto, es importante desentrañar cómo encaja la observabilidad en el panorama de otras prácticas modernas, como los movimientos DevOps, de ingeniería de fiabilidad del sitio (SRE) y nativos de la nube. Este capítulo examina cómo estos movimientos han magnificado la necesidad de la observabilidad y la han integrado en sus prácticas.

La observabilidad no existe en el vacío, sino que es tanto una consecuencia como una parte integral de los movimientos DevOps, SRE y nativos de la nube. Al igual que la comprobabilidad, la observabilidad es una propiedad de estos sistemas que mejora su comprensión. La observabilidad y la comprobabilidad requieren una inversión continua, en lugar de ser una adición de una sola vez, o tener una solución de talla única. A medida que mejoran, se acumulan beneficios para ti, como desarrollador, y para los usuarios finales de tus sistemas. Examinando por qué estos movimientos crearon la necesidad de la observabilidad e integraron su uso, puedes entender mejor por qué la observabilidad se ha convertido en un tema generalizado y por qué equipos cada vez más diversos están adoptando esta práctica.

Nube nativa, DevOps y SRE en pocas palabras

En contraste con los enfoques de desarrollo monolítico y en cascada que empleaban los equipos de entrega de software en los años 90 y principios de los 2000, los equipos modernos de desarrollo y operaciones de software utilizan cada vez más metodologías nativas de la nube y ágiles. En concreto, estas metodologías permiten a los equipos liberar funciones de forma autónoma sin acoplar estrechamente su impacto a otros equipos. El acoplamiento suelto desbloquea varias ventajas empresariales clave, como una mayor productividad y una mejor rentabilidad. Por ejemplo, la capacidad de redimensionar componentes individuales del servicio bajo demanda y agrupar recursos en un gran número de servidores virtuales y físicos significa que la empresa se beneficia de mejores controles de costes y escalabilidad.

Nota

Para ver más ejemplos de las ventajas de las metodologías ágiles y nativas de la nube, consulta el informe DevOps Research and Assessment (DORA) 2019 Accelerate State of DevOps, de Nicole Forsgren et al.

Sin embargo, la nube nativa tiene importantes contrapartidas en cuanto a complejidad. Un aspecto que a menudo se pasa por alto al introducir estas capacidades es el coste de gestión. Los sistemas abstraídos con controles dinámicos introducen nuevos retos de complejidad emergente y patrones de comunicación no jerárquicos. Los antiguos sistemas monolíticos tenían menos complejidad emergente, y bastaban enfoques de monitoreo más sencillos; podías razonar fácilmente sobre lo que ocurría dentro de esos sistemas y dónde podían estar ocurriendo problemas invisibles. Hoy en día, ejecutar sistemas nativos de la nube de forma viable a escala exige prácticas sociotécnicas más avanzadas, como la entrega continua y la observabilidad.

La Cloud Native Computing Foundation (CNCF) define la nube nativa como "la construcción y ejecución de aplicaciones escalables en entornos modernos y dinámicos... Las técnicas [nativas de la nube] permiten sistemas poco acoplados que son resistentes, manejables y observables. Combinadas con una automatización robusta, permiten a los ingenieros realizar cambios de gran impacto de forma frecuente y predecible con un esfuerzo mínimo". Al minimizar el esfuerzo (trabajo humano manual repetitivo) y hacer hincapié en la observabilidad, los sistemas nativos de la nube permiten a los desarrolladores ser creativos. Esta definición se centra no sólo en la escalabilidad, sino también en la velocidad de desarrollo y la operatividad como objetivos.

Nota

Para profundizar en lo que significa eliminar el trabajo, te recomendamos el capítulo 5 de Site Reliability Engineering, editado por Betsy Beyer et al. (O'Reilly).

El cambio a la nube nativa no sólo requiere adoptar un conjunto completo de nuevas tecnologías, sino también cambiar la forma de trabajar de las personas. Ese cambio es inherentemente sociotécnico. A primera vista, el uso de la cadena de herramientas de microservicios no exige explícitamente la adopción de nuevas prácticas sociales. Pero para lograr los beneficios prometidos de la tecnología, también se hace necesario cambiar los hábitos de trabajo. Aunque esto debería ser evidente a partir de la definición y los objetivos declarados, los equipos suelen dar varios pasos antes de darse cuenta de que sus antiguos hábitos de trabajo no les ayudan a abordar los costes de gestión introducidos por esta nueva tecnología. Por eso, la adopción con éxito de patrones de diseño nativos de la nube está inexorablemente ligada a la necesidad de sistemas observables y de prácticas DevOps y SRE.

Del mismo modo, tanto DevOps como SRE destacan en sus definiciones y prácticas el deseo de acortar los bucles de retroalimentación y reducir el trabajo operativo. DevOps proporciona "Mejor valor, antes, más seguro y más feliz"¹ mediante la cultura y la colaboración entre los grupos de desarrollo y operaciones. La SRE aúna los conjuntos de habilidades de ingeniería de sistemas y software para resolver problemas operativos complejos mediante el desarrollo de sistemas de software en lugar del trabajo manual. Como exploraremos en este capítulo, la combinación de la tecnología nativa de la nube, las metodologías DevOps y SRE, y la observabilidad son más fuertes juntas que cada una de sus partes por separado.

Observabilidad: Depurar antes y ahora

El objetivo de la observabilidad es proporcionar un nivel de introspección que ayude a las personas a razonar sobre el estado interno de sus sistemas y aplicaciones. Ese estado puede conseguirse de varias formas. Por ejemplo, podrías emplear una combinación de registros, métricas y trazas como señales de depuración. Pero el objetivo de la observabilidad en sí es agnóstico en cuanto a cómo se consigue.

En los sistemas monolíticos, podías anticiparte a las posibles áreas de fallo y, por tanto, podías depurar tus sistemas por ti mismo y lograr la observabilidad adecuada utilizando un registro de aplicaciones verboso, o métricas groseras a nivel de sistema, como la utilización de CPU/disco , combinadas con destellos de perspicacia. Sin embargo, estas herramientas heredadas y técnicas instintivas ya no funcionan para el nuevo conjunto de retos de gestión creados por las oportunidades de los sistemas nativos de la nube.

Entre las tecnologías de ejemplo que menciona la definición nativa de la nube están los contenedores, las mallas de servicios, los microservicios y la infraestructura inmutable. En comparación con tecnologías heredadas como las máquinas virtuales y las arquitecturas monolíticas, los microservicios en contenedores introducen intrínsecamente nuevos problemas, como la complejidad cognitiva de las interdependencias entre componentes, el estado transitorio descartado tras el reinicio del contenedor y el versionado incompatible entre componentes lanzados por separado. La infraestructura inmutable significa que ya no es factible ssh en un host para depurarlo, ya que puede perturbar el estado en ese host. Las mallas de servicio añaden a una capa de enrutamiento adicional que proporciona una potente forma de recopilar información sobre cómo se están produciendo las llamadas de servicio, pero esos datos tienen una utilidad limitada a menos que puedas analizarlos posteriormente.

La depuración de problemas anómalos requiere un nuevo conjunto de capacidades para ayudar a los ingenieros a detectar y comprender los problemas desde dentro de sus sistemas. Herramientas como el rastreo distribuido pueden ayudar a capturar el estado de las partes internas del sistema cuando se produjeron eventos específicos. Añadiendo contexto en forma de muchos pares clave-valor a cada evento, crearás una visión amplia y rica de lo que ocurre en todas las partes de tu sistema que suelen estar ocultas y sobre las que es imposible razonar.

Por ejemplo, en un sistema distribuido, nativo de la nube, puede resultarte difícil depurar un problema que se produce en varios hosts utilizando registros u otras señales no correlacionadas. Pero utilizando una combinación de señales, podrías profundizar sistemáticamente en el comportamiento anómalo empezando por el nivel alto de tus métricas de servicio, iterando hasta que descubras qué hosts son los más relevantes. Separar los registros por host significa que ya no necesitas una retención e indexación centralizadas de todos los registros, como harías con un monolito. Para comprender las relaciones entre los subcomponentes y servicios de un sistema monolítico o distribuido, es posible que antes necesitaras mantener en tu cabeza las relaciones de todos los componentes del sistema.

En cambio, si puedes utilizar el rastreo distribuido para desglosar y visualizar cada paso individual, necesitas comprender la complejidad de tus dependencias sólo en la medida en que repercuten en la ejecución de una solicitud concreta. Comprender qué rutas de código de llamada y recepción están asociadas a qué versiones de cada servicio te permite encontrar problemas de compatibilidad inversa y cualquier cambio que haya roto la compatibilidad.

La observabilidad proporciona un contexto compartido que permite a los equipos depurar problemas de forma cohesionada y racional, independientemente de la complejidad de un sistema, en lugar de exigir que la mente de una persona retenga todo el estado del sistema.

La observabilidad potencia las prácticas DevOps y SRE

El trabajo de los equipos de DevOps y SRE consiste en comprender los sistemas de producción y domar la complejidad. Así que es natural que se preocupen por la observabilidad de los sistemas que construyen y ejecutan. La SRE se centra en gestionar los servicios según objetivos de nivel de servicio (SLO) y presupuestos de errores (véanse los Capítulos 12 y 13). DevOps se centra en gestionar los servicios mediante prácticas interfuncionales, en las que los desarrolladores mantienen la responsabilidad de su código en producción. En lugar de empezar con una plétora de alertas que enumeran las causas potenciales de las interrupciones, los equipos maduros de DevOps y SRE miden cualquier síntoma visible de dolor para el usuario y luego profundizan en la comprensión de la interrupción utilizando herramientas de observabilidad.

El cambio del monitoreo basado en causas al monitoreo basado en síntomas significa que necesitas la capacidad de explicar los fallos que ves en la práctica, en lugar del enfoque tradicional de enumerar una lista creciente de modos de fallo conocidos. En lugar de dedicar la mayor parte de su tiempo a responder a un montón de falsas alarmas que no tienen ninguna relación con el rendimiento visible para el usuario final, los equipos pueden centrarse en aventar sistemáticamente hipótesis e idear mitigaciones para los fallos reales del sistema. Trataremos esto con más detalle en el Capítulo 12.

Más allá de la adopción de la observabilidad para casos de uso de rotura/reparación, los equipos de DevOps y SRE con visión de futuro utilizan técnicas de ingeniería como el marcado de características, la verificación continua y el análisis de incidentes. La observabilidad potencia estos casos de uso proporcionando los datos necesarios para practicarlos con eficacia. Exploremos cómo la observabilidad potencia cada uno de ellos:

Ingeniería del caos y verificación continua

Éstos requieren que tengas capacidad de observación para "detectar cuándo el sistema está en estado normal y cómo se desvía de ese estado normal a medida que se ejecuta el método del experimento".² No puedes realizar experimentos de caos de forma significativa sin la capacidad de comprender el estado base del sistema, predecir el comportamiento esperado bajo prueba y explicar las desviaciones del comportamiento esperado. "No tiene sentido hacer ingeniería del caos cuando en realidad no sabes cómo se comporta el sistema en su estado actual antes de inyectar el caos".³

Marcar características

Esto introduce combinaciones novedosas de estados de bandera en producción que no puedes probar exhaustivamente en entornos de preproducción. Por tanto, necesitas capacidad de observación para comprender el impacto individual y colectivo de cada bandera de función, usuario por usuario. La noción de monitorizar el comportamiento componente por componente ya no es válida cuando un punto final puede ejecutarse de múltiples formas dependiendo del usuario que lo llame y de las banderas de función que estén activadas.

Patrones de liberación progresiva

Estos patrones, como el canarying y la implementación azul/verde, requieren observabilidad para saber con eficacia cuándo detener la liberación y analizar si las desviaciones del sistema respecto a lo esperado son consecuencia de la liberación.

Análisis del incidente y postmortem sin culpa

Éstas requieren que construyas modelos claros sobre tus sistemas sociotécnicos: no sólo lo que ocurría dentro del sistema técnico en fallo, sino también lo que los operadores humanos creían que estaba ocurriendo durante el incidente. Así pues, una sólida herramienta de observabilidad facilita la realización de excelentes retrospectivas al proporcionar un rastro documental ex post facto y detalles para orientar a los redactores de la retrospectiva.

Conclusión

A medida que las prácticas de DevOps y SRE sigan evolucionando, y a medida que la ingeniería de plataformas crezca como disciplina paraguas, surgirán inevitablemente prácticas de ingeniería más innovadoras en tus cadenas de herramientas. Pero todas esas innovaciones dependerán de tener la observabilidad como sentido central para comprender tus sistemas complejos modernos. El cambio hacia DevOps, SRE y las prácticas nativas de la nube han creado la necesidad de una solución como la observabilidad. A su vez, la observabilidad también ha potenciado las capacidades de los equipos que han adoptado su práctica.

¹ Jonathan Smart, "¿Quieres hacer una transformación ágil? No lo hagas. Céntrate en el flujo, la calidad, la felicidad, la seguridad y el valor", 21 de julio de 2018.

² Russ Miles, Chaos Engineering Observability (Sebastopol, CA: O'Reilly, 2019).

³ Ana Medina, "Ingeniería del caos con Ana Medina de Gremlin", podcast de o11ycast, 15 de agosto de 2019.