ITIL Fase 3: Transición

Objetivos

• Llevar con éxito a producción un servicio nuevo o modificado, diseñado previamente, con los costes previstos.
• Menor impacto y riesgos acotados.
• Proporcionar planes claros e integrales.

PROCESOS

1- Gestión de Cambios

• META: medios y procedimientos estandarizados (bien documentados) reduciendo cualquier impacto sobre el servicio.
• Va de la mano con gestión de configuraciones.
• Gestión de cambios no se encarga de gestionar facturas ni gastos.

• Definiciones:
  • Cambio: «adición, modificación o eliminación de un servicio, y su documentación asociada».
    • No son cambios, ni cambios mayores (cambios estructurales, a nivel de empresa o en un proceso de negocio) ni cambios menores (a nivel operativo).
  • Solicitud de cambio (RFC): petición formal para un cambio.
  • Cambio estándar: cambios rutinarios de bajo riesgo.
  • Cambio de emergencia: cambio que no tiene Service Design Package.
  • Comité de cambios (CAB): se reúne periódicamente para evaluar, priorizar, autorizar, revisar los RFC y ejecutar los PIR (Revisión post-implementación).
  • Comité de cambios de emergencia (ECAB).

• Hay que definir qué es un cambio y qué es operativa normal.
• Documentos de la planificación de cambios:
  • Calendario de Cambios (CS) aprobados.
  • Documento de Paradas Planificadas (Planned Downtime) PD.
• El proceso de cambios consta de las siguientes etapas: Registro -> Revisión -> Evaluación del impacto -> Priorización -> Análisis de riesgo -> Verificación -> Cierre.
  • Registro y revisión
    • Los cambios deben registrarse.
    • Han de existir procedimientos para solicitar cambios.
    • El CAB revisará los RFC.
  • Evaluación: Las 7R de la gestión de cambios -> Evaluación del impacto.
    • Requerimiento: ¿quién solicitó el cambio?
    • Razón: ¿cuál es el motivo del cambio?
    • Resultado esperado con el cambio.
    • Riesgos: ¿qué riesgos presenta el cambio?
    • Recursos que se necesitan para efectuar el cambio.
    • Responsables de hacer el cambio.
    • Relación con otros cambios.
  • Priorización y riesgos
    • Primero se usará el impacto que puede provocar (el impacto determinará la categoría del cambio, menor, medio o mayor).
    • Segundo se le dará una prioridad al cambio.
  • Análisis y cierre
    • El CAB realizará la Revisión Post Implementación (PIR), que garantiza:
      • Que el cambio ha alcanzado sus objetivos.
      • Que todos están satisfechos y no hay efectos secundarios imprevistos.
      • Que todo está documentado.
• Plan de remediación:
  • Actúa cuando el resultado de un cambio no es satisfactorio.
  • No siempre existen back outs (vuelta atrás). Es entonces cuando se usa la remediación.

2- Gestión de la Configuración y Activos de Servicio (SACM)

• Objetivo: definir los componentes de los servicios y de TI y mantener la CMDB.
• Proporciona info precisa sobre configuraciones.
• Minimiza los problemas causados por malas configuraciones.
• La CMDB
  • No es solo de ítems, también lleva relaciones.
  • El número de columnas marca la amplitud de la CMDB.
  • La profundidad de la CMDB (el detalle) viene marcada
• Definiciones:
  • CI (Configuration Item): cada uno de los componentes de la infraestructura.
  • CMDB (Configuration Management DataBase): base de datos para organizar y relacionar los CI. Contiene información sobre incidencias, problemas y solicitudes de cambio de cada CI.
  • CMS (Configuration Management System): herramientas y bases de datos usadas para gestionar la información de configuración.
  • SKMS (Service Knowledge Management System): herramientas y bases de datos usadas para gestionar el conocimiento y la información. Tiene toda la información que un proveedor de servicios necesita para gestionar sus servicios.

• DML (Biblioteca Definitiva de Medios): contiene versiones aprobadas de CI de software. Puede contener licencias y documentación.
• Configuration Baseline: configuración de un servicio funcionando correctamente.
• Snapshot: estado más reciente de un entorno o CI. Se incluye en el CMS.

3- Gestión de Versiones y Despliegues

• Objetivos:
  • Garantizar que existen planes de versiones y despliegues.
  • Asegurar que pueden crearse, instalarse, testearse y desplegarse paquetes de versiones con éxito y dentro de los plazos, con el menor impacto posible.
• Definiciones:
  • Unidad de lanzamiento: parte de un servicio o infraestructura TI que será liberada conjuntamente. No tiene por qué ser un primer lanzamiento, puede ser cualquiera. Por ejemplo: departamento contable.
  • Identificación de la versión: todos los lanzamientos deben identificarse de forma única.
• Tipos de despliegue:
  • Big Bang: a todos los usuarios conjuntamente.
  • Phased (por fases): a diversos grupos en momentos diferentes.
• Opciones:
  • Pushed
  • Pulled
• Modelo en V del servicio (a la izquierda, requisitos del servicio, a la derecha, validación y verificación)

• Roles:
  • Gestor de versiones: crea y prueba la versión final.
  • Gestor de despliegues: planifica el despliegue y es el responsable del mismo.
• Early Life Support: provee recursos para resolver problemas durante el despliegue.