SLA Management (Proceso)

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

  • Planificación:
    • Asignación de recursos.
    • Elaboración de un catálogo de servicios.
    • Desarrollo de SLAs tipo.
    • Herramientas para la monitorización de la calidad del servicio.
    • Análisis e identificación de las necesidades del cliente.
    • Elaboración del los Requisitos de Nivel de servicio(SLR), Hojas de Especificación del Servicio y Plan de Calidad del Servicio(SQP).
  • Implementación de los Acuerdos de Nivel del Servicio:
    • Negociación.
    • Acuerdos de Nivel de Operación.
    • Contratos de Soporte.
  • Supervisión y revisión de los Acuerdos de Nivel de Servicio:
    • Elaboración de informes de rendimiento.
    • Control de los proveedores externos.
    • Elaboración de Programas de Mejora del Servicio (SIP).

Planificación

La correcta planificación de la Gestión de Niveles de Servicio requiere la implicación de prácticamente todos los estamentos de la organización TI. Y, si esto no fuera ya de por sí una labor lo suficientemente compleja, resulta imprescindible la colaboración activa de los clientes y usuarios de los servicios TI.

El objetivo primordial de la Gestión de Niveles de Servicio es definir, negociar y monitorizar la calidad de los servicios TI ofrecidos. Si los servicios no se adecuan a las necesidades del cliente, la calidad de los mismos es deficiente o sus costes son desproporcionados, tendremos clientes insatisfechos y la organización TI será responsable de las consecuencias que se deriven de ello.

Todo el proceso de planificación previo debe estar orientado a dar respuestas a las siguiente preguntas:

  • ¿Qué servicios debemos ofrecer a nuestros clientes?
  • ¿Cuáles son las necesidades de nuestros clientes?
  • ¿Cuál es el nivel adecuado de calidad de servicio?
  • ¿Quiénes y cómo se van a suministrar esos servicios?
  • ¿Cuáles serán los indicadores clave de rendimiento para los servicios prestados?
  • ¿Disponemos de los recursos necesarios para proveer los servicios propuestos con los niveles de calidad acordados?

La respuesta a cada una de estas preguntas debe darse en forma de documentos, algunos de carácter interno y otros accesibles a los clientes, que pasamos a describir sucintamente a continuación.

En primer lugar la Gestión de Niveles de Servicio debe poner a disposición de toda la organización, pero en especial a disposición del Service Desk y la fuerza de ventas un Catálogo de Servicios.

Este catálogo de servicios debe describir, en un lenguaje comprensible para los no expertos, los productos y servicios ofrecidos junto a indicaciones generales del nivel de servicio ofrecido, tales como disponibilidad, tiempos de respuesta, etc.

La elaboración de este Catálogo de Servicios puede resultar una tarea compleja pues es necesario alinear aspectos técnicos con políticas de negocio pero es un documento imprescindible pues:

  • Sirve de guía a los clientes a la hora de seleccionar un servicio que se adapte a sus necesidades.
  • Delimita las funciones y compromisos de la organización TI.
  • Puede ser utilizado como herramienta de venta.
  • Evita malentendidos entre los diferentes actores implicados en la prestación de servicios.

Sin embargo, en la mayoría de los casos, por muy detallado y completo que sea el Catálogo de Servicios, la complejidad de los servicios ofrecidos requiere un largo y extenso periodo de negociación con el cliente.

Los resultados de esta interacción/negociación deben ser incorporados al documento de Requisitos de Nivel de Servicio (SLR) que debe reflejar las necesidades del cliente y sus expectativas respecto a:

  • La funcionalidad y características del servicio.
  • La disponibilidad del servicio.
  • La interacción del servicio con su infraestructura TI o de otro tipo.
  • La continuidad del servicio.
  • Los niveles de calidad del servicio.
  • Tiempo y procedimientos de implantación del servicio.
  • La escalabilidad del servicio ofrecido.
  • Etc.

La información contenida en el SLR debe servir de base para elaborar la documentación interna que permita determinar “cómo” se prestara el servicio y “quién o quiénes” serán responsables del mismo.

Las Hojas de Especificación del Servicio deben contener:

  • Una descripción detallada, con todos los detalles técnicos necesarios, sobre como se prestará el servicio.
  • Cuáles serán los indicadores internos de rendimiento y calidad del servicio.
  • Cómo se implementará el servicio.

Si la prestación del servicio requiere la interacción con los servicios TI del cliente o presentas exigencias técnicas a su infraestructura, está información deberá reflejarse en una Hoja de Especificaciones “externa” que habrá de acordarse con el cliente y su responsables técnicos.

El Plan de Calidad del Servicio (SQP) debe ser el documento maestro para la gestión interna de los servicios prestados y contener información detallada sobre todos los procesos TI involucrados en la prestación de los servicios.

En función de los requisitos plasmados en las Hojas de Especificación del Servicio se elabora un plan global que permita asignar los recursos a la organización TI, establecer metas claras basadas en los indicadores de rendimiento elegidos y asegurar que los niveles de calidad ofrecidos se adaptan a las necesidades de los clientes y a los compromisos asumidos por la organización.

En caso de que se estimen insuficientes los recursos internos o sencillamente se considere oportuno externalizar parte de los servicios el SQP servirá de documento guía para el establecimiento de los contratos con los proveedores externos.


Implementación

La fase de planificación debe concluir con la elaboración y aceptación de los acuerdos necesarios para la prestación del servicio.

Estos acuerdos incluyen los Acuerdos de Nivel de Servicio, Niveles de Operación y Contratos de Soporte.

Acuerdos de Nivel de Servicio

Los SLAs deben contener una descripción del servicio que abarque desde los aspectos más generales hasta los detalles más específicos del servicio.

Es conveniente estructurar los SLAs más complejos en diversos documentos de forma que cada grupo involucrado reciba exclusivamente la información correspondiente al nivel en que se integra, ya sea en el lado del cliente como del proveedor.

La elaboración de un SLA requiere tomar en cuenta aspectos no tecnológicos entre los que se encuentran:

  • La naturaleza del negocio del cliente.
  • Aspectos organizativos del proveedor y cliente.
  • Aspectos culturales locales.
Acuerdos de Nivel de Operación

Los OLAs son documentos de carácter interno de la propia organización TI que determinan los procesos y procedimiento necesarios para ofrecer los niveles de servicio acordados con los clientes.

El OLA, por su naturaleza, involucra detalles sobre la prestación del servicio que deben ser opacos para el cliente pero que resultan imprescindibles a la organización TI para su organización.

Contratos de Soporte

Los Contratos de Soporte (UCs) determinan las responsabilidades de los proveedores externos en el proceso de prestación de servicios.

Mientras que los OLAs son documentos internos susceptibles de cierto dinamismo, los Contratos de Soporte deben representar compromisos claros y perfectamente delimitados. A pesar de esta diferencia crucial, los UCs pueden considerarse como una extensión “externa” de los OLAs en el sentido de que persiguen el mismo fin: organizar los procesos y procedimientos necesarios para la correcta provisión del servicio.


Monitorización

El proceso de monitorización de los niveles de servicio es imprescindible si queremos mejorar progresivamente la calidad del servicio ofrecido, su rentabilidad y la satisfacción de los clientes y usuarios.

La monitorización de la calidad del servicio requiere el seguimiento tanto de procedimientos y parámetros internos de la organización como los relacionados con la percepción de los usuarios.

Para llevar a cabo esta tarea de manera eficiente es necesario haber establecido con anterioridad unos baremos de calidad del servicio que han de servir de guía en la elaboración de los informes correspondientes.

Las principales fuentes principales de información las constituyen:

  • La documentación disponible: SLAs, OLAs, UCs, etc.
  • La Gestión de Incidentes: que debe informar de las incidencias en el servicio y los tiempos de recuperación.
  • La Gestión de la Capacidad y la Disponibilidad: que debe proporcionar la información sobre la infraestructura utilizada para satisfacer la calidad de servicios acordada.
  • El Centro de Servicios (Service Desk): que mediante su trato diario con los clientes, usuarios y organización TI supervisa la calidad de los servicios y conoce la percepción del cliente respecto a los mismos.

Los informes de rendimiento elaborados deben cubrir factores clave tales como:

  • Cumplimiento de los SLAs, con información sobre la frecuencia y el impacto de los incidentes responsables de la degradación del servicio.
  • Quejas, justificadas o no, de los clientes y usuarios.
  • Utilización de la capacidad predefinida.
  • Disponibilidad del servicio.
  • Tiempos de respuesta.
  • Costes reales del servicio ofrecido.
  • Problemas detectados y cambios realizados para restaurar la calidad del servicio.
  • Calidad del servicio de los proveedores externos: nivel de cumplimiento de los OLAs.

Revisión

La correcta Gestión de Niveles de Servicio es un proceso continuo que requiere la continua revisión de la calidad de los servicios ofrecidos.

Esta revisión debe realizarse en base a parámetros objetivos y metrizables resultado de la experiencia previa, los SLAs en vigencia y la evolución del Catálogo de Servicios.

Este proceso de revisión no debe limitarse a aquellos SLAs que por una razón u otra han sido incumplidos, aunque, evidentemente, en estos casos sea inexcusable, sino que debe tener como objetivo mejorar y homogeneizar la calidad del servicio.

El resultado de la revisión debe ser un Programa de Mejora del Servicio (SIP) que tome en cuenta factores tales como:

  • Problemas relacionados con el servicio TI y sus posibles causas.
  • Nuevas necesidades del cliente.
  • Avances tecnológicos.
  • Cumplimiento de los niveles de servicio.
  • Evaluación de los costes reales del servicio.
  • Implicaciones de una degradación de la calidad del servicio en la estructura organizativa del cliente.
  • Evaluación del rendimiento y capacitación del personal involucrado.
  • Reasignación de recursos.
  • Cumplimiento de los OLAs y UCs relacionados.
  • Percepción del cliente y usuarios sobre la calidad de servicio.
  • Necesidades de formación adicional a los usuarios de los servicios.

El SIP debe ser el documento base para negociar la renovación del SLA con el cliente y debe constituir un documento de referencia para la gestión de otros procesos TI como la Gestión de Cambios, Gestión de Problemas, etc.

SLA Management (Conceptos Básicos)

Proveedores, clientes y usuarios

Cliente: es la empresa u organismo que contrata los servicios TI ofrecidos.

Usuarios: las personas que utilizan el servicio.

Proveedor: es la empresa u organismo que proporciona los servicios solicitados por el cliente.

Catálogo de Servicios

El Catálogo de Servicios no es sólo una herramienta imprescindible a la hora de simplificar la comunicación con el cliente sino que también puede ser una gran ayuda tanto a la organización interna como a la proyección exterior de la organización TI.

El Catálogo de Servicios debe:

  • Describir los servicios ofrecidos de manera no técnica y comprensible para clientes y personal no especializado.
  • Utilizarse como guía para orientar y dirigir a los clientes.
  • Incluir, en líneas generales, los niveles de servicio asociados con cada uno de los servicios ofrecidos.
  • Encontrarse a disposición del Service Desk y todo el personal que se halle en contacto directo con los clientes.
Requisitos de Nivel de Servicio (SLR)

El SLR debe incluir información detallada sobre las necesidades del cliente y sus expectativas de rendimiento y nivel de servicios.

El SLR constituye el elemento base para desarrollar el SLA y posibles OLAs correspondientes.

Hojas de Especificación

Las Hojas de Especificación son, primordialmente, documentos técnicos de ámbito interno que delimitan y precisan los servicios ofrecidos al cliente.

Las Hojas de Especificación deben evaluar los recursos necesarios para ofrecer el servicio requerido con un nivel de calidad suficiente y determinar si es necesario el outsourcing de determinados procesos, sirviendo de documento de base para la elaboración de los OLAs y UCs correspondientes.

Programa de Calidad del Servicio (SQP)

El SQP debe incorporar toda la información necesaria para posibilitar una gestión eficiente de los niveles de calidad del servicio:

  • Objetivos de cada servicio.
  • Estimación de recursos.
  • Indicadores clave de rendimiento.
  • Procedimientos de monitorización de proveedores.

En resumen, el SQP debe contener la información necesaria para que la organización TI conozca los procesos y procedimientos involucrados en el suministro de los servicios prestados, asegurando que estos se alineen con los procesos de negocio y mantengan unos niveles de calidad adecuados.

Acuerdo de Nivel de Servicio (SLA)

El SLA debe recoger en un lenguaje no técnico, o cuando menos comprensible para el cliente, todos los detalles de los servicios brindados.

Tras su firma, el SLA debe considerarse el documento de referencia para la relación con el cliente en todo lo que respecta a la provisión de los servicios acordados, por tanto, es imprescindible que contenga claramente definidos los aspectos esenciales del servicio tales como su descripción, disponibilidad, niveles de calidad, tiempos de recuperación, etc.

Acuerdo de Nivel de Operación (OLA)

El OLA es un documento interno de la organización donde se especifican las responsabilidades y compromisos de los diferentes departamentos de la organización TI en la prestación de un determinado servicio.

Contratos de Soporte (UC)

Un UC es un acuerdo con un proveedor externo para la prestación de servicios no cubiertos por la propia organización TI.

Programa de Mejora del Servicio (SIP)

El SIP debe recoger tanto medidas correctivas a fallos detectados en los niveles de servicio como propuestas de mejora basadas en el avance de la tecnología.

El SIP debe formar parte de la documentación de base para la renovación de los SLAs y debe estar internamente a disposición de los gestores de los otros procesos TI.

SLA Management (Objetivos)

La Gestión de Niveles de Servicio es el proceso por el cual se definen, negocian y supervisan la calidad de los servicios TI ofrecidos.

La Gestión de Niveles de Servicio es responsable de buscar un compromiso realista entre las necesidades y expectativas del cliente y los costes de los servicios asociados, de forma que estos sean asumibles tanto por el cliente como por la organización TI.

La Gestión de los Niveles de Servicio debe:

  • Documentar todos los servicios TI ofrecidos.
  • Presentar los servicios de forma comprensible para el cliente.
  • Centrarse en el cliente y su negocio y no en la tecnología.
  • Colaborar estrechamente con el cliente para proponer servicios TI realistas y ajustados a sus necesidades.
  • Establecer los acuerdos necesarios con clientes y proveedores para ofrecer los servicios requeridos.
  • Establecer los indicadores claves de rendimiento del servicio TI.
  • Monitorizar la calidad de los servicios acordados con el objetivo último de mejorarlos a un coste aceptable por el cliente.
  • Elaborar los informes sobre la calidad del servicio y los Planes de Mejora del Servicio (SIP).

Los principales beneficios de una correcta Gestión de Niveles de Servicio son:

  • Los servicios TI son diseñados para cumplir sus auténticos objetivos: cubrir las necesidades del cliente.
  • Se facilita la comunicación con los clientes impidiendo los malentendidos sobre las características y calidad de los servicios ofrecidos.
  • Se establecen objetivos claros y metrizables.
  • Se establecen claramente las responsabilidades respectivas de los clientes y proveedores del servicio.
  • Los clientes conocen y asumen los niveles de calidad ofrecidos y se establecen claros protocolos de actuación en caso de deterioro del servicio.
  • La constante monitorización del servicio permite detectar los “eslabones más débiles de la cadena” para su mejora.
  • La gestión TI conoce y comprende los servicios ofrecidos lo que facilita los acuerdos con proveedores y subcontratistas.
  • El personal del Service Desk dispone de la documentación necesaria (SLAs, OLAs,etc.) para llevar una relación fluida con clientes y proveedores.
  • Los SLAs ayudan a la Gestión TI tanto a calcular los cálculos de costes como a justificar su precio ante los clientes.

Lo que repercute a la larga en una mejora del servicio con la consecuente satisfacción de clientes y usuarios.

Las principales dificultades a la hora de implementar la Gestión de Niveles de Servicio se resumen en:

  • No existe una buena comunicación con clientes y usuarios por lo que los SLAs acordados no recogen sus necesidades reales.
  • Los acuerdos de nivel de servicio están basados más en deseos y expectativas del cliente que en servicios que la infraestructura TI puede ofrecer con un nivel de calidad suficiente.
  • No se alinean adecuadamente los servicios TI a los procesos de negocio del cliente.
  • Los SLAs son excesivamente prolijos y técnicos incumpliendo así sus objetivos primordiales.
  • No se dedican los recursos suficientes pues la dirección los considera como un gasto añadido y no como parte integral del servicio ofrecido.
  • Problemas de comunicación: no todos los usuarios conocen las características del servicio y los niveles de calidad acordados.
  • No se monitoriza adecuada y consistentemente el cumplimiento de los SLAs dificultando así la mejora de la calidad del servicio.
  • No existe en la organización un verdadero compromiso con la calidad del servicio TI ofrecido.

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