Resumen y Sinopsis del Libro: The Devops Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations

El libro escrito por Gene Kim, Patrick Debois, Jez Humble, John Willis, nos describe la filosofía DevOps, sus motivaciones, técnicas y aplicabilidad, desde la visión de cuatro de las personas más relevantes y conocidas en la comunidad, mostrándonos una guía práctica para crear organizaciones de Ti de alto rendimiento.

La obra describe 3 grandes caminos, explicados en 23 capítulos, cada uno documenta las practicas técnicas pertinentes con apoyo de casos de estudio y experiencias procedentes de profesionales del sector:

·     Primer camino: “The principles of Flow”: para acelerar la entrega de valor al cliente.

·     Segundo camino: “The principles of feedback”: donde nos permite crear sistemas de trabajo cada vez más seguros.

·     Tercer camino: “the principles of continual learning and experimentation”

Es importante señalar que los autores nos aclaran que los tres caminos no manejan una progresión lineal. Cada equipo de la organización puede tener fragmentos de cada una de ellas, centrado en llenar las posibles lagunas que puedan existir en el proceso.

El libro parte con una introducción donde nos explican los fundamentos de la filosofía DevOps, algunos antecedentes y nos dan un breve resumen de los 3 caminos.

Continuando con una sesión que nos explican por donde comenzar, describiendo algunos elementos sobre como iniciar el camino a la implementación de la cultura DevOps, evaluando el flujo actual, identificando el punto ideal de arranque en conjunto con la conformación de un equipo que guie la transformación y gestioné el cambio.

Los autores hacen hincapié en hacer visible el trabajo, que tomen en consideración la ley de Cowey en el diseño organizacional en la cual plantea que el software generado es un reflejo de la organización que lo realiza y por último nos detalla cómo obtener grandes resultados integrando las operaciones en el trabajo diario de desarrollo.

Luego nos empiezan a explicar cada uno de los tres caminos, iniciando con “The principles of Flow”, donde nos detallan su visión de cómo debe ser el flujo entre desarrollo y producción, explicando los mecanismos para conseguir que funcione de manera ágil, segura, con calidad y a tiempo. Explicando conceptos tan importantes de La filosofía DevOps como: la automatización de pruebas e integración continua.

En el camino “The principles of Flow”, se establece que para que sea expedito se debe llevar de izquierda (idea/código) a derecha (producción), buscando identificar, medir y mejorar el flujo de trabajo a través de la entrega de valor a los clientes.

Todo este camino cubre los siguientes cinco capítulos:

·     “Create the foundations of our deployment pipeline”: Donde recomiendan proporcionar a todos los pasos del flujo de valor acceso a entornos similares a los de producción tratando su infraestructura y configuración como código, haciendo que la infraestructura sea inmutable, garantizando que el lugar donde operamos, desarrollamos y probamos sea comparable y un indicador fiable del funcionamiento del sistema para los clientes, de forma que el nuevo valor aportado por los desarrolladores pueda desplegarse fácil y previsiblemente a los clientes.

·     “Enable fast and reliable automated testing”: Se plantea que mediante la creación de un bucle de retroalimentación rápida de las pruebas, que están tomando el código más reciente, empujando a un entorno similar a la producción, y probar automáticamente la aplicación en el nivel más rentable y eficaz de los recursos - puede acelerar sus bucles de retroalimentación desarrollador para detectar rápidamente y corregir los errores tan rápida y eficientemente como sea posible.

·     “Enable and practice continuous integration”: Sugieren fusionar el código de vuelta a la rama maestra pronto y con frecuencia, reduciendo la sobrecarga de la integración del código y proporcionando rápidos bucles de retroalimentación sobre el estado del código a través de pruebas automatizadas configuradas de forma complementaria.

·     “Automate and enable low-risk releases”: Donde se establece que todo el despliegue de código debe ser automatizado, repetible y predecible a través de pequeños lotes, mediante la automatización tanto del código como de la infraestructura, y la selección de patrones de lanzamiento adecuados (y arquitectura subyacente) para crear lanzamientos rápidos, pequeños y de bajo riesgo, medidos a través de plazos de despliegue cortos, defectos bajos y MTTR rápidos.

·     “Architect low-risk releases”: Los autores proponen que se cree arquitecturas evolutivas poco acopladas que toleren los cambios, reduzcan el riesgo de despliegue y permitan la adaptabilidad de su arquitectura para satisfacer las necesidades cambiantes de la organización, utilizando el patrón de estrangulamiento cuando sea necesario para aislar y reducir el riesgo de migración de las partes heredadas de su aplicación empresarial.

En el segundo camino ““The principles of feedback”, se recorre el camino contrario al flujo de desarrollo y despliegue (derecha (producción) a izquierda (código)), para proporcionar feedback sobre cómo marcha el proceso. Se insiste en aspectos como la monitorización y medida automatizados, así como otros mecanismos más procedimentales como los test A/B o la revisión y coordinación.

En otras palabras, no recomiendan que se supervise e identifique los fallos con rapidez, automatice esta comprobación en la medida de lo posible y, cuando se detecte un problema, el equipo haga swarming para resolverlo rápidamente, reduciendo su impacto en el negocio.

Todo el camino se desarrollo en los siguientes capítulos del libro:

·     “Create telemetry to enable seeing and solving problems”: Establecen proporcionar los más altos niveles de servicio del sistema, debemos crear visibilidad en forma de telemetría para supervisar el rendimiento del sistema y el funcionamiento a través de aplicaciones y entornos de desarrollo, pre-producción y producción - lo que nos permite identificar rápidamente la causa raíz de los servicios y la infraestructura que crean desviaciones del servicio, reduciendo el MTTR.

·     “Analyze telemetry to better anticipate problems and achieve goals”: Explican que no basta con capturar telemetría, sino que hay que aplicar a esa telemetría las técnicas de análisis y detección adecuadas para garantizar que podemos identificar desviaciones válidas y procesables de la norma. El objetivo es ser proactivos y vigilar los principales indicadores de averías para detectarlas y prevenirlas antes de que se produzcan.

·     “Enable feedback so development and operations can safely deploy code”: Especifican que no basta con tener telemetría: los ingenieros deben poder consumirla para obtener información real y consumible sobre el estado del sistema a través de circuitos de retroalimentación. Sin embargo, esto también debe complementarse con una cultura de responsabilidad compartida para garantizar la salud del sistema en su conjunto mediante la observación del impacto que los cambios tienen en todos los que se encuentran aguas abajo de ellos hasta llegar al cliente.

·     “Integrate hypothesis-driven development and A/B testing into our daily work”:  En este capítulo recomiendan centrarse en permitir la experimentación rápida de ideas de productos mediante la creación de ciclos cortos, rápidos y comprobables utilizando pruebas A/B destinadas a realizar la menor cantidad de trabajo necesaria para probar una hipótesis en su software con clientes reales, y permitirle incorporar rápidamente esos hallazgos de nuevo en su producto.

·     “Create review and coordination processes to increase quality of our current work”: Siguieren evitar las transferencias y las barreras en los procesos de publicación: desarrolle y mejore una cultura de calidad, al tiempo que establece la capacitación y la automatización necesarias para crear publicaciones sin burocracia y garantizar el cumplimiento de las normas de calidad necesarias.

Con respecto al “the principles of continual learning and experimentation”, un camino menos estructurado, donde se habla del aprendizaje continuo, apostando a una cultura de la seguridad o prácticas como el generar intencionadamente incidencias en producción para capacitar a los equipos a reaccionar ante ellos.

En este último camino se establece la confianza y la seguridad psicológica necesarias para aceptar el fracaso como una oportunidad de aprender, invirtiendo constantemente en la mejora de la prestación de servicios mediante la aplicación del método científico para identificar y probar hipótesis de mejora en ciclos rápidos de planificar, hacer, comprobar y actuar.

