Gestión de cambios y DevOps

La gestión del cambio —o la habilitación del cambio, si vive en el mundo de ITIL 4— y DevOps son dos prácticas que pueden ayudar a sus departamentos de TI a transformar la experiencia del cliente. Si se utilizan de manera efectiva, pueden ayudar a habilitar el cambio mientras protegen los servicios activos. Sin embargo, mucha gente piensa que son mutuamente excluyentes. Esto ha conllevado a que la gestión del cambio se haya convertido en el anti-DevOps. Al asumir que ambas prácticas son contradictorias, los departamentos de TI de todo el mundo están perdiendo una oportunidad. Este blog examinará cómo la gestión del cambio y las prácticas de DevOps pueden trabajar juntas para permitir la transformación. ¡Y sin comprometer la estabilidad y el rendimiento!

Lo básico

La gestión del cambio es la práctica que entrega el cambio de manera efectiva, eficiente y segura. También ha sufrido un cambio de imagen en los últimos años. Dependiendo de su versión de ITIL, también podría emplear términos como prácticas de gestión, control o habilitación del cambio. La última guía de "ITIL Towers" dice que se trata de una práctica recién creada: habilitación del cambio. Tiene como finalidad obtener resultados de negocio. Para este artículo, usaré los términos habilitación y gestión de forma intercambiable.

DevOps es una metodología de desarrollo de software que integra el desarrollo de TI y las operaciones de TI. Hace las cosas más eficientes al introducir la automatización y prácticas de trabajo mejores y más rápidas. Su objetivo es mejorar la prestación de servicios integrando y haciendo que las actividades llevadas a cabo por los equipos de desarrollo y soporte estén más estrechamente alineadas.

Cómo se combinan DevOps y la gestión del cambio

Al trabajar juntos, DevOps y la gestión del cambio pueden agilizar y estandarizar el proceso de cambio. Esto puede ir desde el diseño hasta el soporte de BAU. La gestión del cambio puede ayudar a los equipos de desarrollo a evaluar el riesgo, comprender el impacto empresarial y acordar ventanas de implementación si el despliegue puede interrumpir los servicios y las prácticas de DevOps —tales como pruebas, monitoreo, control de versiones y bucles de retroalimentación—, entre otros beneficios. Esto garantiza que los cambios se implementen de forma consistente, confiable y de una manera que ofrezca resultados a los clientes.

Al mezclar aspectos de la gestión del cambio y las mejores prácticas de DevOps, las organizaciones pueden combinar las mejores partes de la habilitación del cambio y la innovación. DevOps sugiere que los equipos de desarrollo y soporte operativo trabajen estrechamente juntos durante todo el ciclo de vida del desarrollo de software. En este, los equipos de operaciones de TI se involucran en la etapa de pruebas y ayudan a los equipos de desarrollo a crear documentación de soporte y prácticas de trabajo. A su vez, el equipo de desarrollo se involucra en el período de soporte durante la etapa inicial. Esto permite a la mesa de servicio y a los equipos de soporte lidiar con incidentes relacionados con el servicio nuevo o cambiado. Este enfoque conduce a un enfoque más cohesivo, implementaciones exitosas, y mejores niveles de servicio y experiencia del cliente.

Ponga las cosas en práctica

Ahora hemos establecido que la gestión de cambios y DevOps pueden habilitarse y apoyarse mutuamente. He aquí algunos consejos principales para mezclar los dos:

