Availability Management (Proceso)

Entre las actividades que la Gestión de la Disponibilidad se encuentran:

  • Determinar cuales son los requisitos de disponibilidad reales del negocio.
  • Desarrollar un plan de disponibilidad donde se estimen las necesidades de disponibilidad futura a corto y medio plazo.
  • Mantenimiento del servicio en operación y recuperación del mismo en caso de fallo.
  • Realizar diagnósticos periódicos sobre la disponibilidad de los sistemas y servicios.
  • Evaluar la capacidad de servicio de los proveedores internos y externos.
  • Monitorizar la disponibilidad de los servicios TI.
  • Elaborar informes de seguimiento con la información recopilada sobre disponibilidad, fiabilidad, matenibilidad y cumplimiento deOLAs y UCs.
  • Evaluar el impacto de las políticas de seguridad en la disponibilidad.
  • Asesorar a la Gestión del Cambio sobre el posible impacto de un cambio en la disponibilidad.

Requisitos de Disponibilidad

Es indispensable cuantificar los requisitos de disponibilidad para la correcta elaboración de losSLAs.

La disponibilidad propuesta debe encontrase en línea tanto con los necesidades reales del negocio como con las posibilidades de la organización TI.

Aunque en principio todos los clientes estarán de acuerdo con unas elevadas cotas de disponibilidad es importante hacerles ver que una alta disponibilidad puede generar unos costes injustificados dadas sus necesidades reales. Quizá unas pocas horas sin un determinado servicio pueden representar poco más allá de una pequeña inconveniencia mientras que la certeza de un servicio prácticamente continuo y sin interrupciones puede requerir la replicación de sistemas u otras medidas igualmente costosas que no van a tener una repercusión real en la rentabilidad del negocio.

Para llevar a cabo eficientemente está tarea es necesario que la Gestión de la Disponibilidad:

  • Identifique las actividades clave del negocio.
  • Cuantifique los intervalos razonables de interrupción de los diferentes servicios dependiendo de sus respectivos impactos.
  • Establezca los protocolos de mantenimiento y revisión de los servicios TI.
  • Determine las franjas horaria de disponibilidad de los servicios TI (24/7, 12/5, …).

Planificación

La correcta planificación de la disponibilidad permite establecer unos niveles de disponibilidad adecuados tanto en lo que respecta a las necesidades reales del negocio como a las posibilidades de la organización TI.

El documento que debe recoger los objetivos de disponibilidad presentes y futuros y que medidas son necesarias para su cumplimiento es el Plan de Disponibilidad.

Este plan debe recoger:

  • La situación actual de disponibilidad de los servicios TI. Obviamente esta información debe ser actualizada periódicamente.
  • Herramientas para la monitorización de la disponibilidad.
  • Métodos y técnicas de análisis a utilizar.
  • Definiciones relevantes y precisas de las métricas a utilizar.
  • Planes de mejora de la disponibilidad.
  • Expectativas futuras de disponibilidad.

Es imprescindible que este plan proponga los cambios necesarios para que se cumplan los estándares previstos y colabore con la Gestión de Cambios y la Gestión de Versiones en su implementación (en caso de ser aprobados, claro está).

Para que este plan sea realista debe contar con la colaboración de los otros procesos TI involucrados.

Diseño para la Disponibilidad

Es crucial para una correcta Gestión de la Disponibilidad participar desde el inicio en el desarrollo de los nuevos servicios TI de forma que estos cumplan los estándares plasmados en el Plan de Disponibilidad.

Un diferente nivel de disponibilidad puede requerir cambios drásticos en los recursos utilizados o en las actividades necesarias para suministrar un determinado servicio TI. Si éste se diseña sin tener en cuenta futuras necesidades de disponibilidad puede ser necesario un completo rediseño al cabo de poco tiempo, incurriendo en costes adicionales innecesarios.


Mantenimiento y Seguridad

Aunque hayamos realizado un correcto diseño de los servicios según el Plan de Disponibilidad y se hayan tomado todas las medidas preventivas necesarias, tarde o temprano, nos habremos de enfrentar a interrupciones del servicio.

En esos casos es necesario recuperar el servicio lo antes posible para que no tenga un efecto indeseado sobre los niveles de disponibilidad acordados.

Aunque la responsabilidad de restaurar el servicio corresponde a la Gestión de Incidentes y las actividades de recuperación han de ser coordinadas por el Service Desk, la Gestión de la Disponibilidad debe prestar su asesoramiento mediante planes de recuperación que tengan en cuenta:

  • Las necesidades de disponibilidad del negocio.
  • Las implicaciones del incidente en la infraestructura TI y los procesos necesarios para restaurar el servicio.
Gestión de las Interrupciones de Mantenimiento

Independientemente de las interrupciones del servicio causadas por incidencias es habitualmente necesario interrumpir el servicio para realizar labores de mantenimiento y/o actualización.

Estas interrupciones programadas pueden afectar a la disponibilidad del servicio y por lo tanto han de ser cuidadosamente planificadas para minimizar su impacto.

En aquellos casos en que los servicios no son 24/7 es obvio que, siempre que ello sea posible, deben aprovecharse las franjas horarias de inactividad para realizar las tareas que implican una degradación o interrupción del servicio.

Si el servicio es 24/7 y la interrupción es necesaria se debe:

  • Consultar con el cliente en que franja horaria la interrupción del servicio afectará menos a sus actividades de negocio.
  • Informar con la antelación suficiente a todos los agentes implicados.
  • Incorporar dicha información a los SLAs.
Seguridad

Uno de los aspectos esenciales para obtener altos niveles de fiabilidad y disponibilidad es una correcta Gestión de la Seguridad.

Los aspectos relativos a la seguridad deben ser tomados en cuenta en todas las etapas del proceso.

Es tan importante determinar cuándo el servicio estará disponible como el “quién y cómo” va a utilizarlo. La disponibilidad y seguridad son interdependientes y cualquier fallo en una de ellas afectará gravemente a la otra.


Monitorización de la Disponibilidad

La monitorización de la disponibilidad del servicio y la elaboración de los informes correspondientes son dos de las principales actividades de la Gestión de la Disponibilidad.

Desde el momento de la interrupción del servicio hasta su restitución o “tiempo de parada” el incidente pasa por distintas fases que deben ser individualizadamente analizadas:

  • Tiempo de detección: es el tiempo que transcurre desde que ocurre el fallo hasta que la organización TI tiene constancia del mismo.
  • Tiempo de respuesta: es el tiempo que transcurre desde la detección del problema hasta que se realiza un registro y diagnóstico del incidente.
  • Tiempo de reparación/recuperación: periodo de tiempo utilizado para reparar el fallo o encontrar un “workaround” o solución temporal al mismo y devolver el sistema a la situación anterior a la interrupción del servicio.

Es importante determinar métricas que permitan medir con precisión las diferentes fases del ciclo de vida de la interrupción del servicio. El cliente debe conocer estas métricas y dar su conformidad a las mismas para evitar malentendidos. En algunos casos es difícil determinar si el sistema está “caído o en funcionamiento” y la interpretación puede diferir entre proveedores y clientes, por lo tanto, estás métricas deben de poder expresarse en términos que el cliente pueda entender.

Algunos de los parámetros que suele utilizar la Gestión de la Disponibilidad y que debe poner a disposición del cliente en los informes de disponibilidad correspondientes incluyen:

  • Tiempo Medio de Parada (Downtime) : que es el tiempo promedio de duración de una interrupción de servicio, e incluye el tiempo de detección, respuesta y resolución.
  • Tiempo Medio entre Fallos (Uptime): es el tiempo medio durante el cual el servicio esta disponible sin interrupciones.
  • Tiempo Medio entre Incidentes: es el tiempo medio transcurrido entre incidentes que es igual a la suma del Tiempo Medio de Parada y el Tiempo Medio entre Fallos. El Tiempo Medio entre Incidentes es una medida de la fiabilidad del sistema.

Métodos y Técnicas

Aunque llevamos hablando ya un buen rato de disponibilidad aún no hemos aportado un método para cuantificarla.

Es habitual definir la disponibilidad en tanto por ciento de la siguiente manera:

donde:

ASTse corresponde con el tiempo acordado de servicio,DT es el tiempo de interrupción del servicio durante las franjas horarias de disponibilidad acordadas.

Por ejemplo, si el servicio es 24/7 y en el último mes el sistema ha estado caído durante 4 horas por tareas de mantenimiento la disponibilidad real del servicio fue:

La Gestión de la Disponibilidad tiene a su disposición un buen número de métodos y técnicas que le permiten determinar que factores intervienen en la disponibilidad del servicio y que le permiten consecuentemente prever que tipo de recursos se deben asignar para las labores de prevención, mantenimiento y recuperación, así como elaborar planes de mejora a partir de dichos análisis.

Entre dichas técnicas se cuentan:

CFIA

Que son las siglas de Component Failure Impact Analysis (Análisis del Impacto de Fallo de Componentes).

Mediante esté metodo se identifica el impacto que tiene en la disponibilidad de los servicios TI el fallo de cada elemento de configuración involucrado. Es evidente que este método requiere una CMDB correctamente actualizada.

FTA

Que son las siglas de Failure Tree Analysis (Análisis del Árbol de Fallos).

Su objetivo es estudiar como se “propagan” los fallos a traves de la infraestructura TI para comprender mejor su impacto en la disponibilidad del servicio.

CRAMM

Que son las siglas de CCTA Risk Analysis and Management Method (Método de Gestión y Análisis de Riesgos de la CCTA).

Su objetivo es identificar los riesgos y vulnerabilidades a los que se haya expuesta la infraestructura TI con el objetivo de adoptar contramedidas que los reduzcan o que permitan recuperar rápidamente el servicio en caso de interrupción del mismo.

SOA

Que son las siglas de Service Outage Analysis (Análisis de Interrupción del Servicio).

Ésta técnica tiene como objetivo analizar las causas de los fallos detectados y proponer soluciones a los mismos.

Se diferencia de los anteriores métodos en que realiza el análisis desde el punto de vista del cliente haciendo especial énfasis en aspectos no exclusivamente técnicos ligados directamente a la infraestructura TI.


Control del Proceso

La Gestión de la Disponibilidad debe elaborar periódicamente informes sobre su gestión que incluyan información relevante tanto para los clientes como para el resto de la organización TI.

Estos informes deben incluir:

  • Técnicas y métodos utilizados para la prevención y el análisis de fallos.
  • Información estadística sobre:
    • Tiempos de detección y respuesta a los fallos.
    • Tiempos de reparación y recuperación del servicio.
    • Tiempo medio de servicio entre fallos.
  • Disponibilidad real de los diferentes servicios.
  • Cumplimiento de los SLAs en todo lo referente a la disponibilidad y fiabilidad del servicio.
  • Cumplimiento de los OLAs y UCs en todo lo referente a la capacidad de servicio prestada por los proveedores internos y externos.

Para que toda esta información sea fácil y correctamente analizada es imprescindible el establecimiento de métricas precisas que permitan determinar de forma inequívoca parámetros tales como tiempos de parada y funcionamiento. Por ejemplo, en el caso de un servicio online de comercio electrónico se puede considerar que tiempos de respuesta superiores a 10 segundos son equivalentes a que el sistema esta caído, aunque estrictamente hablando el sistema termine respondiendo.

Availability Management (Objetivos)

El objetivo primordial de la Gestión de la Disponibilidad es asegurar que los servicios TI estén disponibles y funcionen correctamente siempre que los clientes y usuarios deseen hacer uso de ellos en el marco de los SLAs en vigor.

Las responsabilidades de la Gestión de la Disponibilidad incluyen:

  • Determinar los requisitos de disponibilidad en estrecha colaboración con los clientes.
  • Garantizar el nivel de disponibilidad establecido para los servicios TI.
  • Monitorizar la disponibilidad de los sistemas TI.
  • Proponer mejoras en la infraestructura y servicios TI con el objetivo de aumentar los niveles de disponibilidad.
  • Supervisar el cumplimiento de los OLAs y UCs acordados con proveedores internos y externos.

Los indicadores clave sobre los que se sustenta el proceso de Gestión de la Disponibilidad se resumen en:

  • Disponibilidad: porcentaje de tiempo sobre el total acordado en que los servicios TI han sido accesibles al usuario y han funcionado correctamente.
  • Fiabilidad: medida del tiempo durante el cual los servicios han funcionado correctamente de forma ininterrumpida.
  • Mantenibilidad: capacidad de mantener el servicio operativo y recuperarlo en caso de interrupción.
  • Capacidad de Servicio: determina la disponibilidad de los servicios internos y externos contratados y su adecuación a los OLAs y UCsen vigor. Cuando un servicio TI es subcontratado en su totalidad la disponibilidad y la capacidad de servicio son términos equivalentes.

La disponibilidad depende del correcto diseño de los servicios TI, la fiabilidad de los CIs involucrados, su correcto mantenimiento y la calidad de los servicios internos y externos acordados.

Los principales beneficios de una correcta Gestión de la Disponibilidad son:

  • Cumplimiento de los niveles de disponibilidad acordados.
  • Se reducen los costes asociados a un alto nivel de disponibilidad.
  • El cliente percibe una mayor calidad de servicio.
  • Se aumentan progresivamente los niveles de disponibilidad.
  • Se reduce el número de incidentes.

Las principales dificultades con las que topa la Gestión de la Disponibilidad son:

  • No se monitoriza correctamente la disponibilidad real del servicio.
  • No existe compromiso con el proceso dentro de la organización TI.
  • No se dispone de las herramientas de software y personal adecuado.
  • Los objetivos de disponibilidad no están alineados con las necesidades del cliente.
  • Falta de coordinación con los otros procesos.
  • Los proveedores internos y externos no reconocen la autoridad del Gestor de la Disponibilidad por falta de apoyo de la dirección.

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.

Version Management (Conceptos Básicos)

Conceptos básicos

Una versión es un grupo de CIs de nueva creación o modificados que han sido validados para su instalación en el entorno de producción. Las especificaciones funcionales y técnicas de una versión están determinadas en la RFC correspondiente.

Las versiones pueden clasificarse, según su impacto en la infraestructura TI, en:

  • Versiones mayores: que representan importantes despliegues de software y hardware y que introducen modificaciones importantes en la funcionalidad, características técnicas, etc.
  • Versiones menores: que suelen implicar la corrección de varios errores conocidos puntuales y que a menudo son modificaciones que vienen a implementar de una manera correctamente documentada soluciones de emergencia.
  • Versiones de emergencia: modificaciones que reparan de forma rápida un error conocido.

Como pueden llegar a existir múltiples versiones es conveniente definir una referencia o código que los identifique unívocamente. El sistema universalmente aceptado es:

  • Versiones mayores: 1.0, 2.0, etc.
  • Versiones menores: 1.1, 1.2, 1.3, etc.
  • Versiones de emergencia: 1.1.1, 1.1.2, etc

Aunque en algunos casos esta clasificación se refina aún más (vea, por ejemplo, en la ayuda la versión de su navegador).

En su ciclo de vida una versión puede encontrase en diversos estados: desarrollo, pruebas, producción y archivado.

El despliegue de nuevas versiones puede realizarse de diferentes maneras y es responsabilidad de la Gestión de Cambios el determinar la forma más conveniente de hacerlo. Entre las opciones más habituales cabe contar:

  • Versión delta: sólo se testean e instalan los elementos modificados. Esta opción tiene como ventaja su mayor simplicidad pero conlleva el peligro de que puedan aparecer problemas e incompatibilidades en el entorno de producción.
  • Versión completa: Se distribuyen todos los elementos afectados ya hayan sido modificados o no. Aunque esta opción es obviamente más trabajosa es más improbable que se generen incidentes tras la instalación si se han realizado las pruebas pertinentes.
  • Paquete de Versiones: La Gestión de Cambios puede optar por distribuir de forma sincronizada diferentes paquetes de versiones, de esta forma se ofrece una mayor estabilidad al entorno TI. En algunos casos esta opción es obligada por incompatibilidades entre una nueva versión con software o hardware previamente instalado. Pensemos, por ejemplo, en la migración a un nuevo sistema operativo que requiere hardware más avanzado y/o nuevos versiones de los programas ofimáticos.
DSL

La Biblioteca de Software Definitivo (DSL)debe contener copia de todo el software instalado en el entorno TI. Esto incluye no solo sistemas operativos y aplicaciones sino también controladores de dispositivos y documentación asociada.

La DSL debe contener el histórico completo de versiones de un mismo software para proporcionar la versión necesaria en caso de que se deban implementar los planes de back-out.

La DSL debe ser almacenada en un entorno seguro y es conveniente que se realicen back-up periódicos.

DHS

El Depósito de Hardware Definitivo (DHS) contiene piezas de repuesto para los CIs en el entorno de producción.

Los activos almacenados deben incorporarse a la CMDB en el caso de que los CIs correspondientes se hallen registrados en la misma (esto puede depender del alcance y nivel de detalle de la CMDB).

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

Incident Management (Control del Proceso)

La correcta elaboración de informes forma parte esencial en el proceso de Gestión de Incidentes.

Incident Closed

Estos informes deben aportar información esencial para, por ejemplo:

  • La Gestión de Niveles de Servicio: es esencial que los clientes dispongan de información puntual sobre los niveles de cumplimiento de los SLAs y que se adopten medidas correctivas en caso de incumplimiento.
  • Monitorizar el rendimiento del Centro de Servicios: conocer el grado de satisfacción del cliente por el servicio prestado y supervisar el correcto funcionamiento de la primera línea de soporte y atención al cliente.
  • Optimizar la asignación de recursos: los gestores deben conocer si el proceso de escalado ha sido fiel a los protocolos preestablecidos y si se han evitado duplicidades en el proceso de gestión.
  • Identificar errores: puede ocurrir que los protocolos especificados no se adecuen a la estructura de la organización o las necesidades del cliente por lo que se deban tomar medidas correctivas.
  • Disponer de Información Estadística: que puede ser utilizada para hacer proyecciones futuras sobre asignación de recursos, costes asociados al servicio, etc.

Por otro lado una correcta Gestión de Incidentes requiere de una infraestructura que facilite su correcta implementación. Entre ellos cabe destacar:

  • Un correcto sistema automatizado de registro de incidentes y relación con los clientes
  • Una Base de Conocimiento (KB) que permita comparar nuevos incidentes con incidentes ya registrados y resueltos. Una (KB) actualizada permite:
    • Evitar escalados innecesarios.
    • Convertir el “know how” de los técnicos en un activo duradero de la empresa.
    • Poner directamente a disposición del cliente parte o la totalidad de estos datos (a la manera de FAQs) en una Extranet. Lo que puede permitir que a veces el usuario no necesite siquiera notificar la incidencia.
  • Una CMDB que permita conocer todas las configuraciones actuales y el impacto que estas puedan tener en la resolución del incidente.

Para el correcto seguimiento de todo el proceso es indispensable la utilización de métricas que permitan evaluar de la forma más objetiva posible el funcionamiento del servicio. Algunos de los aspectos clave a considerar son:

  • Número de incidentes clasificados temporalmente y por prioridades.
  • Tiempos de resolución clasificados en función del impacto y la urgencia de los incidentes.
  • Nivel de cumplimiento del SLA.
  • Costes asociados.
  • Uso de los recursos disponibles en el Centro de Servicios.
  • Porcentaje de incidentes, clasificados por prioridades, resueltos en primera instancia por el Centro de Servicios.
  • Grado de satisfacción del cliente.