ITIL - Change Management

Quiero hablar puntualmente de la Gestion de Cambio o Change Management, segun lo trata ITIL ,separado de otros procesos de esta metodologia.

La experiencia demuestra que una proporcion elevada de los problemas de TI ocurren despues de realizarse alguna modificacion. Los cambios en la infraestructura de TI muchas veces resultan en problemas serios, que cuestan mucho mas para solucionarlos que el costo real del cambio.

Por seguridad todo cambio en la infrestructura de TI, por una tema de capacidad o por solucion de problemas tiene asociado un riesgo el cual dependera del tamaño de la modificacion.

Esta razon es porque es conveniente realizar un estudio sobre los procesos de administracion de los cambios.

En el caso de Seguridad Informatica, cualquier modificacion a las reglas de un firewall o a realizarse sobre equipos criticos debe pasar por este proceso.

El proceso de Gerenciamiento de Cambios es responsable por el control de las modificaciones en la infraestructura TI o cualquier modificacion que impacte en los niveles de servicios acordados con las areas de negocios.

La gestion de cambio esta ligada fuertemente con el Gerenciamiento de configuracion (Lleva el control de todos los elementos de configuración de la infraestructura TI con el adecuado nivel de detalle y gestiona dicha información a través de la Base de Datos de Configuración ) el Gerenciamiento de Liberacion (es la encargada de la implementación y control de calidad de todo el software y hardware instalado en el entorno de producción. ) y por ultimo con la Central de Servicios ( El objetivo primordial, del Centro de Servicios es servir de punto de contacto entre los los usuarios y la Gestión de Servicios TI )

La Central de Servicios debe estar alineada muy fuertemente dado que cada nueva modificacion autorizada deve serle informada para que no haya sorpresas en caso de exisitir algun incidente.

El ciclo de una modificacion :


Caracteristicas de un "cambio"

Debemos establecer claramente cuales son las solicitaciones que deben ser tratadas por el equipo de Gestion de Cambios ( en Brasil se llama Gestion de mudanças y al proceso GMUD ).

Las operaciones diarias como, cambio de passwords, cambio de nombres de usuarios, instalacion de software de desktops o creacion de nuevos usuarios no deben pasar por el proceso de Gestion Cambios ya que de otra manera se formaria un cuello de botella contraproducente.

Unicamente en casos especiales ( cambios de passwords de servicios criticos) deben ser informados.

Por lo tanto cada organizacion debe establecer el limite desde el cual una modificacion sera entendida como critica y debera pasar por el proceso correspondiente.

Items que deben someterse a la Gerencia de Cambios

Tomando en cuenta las caracteristicas anteriores :

Hardware

Aplicativos y Sistema Operativo

Aplicativos de Negocios

Bases de Datos

Relaciones entre las BD y las aplicaciones

Documentos de configuracion

Documentacion de procesos y flujos de trabajo

Plan de capacidad y Plan de continuidad.


Cualquier modificacion a uno de estos items debe pasar por el proceso de Gerenciamientos de cambio para su registro, validacion y aprovacion para su implementacion.

La gerencia de cambio no tiene poder para decidir que cual o cuando una modificacion se realizara, solamente ayuda a tomar la decision al comite de modificaciones.

Para agilizar todo el proceso se recomienda una solucion de workflow de procesos


Participantes y Responsabilidades
Hasta ahora hay mucho buzzword, pasemos en limpio cada uno de los participantes del proceso.

Comite de cambios : es la entidad dentro de cada organizacion que tiene el poder para aprobar, rechazar o priorizar los cambios propuestos. Todo de acuerdo al impacto que puedan tener sobre los niveles de SLA comprometidos con las areas de negocios.

Esta formado por un grupo de personas con experiencia en el dia a dia de la empresa y multidisciplinar. Tienen que tener partiipacion las areas tecnicas, de negocios y produccion.

Segun el tamaño de la organizacion, la cantidad de participantes, basicamente deben estar presentes :

Gerente de Cambios

Representante de la direccion

Representante de las areas de atencion a cliente

Representante del equipo de desarrollo y mantenimiento de sistemas

Representantes de las areas de Tecnologia ( BD, Seguridad,Mail...)

Representante de produccion

Representante de otros procesos de ITIL

Representantes de los partners de Tecnologia


