DEVOPS: ¿Una mejora para ITIL?

Introducción DEVOPS

Comienzo a escribir un tema que esta muy de moda en las areas crecientes de T.I., y es DEVOPS. Tenemos hoy por hoy muchos marcos de referencia para todo y para todos los gustos, tales como SOA, ITIL, BPM, COBIT, IT4IT… Sin embargo hoy les quiero compartir que “DEVOPS” es mucho mas que una serie de procesos. Se acerca mas a una filosofía de trabajo.

DEVOPS, pretende unir la “relación rota” entre el el personal de operaciones de TI y el personal de desarrollo de software. Y esto porque los desarrolladores de software cada vez tienen que escribir mas y mas código y cada vez con mayor frecuencia. y por otra parte operaciones de T.I., pretende que todo esté en linea y operacional el 100% del tiempo en la medida de lo posible. DEVOPS prentender armonizar un poco esa relación.

¿Cómo?

La idea o mejor la filosofía de DEVOPS es justamente un trabajo colaborativo como vemos en la imagen de introducción, entre operaciones y construcción de software. Hay que incluir tambien a los administradores de sistema dentro de los procesos de desarrollo. Hay que asociar las herramientas de T.I., y que toda el área la pueda usar, visualizar y por supuesto aportar:

La explicación podría ser así para este ejemplo especifico y efectos estrictamente de visualización:

El usuario de negocio tiene una solicitud / incidente / requerimiento sobre el proceso de negocio al que pertence. Este se comunica con una mesa de ayuda proporcionado por el área de tecnología y este a su vez crea el registro en la herramienta de gestión de servicios de tecnología de información. Según el caso, este se asignará al grupo correspondiente (administradores, desarrolladores, otros).

La clave aquí es que se ejecutarán los procesos de incidentes, gestión de conocimiento u otro, según aplique, cualquier responsable de resolver el asunto de negocio. Y por su puesto se resolverán y comunicarán a la mesa de ayuda la resolución. Y la resolucion será comnucicada al usuario de negocio cerrando asi el ciclo.

Lo que se pretende mostrar aquí es que muchas compañías que cuentan con gestion de servicios como ITIL, es justamente la mejora. La mejora del toda el área de operaciones involucrando al área de desarrollo y construcción de software.


La Gestión de Cambio

Por ejemplo, tradicionalmente, el proceso de ITIL de gestión de cambios suele estar precedido de muchas autorizaciones, horarios, priorizaciones… Es decir depende en buena medida del factor humano. Esto hace que este proceso “per-sé” siempre sea un cuello de botella en el área de T.I. y también para el negocio.

DEVOPS, nos puede ayudar aquí a este proceso típicamente reactivo, es justamente hacer un entorno colaborativo entre el negocio y T.I. Su objetivo principal podría ser ya con la inclusión de DEVOPS de la pre-aprobación de los cambios con los interesados en las áreas de negocio y quitar la opción de “rechazado” para la aprobación del cambio. Sin embargo el dueño del proceso de negocio podría tener la posibilidad que hacer una solicitud al responsable del cambio de mayor información y este a su vez lo retroalimentará obligatoriamente. Recordemos que el proceso de cambio su objetivo es minimizar o mitigar la interrupcion de los servicios de T.I., para mejorar la calidad de la plataforma / sistema / software administrado para el servicio del negocio.

  • Desafío para el proceso de cambios:

Una compañía que integre DEVOPS a su operación de T.I., sera entregar continuamente servicio, dentro de los tiempos, plazos y con la calidad acordada. La idea es es que mayor parte de  los cambios de T.I., pasen por la categoria “standard” como lo propone ITIL.  Otro desafío podría ser, existe la posibilidad que haya una forma automatizada de aprobación de los cambios?


La Gestión de Incidentes

Hay que recordar que el principal objetivo de la gestión de incidentes segun ITIL, es retornar el servicio lo mas pronto posible. Para DEVOPS es similar: Retornar la funcionalidad total de la aplicación desarrollada y productiva a sus usuarios.

Normalmente, sucede que cuando DEVOPS no esta integrado al area de operaciones, la gestión de incidentes de administración de sistemas y plataforma no soporta los errores que vienen para el área de desarrollo. Entonces hay escalar al área de desarrollo y crear el incidente para esta area. Note como aquí se tienen 2 procesos de incidentes y actuan como silos independientes. y al actuar así, se esta iendo en contra del principal objetivo de este proceso.

El principal desafío para la gestión de incidentes es justamente como integrar de manera eficiente al grupo de desarrollo dentro de su herramienta y tener también una primera línea de atención de incidentes para desarollo. Así no parezca, esto crea camaradería y compañerismo entre las áreas (Entorno de Colaboración), permitiendo que en una parte los encargados del diseño y desarrollo de aplicaciones, entiendan el impacto de sus software desarrollado sobre la plataforma y crear mejor código y diseño; por otro lado los administradores de plataforma entenderán como la aplicación inpacta el funcionamiento y la operación del día a día del negocio. Dentro de la misma herramienta de gestion de servicios de T.I., incluir las herramientas de monitoreo / performace de aplicaciones / bugs, entre otras que podrían ayudar a los desarrolladores a ser mejores en su operación de desarrollo.


Gestión del Conocimiento

El principal objetivo de la gestion del conocimiento es mejorar la eficiencia de este, para reducir la necesidad de re-descubrir conocimiento ya adquirido.

Siempre ha sido un enorme desafío para las compañías basadas den servicios de tecnología y tambien para las que tienen un fuerte apoyo en tecnologias de información, dado que casi siempre se almacena en documentos que nadie lee y por consiguiente nadie actualiza. El no hacer esto, implica que cada vez que pase algo, se deba volver a construir la documentación… y así al paso de los años y el talento humano.

Es importante que la herramienta que se tenga para la gestión del conocimiento, califique y colabore a todo el talento humano de T.I., tenga un registro de acciones y documentación similar, tanto para el momento de crearla, como para el momento de consultarlas para resolver inquietudes, solicitudes, incidencias, entre otros. Entonces la idea es que este proceso esté automatizado. Sin importar la fase que se encuentre el desarrollo (planeación, diseño, desarrollo…), Se capture toda la actividad relevante para almacenar el conocimiento. De esta forma también se prueba el desarrollo realizado y a su vez la aplicación creada “certifica” la documentación creada.


Factores Claves de Exito

Crear y definir nuevos roles, equipos con conocimiento y habilidades específicas será clave para las areas de Tecnología de Información:


Finalmente un esquema de DEVOPS para incluir las fases típicas (planear, diseñar, codificar, probar, liberar, desplegar, operar, aprender), dentro de ITIL podría ser algo como esto: