The Visible OPS – Aplicando ITIL – Fase I

Desde hace unos meses estoy trabajando en un área diferente a lo que había venido haciendo hasta el momento, participando en la definición y gestión del soporte de servicios de varias aplicaciones, y tomando como referencia la metodología ITIL.

Uno de los libros que estoy utilizando como referencia de qué cosas hay que hacer y cómo hay que hacerlas, es “The Visible OPS Handbook”. Este libro presenta, pese a su reducido tamaño, una interesante guía de las principales tareas y objetivos que hay que llevar a cabo para implantar satisfactoriamente una metodología de gestión de soporte, particularizándolo en ITIL, y en la parte de gestión de cambios y el control de la evolución de los sistemas de información.

Como desarrolladores muchas veces pensamos que lo importante es desarrollar la aplicación y que una vez hecho, ya está todo resuelto, sin embargo esto no tan sencillo. El objetivo cualquier aplicación es ser utilizada, para lo cual es necesario llevar un correcto control de los cambios que se realizan sobre la aplicación, la infraestructura sobre la que sustenta, o sobre cualquier otro componente directa o indirectamente relacionado con el sistema y por el cual pudiera verse afectado. Esto que es relativamente sencillo con aplicaciones aisladas o pequeñas, se vuelve en una auténtica pesadilla cuando el número de sistemas y su complejidad crecen. Seguramente a muchos sonarán situaciones críticas en las que todo un sistema se cae misteriosamente, y al final se debe a un cambio “insignificante” subido a producción por alguien que pensaba que no podía pasar nada.

Para tratar de paliar estas situaciones y muchas más relacionadas, el libro propone una serie de características contempladas en algunas de las empresas con mejores procesos, fruto de una extensiva revisión de los autores durante varios años de consultoría.

• Aumentar el MTBF (mean time between failures)
• Reducir el MTTR (mean time to resolve)
• 80% errores relacionados con los cambios
• 80% del tiempo de resolución orientado a buscar qué ha fallado
• Reducir el tiempo de trabajo no planificado (apagafuegos) a entorno al 5%

Se divide el libro en cuatro pasos o fases, en las cuales se trata de ir consiguiendo poco a poco y de una forma auditable, todos estos objetivos. A continuación explico de forma resumida la Fase 1, que me ha parecido bastante significativa.

Fase 1: Estabilizar al paciente

El objetivo de esta primera fase es reducir el trabajo no planificado a menos de un 25%, reduciendo el número de problemas auto inflingidos y modificando la forma en que se resuelven los problemas.

Para ello la primera tarea es controlar y protocolizar la manera en la que se realizan los cambios, para lo cual los autores proponen una serie de medidas.

• Reducir o eliminar accesos, con el fin de tener controlado el número de personas con autorizaciones para realizar cambios.
• Documentar la nueva política de cambios, centrada en un “no cambia nada en el sistema que no haya sido autorizado por mi”.
• Notificar a los participantes la nueva política, para que todo el mundo sea consciente de ella.
• Crear ventanas de cambios, para que los cambios se realicen siempre en unas determinadas franjas horarias .
• Insistir en el proceso a todo el equipo, indicando que este es un trabajo en equipo y que las modificaciones realizadas sin autorización afectan no solo al sistema, sino al trabajo e imagen de todo el equipo.

Electrificar la alambrada

Con los pasos anteriores se ha creado un proceso sencillo de aplicación de cambios, sin embargo, es rara la vez que estas indicaciones se llevan a rajatabla. Siempre hay situaciones en las que algunos usuarios se saltan las autorizaciones previas, o las ventanas de cambio, y suben modificaciones por su propia cuenta, muchas veces por pensar que son cambios insignificantes.

Para prevenir estas situaciones es necesario ahondar más en la cultura de gestión de cambios, para lo cual es una buena opción crear una serie de medidas que permitan detectar y verificar que los cambios se están realizando según el proceso expuesto, con las autorizaciones pertinentes y en las ventanas horarias establecidas.

Se deben revisar todos los cambios ocurridos en el sistema, tanto aplicativos como dispositivos hardware como servidores, bases de datos, dispositivos de red, etc. Todo cambio identificado debe corresponderse a un trabajo autorizado y en caso contrario, es necesario investigarlo.

• ¿Quién hizo el cambio?
• ¿Qué se cambió?
• ¿Debería echarse para atrás? ¿Cómo?
• ¿Cómo prevenimos que no vuelva a suceder?

Para ello es conveniente la utilización de herramientas automáticas que chequeen la plataforma diariamente, o tras cada ventana de modificación, con el fin de encontrar elementos modificados y compararlos con la lista de trabajos autorizados.

Con el fin de completar el proceso de gestión del cambio, es necesario disponer también de alguna forma de recoger las solicitudes de cambio (RFC) y gestionarlas a través de su autorización, implementación y verificación. Existen diversas herramientas que permiten automatizar y llevar un control del ciclo de vida de cada una de estas RFC. Por último es necesario crear también un comité de cambio, que debería reunirse de forma periódica (semanalmente, cada dos semanas, etc.), con el fin de por un lado revisar los cambios realizados (planificados y no), y por otro, revisar y planificar las solicitudes pendientes.