• Dele brillo a su CAB. La nueva guía de ITIL4 ha iniciado un cambio en los roles de aprobación. El reciente rol de la autoridad de cambio ha sustituido al modelo de comité asesor de cambios (CAB) usado en las versiones anteriores de ITIL. Uno de los puntos débiles más importantes que los técnicos, desarrolladores y gerentes de proyectos tenían con la gestión de cambios tradicional era la expectativa de que todo tenía que ser revisado y aprobado por el CAB. Reemplazar el CAB por una autoridad de cambio significa que los revisores por pares y la automatización pueden evaluar y permitir cambios.
• Otra opción podría ser reemplazar el CAB por completo con una sesión diaria para revisar la actividad de liberación. En lugar de una reunión tradicional del CAB, este enfoque pretende que los expertos técnicos revisen el cronograma de cambios del día, discutan cualquier problema y piensen rápidamente para que la persona que implementa el cambio pueda comprobar su enfoque y pedir apoyo adicional.
• Utilice modelos y cambios estándar para mejorar el flujo. Los modelos son un conjunto de pasos predefinidos. Si la naturaleza del cambio es conocida y entendida, debería poder ser aprobada a través de su herramienta por las partes interesadas apropiadas. Los cambios estándar llevan esto un paso más allá al contar con la autorización previa para la actividad de cambio de rutina de bajo riesgo.
• Use su biblioteca multimedia definitiva (DML) y la tienda de hardware (HS) para implementar versiones, de modo que sepa que los activos involucrados están bajo un control de versiones. Cumpla con las especificaciones requeridas, a salvo de amenazas externas y con la licencia adecuada.
• Asegúrese de que las convenciones de nomenclatura se acuerden de antemano. Esto facilita la implementación del código correcto en el entorno adecuado.
• Al crear y probar el código en entornos de preproducción, libere todo el código en ciclos para que cualquier dependencia pueda identificarse de forma oportuna.
• Introduzca el concepto de pruebas sin riesgo de fallo. Si algo va a fallar, es mejor averiguarlo cuanto antes. El concepto "sin riesgo de fallo" se aplica para probar diferentes formas de lograr el mejor resultado posible a través del cambio. Un aspecto clave de este concepto es el cambio cultural que trae consigo. Al crear espacios seguros, los colegas se sienten empoderados para experimentar y aprender. Aclare a su personal que una parte clave del proceso de prueba y mejora es que no hay errores tontos, siempre y cuando sean identificados, resueltos rápidamente y aprendidos
• Use entornos de pruebas o piloto para verificar los cambios más grandes. Si adoptamos las mejores prácticas, deberíamos poder confiar en nuestro código, prácticas de trabajo y personas. Aun así, no podemos planificar todo. Esto incluye peculiaridades del sistema operativo, defectos que solo ocurren en ciertos escenarios y cambios en la red. Al implementar primero en un grupo contenido, puede entender cómo se comporta su implementación en un entorno en vivo sin arriesgar el servicio para toda su base de usuarios.
• Utilice el monitoreo continuo para detectar problemas de cumplimiento y seguridad asociados con su entorno de producción. Emplee la automatización para activar eventos y alertas. De esta forma, los equipos de gestión de eventos e incidentes pueden tomar las medidas adecuadas si se detecta un problema.
• Use lotes para reducir el retraso. Disminuir el tamaño de los lotes y realizar cambios pequeños y frecuentes permite un flujo rápido hacia la producción, pero también un flujo rápido y constante de retroalimentación a lo largo del ciclo de vida de diseño y transición. Una forma de lograr esto es reducir el tamaño de sus paquetes de liberación y aumentar la frecuencia. Al agrupar el trabajo en trozos pequeños y alcanzables en lugar de implementaciones más grandes, puede facilitar la implementación de código y menguar el riesgo de defectos importantes. Esto permite la integración y entrega continuas.
• Incremente la velocidad hablando con sus equipos sobre la eliminación de restricciones y bloqueos. Como punto de partida, hable con sus técnicos, desarrolladores y gerentes de proyecto y dedíquese a encontrar las dificultades en el trabajo diario y solucionarlas.
• Cree una plantilla para que las notas de la versión tengan un aspecto coherente. Vincúlelas a su base de conocimientos para que se puedan almacenar de forma centralizada y se pueda acceder fácilmente a ellas.
• Hablando de bases de conocimiento, almacene el conocimiento de forma centralizada. De esta forma, todos sabrán a dónde ir para obtener instrucciones de instalación, guías de solución de problemas o datos de contacto de soporte.
• Actúen como un equipo. Todo el trabajo se revisa por pares antes de que pueda progresar. Se trabaja con los demás para crear un entorno de trabajo propicio, de modo que todos se sientan cómodos cuestionando las cosas cuando no parecen estar bien. Tenga equipos técnicos involucrados en el desarrollo y pruebas de código para que puedan entender y apoyar los nuevos servicios de manera efectiva. Haga que los colegas del equipo de desarrollo ayuden a la mesa de servicio y a los equipos de soporte operativo en la fase inicial de implementación y soporte para que cualquier solución de problemas pueda llevarse a cabo de forma rápida, eficiente y segura.
• Procure que sus conjuntos de herramientas hagan el trabajo pesado. Integre la cadena de herramientas de DevOps con su herramienta de gestión de servicios de TI (ITSM) para que las notificaciones se puedan enviar a las partes interesadas relevantes en los puntos clave del proceso. Pase a un enfoque basado en la extracción para aumentar la eficiencia y el flujo. Considere cómo la automatización puede incrementar la velocidad, por ejemplo, mediante scripts de liberación y haciendo que las implementaciones se empaqueten juntas en lugar de implementar manualmente archivos separados.
• Cree un repositorio de código central para que cada cambio en el código fuente se registre y se pueda revertir rápida y fácilmente de ser necesario.
• Comprenda y responda a todos los comentarios de las partes interesadas. Asegúrese de que los comentarios sean reconocidos, registrados y abordados.
• Gestione sus bucles de retroalimentación. Al reducir y ampliar los circuitos de retroalimentación, los problemas de calidad se pueden solucionar en su origen. Esto evita defectos y repeticiones.
• Haga tiempo para la mejora continua. Un enfoque es emplear el concepto de ganancias marginales. Según esta teoría, mejorar y optimizar su rendimiento de forma granular en múltiples áreas conducirá a mejoras más significativas y notables a nivel general. La idea es llevar a cabo una pequeña actividad de mejora o una fracción alcanzable, darle tiempo para integrarse en su organización y luego proseguir con su próximo ciclo de mejora. En palabras de Walt Disney, "sigue adelante" y las cosas mejorarán con el tiempo. Otra opción es utilizar el enfoque Kaizen de Lean Sigma, donde se programan regularmente breves ráfagas de actividad de mejora como parte del trabajo diario. Kaizen se trata de hacer de forma continua muchas mejoras pequeñas para que sus productos, servicios y formas de trabajo se refinen continuamente.

