Version Management (Proceso)

Las principales actividades de la Gestión de Versiones se resumen en:

  • Establecer una política de planificación para la implementación de nuevas versiones.
  • Desarrollar o adquirir de terceros las nuevas versiones.
  • Poner a prueba las nuevas versiones en un entorno que simule lo mejor posible el entorno de producción.
  • Validar las nuevas versiones.
  • Implementar las nuevas versiones en el entorno de producción.
  • Llevar a cabo los planes de back-out o retirada de la nueva versión si esto fuera necesario.
  • Actualizar la DSL, el DHS y la CMDB.
  • Comunicar y formar a los clientes y usuarios sobre las funcionalidades de la nueva versión.

Planificación

Es crucial establecer un marco general para el lanzamiento de nuevas versiones que fije una metodología de trabajo. Esto es especialmente importante para los casos de versiones menores y de emergencia pues en el caso de lanzamientos de gran envergadura se deben desarrollar planes específicos que tomen en cuenta las peculiaridades de cada caso.

A la hora de planificar correctamente el lanzamiento de una nueva versión se deben de tomar en cuenta los siguientes factores:

  • Cómo puede afectar la nueva versión a otras áreas del entramado TI.
  • Qué CIs se verán directa o indirectamente implicados durante y tras el lanzamiento de la nueva versión.
  • Cómo ha de construirse el entorno de pruebas para que éste sea fiel reflejo del entorno de producción.
  • Qué planes de back-out son necesarios.
  • Cómo y cuándo se deben implementar los planes de back-out para minimizar el posible impacto negativo sobre el servicio y la integridad del sistema TI.
  • Cuáles son los recursos humanos y técnicos necesarios para llevar a cabo la implementación de la nueva versión con garantías de éxito.
  • Quiénes serán los responsables directos en las diferentes etapas del proceso
  • Qué planes de comunicación y/o formación deben desarrollarse para que los usuarios estén puntualmente informados y puedan percibir la nueva versión como una mejora.
  • Qué tipo de despliegue es el más adecuado: completo, delta, sincronizado en todas los emplazamientos, gradual, …
  • Cuál es la vida media útil esperada de la nueva versión.
  • Qué impacto puede tener el proceso de lanzamiento de la nueva versión en la calidad del servicio.
  • Si es posible establecer métricas precisas que determinen el grado de éxito del lanzamiento de la nueva versión.

Desarrollo

La Gestión de Versiones es la encargada del diseño y construcción de las nuevas versiones siguiendo las pautas marcadas en las RFCs correspondientes.

A veces el desarrollo se realizara “en la casa” y muchas otras requerirá la participación de proveedores externos. En este segundo caso, la tarea de la Gestión de Versiones será la de asegurar que el paquete o paquetes de software o hardware ofrecidos cumple las especificaciones detalladas en la RFC. Asimismo, la Gestión de Versiones será la responsable de todo el proceso de configuración necesario.

El desarrollo debe incluir, si esto fuera necesario o simplemente recomendable, todos los scripts de instalación necesarios para el despliegue de la versión. Estos scripts deberán tener en cuenta aspectos tales como:

  • Back-up automático de datos.
  • Actualizaciones necesarias de las Bases de Datos asociadas.
  • Instalación de las nuevas versiones en diferentes sistemas o emplazamientos geográficos.
  • Creación de logs asociados al proceso de instalación.

Parte integrante del desarrollo lo componen los planes de back-out asociados. Estos tendrán que tomar en cuenta la disponibilidad acordada con los clientes en los SLAs correspondientes.


Validación

Un bien planificado protocolo de tests es absolutamente indispensable para lanzar al entorno de producción una nueva versión con razonables garantías de éxito.

Las pruebas no deben limitarse a una validación de carácter técnico (ausencia de errores) sino que también deben realizarse pruebas funcionales con usuarios reales para asegurarse de que la versión cumple los requisitos establecidos y es razonablemente usable (siempre existe una inevitable resistencia al cambio en los usuarios que debe ser tenida en consideración).

Es importante que las pruebas incluyan los planes de back-out para asegurarnos que se podrá volver a la última versión estable de una forma rápida, ordenada y sin perdidas de valiosa información.

Las principales actividades realizadas en el proceso de prueba deben incluir:

  • Pruebas del correcto funcionamiento de la versión en un entorno realista.
  • Pruebas de los procedimientos automáticos o manuales de instalación.
  • Listas de “bugs” o errores detectados, si se diera el caso.
  • Pruebas de los planes de back-out.
  • Documentación para usuarios y personal de servicio.

La Gestión de Cambios será la encargada de dar la validación final a la versión para que se proceda a su instalación. Si la versión no fuera aceptada se devolverá a la Gestión de Cambios para su reevaluación.


Implementación

Llego el momento de la verdad: la distribución de la nueva versión, también conocida como roll out.

El roll out puede ser de varios tipos:

  • Completo y sincronizado: se realiza de manera integral y simultánea en todos los emplazamientos.
  • Fragmentado: ya sea bien espacial o temporalmente. Por ejemplo, introduciendo la nueva versión por grupos de trabajo o incrementando progresivamente la funcionalidad ofrecida.

El procedimiento de rollout debe ser cuidadosamente documentado para que todas las partes conozcan sus tareas y responsabilidades específicas. En particular los usuarios finales deben estar puntualmente informados del calendario de lanzamiento y de cómo este puede afectar a sus actividades diarias.

Es imprescindible determinar claramente:

  • Los CIs que deben borrarse e instalarse y en que orden debe realizarse este proceso.
  • Cuándo debe realizarse este proceso para diferentes grupos de trabajo y/o localizaciones geográficas.
  • Que métricas determinan la puesta en marcha de los planes de back-out y si estos deben ser completos o parciales.

Tras la distribución la Gestión de Versiones debe asegurarse de que:

  • Se incluya una copia de la versión en la DSL.
  • El DHS incorpore repuestos funcionales de los nuevos CIs.
  • La CMDB esté correctamente actualizada.
  • Los usuarios están debidamente informados de las nuevas funcionalidades y han recibido la formación necesaria para poder sacar el adecuado provecho de las mismas.

Tras la implementación, la Gestión de Versiones debe ser puntualmente informada por el Service Desk de los comentarios, quejas, incidentes, etc. que la nueva versión haya podido suscitar. Toda esta información deberá ser analizada para asegurar que las próximas versiones incorporen las sugerencias recibidas y que se tomen las medidas correctivas necesarias para minimizar el impacto negativo que puedan tener futuros cambios.


Comunicación y Formación

Es frecuente, y a su vez un grave error, que cuando se aborden cuestiones de carácter técnico se obvie el factor humano.

Salvo contadas excepciones, es necesaria la interacción usuario-aplicación y ésta suele representar el eslabón más débil de la cadena.

Es inútil disponer de un sofisticado servicio TI si los usuarios , debido a una incompleta (in)formación, no se encuentran en disposición de aprovechar sus ventajas.

La (in)formación debe estructurarse en distintos niveles:

  • Los usuarios deben conocer el próximo lanzamiento de una nueva versión y conocer con anterioridad la nueva funcionalidad planificada o los errores que se pretenden resolver para participar, a su discreción, en el proceso.
  • Siempre que sea posible las pruebas de carácter funcional deben ser realizadas por un selecto grupo de usuarios finales. Durante este proceso de prueba se documentarán y analizarán:
    • La experiencia subjetiva de usuario.
    • Los comentarios y sugerencias sobre usabilidad y funcionalidad. o Las dudas que hayan surgido durante el uso de la nueva versión.
    • La claridad de la documentación que se pondrá a disposición del usuario final.
  • Cuando se considere oportuno se impartirán cursos presenciales o remotos mediante módulos de e-learning sobre el funcionamiento de la nueva versión.
  • Se desarrollará una página de FAQs donde los usuarios puedan aclarar las dudas más habituales y puedan solicitar ayuda o soporte técnico en el uso de la nueva versión.

Control del Proceso

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Versiones.

