Publicado el

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.

SKMS

  • 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)

Modelo en V

  • 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.