The Visible OPS – Aplicando ITIL – Fases II, III y IV

Continuando con el post que publiqué la semana pasada sobre la primera parte de este libro, hoy voy a mostrar un pequeño resumen del resto del libro, explicando las fases II, III y IV que se proponen para implantar ITIL. Estas fases, al igual que la fase I, ofrecen un buen punto de partida para abordar los problemas existentes en la mayoría de sistemas de información, aunque es conveniente también mirar en profundidad otras cuestiones, como la gestión de incidencias o problemas, que no se abordan en este libro.

Fase II – Inventariar

Una vez que en la fase I se ha estabilizado la situación mediante la adopción de un proceso de gestión de cambios y una serie de controles relacionados, esta fase tiene como objetivo principal crear un inventario del equipamiento existente en los sistemas de producción. Hay que inventariar cada equipo e identificar qué servicios ejecuta, qué otros equipos o servicios dependen de él, quién es el responsable de su gestión, cómo de frágil es, cuánto suele fallar, etc.

Dada la importancia de este inventario, y lo complejo que suele ser en muchas ocasiones determinar este tipo de información, es conveniente que este trabajo lo realice personal experimentado y no personal novel.

Entre otras cuestiones es necesario identificar la siguiente información para cada artefacto:

• ¿Cuál es su objetivo?
• ¿Qué plataforma hardware es? ¿Qué sistema operativo?
• ¿Qué aplicaciones hay instaladas? ¿Qué servicios ofrece?
• ¿Quién es su responsable? ¿Quién está autorizado para hacer cambios?
• ¿Qué sucedería si este equipo se degrada? ¿Y si falla completamente?
• ¿Cuál es el porcentaje de cambios exitosos? ¿Es un dispositivo frágil? ¿Se puede construir uno nuevo si falla?
• ¿Cuáles son sus dependencias? ¿Qué infraestructuras dependen de él?
• ¿Cuál es su nombre? ¿Es adecuado para sus funciones? ¿Dónde está ubicado? ¿Cómo se accede a él (remoto…)?
• ¿Cómo y cuándo se hacen copias de seguridad? ¿Tiene tolerancia a fallos? ¿Existen repuestos hardware disponibles?
• ¿Se monitoriza de alguna forma su disponibilidad o la de los servicios ofrecidos? ¿Se monitorizan los cambios?

Como fruto de este proceso de inventariado se obtendrá una Configuration Management DataBase (CMDB), y un conjunto de Configuration Ítems (CI), correspondientes a los diferentes equipamientos existentes.

Gracias a este inventario habremos adquirido una imagen clara de los componentes de nuestra infraestructura, sus funciones, sus dependencias, y su fragilidad. Este conocimiento habrá pasado de estar repartido por diferentes personas, o posiblemente perdido incluso, a estar perfectamente inventariado y a disposición de los diferentes participantes, como gestión de cambios, versiones, monitorizaciones, etc.

Es conveniente, una vez hecho el inventario, identificar los artefactos más frágiles de la infraestructura, es decir, aquellos con muchos fallos en los cambios y MTTR altos. Esto nos ayudará en la siguiente fase a determinar sobre qué sistemas hay que trabajar de forma prioritaria.

Fase III – Biblioteca de Software y Hardware

Esta fase está relacionada con la gestión de versiones, tal como se contempla en ITIL. El objetivo es por un lado construir una biblioteca de configuraciones con los elementos existentes en la infraestructura, y por otro, crear una separación entre las funciones y responsabilidades de las personas encargadas del desarrollo y las encargadas de la gestión de operaciones.

A partir de los elementos más frágiles encontrados en la fase anterior, el primer paso es estudiarlos y definir el procedimiento necesario para su construcción, partiendo de una configuración hardware limpia, y enumerando todos los pasos y aplicaciones que hay que instalar, y configuraciones que hay que realizar, para poder disponer del equipo en producción. El objetivo de esto no es otro que tratar de reducir el MTTR de estos sistemas frágiles, no tratando de arreglar fallos que podrían ser complicados de determinar, sino directamente reconstruir la situación anterior, tal como se indique en el procedimiento.