Para que estos informes ofrezcan una información precisa y de sencilla evaluación es necesario elaborar métricas de referencia que cubran aspectos tales como:

  • Número de lanzamientos de nuevas versiones.
  • Número de back-outs y razones de los mismos.
  • Incidencias asociadas a nuevas versiones.
  • Cumplimientos de los plazos previstos para cada despliegue.
  • Asignación de recursos en cada caso.
  • Corrección y alcance de la CMDB y la DHS.
  • Existencia de versiones ilegales de software.
  • Adecuado registro de las nuevas versiones en la CMDB.
  • Incidencias provocadas por uso incorrecto (formación inadecuada) de la nueva versión por parte de los usuarios.
  • Disponibilidad del servicio durante y tras el proceso de lanzamiento de la nueva versión.

Configuration Magament (Proceso)

Las principales actividades de la Gestión de Configuraciones son:

Planificación: determinar los objetivos y estrategias de la Gestión de Configuraciones.

Clasificación y Registro: los CIs deben ser registrados conforme al alcance, nivel de profundidad y nomenclatura predefinidos.

Monitorización y Control: monitorizar la CMDB para asegurar que todos los componentes autorizados estén correctamente registrados y se conoce su estado actual.

Realización de auditorías: para asegurar que la información registrada en la CMDB coincide con la configuración real de la estructura TI de la organización.

Elaboración de informes: para evaluar el rendimiento de la Gestión de Configuraciones y aportar información de vital importancia a otras áreas de la infraestructura TI.


Planificación

La Gestión de Configuraciones es uno de los pilares de la metodología ITIL por sus interrelaciones e interdependencias con el resto de procesos. Por ello su implantación es particularmente compleja.

Aunque ofrecer un detallado plan de implementación de la Gestión de Configuraciones va mucho más allá de lo que aquí podemos ofrecer, creemos conveniente, al menos, destacar algunos puntos que consideramos esenciales:

  • Designar un responsable: una descentralización excesiva puede generar descoordinación y llevar al traste todo el proceso.
  • Invertir en alguna herramienta de software adecuada a las actividades requeridas: una organización manual es impracticable.
  • Realizar un cuidadoso análisis de los recursos ya existentes: gestión de stocks, activos, etc.
  • Establecer claramente:
    • El alcance y objetivos.
    • El nivel de detalle
    • El proceso de implementación: orden de importancia, cronograma, …
  • Coordinar el proceso estrechamente con la Gestión de Cambios, Gestión de Versiones y los Departamentos de Compras y Suministros

Una falta de planificación conducirá con total certeza a una Gestión de Configuraciones defectuosa con las graves consecuencias que esto supondrá para el resto de los procesos.


Clasificación y Registro

La principal tarea de la Gestión de Configuraciones es mantener la CMDB. Es imprescindible, para llevar esta labor con éxito, predeterminar la estructura del CMDB de manera que:

  • Los objetivos sean realistas: una excesiva profundidad o detalle puede sobrecargar de trabajo a la organización y resultar, a la larga, en una dejación de responsabilidades.
  • La información sea suficiente: debe existir, al menos un registro de todos los sistemas críticos para la infraestructura TI.
Alcance

En primer lugar habremos de determinar que sistemas y componentes TI van a ser incluidos en la CMDB:

  • Es esencial incluir al menos todos los sistemas de hardware y software implicados en los servicios críticos.
  • Se debe determinar que CIs deben incluirse dependiendo del estado de su ciclo de vida. Por ejemplo, pueden obviarse componentes que ya han sido retirados.
  • Es recomendable incorporar, al menos, la documentación asociada a proyectos, SLAs y licencias.

En general cualquier servicio o proceso es susceptible de ser incluido en la CMDB pero unos objetivos en exceso ambiciosos pueden resultar contraproducentes.

Nivel de detalle y Profundidad

Una vez determinado el alcance de la CMDB es imprescindible establecer el nivel de detalle y profundidad deseados:

  • Determinar los atributos que describen a un determinado CI.
  • Tipo de relaciones lógicas y físicas registradas entre los diferentes CIs.
  • Subcomponentes registrados independientemente.

Por ejemplo, si se decide incluir los equipos de sobremesa en la CMDB:

  • Atributos: Fecha de compra, fabricante, procesador, sistema operativo, propietario, estado, coste, etc.
  • Relaciones: conexión en red, impresoras conectadas, etc.
  • Profundidad: tarjetas de red, discos duros, tarjetas gráficas, etc.