Beneficios de combinar la gestión de cambios y DevOps

• Los resultados de negocio se entregan de manera consistente, efectiva y segura.
• Cambiar las reuniones del CAB liberará tiempo y recursos para centrarse en cambios más complejos. Uno de mis casos de uso favoritos gira en torno al rol cambiante del CAB. Todavía hay un lugar para ello. Abogo por cambiar su alcance para que sea una reunión muy poco frecuente que se centre en cambios complejos y de alto riesgo que podrían causar una interrupción del servicio.
• Seguir un modelo de lanzamiento continuo significa que el software se implementa de una manera que se puede adaptar a las necesidades de la organización y sus partes interesadas.
• Mejor comunicación entre los equipos de TI y de negocios. Al combinar la gestión de cambios y DevOps, se asegura de que las implementaciones se gestionen de manera efectiva. Simultáneamente, se basan en una cultura de comunicación, colaboración y confianza. Todos serán escuchados. Tener perspectivas adicionales puede generar nuevas ideas y mejorar los métodos de trabajo.
• Reducción del riesgo y mayor capacidad de respuesta. Si hay un problema con el código, el cambio no está progresando o algo no está del todo bien. Ya que todos pueden verlo, es fácil tomar la acción correcta.
• Aumentar el uso de la automatización incrementa la velocidad y reduce el potencial de errores humanos o de proceso.
• La cola de cambios está más controlada. Las transferencias son más eficientes y los resultados de negocio se obtienen más rápido. En resumen, DevOps ayuda a que su proceso de gestión de cambios deje de ser una restricción percibida para convertirse en un habilitador clave para el negocio.
• Una cultura de mejora continua. TI se convierte en una plataforma para la mejora continua y la innovación porque se fomenta la experimentación. Se motiva a las personas a probar cosas nuevas y todos trabajan como un solo equipo.

Reflexiones finales

La gestión/habilitación del cambio y DevOps son mucho más eficaces cuando se emplean juntos. Al combinar aspectos del cambio en las prácticas de DevOps, se aumenta el apoyo para la gobernanza, GRC y escalamientos. Al incorporar DevOps en su práctica de cambio, sus flujos de trabajo se vuelven más eficientes. La automatización aumentará el flujo y habrá más apoyo para la colaboración y el trabajo en equipo. ¿Cuál es el beneficio? Resultados más rápidos, ligeros, seguros y una #CX mejorada. ¡Me apunto!