ITIL V3: SERVICE TRANSITION (TRANSICIÓN DEL SERVICIO)

Post gracias a Omar Palomino. (http://www.el-palomo.com/)

Cuarto post sobre ITIL v3, en donde hablaremos sobre la transición del servicio. Para poder entender correctamente este post y relacionar correctamente todos los temas deberíamos haber leído antes: Introducción a ITIL v3, Estrategia del Servicio (SE) y Diseño del Servicio (SD).

ITIL se baja en algo tan simple como la lógica!!! no hay nada misterioso o que nunca hayamos hecho antes los que estamos metidos en el mundo de TI, analicemos un poco; primero analizamos la estrategia para saber como podemos enfrentar una solución de TI, luego diseñamos los pasos a seguir es decir los procedimientos y ahora lo que debe continuar es IMPLEMENTAR EL SERVICIO, es decir la TRANSICION de lo pensado hacia sistemas tangibles.

Entonces Service Transition (ST) se encarga de coordinar los procesos y funciones para empaquetar, construir, probar y desplegar una versión del servicio según lo acordado en el SLA, con el objetivo de llevar un control  e información de los cambios realizados, mejorar el impacto sobre el ambiente de producción e incrementar la satisfacción del cliente durante el proceso de transición.

Algunos conceptos y definiciones de ITIL v3

• Ítem de configuración (CI): Es todo activo, servicio, componente de servicio o cualquier ítem que es o esta bajo el control de la gestión de la configuración, aunque el termino parece sencillo el examen de certificación de ITIL trae siempre preguntas sobre esta definición.
• Sistema de congestión de la configuración (CMS): Gestiona todos los CIs.
• Definitive Media Library (DML): Biblioteca segura que almacena y protege las versiones autorizadas y definitivas de todos los CIs.
• Unidad de liberación (Release Unit): Porción de un servicio o infraestructura de TI que es liberada o desplegada según las políticas de la organización.

Como ya habíamos comentado en las primeras líneas, la “Transición del Servicio” ejecuta y plasma el diseño del servicio en un servicio táctil y utilizable; sin embargo no es están simple como “hacerlo o ejecutarlo” sino que hay toda una gestión y procesos detrás de estos, estos procesos son:

• Gestión del Cambio
• Gestión del Activo servicio y la configuración (SACM)
• Gestión de la liberación y el despliegue

GESTION DEL CAMBIO

La gestión del cambio se asegura que todos los cambios sean registrados, evaluados, autorizados, priorizados, planeados, probados, implementados, documentados y revisados de manera controlada, para que el impacto en los usuarios sea confortable. 

Conceptos en la gestión del cambio

• Políticas y estándares: reglas que proveen una cultura y ambiente que soporta el cambio. Por ejemplo una política de cambio es que todo cambio debe ser probado por el periodo de 15 días hábiles como mínimo.
• Requerimientos de cumplimiento regulatorio: Este se aplica a disposiciones legales, por ejemplo si el estado decide aplicar un aumento al IGV, el sistema informático debe cambiar, a esto se le llame un cumplimiento regulatorio.
• Pruebas y procedimientos de post evaluación: La gestión encargada de evaluar que el cambio ha sido implementado con éxito es la GESTION DEL CAMBIO (pregunta de certificación)
• CAB (Comité de Cambio) y ECAB (comité de cambio de emergencia)
• Stakeholders: Involucrados en la planeación y preparación del cambio, aconsejan cronograma de cambios.

¿Que es para ITIL un cambio?

• Un cambio en el estado de un CI
• Un cambio de un CI en las relaciones con otro CI
• UN NUEVO CI (pregunta de certificación)
• Un nuevo propietario o cambio de ubicación de un CI

Actividades del proceso

La imagen superior resume todo lo que hace la gestión del cambio, voy ahondar un poco tratando de no caer en la redundancia:

1. Registro: Registrar todos los RFC (Request for change – Solicitud de cambio) y cambios en la CMDB, registrar el tipo de cambio, si fue un cambio estándar (planeado) o fue un cambio no estándar (un cambio de emergencia por ejemplo).
2. Aceptación: Evaluación inicial del RFC donde se puede rechazar RFC poco claras e ilógicas y hasta innecesarias. Esto es muy importante porque si el RFC es rechazada por ser poco clara hará que el solicitante sea mas explicito y mejore el entendimiento del cambio.
3. Clasificación: Especifica la prioridad (importancia del cambio frente a otro cambio) y la categoría (en base del impacto y recursos).

Asignación de la prioridad

• Inmediato: Un cambio que origina que el servicio este caído o el impacto en la organización sea muy grande, esto debe hacer que el ECAB deba reunirse.
• Alto: Afecta un buen numero de usuarios.
• Medio: No hay un impacto severo.
• Bajo: Cambio justificado y necesario, puede esperar la calendarización.

La imagen muestra procedimientos de cambio de emergencia y es evidente que este no sigue procedimientos normales, debe tener la mayor prioridad y debe contar con la reunión del ECAB.

4. Planificación: Los cambios se planifican usando utilizando un Calendario de Cambio a futuro (FSC: Forward Schedule of Changes)

Políticas de Cambio
Las políticas determina si se combinan RFCs, horarios y fechas de cambio.
Reuniones del CAB
RFCs que deben ser evaluadas por el comité, cambios abiertos y cerrados, evaluación de cambios pasados, cambios autorizados que no han sido remitidos al cab y revisar los cambios que no han sido autorizadas son las tareas del comité de cambio (CAB).

5. Coordinación: Los cambios aprobados se comunican con los especialistas para que implementen el cambio. Aquí hay algo importante que decir, la gestión del cambio NO IMPLEMENTA EL CAMBIO (pregunta de certificación), entonces…. ¿quién implementa el cambio? la respuesta esta en este mismo post así que sigue leyendo.

6 Evaluación: Se encargan de cerrar el RFC si el cambio fue exitoso y se registra en el PIR (Post – Implementation Review) y si el cambio no fue exitoso se retorna al punto de error.

Todo creo que esta claro hasta aquí y para aquellos que ya han leído los primeros posts sobre ITIL saben que todos los procesos para ITIL deben ser cuantitativos, es decir que a partir de esto nosotros debemos hacer reportes donde se indique lo siguiente:

• Métricas de Salida:
  • Numero de interrupciones, incidente y problemas que hubo con el servicio.
  • Numero de cambios no autorizados que se han llevado a cabo.
  • Numero de cambios forzosos o de emergencia que se realizaron
  • Tiempo, esfuerzo y costo que ocasiono el cambio
• Métricas de trabajo
  • Frecuencia de cambios
  • Volumen de cambios
• Proceso de medición
  • Satisfacción del usuario

Si olvidan que para ITIL todo debe ser medido y por ende registrado, están olvidando la esencia de ITIL.

GESTION DEL ACTIVO SERVICIO Y LA CONFIGURACION

¿Suena raro el nombre verdad? Pues cuando yo escuche por primera vez esto no entendí muy bien a lo que se refería pero luego lo entendí fácilmente y eso es lo que voy a tratar de hacer aquí, que los que lo lean lo entiendan fácilmente.

Entonces… un ACTIVO SERVICIO es todo lo que se pueda registrar referente a TI, desde un switch, software, dueños de hardware/software hasta documentación. Teniendo esto en cuenta LA GESTION DEL ACTIVO SERVICIO Y LA CONFIGURACION define y controla todos los componentes de los servicios brindados, así como la infraestructura con el objetivo de mantener los registros actualizados y exactos, aun no lo entendiste? OK digámoslo mas sencillo aun y con un ejemplo, si mañana se reemplaza un switch no administrable por un switch cisco administrable, la configuración y la relación de este switch con los demás switches debe ser actualizada y registrada por este proceso.

Esto obviamente tiene sus ventajas, por ejemplo…. si tenemos toda la configuración debidamente registrada la GESTION DEL CAMBIO puede tomar la decisión de un cambio de manera mas sencilla y con mejor precisión, además se puede resolver problemas con mayor rapidez y además tenemos un control de todos los activos.

Conceptos en la Gestión del Activo Servicio y la Configuración (SACM)

• Sistema de Gestión de la configuración (CMS)
  La CMS mantiene toda la información relativa al activo servicio y a la gestión de la configuración.

Nota: CMDB –> CMS –> SERVICE KNOWLEDGE MANAGEMENT SYSTEM, este es el modo evolutivo de almacenamiento de información de ITIL. [Aquí pueden leer acerca de esta evolución]

• Definitive Media Library (DML)
  Sobre DML vienen muchas preguntas de certificación, la DML es el sitio FISICO donde se almacena el software que se utiliza en la organización, pero no cualquier software sino la versión final y de uso del software; es decir no una versión incompleta del software sino la versión autorizada por el equipo de desarrollo por ejemplo.
• Línea base de configuración (Baseline)
  Es una solo una línea de referencia para configuraciones, por ejemplo la “baseline” de las computadoras de una organización es para todos igual (sistema operativo Windows, drivers, codecs, etc.) y dependiendo del área donde trabaje se le instalan otras aplicaciones.
• Gestión de Configuración
  Por un lado esta Gestión del activo servicio que se encarga de almacenar la información de un CI y por otro lado esta la Gestión de la Configuración que no solo almacena la configuración de un CI también almacena la relación que tiene el CI con otros CIs.

La grafica superior muestra como actúa la gestión de la configuración, aplicando ITIL nosotros debemos ser capaces de saber cuantos usuarios y de que departamentos serán afectados sin un servidor de Base de Datos falla y la respuesta debe ser en un periodo corto de tiempo sin necesidad de ir preguntado usuario por usuario por el problema.

Nota: Es obvio que llegar a este punto no es sencillo, si me preguntaran a mi cuantos usuarios y que servicios se ven afectados si se cae determinado switch tendría que revisar la ubicación física, los tipos de usuarios, etc; por lo tanto para llegar al nivel que recomienda ITIL me falta aun bastante (pero voy rumbo a ese objetivo).

En conclusión lo que hace la GESTION DEL ACTIVO SERVICIO Y LA CONFIGURACION almacenar los atributos de un CI y su relación con otros CI, que almacenar de un CI? pues eso depende lo que sea relevante para una organización, aunque ITIL recomienda algunos atributos básicos,

Es evidente que esto no es todo lo que se debe de almacenar de un CI, existen otros datos importantes como el numero de serie, numero de modelo, fabricante, categoría, ubicación, propietario responsable, licencia, estado actual, costos y algunos otros comentarios.

¿Existe relación entre la Gestión del Cambio y la Gestión de la Configuración?

Evidentemente existe una relación, cuando se realiza un cambio en un CI la información de ese CI y la relación con otros CI debe ser almacenada, la grafica inferior lo explica mejor.

No hay mucho que comentar acerca de la grafica y es que es evidente que la Gestión de la Configuración esta relacionada directamente con la Gestión del Cambio debido a que todo cambio debe ser almacenado y esa es la función de la Gestión de la configuración.

Definitivamente almacenar todos los atributos de un CI, el status y sus relaciones con otros CI no es tarea sencilla pero tiene sus beneficios como una mejor gestión de los componentes de TI, se reduce errores y costos, eficacia en la solución de problemas, cambios mas veloces, mejor control de hardware y software.

Gestión de las Versiones y el Despliegue (RDM – Release and Deployment Management)

Lo primero que hay que saber aquí es que los gringos utilizan la palabra “RELEASE” y nosotros no hemos encontrado una mejor traducción que “VERSION”, quizás una mejor traducción hubiera sido “LANZAMIENTO” aunque no se…. ya me acostumbre a decir “Gestión de las Versiones” y así pienso dejarlo.

Un release es un conjunto de elementos de configuración nuevos y/o modificados que están evaluados (gestión del cambio) y se introducen en el entorno de producción, en conclusión la gestión de versiones es quien implementa los cambios en los servicios de TI y dirige todos los aspectos técnicos y no técnicos de los cambios.

La imagen superior que parece tan inofensiva es una “caserita” de examen de certificación de ITIL, ¿quién implementa el cambio? ¿quién verifica el cambio? lo han preguntado mil veces y lo seguirán preguntando.

Objetivos

- Hace los planes de liberación y despliegue
- Construir, instalar, hacer las pruebas y desplegar los paquetes de liberación
- Diseñar e implementar los procedimientos para instalar los cambios en los servicios de TI
- SACM es el responsable de todos los CIs, sin embargo RDM debe de apoyar que todas las copias de software estén en el DSL y el hardware necesario esta en el DHS.

Nota: En ITIL v2 hay dos términos importantes, DSL (Definitive software library) y DHS (Definitive hardware store), en ITIL v3 esos dos términos carecen de sentido porque existe un nuevo concepto llamando DML (Definitive media library) y que esta bajo la gestión de SACM. Pueden leer un poco mas sobre eso [AQUI].

Conceptos de RDM

- Entornos de Software: ITIL v3 recomienda tres entornos o tres ambientes de software

• Entorno de desarrollo: Aquí se puede instalar de todo y todos los usuarios tienen acceso.
• Entorno de pruebas: Ambiente idéntico al de producción donde solo tienen acceso los tester, aquí se hacen pruebas técnicas, de performance, funcionales y es aquí donde se recibe la aceptación final por el grupo de usuarios para pasar el software a producción.
• Entorno de producción: Aquí se ponen los servicios a disposición de los usuarios, este ambiente no se sin antes haber pasado por desarrollo y pruebas.

Tipos de versiones:

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

Llegado a este punto, debemos ser capaces de entender todo el proceso que ITIL propone y la siguiente grafica lo explica claramente.

Hasta este punto y si han leído los primeros post de ITIL, ya comprenden acerca del Nivel de Servicio, la Gestión del Cambio, la Gestión de la configuración y pueden notar que todo ITIL esta relacionado, ahora lo que falta ahondar mas es en la Gestión de Versiones y sus actividades internas, ¿ven el cuadrito que dice “Gestión de Versiones” en la imagen superior? pues vamos hacerle un zoom y hablar sobre eso.

Este es el zoom del recuadro, la imagen muestra todas las actividades que realiza la gestión del release y los respectivos ambientes donde se realiza la actividad. Vamos a explicar las actividades y con esto términos este extenso post.

1.- Política y planificación de liberación de versiones: Define políticas que responden a preguntas: ¿cómo y cuando se configura y despliega una versión?, define horarios de liberación, horas/hombre.
2.- Diseño, construcción y configuración: Desarrollo procedimientos para construir y configurar.
3.- Prueba y aceptación de le versión: Pruebas funcionales de los usuarios, prueba operativa del personal de TI (la gestión del cambio debe coordinar la aceptación final por parte del usuario)
4.- Planificación del despliegue: Detalla recursos y responsabilidades, además analiza las formas de implementación (una implementación total – Big Bang- o una implementación por partes)
5.-  Comunicación, preparación y capacitación: Capacitación e información al usuario.
6.- Distribución e instalación de versiones: Finalmente poner en producción todo lo probado.

Post gracias a Omar Palomino. (http://www.el-palomo.com/)