Nomenclatura

Aunque este sea un aspecto muy técnico es de vital importancia predefinir los códigos de clasificación de los CIs para que el sistema sea funcional:

  • La identificación debe ser, por supuesto, única y si es posible interpretable por los usuarios.
  • Este código debe ser utilizado en todas las comunicaciones referentes a cada CI y si es posible debe ir físicamente unido al mismo (mediante una etiqueta de difícil eliminación).
  • Los códigos no deben ser sólo utilizados para componentes de hardware sino también para documentación y software.

Es imprescindible conocer el estado de cada componente en todo momento de su ciclo de vida. Esta información puede ser de gran utilidad, por ejemplo, a la Gestión de Disponibilidad para conocer que CIs han sido responsables de la degradación de la calidad del servicio.

Puede ser de gran utilidad para el análisis el uso de herramientas de software que ofrezcan representaciones visuales del ciclo de vida de las componentes, organizados por diferentes filtros (tipo, fabricante, responsable, costes, etc.).


Control

La Gestión de Configuraciones debe estar puntualmente informada de todos los cambios y adquisiciones de componentes para mantener actualizada la CMDB.

El registro de todas las componentes de hardware debe iniciarse desde la aprobación de su compra y debe mantenerse actualizado su estado en todo momento de su ciclo de vida. Asimismo, debe estar correctamente registrado todo el software “en producción”.

Las tareas de control deben centrarse en:

  • Asegurar que todos los componentes están registrados en la CMDB.
  • Monitorizar el estado de todos los componentes.
  • Actualizar las interrelaciones entre los CIs.
  • Informar sobre el estado de las licencias.

Auditorías

El objetivo de las auditorías es asegurar que la información registrada en la CMDB coincide con la configuración real de la estructura TI de la organización.

Existen herramientas que permiten una gestión remota, centralizada y automática de los elementos de configuración de hardware y software. La información recopilada puede ser utilizada para actualizar la CMDB.

Si el alcance de la CMDB incluye aspectos como documentación, SLAs, personal, etc. es necesario complementar estos datos con auditorías manuales. Éstas deben realizarse con cierta frecuencia y al menos:

  • Tras la implementación de una nueva CMDB.
  • Antes y después de cambios mayores en la infraestructura.
  • Si existen fundadas sospechas de que la información almacenada en la CMDB es incorrecta o incompleta.

Las auditorías deben dedicar especial atención a aspectos tales como:

  • Uso correcto de la nomenclatura en los registros de los CIs.
  • Comunicación con la Gestión de Cambios: información sobre RFCs , cambios realizados, …
  • Estado de los CIs actualizado.
  • Cumplimiento de los niveles de alcance y detalle predeterminados.
  • Adecuación de la estructura de la CMDB con la de la estructura TI real.

Configuration Management (Definición)

A lo largo de este capítulo hemos utilizado y utilizaremos con profusión conceptos tales como elementos de configuración (CI) y base de datos de gestión de configuraciones (CMDB) es por lo tanto conveniente que nos detengamos en dar una definición precisa de ambos.

Elementos de configuración: todos, tanto los componentes de los servicios TI como los servicios que éstos nos ofrecen, constituyen diferentes elementos de configuración. A modo de ejemplo citaremos:

  • Dispositivos de hardware como PCs, impresoras, routers, monitores, etc. así como sus componentes: tarjetas de red, teclados, lectores de CDs, …
  • Software: sistemas operativos, aplicaciones, protocolos de red, …
  • Documentación: manuales, acuerdos de niveles de servicio, …

En resumen, todos los componentes que han de ser gestionados por la organización TI.

Base de Datos de la Gestión de Configuraciones: esta base de datos debe incluir:

  • Información detallada de cada elemento de configuración.
  • Interrelaciones entre los diferentes elemento de configuración, como, por ejemplo, relaciones “padre-hijo” o interdependencias tanto lógicas como físicas

La CMDB no se limita a una mera enumeración del stock de piezas sino que nos brinda una imagen global de la infraestructura TI de la organización

Problem Management (Control–Proceso)

El objetivo de la Gestión de Problemas no es otro que el de mejorar el funcionamiento de la infraestructura TI y para evaluar su eficacia es imprescindible realizar un continuo seguimiento de los procesos relacionados y evaluar su rendimiento.

