Top 11: lo que debes saber sobre DevOps
Tabla de contenido
- ¿Qué es DevOps y de dónde viene?
- ¿En qué se diferencian DevOps y Agile?
- ¿En qué se diferencian DevOps y ITIL o ITSM?
- ¿Cómo encaja DevOps con VisibleOps?
- Los principios fundamentales de DevOps
- ¿Cuáles son las áreas de los patrones de DevOps?
- ¿Cuál es el valor de DevOps?
- ¿Cómo se integran Seguridad y QA en el flujo de trabajo?
- Primer Patrón DevOps
- Segundo Patrón DevOps
- Tercer Patrón DevOps
1. ¿Qué es DevOps y de dónde viene?
El término DevOps se refiere usualmente al movimiento profesional emergente que aboga por una relación colaborativa entre Desarrollo y Operaciones de TI, lo que resulta en un flujo rápido de trabajo planificado, es decir, un alto ritmo de implementaciones, incrementando simultáneamente la confiabilidad, la estabilidad, la resistencia y la seguridad del entorno de producción.
¿Por qué Desarrollo y Operaciones TI?
Porque habitualmente es la cadena de valor que se encuentra entre el negocio (donde se definen los requerimientos), y el cliente (donde se entrega el valor).
Los orígenes del movimiento DevOps se encuentran alrededor de 2009, como resultado de la convergencia de numerosos movimientos adyacentes que se alimentaron mutuamente:
- El movimiento de las conferencias Velocity, especialmente el seminario “10 implementaciones al día”, de John Allspaw y Paul Hammond.
- El movimiento “Infraestructur como código” (Mark Burgess y Luke Kanies) el movimiento “Infraestructura Ágil” (Andrew Shafer) y el movimiento “Administración de sistema Ágil” (Patrick DeBois).
- El movimiento “Lean Startup” de Eric Ries.
- El movimiento “Integración continua y liberación” de Jez Humble
- La amplia disponibilidad de tecnologías en la nube y PaaS (plataforma como servicio), por ejemplo Amazon Web Services.
Uno de los coautores del “Recetario de DevOps”, John Willis, escribió un fantástico documento acerca de la “Convergencia de DevOps” aquí:
2. ¿En qué se diferencian DevOps y Agile?
Uno de los principios del proceso de desarrollo ágil es entregar software funcional en entregas más pequeñas y frecuentes, en oposición al enfoque "Big Bang" de la metodología en cascada. Esto es muy evidente en el objetivo de las metodologías ágiles de tener funcionalidades potencialmente entregables, al final de cada iteración, (normalmente cada dos semanas).
Las altas tasas de implementaciones suelen apilarse en la puerta de Operaciones de IT para ser implementadas. Se atribuye a Clyde Logue, fundador de StreamStep, la frase “Agile fue clave en que Desarrollo reconquistara la confianza del negocio, pero, sin querer, dejó a Operaciones rezagado. DevOps es una manera para que el negocio recupere la confianza en la organización TI por completo.”
DevOps es especialmente complementario al proceso de desarrollo de software ágil, dado que lo extiende y completa la integración continua y el proceso de liberación al asegurar que el código está listo para producción y proveyendo valor al cliente.
DevOps permite un flujo de trabajo mucho más continuo dentro del equipo de operaciones TI. Cuando el código no se promueve hasta estar en producción, al ritmo al que es desarrollado, (por ejemplo, Desarrollo entrega códigos cada dos semanas pero son implementados cada dos meses), las implementaciones se apilan frente a la puerta de operaciones de TI, los clientes no reciben el valor y los despliegues a menudo resultan en caos e interrupciones de servicio.
DevOps tiene un componente inherente de cambio cultural, dado que modifica el flujo de trabajo y las medidas locales de Desarrollo y Operaciones de TI.
3. ¿En qué se diferencian DevOps e ITIL o ITSM?
Aunque la mayoría de las personas ve DevOps como una reacción a ITIL (Biblioteca de Infraestructura de TI) o a ITSM(gestión de servicios de TI), yo tengo una visión distinta. ITIL y ITSM son mejores codificaciones de los procesos de negocio que forman la base de Operaciones de TI y de hecho describen muchas de las capacidades que Operaciones de TI necesitan tener en orden para dar soporte al flujo de trabajo al estilo DevOps.
La metodologías ágil y de integración y liberación contínua son el resultado que genera Desarrollo como salida, las cuales son las entradas para Operaciones de TI. Para acomodar la rápida cadencia de liberaciones asociada con DevOps, muchas áreas de los procesos ITIL requieren estar automatizados, especialmente los procesos de cambio, configuración y liberación.
El objetivo de DevOps no sólo es incrementar el ritmo de cambio, sino implementar exitosamente nuevas funcionalidades en producción, sin causar caos ni interrumpir otros servicios, permitiendo la rápida detección y corrección cuando ocurran. Esto se añade a las disciplinas ITIL de diseño de servicio y gestión de incidentes y problemas.
4. ¿Cómo encaja DevOps con VisibleOps?
Visible Ops es una guía prescriptiva para transmitir las mejoras para los equipos de operaciones de alto rendimiento, y uno de los conceptos clave es la noción de cómo controlar y reducir el trabajo no planificado.
En muchos aspectos, DevOps es lo opuesto: enfocado principalmente en cómo crear un flujo de trabajo planificado rápido y estable a través de los equipos de Desarrollo y de Operaciones. No obstante, DevOps también tiene un enfoque más holístico hacia la erradicación sistemática del trabajo no planificado, aplicando principios de la ingeniería resiliente y la gestión y reducción responsable de la deuda técnica.
5. Los principios fundamentales de DevOps
Los principios fundamentales de todos los patrones DevOps pueden derivarse de “Las tres vías”. Éstas describen los valores y filosofías que enmarcan los procesos, procedimientos, y prácticas, así como los pasos prescriptivos.
La Primera Vía enfatiza el rendimiento del sistema entero, en oposición al rendimiento de un departamento específico que puede ser tan grande como una división (por ejemplo Desarrollo u Operaciones de TI), o tan pequeño como un individuo (por ejemplo, un desarrollador, un administrador de sistema)
El foco está en todos los flujos de valor de negocio habilitados por TI. En otras palabras, empieza cuando se identifican requerimientos (por ejemplo, por el negocio o por IT), se crea la solución en Desarrollo y se mueve a Operaciones de IT, donde el valor se entrega al cliente como un servicio.
Los resultados de la puesta en práctica de la Primera Vía incluyen nunca permitir que un error conocido avance hacia centros de trabajo subsiguientes en el flujo de trabajo, nunca permitir que la optimización local cree degradación global, buscar siempre incrementar el flujo, y buscar siempre alcanzar el conocimiento más profundo del sistema.
La Segunda Vía consiste en crear bucles de retroalimentación de derecha a izquierda. El objetivo de casi cualquier proceso de mejora es acortar y amplificar los bucles de retroalimentación de modo que las correcciones necesarias puedan realizarse contínuamente.
Los resultados de la Segunda Vía incluyen comprensión y respuesta a las necesidades de los clientes, internos y externos, el acortamiento y amplificación de los bucles de retroalimentación, e incluir conocimiento donde sea necesario.
La Tercera Vía fomenta la creación de una cultura basada en dos cosas: La experimentación continua, que requiere asumir riesgos y aprender del éxito y del fracaso; y la comprensión de que la repetición y la práctica son pre-requisitos para alcanzar la maestría.
Necesitamos ambas por igual. La experimentación y la toma de riesgos son lo que garantiza permanecer en marcha hacia la mejora, incluso cuando signifique entrar en la zona de peligro más allá de lo que se haya entrado jamás. Y es necesaria la maestría en las habilidades que pueden ayudarnos a salir de la zona de peligro cuando se ha ido demasiado lejos.
Los resultados de la Tercera Vía incluyen encontrar tiempo para la mejora del trabajo diario, crear rituales que recompensen al equipo por asumir riesgos, e introducir fallos en el sistema para incrementar la resistencia.
6. ¿Cuáles son las áreas de los patrones de DevOps?
Los patrones DevOps se pueden dividir en cuatro áreas:
Área 1:
Extender a Desarrollo en Producción: Esto incluye extender las funciones de integración y liberación continua en Producción, integrando a QA y Seguridad en el flujo de trabajo, asegurando la disponibilidad para Producción del código y el entorno
Área 2:
Crear retroalimentación de Producción a Desarrollo: Esto incluye crear una línea temporal completa con los eventos de Desarrollo y Operaciones de TI para ayudar a la resolución de problemas, incluyendo a Desarrollo en reuniones post-mortem sin búsqueda de culpabilidad, permitiendo a los desarrolladores obtener auto-servicio cuando sea posible y creando radiadores de información que muestren cómo las decisiones locales afectan las metas globales.
Área 3:
Insertar a Desarrollo en Operaciones de TI: Esto incluye poner a Desarrollo en la cadena de escalada de producción, asignar recursos de Desarrollo a la gestión de problemas de producción y ayudar a disminuir deuda técnica, y crear una capacitación cruzada entre Operaciones y Desarrollo que permita reducir la cantidad de escaladas.
Área 4:
Insertar a Operaciones de TI en Desarrollo: Esto incluye insertar o enlazar recursos de Operaciones en Desarrollo, crear historias de usuario reutilizables para el equipo de Operaciones de TI (incluyendo implementación, gestión del código en producción, etc.); y definir requerimientos no funcionales que puedan ser usados en todos proyectos.
7. ¿Cuál es el valor de DevOps?
Se puede pensar que existen tres beneficios comerciales para las organizaciones que adoptan DevOps:
- Reducción en el tiempo de comercialización, es decir, con tiempos de ciclo más reducidos y tasas de despliegue más altas.
- Incremento de la calidad, es decir, incremento de disponibilidad, incremento del ritmo de cambios exitosos, reducción de los fallos, etc.
- Incremento de la efectividad organizacional, por ejemplo, basada en el incremento de la inversión del tiempo en las actividades que aporten valor en lugar del gasto, incremento en la cantidad de valor que se ofrece al cliente.
Reducción en el tiempo de comercialización:
En 2007, en el IT Process Institute, se realizó un análisis comparando 1.500 organizaciones de TI, concluyendo que las organizaciones TI de alto rendimiento eran, en promedio, de 5 a 7 veces más productivas que el resto de las organizaciones. Realizaron 14 veces más cambios, con la mitad de fallos, de los que 4 veces más fueron resueltos al primer arreglo, y los tiempos de las incidencias de severidad 1 fueron 10 veces más cortos. También tenían 4 veces menos problemas encontrados repetidamente en auditorías, la probabilidad de detectar agujeros en el control interno automatizado era 5 veces menor, y la efectividad en cuanto a las fechas de entrega de los proyectos era 8 veces mejor.
Una de las características de las organizaciones de alto rendimiento es que se alejan aceleradamente de la manada. En otras palabras, lo mejor continúa mejorando. Esto ocurre completamente en el área de los altos ritmos de implementaciones. Las organizaciones aplicando prácticas DevOps sobrepasan nuestro mejor ejemplo de alto rendimiento en órdenes de magnitud.
Accenture realizó un estudio sobre lo que las empresas de Internet están haciendo, en el cual Amazon afirmó que ellos hacen más de 1000 implementaciones al día, ¡con una tasa de éxito del cambio del 99,999%!
La capacidad de mantener altos ritmos de implementación, es decir, tiempos de ciclo rápidos, se traduce en valor de negocio de dos formas: Cuán rápido la organización puede pasar de una idea a la entrega del valor al cliente, (es decir del “concepto al cobro” como dirían Damon Edwards and John Willis) y en cuántos experimentos la organización puede realizar simultáneamente.
Si una organización puede hacer sólo una implementación cada nueve meses, y la competencia puede hacer 10 en un día, existe una desventaja competitiva estructural muy importante.
Los ritmos de implementación altos también permiten una experimentación rápida y constante. Scott Cook, fundador de Intuit, ha sido uno de los más ardientes defensores de una "cultura de la innovación desenfrenada" en todos los niveles de la organización.
Todo empleado debería ser capaz de hacer experimentos rápidos y a una alta velocidad... Dan Maurer está a cargo de nuestra división de consumo, incluyendo la operación del sitio web de TurboTax. Cuando entró, realizábamos cerca de siete experimentos al año. Al instalar una cultura de innovación desenfrenada, ahora realizan 165 experimentos en la temporada de declaración de impuestos. ¿Resultado para negocio? La tasa de conversión del sitio web ha subido un 50%. ¿Resultado para los empleados? Ellos están encantados, porque ahora sus ideas llegan al mercado.
-Scott Cook
La parte más impactante de la historia de Scott Cook es que estaban haciendo todos esos experimentos ¡durante el período de declaración de impuestos! La mayoría de las organizaciones congelan sus operaciones en las temporadas de mayor importancia (por ejemplo el departamento de ventas al detal puede frecuentemente tener paralización de cambios por vacaciones desde Octubre hasta Enero). Pero si se consiguen incrementar los ritmos de conversión, y por lo tanto, las ventas, durante esas temporadas, cuando la competencia no puede, eso se convierte en una auténtica ventaja.
Los pre-requisitos para hacer esto incluyen ser capaz de hacer muchos cambios pequeños rápidamente, sin interrumpir el servicio a los clientes.
Trabajar en la mayoría de las organizaciones TI es a menudo desagradecido y frustrante. Mucha gente se siente atrapada en una película de terror que no deja de repetirse e impotente para lograr un cambio en la situación. La gestión abdica su responsabilidad en el correcto funcionamiento de TI, resultando en unas interminables guerras tribales entre los departamentos de desarrollo, operaciones, y seguridad informática. Y las cosas sólo empeoran cuando aparecen los auditores.
Todo esto resulta, inequívocamente en un bajo rendimiento crónico. La vida de un profesional en TI es, a menudo, desmoralizante y frustrante, lo que lleva, normalmente, a sentimientos de impotencia y estrés, que se acaban filtrando en cada aspecto de la vida. Desde problemas de salud relacionados con el estrés, hasta problemas sociales o tensiones en casa, ser un profesional de TI no sólo no es saludable, sino que además es insostenible.
Como personas, estamos hechos para contribuir y sentir que realmente marcamos la diferencia. Además de esto, cuando los profesionales de TI piden ayuda a sus organizaciones, a menudo son recibidos con un 'no lo entiendes' o, aún peor, con un apenas enmascarado 'tú no importas'.
8. ¿Cómo se integran Seguridad y QA en el flujo de trabajo?
Los altos ritmos de implementación usualmente asociados con el flujo de trabajo de DevOps a menudo ponen una enorme presión sobre los equipos de Control de calidad y Seguridad informática. Consideremos el caso en el que Desarrollo está haciendo 10 implementaciones diarias, mientras que Seguridad requiere tiempos de espera de cuatro meses para completar las revisiones de seguridad de la aplicación. A simple vista, se observa una falta de coincidencia entre el ritmo de despliegues y el de revisiones de seguridad.
Un ejemplo del riesgo expuesto por despliegues insuficientemente comprobados es el famoso caso del fallo de Dropbox en 2011, en el que la autenticación quedó desactivada durante cuatro horas, permitiendo a usuarios no autorizados acceder a toda la información almacenada.
La buena noticia para Control de calidad y Seguridad Informática es que las organizaciones capaces de sostener ritmos altos de implementaciones, suelen usar integración contínua y otras prácticas relacionadas con la liberación contínua, que a menudo incluyen una cultura de prueba continua. Dicho en otras palabras, cada vez que se va a integrar el código, se ejecutan pruebas automatizadas y cualquier problema que aparezca debe ser corregido para continuar, del mismo modo que un desarrollador revisa un código que no se compila.
Mediante la inclusión de las pruebas funcionales, de integración y de seguridad en las operaciones diarias de Desarrollo, los defectos se detectan y resuelven en menor tiempo que nunca.
Hay un número creciente de herramientas de seguridad informática, como Gauntlet y Security Monkey, que ayudan a probar objetivos de seguridad en los procesos de desarrollo y producción.
Una preocupación habitual genuina es que las herramientas de análisis estático de código requieren demasiado tiempo para ejecutarse que harían que los tiempos de los procesos de prueba e integración tardasen horas o incluso días en completarse. En esos casos, Seguridad Informática debería designar los módulos específicos sobre los que se delegan las funcionalidades de seguridad (por ejemplo, cifrado, autenticación, etc.). Cada vez que se modifican esos módulos, se ejecutan las pruebas completas de nuevo, de otro modo, la implementación puede continuar.
Una última nota: Los flujos de trabajo de DevOps a menudo tienen más dependencia en la detección y recuperación, que en la prueba unitaria estándar. En otras palabras, en el desarrollo de software empaquetado, que dificulta el despliegue de cambios y parches, Control de calidad depende mucho de la prueba del código para cumplir la funcionalidad antes de ser enviado. Por otro lado, cuando el software se entrega como un servicio y los defectos pueden ser resueltos muy rápidamente, Control de calidad puede reducir su dependencia en las pruebas y concentrarse en la monitorización de producción para detectar problemas, siempre y cuando se puedan resolver rápidamente.
La recuperación rápida de errores de código puede ser mejorada con la inclusión de feature flags, o activadores de funcionalidades, que activan y desactivan funcionalidades del código mediante opciones de configuración, en lugar de tener que descartar una implementación nueva por completo.
Depender en la detección y recuperación para CC es obviamente, mucho más aplicable cuando lo peor que puede ocurrir es la pérdida de funcionalidad o del rendimiento requerido. Sin embargo, cuando los errores ponen en riesgo de perder confidencialidad o integridad entre los sistemas o datos, la dependencia no se debe poner en la detección y recuperación, sino que debe ser probado antes de desplegar el código, porque un error de producción generaría un incidente de seguridad genuino.
9. Primer Patrón DevOps
Demasiado a menudo en los proyectos de desarrollo de software, Desarrollo acaba empleando todo el tiempo de la planificación en el desarrollo de funcionalidades. Esto no deja tiempo suficiente para tratar los asuntos de Operaciones. Lo que lleva a tomar atajos de forma sucesiva en la definición, creación y comprobación de todo en lo que el código se basa, lo cual incluye las bases de datos, los sistemas operativos, la red, la virtualización y demás. Ésta es, sin duda, una de las principales causas de la tensión perpetua entre Desarrollo y Operaciones, y sus resultados no óptimos.
Las consecuencias de esto son bien conocidas: Entornos con definiciones y especificaciones inadecuadas, procedimientos de implementación irrepetibles, incompatibilidades entre el código implementado y el entorno, entre otros.
En este patrón, crearemos los entornos al principio del proceso de desarrollo y aplicaremos un política que fuerce probar el código y el entorno juntos. Cuando el equipo de desarrollo utiliza un proceso Agile se puede hacer algo muy sencillo y elegante.
De acuerdo con Agile, se supone que dispondremos de código entregable y funcional al final de cada iteración (usualmente cada dos semanas). Modificaremos la política de iteración de Agile para que al final de la iteración no sólo tengamos el código listo, sinó también el entorno en el que se implementará, desde la primera iteración, es decir iteración 0 e iteración 1.
En lugar de responsabilizar a Operaciones de crear un entorno productivo que se ajuste a las especificaciones, se construirá un proceso de creación del entorno automatizado. Este mecanismo creará el entorno de producción, pero también los entorno para Desarrollo y Control de calidad.
Al hacer que los entornos, y las herramientas para crearlos, estén disponibles pronto, quizás antes de que el proyecto empiece, los desarrolladores y Control de calidad pueden ejecutar y probar su código en entornos consistentes y estables, con una desviación controlada del entorno de producción.
Además, al mantener esta desviación entre los distintos entornos (por ejemplo Desarrollo, Control de calidad, Prueba de Integración, Producción) lo más reducida posible, encontraremos y resolveremos asuntos de interoperabilidad entre el código y el entorno mucho antes de la implementación en producción.
Idealmente, el mecanismo de implementación que hemos construido estará completamente automatizado. Las herramientas que se pueden utilizar incluyen shell scripts, Puppet, Chef, Solaris Jumpstart, Redhat Kickstart, Debian Preseed, etc.
10. Segundo Patrón DevOps
Patrick Lightbody, antiguo CEO de BrowserMob, dijo: “Hemos descubierto que cuando despertamos a los desarrolladores a las 2 de la madrugada, se genera un bucle de retroalimentación fenomenal. Los problemas son solucionados más rápido que nunca.”
Esto subraya el problema de que Desarrollo revise su código el viernes a última hora, felicitándose en el estacionamiento de camino a casa, dejando al equipo de Operaciones el trabajo de arreglar el desastre durante todo el fin de semana. Peor aún, los defectos y errores conocidos son recurrentes en producción, forzando al equipo de Operaciones a estar contínuamente apagando fuegos, sin que la razón raíz del problema se arregle nunca porque Desarrollo se mantiene enfocado en desarrollar nuevas funcionalidades.
Un elemento importante de la Segunda Vía es acortar y amplificar los bucles de retroalimentación, y de acercar a Desarrollo a la experiencia del cliente (que incluye tanto al equipo de Operaciones de TI como a los usuarios finales del servicio entregado).
La simetría aquí es destacable: El primer patrón trata acerca de hacer que los entornos estén disponibles temprano. Consiste principalmente en insertar a Operaciones en Desarrollo, mientras que el segundo patrón consiste en poner a Desarrollo en Operaciones.
Aquí, ponemos a Desarrollo en la cadena de escalada de Operaciones, posiblemente poniéndolos en un tercer nivel de soporte, o incluso haciendo a Desarrollo completamente responsable del éxito del despliegue del código, ya sea echándolo atrás o arreglando los problemas hasta que el servicio sea restaurado al cliente.
La meta no es reemplazar a Operaciones por Desarrollo. En su lugar, consiste en garantizar que Desarrollo vea los efectos de su trabajo y de sus cambios, y de que vivan la realidad de Operaciones lo suficiente para que estén motivados para arreglar los problemas rápidamente para ayudar con el alcance de los logros globales.
11. Tercer Patrón DevOps
Otro problema que ocurre frecuentemente es la falta de estandarización en el flujo de valor entre Desarrollo y Operaciones. Ejemplos de esto serían las implementaciones realizados de forma distinta cada vez, o los entornos que reúnen diferentes propiedades. Cuando esto ocurre, ninguna maestría se crea en las configuraciones o procedimientos de la organización.
En este patrón, definimos procedimientos de despliegue reutilizables que puedan ser utilizados en todos los proyectos. Hay una solución muy elegante en las metodologías Ágiles para esto, en la que las actividades de implementación se convierten en una historia de usuario. Por ejemplo, podríamos construir una historia de usuario reutilizable para Operaciones llamada 'Implementación en un entorno de alta disponibilidad', la cual definiría los pasos exactos para construir el entorno, así como cuánto tiempo lleva, qué recursos se necesitan, etc.
Esta información puede, entonces, ser usada por los directores de proyecto para integrar detalladamente las actividades de implementación en el plan de proyecto. Por ejemplo, podríamos tener mucha confianza en el horario de implementación si supiéramos que la historia “Implementación en un entorno de alta disponibilidad” ha sido ejecutada en quince ocasiones en el último año, llevando una media de tres días, con un margen de error de un día.
Además, también ganamos confianza en que las actividades de implementación están siendo debidamente integradas en cada proyecto de software.
Al reconocer que ciertos proyectos de software requieren entornos únicos que Operaciones no soporta oficialmente, podemos permitir excepciones en las que esos entornos están permitidos en producción, pero que sean soportados por alguien fuera de Operaciones, es decir, entornos no soportados.
Al hacer esto, tenemos los beneficios de la estandarización de los entornos (por ejemplo, variedad de producción reducida, menores diferencias en producción, aumento de capacidad de Operaciones de TI para soporte y mantenimiento confiable, etc.), mientras que permitimos los casos especiales que permiten la agilidad que a veces el negocio requiere.