Durante las reuniones se discuten el imapcto de los cambios al ambiente y su riesgo, esto debe ser conducido por una persona que oficie de mediador.

La perioricidad dependera del negocio, maduridad del ambiente. Pueden ser reuniones semanales o mensuales.

Para las emergencias existe un Comite de cambios Emergenciales antes del cual debe definirse bien que cambios tienen estas caracteristicas para evitar que se banalice su accionar y se deje de lado el Comite de cambios.

Analisis de Riesgo

El analisis de riesgo de un cambio se puede realizar mediante una matriz SWOT, la cual es compuesta por las variables internas y externas.
Las magnitudes a utilizar pueden ser : 3 ( alto ) 2 (Medio) 1 (Bajo) par cada variable positiva ( Fortaleza y Oportunidad ) y -1(bajo) -2(medio) y -3(alto) para cada variable negativa (Debilidades, Amenazas)

En mi experiencia, en las reuniones que participe, el analisis de riesgo fue realizado en base al conocimiento del ambiente y sus amenazas. No se utilizo para cada modificacion un diagrama SWOT.
Solicitacion de un cambio :

Una soliitacion de cambio ( en ingles Reques for Change RFC )es el punto de partida de todo el proceso de la Gerancia de Cambios.

Independientemente del motivo por el cual un cambio es pedido, una RFC debe contener :

* Fecha de recepción.
* Identificador único de la RFC.
* Identificador del error conocido asociado (dado el caso).
* Descripción del cambio propuesto:
o Motivación.
o Propósito.
o CIs involucrados.
o Estimación de recursos necesarios para la implementación.
o Tiempo estimado.
* Estatus: que inicialmente será el de "registrado".

Tambien existe otros campos que pueden adicionarse :

* Prioridad
* Plan de Rollback
* Hora de Inicio
* Nombre y lugar donde puede ser localizada la persona que propone el cambio
* Detalles del cambio

Entre otros, uno puede hacer esto mas o menos detallado.

Todo esto debera ser almacenado en un historico de cambios, para luego poder consultarse en el futuro en caso de problemas.

Proceso

Par explicar todo el proceso voy a utilizar material de la pagina http://www.osiatis.es/ la cual tiene una excelente capacitacion online sobre ITIL :

Registro

El primer paso del proceso de cambio es registrar adecuadamente las RFCs.

El origen de una RFC puede ser de muy distinta índole:

* Gestión de Problemas: se encarga de proponer soluciones a errores conocidos. En la mayoría de los casos esta solución acarrea un cambio en la infraestructura TI. En este caso el RFC debe ser registrado con información del error conocido asociado para que posteriormente pueda ser evaluada correctamente la pertinencia del proceso.
* Nuevos Servicios: el desarrollo de nuevos servicios usualmente requiere cambios de la infraestructura TI. En este caso es importante coordinar todo el proceso con las Gestiones de Capacidad, Disponibilidad y Niveles de Servicio para asegurar que estos cambios cumplen las expectativas previstas y no deterioran la calidad de los otros servicios prestados.
* Estrategia empresarial: la dirección puede decidir una redirección estratégica que puede afectar, por ejemplo, a los niveles de servicio ofrecidos o a la implantación de un nuevo CRM, etc. y que por regla general requieren de cambios de hardware, software y/o procedimientos.
* Actualizaciones de software de terceros: los proveedores pueden dejar de soportar versiones anteriores de paquetes de software o introducir nuevas versiones con grandes mejoras que recomienden la actualización.
* Imperativo legal: un cambio de legislación (como, por ejemplo, la LOPD) puede exigir cambios en la infraestructura TI.
* Otro: en principio cualquier empleado, cliente o proveedor puede sugerir mejoras en los servicios que pueden requerir cambios en la infraestructura.

No siempre un cambio implica una RFC. Para cambios de escasa importancia o que se repiten periódicamente pueden acordarse procedimientos estándar que no requiera la aprobación de la Gestión de Cambios en cada caso.


Aceptación

Tras el registro del RFC se debe evaluar preliminarmente su pertinencia. Una RFC puede ser simplemente rechazada si se considera que el cambio no esta justificado o se puede solicitar su modificación si se considera que algunos aspectos de la misma son susceptibles de mejora o mayor definición. En cualquiera de los casos la RFC debe ser devuelta al departamento o persona que la solicito con el objetivo de que se puedan realizar nuevas alegaciones a favor de dicha RFC o para que pueda ser consecuentemente modificada.