En particular una buena gestión de problemas debe traducirse en una:

  • Disminución del número de incidentes y una más rápida resolución de los mismos.
  • Mayor eficacia en la resolución de problemas.
  • Gestión proactiva que permita identificar problemas potenciales antes de que estos se manifiesten o provoquen una seria degradación de la calidad del servicio.

La correcta elaboración de informes permite evaluar el rendimiento de la Gestión de Problemas y aporta información de vital importancia a otras áreas de la infraestructura TI.

Entre la documentación generada cabría destacar:

  • Informes de Rendimiento de la Gestión de Problemas: donde se detalle el número de errores resueltos, la eficacia de las soluciones propuestas, los tiempos de respuesta y el impacto en la Gestión de Incidentes.
  • Informes de Gestión Proactiva: donde se especifiquen las acciones ejercidas para la prevención de nuevos problemas y los resultados de los análisis realizados sobre la adecuación de las estructuras TI a las necesidades de la empresa.
  • Informes de Calidad de Productos y Servicios: donde se evalúe el impacto en la calidad del servicio de los productos y servicios contratados y que eventualmente puedan permitir adoptar decisiones informadas sobre cambios de proveedores, etc.

Una eficaz Gestión de Problemas también requiere determinar claramente quienes son los responsables de cada proceso. Sin embargo, en pequeñas organizaciones es recomendable no segmentar en exceso las responsabilidades para evitar los costes asociados: sería poco eficaz y contraproducente asignar unos recursos humanos desproporcionados al proceso de identificación y solución de problemas.

Problem Management (Control – Errores)

Una vez que el Control de Problemas ha determinado las causas de un problema es responsabilidad del Control de Errores el registro del mismo como error conocido.

Identificación y Registro de errores

El registro de los errores conocidos es de vital importancia para la Gestión de Incidentes pues debe llevar asociado, siempre que esto sea posible, algún tipo de solución temporal que permita minimizar el impacto de los incidentes asociados.

Análisis y Solución

Se deben investigar diferentes soluciones para el error evaluando en cada momento:

  • El posible impacto de las mismas en la infraestructura TI.
  • Los costes asociados.
  • Sus consecuencias sobre los SLAs.

En algunos casos, en los que el impacto del problema puede tener consecuencias graves en la calidad del servicio, pueden emitirse una RFC de emergencia para su procesamiento urgente por la Gestión de Cambios.

Una vez determinada la solución óptima al problema y antes de elevar una RFC a la Gestión de Cambios han de tenerse en cuenta las siguientes consideraciones:

  • ¿Es conveniente demorar la solución? Ya sea porque se prevén cambios significativos en la infraestructura TI a corto plazo o por el escaso impacto del problema en cuestión.
  • ¿Es la solución temporal aportada suficiente para mantener unos niveles de calidad de servicios aceptable?
  • ¿Los beneficios justifican los costes asociados?

Sea cual sea la respuesta, todo la información sobre el error y su solución se registrará en las bases de datos asociadas. En el caso en el que se considere que el problema necesita ser solucionado se emitirá una RFC. Será responsabilidad de la Gestión de Cambios la implementación de los cambios de infraestructura propuestos.

Revisión Post Implementación y Cierre

Antes de dar el problema por resuelto y cambiar su estado a “cerrado” se debe analizar el resultado de la implementación de la RFC elevado a la Gestión de Cambios (PIR).

Si los resultados de esta PIR son los deseados y se pueden cerrar todos los incidentes relacionados con este problema se considera concluido el proceso y se emiten los informes correspondientes.

Problem Management (Control)

El principal objetivo del Control de Problemas es conseguir que estos se conviertan en Errores Conocidos para que el Control de Errores pueda proponer las soluciones correspondientes.

El Control de Problemas se compone en esencia de tres fases:

1. Identificación y Registro