Para abordar todo el camino los autores utilizan tres capítulos, donde explican en detalle lo que se desea hacer y alcanzar:

·     “Enable and inject learning into daily work”: Plantean que las empresas deben desarrollar una cultura del aprendizaje, centrada en el autodiagnóstico, la mejora y el intercambio de conocimientos, no sólo para responder con rapidez a los problemas, sino también para garantizar que se extraen y comparten las lecciones aprendidas y reducir así el riesgo de que otros miembros de la organización cometan los mismos errores.

·     “Convert local discoveries into global improvements”: Se enfocan en que las organizaciones necesitan compartir conocimientos y comprensión mediante un intercambio rápido y automatizado, creando repositorios centralizados y principios de desarrollo que permitan a la empresa encontrar un equilibrio entre la escala y la velocidad de desarrollo mediante normas y repetibilidad, garantizando al mismo tiempo que esos límites sean lo suficientemente suaves como para no ahogar la innovación.

·     “Reserve time to create organizational learning and improvement”: Plantean que las organizaciones tienen que crear una cultura del aprendizaje, dotando a su personal de la autonomía y el poder necesarios para autoorganizarse con el fin de mejorar los procesos, y dándole tiempo no sólo para resolver esos problemas, sino también para compartir lo aprendido y crear comunidades de práctica que aumenten las capacidades generales de la organización en su conjunto.

El libro culmina detallando los aspectos de la seguridad, que deben ser parte natural en todos los pasos y que se apoya con la automatización de los controles necesarios o en la inclusión de ella en el monitoreo productivo e igualmente levantan temas de gestión del cambio, todo esto esta incluido en los dos últimos capítulos:

·     “Information security as everyone’s job, every day”: Las organizaciones deben unir a los desarrolladores, las operaciones y la seguridad de la información para abordar colectivamente el tema de incorporar la seguridad en todas las capas del flujo de valor del desarrollo, asegurando que las prácticas se comprendan, la automatización y el monitoreo sean rigurosos y no se hagan suposiciones en torno a la seguridad de cualquier libreria, servicio, entorno o infraestructura.

·     “Protecting the deployment pipeline and integrating into change management and other security and compliance controls”: Debemos crear un equilibrio de defensa, control y capacidad de auditoría de los sistemas de producción que mantenemos en proporción a los riesgos inherentes a esos sistemas y cambios, poniendo una burocracia viable y mínima para garantizar que se mitigue el riesgo, pero sin sacrificar la eficiencia del desarrollador. y escala de despliegue.

Para concluir les dejo algunos Highlights que condensan un poco las ideas del libro:

·     La ingeniería de calidad consiste en crear y reforzar circuitos de retroalimentación.

·     Las grandes transformaciones culturales son posibles.

·     Desarrollar generalistas con entrenamiento cruzado.

·     Agregue telemetría en todas partes.

·     Nuestro objetivo es reducir el tiempo de producción y aumentar la calidad y la confiabilidad.

·     Cuando el equipo de desarrollo tiene problemas con la implementación o las pruebas, necesitan capacitación, no solo tecnología.

·     El miedo a la implementación es un asesino de la productividad.

·     En DevOps, normalmente definimos nuestro flujo de valor tecnológico como el proceso necesario para convertir una hipótesis comercial en un servicio habilitado por tecnología que entrega valor al cliente.

·     Lean y DevOps encajan muy bien entre sí.

·     Además de los plazos de entrega y los tiempos de proceso, la tercera métrica clave en el flujo de valor de la tecnología es el porcentaje completo y preciso (% C/ A). Esta métrica refleja la calidad del resultado de cada paso en nuestro flujo de valor.

El libro es una hoja de ruta practica para mejorar la gestión de Ti en cualquiera organización, condensa elementos valiosos sobre desarrollo de software que he leído en los últimos años, por otro lado muestra explicaciones de las ideas que propone, aporta casos reales e incluso identifica herramientas software específicas.