La aceptación del cambio no implica su posterior aprobación por el CAB y es sólo indicación de que se ha encontrada justificado su ulterior procesamiento.


Clasificación

Tras su aceptación se deben asignar a la RFC una prioridad y categoría dependiendo de la urgencia y el impacto de la misma.

La prioridad determinará la importancia relativa de esta RFC respecto a otras RFCs pendientes y será el dato relevante para establecer el calendario de cambios a realizar.

La categoría determina la dificultad e impacto de la RFC y será el parámetro relevante para determinar la asignación de recursos necesarios, los plazos previstos y el nivel de autorización requerido para la implementación del cambio.

Aunque el rango de posibles prioridades pueda ser tan amplio como se desee se debería considerar una clasificación que incluyera, al menos, los siguientes niveles de prioridad:

* Baja: puede ser conveniente realizar este cambio junto a otros cuando, por ejemplo, se decidan actualizar ciertos paquetes de software o se compre nuevo hardware, etc.
* Normal: Es conveniente realizar el cambio pero siempre que ello no entorpezca algún otro cambio de más alta prioridad.
* Alta: un cambio que debe realizarse sin demora pues esta asociado a errores conocidos que deterioran apreciablemente la calidad del servicio. El CAB debe evaluar este cambio en su próxima reunión y adoptar las medidas pertinentes que permitan una pronta solución.
* Urgente: es necesario resolver un problema que esta provocando una interrupción o deterioro grave del servicio. Un cambio de prioridad urgente desencadena un proceso denominado cambio de emergencia que trataremos de forma independiente.

La determinación de la categoría se basa en el impacto sobre la organización y el esfuerzo requerido para su implementación. El abanico de posibilidades incluye desde cambios que apenas requieren la participación del personal TI y que apenas modifican la calidad del servicio hasta cambios que necesiten grandes recursos y requieran de la aprobación directa de la Dirección.

Los cambios menores pueden no necesitar la aprobación del CAB y ser implementados directamente. Cualquier otro cambio habrá de ser discutido en el CAB y se habrá de solicitar la colaboración de personal especializado para realizar tareas de asesoramiento.

Aprobación y Planificación
La planificación es esencial para una buena gestión del cambio.
Los sistemas de gestión de la información son muy susceptibles a los cambios de configuración por las sofisticadas interrelaciones entre todos los CIs involucrados. Un cambio aparentemente menor puede desencadenar una reacción en cadena con resultados catastróficos. Es imprescindible, como mínimo, disponer siempre de planes de "back out" que permitan la recuperación de la última configuración estable antes del cambio. Pero esto obviamente no es suficiente.
En primer lugar el CAB debe reunirse periódicamente para analizar y eventualmente aprobar los RFCs pendientes y elaborar el FSC o calendario del cambio correspondiente.
Para su aprobación el cambio se debe evaluar minuciosamente:

• ¿Cuáles son los beneficios esperados del cambio propuesto?
• ¿Justifican esos beneficios los costes asociados al proceso de cambio?
• ¿Cuáles son los riesgos asociados?
• ¿Disponemos de los recursos necesarios para llevar a cabo el cambio con garantías de éxito?
• ¿Puede demorarse el cambio?
• ¿Cuál será el impacto general sobre la infraestructura y la calidad de los servicios TI?
• ¿Puede el cambio afectar los niveles establecidos de seguridad TI?

En el caso de cambios que tengan un alto impacto debe también consultarse a la dirección pues pueden entrar en consideración aspectos de carácter estratégico y de política general de la organización.
Una vez aprobado el cambio (en caso contrario se seguiría el proceso ya descrito para el caso de no aceptación) debe evaluarse si este ha de ser implementado aisladamente o dentro de un "paquete de cambios" que formalmente equivaldrían a un solo cambio. Esto tiene algunas ventajas:

• Se optimizan los recursos necesarios.
• Se evitan posibles incompatibilidades entre diferentes cambios.
• Sólo se necesita un plan de back-out.
• Se simplifica el proceso de actualización de la CMDB y la revisión post-implementación.