Una de las tareas principales de la Gestión de Problemas es identificar los mismos. Las principales fuentes de información utilizadas son:

  • La base de datos de Incidentes: en principio cualquier incidente del que no se conocen sus causas y que se ha cerrado mediante algún tipo de solución temporal es potencialmente un problema. Sin embargo, se habrá de analizar si este incidente es aislado o su impacto en la estructura TI antes de elevarlo a la categoría de problema.
  • Análisis de la infraestructura TI: en colaboración con la Gestión de Disponibilidad y de Capacidad, la Gestión de Problemas debe analizar los diferentes procesos y determinar en que aspectos se debe reforzar los sistemas y estructuras TI para evitar futuros problemas.
  • Deterioro de los Niveles de Servicio: el descenso del rendimiento puede ser una indicación de la existencia de problemas subyacentes que no se hayan manifestado de forma explicita como incidentes.

Todas las áreas de la infraestructura TI deben colaborar con la Gestión de Problemas para identificar problemas reales y potenciales informando a ésta de cualquier síntoma que pueda ser señal de un deterioro en el servicio TI.

El registro de problemas es, en principio, similar al de los incidentes aunque el énfasis debe hacerse no en los detalles específicos de los incidentes asociados sino más bien en su naturaleza y posible impacto.

El registro debe incorporar, entre otra, información sobre:

  • Los CIs implicados.
  • Causas del problema.
  • Síntomas asociados.
  • Soluciones temporales.
  • Servicios involucrados.
  • Niveles de prioridad, urgencia e impacto.
  • Estado: activo, error conocido, cerrado.
2. Clasificación y Asignación de Recursos

La clasificación del problema engloba desde las características generales de éste, tales como si es un problema de hardware o software, que áreas funcionales se ven afectadas y detalles sobre los diferentes elementos de configuración (CIs) involucrados en el mismo.

Un factor esencial es la determinación de la prioridad del problema, que al igual que en el caso de los incidentes, se determina tanto a partir de la urgencia (demora aceptable para la solución del problema) como de su impacto (grado de deterioro de la calidad del servicio).

Al igual que en la Gestión de Incidentes la prioridad puede cambiar en el curso del ciclo de vida del problema, por ejemplo, si se encuentra una solución temporal al mismo que reduce considerablemente su impacto.

Una vez clasificado y determinada su prioridad se deben de asignar los recursos necesarios para su solución. Estos recursos deben ser suficientes para asegurar que los problemas asociados son tratados eficazmente y así minimizar su impacto en la infraestructura TI.

3. Análisis y Diagnóstico: Error conocido

Los objetivos principales del proceso de análisis son:

  • Determinar las causas del problema.
  • Proporcionar soluciones temporales a la Gestión de Incidentes para minimizar el impacto del problema hasta que se implemente los cambios necesarios que lo resuelvan definitivamente.

Es esencial tener en cuenta que no siempre el origen del problema es un error de hardware o software. Es moneda frecuente que el problema este causado por:

  • Errores de procedimiento.
  • Documentación incorrecta.
  • Falta de coordinación entre diferentes áreas.

Es también posible que la causa del problema sea un “bug” bien conocido de alguno de las aplicaciones utilizadas. Por lo tanto es conveniente establecer contacto directo con el entorno de desarrollo, en caso de aplicaciones desarrolladas “en la casa”, o investigar en Internet información sobre errores conocidos aplicables al problema en cuestión.

Una vez determinadas las causas del problema éste se convierte en un Error Conocido y se remite al Control de Errores para su posterior procesamiento.

Change Management (Control)

Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Cambios.

Para que estos informes ofrezcan una información precisa y de sencilla evaluación es imprescindible elaborar métricas de referencia que cubran aspectos tales como:

  • RFCs solicitados.
  • Porcentaje de RFCs aceptados y aprobados.
  • Número de cambios realizados clasificados por impacto y prioridad y filtrados temporalmente.
  • Tiempo medio del cambio dependiendo del impacto y la prioridad
  • Número de cambios de emergencia realizados.
  • Porcentaje de cambios exitosos en primera instancia, segunda instancia, etc.
  • Numero de back-outs con una detallada explicación de los mismos.
  • Evaluaciones post-implementación.
  • Porcentajes de cambios cerrados sin incidencias ulteriores.
  • Incidencias asociadas a cambios realizados.
  • Número de reuniones del CAB con información estadística asociada: número de asistentes, duración, nº de cambios aprobados por reunión, etc.