Esto permite aplicar un cambio en la forma de trabajo, pasando de una forma reactiva, provocada por la aparición de fallos, y en la que hay que trabajar averiguando el motivo del fallo y reparándolo, lo que habitualmente se denomina “apagafuegos”, a una forma de trabajo proactiva, en la que se documentan los pasos necesarios para reconstruir los diferentes componentes de la infraestructura, y cuando ocurren fallos, en función de su tipo, simplemente se sustituye o reconstruye el equipo o servicio. Es importante tener en cuenta como en esta aproximación, el personal experto de la empresa, que habitualmente está luchando en múltiples incendios de forma continua, pasa a tener un role diferente, en el que se encarga de la definición de los procedimientos de reconstrucción, pudiendo encargarse la aplicación de estos procedimientos a personal novel, obteniendo así un mayor aprovechamiento del conocimiento de los expertos y liberándoles de un trabajo que puede no ser necesario.

Como fruto de este trabajo de creación de configuraciones de construcción, se obtienen dos bibliotecas diferentes: la Definitive Software Library (DSL) y el Definitive Hardware Store (DHS). Los siguientes pasos de esta fase se centran en definir como se mantienen estas bibliotecas, y en la creación de un proceso de aceptación, que incluye la existencia de entornos sincronizados de producción y preproducción, y delimita las funciones y responsabilidades de los grupos de desarrollo y operaciones.

Inicialmente en la DSL se incluirían todas las aplicaciones existentes, bajo un paraguas de aplicaciones bajo “amnistía”, por un periodo de tiempo determinado. Una vez hecho esto habría que ir creando los paquetes de construcción de cada una y ubicarlos en la DSL para que estén accesibles, tratando de estandarizar configuraciones que pudieran ser similares y que podrían agruparse en una común, reduciendo de esta forma la complejidad de la infraestructura.

A partir de la creación de la DSL, la incorporación de nuevos elementos a ella, deberá venir precedida de una aceptación. Para ello se estudiará si existen ya soluciones similares, si es posible prestar el soporte necesario, y se construirá un prototipo si es necesario, en un entorno de pruebas aislado.

Con el fin de poder probar los cambios que se vayan a incorporar en las aplicaciones, es necesario disponer de entornos de preproducción equivalentes y sincronizados con los existentes en producción, siendo posible e incluso conveniente, la utilización de entornos de máquinas virtuales para ello. Para que estos entornos sean útiles, es necesario definir un procedimiento por el cual los cambios proporcionados por los equipos de desarrollo, se incorporen en preproducción, se prueben, y una vez validados, se desplieguen en producción. Para ello los equipos de desarrollo deberán crear los paquetes de instalación y las instrucciones necesarias, para que el personal de operaciones pueda realizar las instalaciones, primero en preproducción, y tras su validación, en producción. Además es conveniente garantizar que únicamente los equipos de operaciones puedan tener acceso a modificar ambos entornos, y que junto a cada cambio, se proporcione un procedimiento de back-out asociado, que debería ser probado también.

Fase IV – Mejora Continua

Una vez realizadas las anteriores fases, se ha estabilizado la situación y se han liberado los recursos suficientes como para poder realizar un trabajo más proactivo, y poder atajar los problemas de raíz, antes incluso de que surjan. En esta fase se proponen un conjunto de métricas que deberían utilizarse para medir el cumplimiento de los compromisos adquiridos en cada una de ellas, así como para localizar posibles puntos de mejora, o fuentes de problemas.

Las métricas principales son:

• Métricas de versiones: ¿cuánto tiempo cuesta construir un sistema conocido a partir de un hardware en limpio? ¿Cuántas veces es necesario modificar un paquete de instalación antes de su aceptación para producción? ¿Cuál es el tiempo de vida de las versiones en producción? ¿Cuál es porcentaje de sistemas que se corresponden con configuraciones predefinidas?…
• Métricas de controles: número de cambios autorizados/no autorizados por semana, % de éxito en los cambios, ¿cuántos cambios han producido caídas de servicio? ¿número de cambios de emergencia? ¿número de cambios realizados fuera de la gestión de cambios? ¿cuántos cambios “business as usual”, correspondientes a peticiones de servicio por ejemplo, se han realizado?…
• Métricas de resolución: Mean Time To Repair (MTTR), Mean Time Between Failure (MTBF)