Implementación
Aunque la Gestión de Cambios NO es la encargada de implementar el cambio, algo de lo que se encarga habitualmente la Gestión de Versiones, si lo es de supervisar y coordinar todo el proceso.
En la fase de desarrollo del cambio se deberá monitorizar el proceso para asegurar que:

• Tanto el software desarrollado como el hardware adquirido se ajustan a las especificaciones predeterminadas.
• Se cumplen los calendarios previstos y la asignación de recursos es la adecuada.
• El entorno de pruebas es realista y simula adecuadamente el entorno de producción.
• Los planes de "back-out" permitirán la rápida recuperación de la última configuración estable.

Si es posible, debe permitirse el acceso restringido de usuarios al entorno de pruebas para que realicen una valoración preliminar de los nuevos sistemas en lo que respecta a su:

• Funcionalidad.
• Usabilidad.
• Accesibilidad.

La opinión de los usuarios debe ser tomada en cuenta y la RFC debe ser revisada en caso de que se encuentren objeciones justificadas al cambio (debe tenerse en cuenta la resistencia habitual al cambio por parte de cierto tipo de usuarios).
Los clientes y proveedores no deben percibir el cambio como algo inesperado. Es función tanto de la Gestión de Cambios como del Service Desk mantener informados a los usuarios de los futuros cambios y, dentro de lo posible, hacerles participes del mismo:

• Escuchando sus sugerencias.
• Comunicando las ventajas asociadas.
• Aclarando sus dudas y dando soporte cuando ello sea necesario: la percepción de mejora debe ser compartida por usuarios y clientes.

Evaluación

Antes de proceder al cierre del cambio es necesario realizar una evaluación que permita valorar realmente el impacto del mismo en la calidad del servicio y en la productividad de la organización.
Los aspectos fundamentales a tener en cuenta son:

• ¿Se cumplieron los objetivos previstos?
• En que medida se aparto el proceso de las previsiones realizadas por la Gestión de Cambios.
• ¿Provocó el cambio problemas o interrupciones del servicio imprevistas?
• ¿Cuál ha sido la percepción de los usuarios respecto al cambio?
• ¿Se pusieron en marcha los planes de "back-out" en alguna fase del proceso?¿Por qué?

Si la evaluación final determina que el proceso y los resultados han sido satisfactorios se procederá al cierre de la RFC y toda la información se incluirá en la PIR asociada.
Cambios de Emergencia
Aunque habitualmente los cambios realizados mediante procedimientos de emergencia son resultado de una planificación deficiente a veces resultan inevitables.
Cualquier interrupción del servicio de alto impacto, ya sea por el número de usuarios afectados o porque se han visto involucrados sistemas o servicios críticos para la organización, debe encontrar una respuesta inmediata. Es frecuente que la solución al problema requiera un cambio y que éste haya de realizarse siguiendo un procedimiento de urgencia.
El procedimiento a seguir en estos casos debe estar debidamente previsto. Por ejemplo, se deben establecer protocolos de validación de los cambios urgentes que pueden requerir:

• La reunión urgente del CAB y/o EC si esto fuera posible.
• Una decisión del Gestor del Cambio si es imposible demorar la resolución del problema o éste sucede durante un fin de semana o periodo vacacional (lo que puede dificultar la reunión del EC).

Como el objetivo prioritario en estos casos es restaurar el servicio es a menudo frecuente que los procesos asociados sigan un orden inverso al usual: tanto los registros en la CMDB como la documentación asociada al cambio se realicen a posteriori.
Es, sin embargo, esencial que al cierre del cambio de emergencia se disponga de la misma información de la que dispondríamos tras un cambio normal. Si esto no fuera así se podrían provocar situaciones de cambios futuros incompatibles, configuraciones registradas incorrectas, etc. que serían fuente de nuevas incidencias y problemas.
Control del Proceso
Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Cambios.
Para que estos informes ofrezcan una información precisa y de sencilla evaluación es imprescindible elaborar métricas de referencia que cubran aspectos tales como:

