Una cultura DevOps saludable afecta a todos en una organización. Cuando el concepto de DevOps de una empresa es que es un equipo, o que solo ciertos grupos se ven afectados por DevOps, en realidad se han convertido en un anti-patrón para DevOps.
Las empresas de la generación que empezó después de la nube han adoptado todos los principios de DevOps sin problemas y les ayuda a tener éxito en un entorno de aplicación moderno.
Algunas empresas exitosas de AD [1] han analizado este fenómeno y, al ver algunas de las ventajas que disfrutan las empresas modernas, han decidido probar las aguas para ver si pueden disfrutar de los mismos beneficios.
Fruta madura
Debido a que es difícil dar la vuelta a un barco grande, las empresas de AD comienzan por adoptar algunos de los componentes de DevOps más sencillos y rentables, como pasar a un sistema de control de versiones moderno, construir algunas canalizaciones (CI) o adoptar una estrategia limitada de infraestructura-como-código (IaC) para algunos de sus proyectos más nuevos.
Pero para beneficiarse plenamente de DevOps, se debe abordar el problema principal: una cultura de Cambio Continuo.
Cambio Continuo
A estas alturas, probablemente ya hayas oído hablar de CI y CD y podrías estar pensando que esto es a lo que se refiere el Cambio Continuo. Cerca, pero no exactamente. Permíteme explicar.
CI
La Integración Continua (CI, por sus siglas en Inglés) es la disciplina que obliga a todos los desarrolladores [2] a integrar sus cambios con los cambios de los demás constantemente, y por constantemente, nos referimos a varias veces al día. Este es un cambio de comportamiento que es muy difícil para los equipos que fueron entrenados AD. No confundas esto con metodologías ágiles. Ágil divide los esfuerzos en partes más pequeñas (dos semanas), pero incluso usando Ágil, los desarrolladores pueden hacer su tarea asignada y trabajar en ella hasta que sientan que está lista. CI en DevOps dicta que los cambios deben integrarse varias veces al día, independientemente de su estado. Esto puede parecer una práctica peligrosa, y los desarrolladores de AD evitan las formas más radicales, pero, una vez que se acostumbran a la disciplina y con la ayuda de una canalización madura, CI tiene muchos beneficios. Probablemente deberíamos seguir con un artículo completo sobre las prácticas de CI.
CD
Entrega Continua o Despliegue Continuo (CD, por sus siglas en Inglés) es el principio que establece que cada vez que se crea exitosamente un artefacto (CI), también se lo entrega al cliente. Dependiendo de la naturaleza de la aplicación, esa entrega puede ser un nuevo archivo setup.exe subido a un sitio web (Entrega Continua) o una nueva versión de la aplicación instalada en un servidor en vivo (Despliegue Continuo). Bueno, esto suena como una práctica muy peligrosa, ¿no? Un desarrollador cambia algo de lógica en el código y, lo siguiente que sabes, se está ejecutando en el servidor de producción. Me recuerda a “Nunca verifico mi código, pero cuando lo hago, lo hago en producción”. Si estás empezando a entrar en pánico, no te sientas solo. Esa fue exactamente la reacción de mi equipo hace una década cuando propuse que empezáramos a hacer precisamente eso, pero si tomas los principios de DevOps como un todo y no los fragmentas a tu conveniencia, te darás cuenta de que no es una práctica peligrosa. Una vez más, probablemente también deberíamos seguir con un artículo completo sobre CD.
Entonces, ¿qué es el Cambio Continuo y en qué se diferencia de CI/CD?
Cambio Continuo es un cambio cultural y es un requisito para una transformación exitosa de DevOps, pero requiere que se adopten todos los principios de DevOps.
Esta es el área donde tendrá lugar el mayor cambio cultural, el área donde podría parecer que DevOps tiene el potencial de causar estragos en nuestros sistemas estables y, por lo tanto, las empresas intentan evitarlo a toda costa.
ITIL
ITIL y la gestión de cambios tradicional han hecho un buen trabajo protegiendo la estabilidad de nuestras aplicaciones durante décadas y han evolucionado para especificar roles, pautas y mejores prácticas para proteger nuestras aplicaciones.
Hay que decir que tanto ITIL como DevOps tienen el mismo objetivo en este sentido: proteger la estabilidad de nuestras aplicaciones. Simplemente lo hacen en lo que podrían parecer formas opuestas de lograrlo.
Se han escrito muchos artículos sobre cómo hasta el 80 % de los incidentes relacionados con IT (Tecnologías de Información, por sus siglas en Inglés) están relacionados con cambios, y aunque algunos en el campo de DevOps cuestionarán el número, es un número muy alto a pesar de todo.
ITIL protege las aplicaciones en ejecución al garantizar que, si un cambio es absolutamente necesario, se realice con una planificación cuidadosa, pruebas adecuadas, ensayos, estrategias de reversión, tiempo y consideraciones de recursos.
Probablemente ya te hayas dado cuenta que, aunque la gestión de cambios tradicional se crea para que el cambio se realice de manera segura, es percibida como “no toques”. Una vez más, el propósito es que los sistemas en ejecución no se cambien sin una planificación cuidadosa, pero el efecto es que debido a la percepción y la sobrecarga del cambio, el cambio es poco frecuente.
La estabilidad del sistema se protege en la realidad desincentivando el cambio.
DevOps
La filosofía de DevOps básicamente dice: creemos la cultura y las herramientas adecuadas para que el cambio sea tan frecuente que nos volvamos maestros del cambio, la interrupción se minimice según el tamaño del cambio y toda la preparación se verifique mediante la automatización.
En otras palabras, DevOps desafía la noción de que el cambio en sí mismo es el culpable de la interrupción del servicio al abordar tres áreas principales de cambio: frecuencia, tamaño y preparación.
Frecuencia – la primera sugerencia de optimización está relacionada con la frecuencia. En un entorno DevOps, para cuando la aplicación esté disponible a los usuarios, se ha desplegado cientos de veces en un entorno-casi-producción [3]. Cualquier tema relacionado con el despliegue (cambio) ha sido ejercitado y perfeccionado progresivamente. Muy relacionado con la frecuencia está el tiempo. Cuando el cambio se implementa inmediatamente en producción, está muy fresco en la mente de todos los involucrados, a diferencia de ver una falla hoy relacionada con un cambio en el código o la configuración que ocurrió hace varias semanas. La integración continua obliga a los desarrolladores, o mantenedores de aplicaciones, a fusionar sus cambios lo antes posible, lo que hace que la fusión sea más fluida y menos probable que se produzca un conflicto, y lo mismo ocurre con la entrega y la implementación.
Tamaño : DevOps también sostiene que la magnitud del impacto en los incidentes de IT es directamente proporcional al tamaño del cambio. Seamos honestos, por mucho que nos gustaría, no existe un código perfecto. Bajo esa suposición, es fácil inferir que la entrega de paquetes más pequeños causará menos interrupciones. Acumular una mayor cantidad de cambios 1. aumenta la complejidad (potencial de conflictos) y 2. el número de usuarios afectados, lo que provoca una interrupción original. Pero también agrava la interrupción de la reversión, ya que 3. todas las características (incluso aquellas que no estaban rotas) deben revertirse juntas, y el 4. MTTR (Tiempo Medio de Reparación, por sus siglas en Inglés) es mayor.
Preparación– Pero, DevOps sería irrelevante si no pudiera mejorar el aspecto de preparación del cambio. DevOps está 100% de acuerdo con la sabiduría común de que la gran mayoría de los incidentes de IT causados por cambios se deben a una preparación y verificación de preparación deficientes, pero en este sentido, un enfoque de DevOps puede verse como una aplicación de la lista de verificación que exige la gestión de cambios, pero a través de procesos automatizados. La automatización no solo puede cumplir con los requisitos de preparación, sino incluso llevarlos a un mayor nivel de cumplimiento porque todos los procesos y puntos de control son digitales por naturaleza. Los inspectores entrenados en DevOps (SDLC y procesos de negocios, redes, seguridad, etc.) pueden leer la canalización y decidir desde el principio si proporciona puertas suficientes y apropiadas para que la aplicación se implemente en producción. En un entorno completo de DevOps, la canalización es el runbook[4] y la Evaluación de Preparación combinadas.
Áreas que necesitarán atención
Herramientas
La mayoría de las empresas de AD han invertido mucho en herramientas para la gestión de cambios desde la perspectiva de ITIL, la mayoría de esas herramientas están evolucionando para incluir módulos DevOps. Pero, dado que DevOps puede significar diferentes cosas para diferentes personas o instituciones, las empresas deben considerar detenidamente las herramientas en coordinación con el DevOps CoE (Centro de Excelencia, por sus siglas en Inglés), o el equipo/personas que impulsan la transformación de DevOps para que las herramientas identificadas estén en línea con las iniciativas.
En algunos casos, podría ser una buena opción mantener tanto la gestión de cambios tradicional como el seguimiento de cambios de DevOps en la misma herramienta (suponiendo que la herramienta tenga un módulo u opción de DevOps) y, en otros casos, podría ser mejor mantenerlos totalmente separados. Las circunstancias especiales de cada empresa, la madurez del proceso de gestión del cambio y las herramientas existentes hacen que sea muy difícil dar una respuesta única a la cuestión de las herramientas.
Cultura
Es muy poco probable que todos en una organización AD estén capacitados y listos para comenzar a marcar la diferencia utilizando metodologías DevOps, y es probable que cause cierto temor al cambio (juego de palabras intencional). Pero, el cambio de cultura de DevOps no se trata principalmente de nuevas herramientas o tecnologías, sino de cambiar la forma en que hacemos las cosas, y la mayoría de las personas son capaces de hacer el cambio con la capacitación adecuada. En otras palabras, una transformación exitosa de DevOps debería cambiar la cultura y las prácticas de las personas sobre las cosas que hacen hoy, en lugar de traer nuevas herramientas o incluso nuevas personas.
Métrica
Si no puedes medirlo, no sucedió, o eso dicen. Comience por crear criterios para el éxito. ¿Cómo determinará si está teniendo éxito en la transición? Si la gestión de cambios tradicional no ha brindado estabilidad, podría ser fácil determinar una conversión exitosa, pero será más complicado si el sistema ya es estable, la determinación deberá pasar a otras áreas como MTTR, satisfacción del cliente, etc.
Conclusión
DevOps no es perfecto y, durante la etapa de adopción, habrá demoras y frustraciones. Sin embargo, empresas muy grandes y exitosas están utilizando sus principios para mantener algunas de las aplicaciones mas grandes y complejas del mundo funcionando estables y sin muchos problemas. Para emular su éxito, una empresa debe estar dispuesta a realizar este profundo y cultural cambio en la “gestión del cambio“.