• RFCs solicitados.
• Porcentaje de RFCs aceptados y aprobados.
• Número de cambios realizados clasificados por impacto y prioridad y filtrados temporalmente.
• Tiempo medio del cambio dependiendo del impacto y la prioridad
• Número de cambios de emergencia realizados.
• Porcentaje de cambios exitosos en primera instancia, segunda instancia, etc.
• Numero de back-outs con una detallada explicación de los mismos.
• Evaluaciones post-implementación.
• Porcentajes de cambios cerrados sin incidencias ulteriores.
• Incidencias asociadas a cambios realizados.
• Número de reuniones del CAB con información estadística asociada: número de asistentes, duración, nº de cambios aprobados por reunión, etc.

Por ultimo un ciclo de Gestion de Cambios en el cual participe y sus diferentes etapas :

Jueves :

Hasta este dia hay tiempo de enviar un RFC

Se realiza un preanalisis del RFC por parte del analista de Cambios y en caso de falta de informacion se devuelve

Jueves y Viernes

Se realiza analisis Tecnico de los cambios por parte de las partes envolvidas,

Lunes

Se realiza la reunion de Comite de Cambios donde se analizan las modificaciones a implementar
Aqui pueden rechazarse las modificaciones por tener impacto en el negocio o por riesgos asociados a la implementacion. Se genera un acta.


Martes

Se realiza las pruebas en homologacion, si existen errores se cierra la modificacion.

Miercoles a Domingo

Se implementan las modificaciones previamente acordadas.



Para los emergenciales, se reunen los responsables de produccion, ya que solo se implementan cuando un prob

Falsos Negativos, la reorganizacion de una sala de servers y mi nueva notebook

Despues de bastane tiempo, algunas cosas interesantes para comentar.
Esta semana viaje a Sao Pablo, fui a cerrar un par de temas personales y a reunirme con antiguos compañeros de trabajo con los cuales quedo una amistad.
El vuelo hacia Brasil fue bastante tranquilo, hasta que abri mi mochila y encontre lo que ven en la fotografia siguiente :

En la foto puede verse desde tornillos, precintos, mechas de 8mm hasta una broca de 13mm la cual tiene un tamaño mas que considerable, si la comparamos con un lapiz como en la siguiente foto, podemos tener una idea del tamaño.

Todo eso, paso por el sistema de rayos X de Aeroparque en mi mochila.
No es que yo quise inconcientemente secuestrar un avion, el fin de semana largo, estube reorganizando una sala pequeña de servidores, donde ya era imposible ingresar y hacer cualquier tarea sin correr peligro de quedar electrocutado o hacer caer la red.

En la foto siguientes se puede ver el estado de esta salita ( de unos 2m x 1,5m ) antes del trabajo. El descontrol  era tridimensional, ya que por ejemplo la central telefonica contra la pared era una maraña de capas de cables.

Yo diria que eran capas geologicas de cables, ya que diferentes personas hicieron diferentes cableados y se
fueron acumulando, desde cables telefonicos, de video y de red.


En esta foto podemos ver como quedo la sala, se instalo un rack abierto con el cableado telefonico y de datos.

Los servers van a colocarse en estantes, por el momento no hubo tiempo de terminar esta parte, pero en los proximos dias voy a finalizar esto.

Con motivo de este trabajo, es que quedaron las herramientas que pasaron tranquilamente por el sistema de seguridad de Aeroparque.

Las preguntas que me surgen son las siguientes :

Lo habran visto y consideraron que no era peligroso ?

No lo vieron ?

La notebook los tapo ? ( En muchos aeropuertos, piden quitar las notebooks del bolso ya que aparentemente
el material de las pantallas actua como un bloqueador de los rayos X )

Como veran, este es un ejemplo de un falso negativo, una amenaza que no es detectada aun teniendo los sistemas adecuados, queda la duda si fue un error humano o del equipo.

Les comente de la notebook que llevaba en la mochila, bueno esta es mi nueva adquisicion, una Thinkpad T410. Procesador i5, 4GB de memoria y 320GB de disco. Esta maquina es lo suficientemente fuerte y robusta como para soportar mi ritmo de trabajo.

Incluso en este video se ve la prueba del agua, ( algo que no pienso probar en casa ), donde una T410 sigue
funcionando normalmente mientras un base de agua se escurre por su teclado.



Se el feliz poseedor de este equipo es fracias a Guillermo de ALT-TAB quien me paso el dato de una oferta dificil de rechazar. Gracias Guille !!!

Proximo paso, es instalar Ubuntu.