Workflow del proceso de la gestión de cambios

La gestión de cambios es el proceso de gestión de una petición de cambio durante el ciclo de vida de la solicitud. La gestión de cambios garantiza que se utilizan los procedimientos y métodos normalizados para el tratamiento de los cambios.

Las tecnologías están cambiando a un ritmo muy rápido y es necesario que las ofertas de servicios de TI se adapten a estos cambios. Los cambios que no están bien planificados pueden generar problemas. Por lo tanto, es necesario un enfoque gestionado y controlado adecuadamente en relación con el cambio en los servicios y sistemas de TI. 

La gestión de cambios pretende minimizar todas interrupciones no deseadas en el servicio de TI existente provocadas por la implementación de los cambios. La gestión de cambios implila configuración de un proceso para gestionar cambios y garantizar lo siguiente:ca

• El cambio se clasifica mediante un tipo de cambio adecuado y se debe procesar mediante un workflow para ese tipo de cambio.
• El cambio se envía mediante un proceso de aprobación de cambios adecuado y específico para el tipo de cambio.
• El cambio se implementa según un proceso definido con tareas para garantizar que todos los aspectos del cambio se implementan.
• La implementación del cambio se revisa para asegurarse de que el riesgo global del negocio se minimiza. La implementación del cambio también garantiza que el cambio se registra en todos los sistemas relacionados antes del cierre.  

Cloud Service Management proporciona seis workflows de proceso de la gestión de cambios predefinidos:   

El estado de los workflows de proceso de la gestión de cambios predeterminados es:

• Flujo de proceso de la gestión de cambios normales predeterminado: Publicado.
• Flujo de proceso de la gestión de cambios estándar predeterminado: Publicado.
• Flujo de proceso de la gestión de cambios de emergencia predeterminado: Publicado.
• Flujo de proceso de la gestión de cambios de reparación predeterminado: Publicado.
• Flujo de proceso de la gestión de cambios principal: Borrador.
• Flujo de proceso de gestión de cambios DevOps: Borrador.

Flujo de proceso de la gestión de cambios normales predeterminado

El flujo de proceso de la gestión de cambios normales predeterminado define el workflow de proceso básico de una solicitud que está relacionada con un cambio normal. El proceso predeterminado se aplica cuando una solicitud no coincide con los criterios de entrada de otros workflows de proceso de cambio que están activos.

En el siguiente diagrama se muestra el proceso de la gestión de cambios normal predeterminado:

Los siguientes pasos explican cómo funciona el flujo de proceso de la gestión de cambios normales predeterminado:

1. Cuando se genera un ticket, en función de las condiciones de coincidencia se verificarán los criterios de entrada para asignar la solicitud. De forma predeterminada, la solicitud se asigna al grupo Gestión de cambios cuando no coincide ninguna condición.
2. El Coordinador de cambios valora y evalúa la solicitud y envía la solicitud para que la apruebe el gestor.
3. El gestor realiza una de las siguientes acciones en la solicitud:
   • Aprobar: la solicitud se asigna al Comité asesor de cambios (CAB) para evaluación. 
   • Rechazar: la solicitud se reasigna al Coordinador de cambios para la reevaluación o se cierra la solicitud.
4. El CAB evalúa la solicitud con una de las siguientes acciones:
   
   • Aprobar mediante todos los aprobadores: todos los miembros del CAB aprueban la solicitud.
   • Aprobar o rechazar mediante un aprobador: uno de los miembros del CAB aprueba la solicitud.
   • Aprobar urgentemente mediante todos los aprobadores: - la solicitud se envía para que el CAB la apruebe urgentemente.
     Nota: El gestor puede retirar la solicitud de la aprobación del CAB y puede cerrar la solicitud durante la fase de aprobación.
5. Cuando el CAB lo aprueba, el cambio se implementa. Si no, el CAB propone una aprobación con modificaciones en la petición de cambio. 

Flujo de proceso de la gestión de cambios estándar predeterminado

El flujo de proceso de la gestión de cambios estándar predeterminado define el workflow de proceso básico de una solicitud que está relacionada con un cambio normal. Por ejemplo, solicitudes como aplicar un service pack, aplicar un pack normal y agregar un servidor para el entorno de prueba. El proceso predeterminado se aplica cuando una solicitud no coincide con los criterios de entrada de otros workflows de proceso de cambio que están activos.

En el siguiente diagrama se muestra el proceso de la gestión de cambios estándar predeterminado:

Los siguientes pasos explican cómo funciona el flujo de proceso de la gestión de cambios estándar predeterminado:

1. Cuando se genera una petición de cambio, en función de las condiciones de coincidencia se verificarán los criterios de entrada para asignar la solicitud. De forma predeterminada, la solicitud se asigna al grupo Gestión de cambios cuando no coincide ninguna condición.
2. El Coordinador de cambios evalúa y envía la solicitud para la aprobación desde el Gestor de cambios.
   Nota: El Coordinador de cambios puede retirar la solicitud de la aprobación del gestor para modificar la solicitud. Después de las modificaciones, el Coordinador de cambios vuelve a enviar la solicitud para la aprobación del gestor.  
3. El Gestor de cambios lleva a cabo una de las siguientes acciones:
   • Aprobar: la solicitud se implementa y se cierra como correcta.
   • Rechazar: se ha producido un fallo en la solicitud y se ha cerrado con excepciones. 

Flujo de proceso de la gestión de cambios de emergencia predeterminado

El flujo de proceso de la gestión de cambios de emergencia predeterminado define el workflow de proceso básico de una solicitud que está relacionada con un cambio de emergencia. Por ejemplo, las solicitudes para corregir el tiempo de inactividad del entorno de producción y el tiempo de inactividad de la red. El proceso predeterminado se aplica cuando una solicitud no coincide con los criterios de entrada de otros workflows de proceso de cambio que están activos.

En el siguiente diagrama se muestra el proceso de la gestión de cambios de emergencia predeterminado:

Los siguientes pasos explican cómo funciona el flujo de proceso de la gestión de cambios de emergencia predeterminado:

1. Cuando se genera una petición de cambio, en función de las condiciones de coincidencia se verificarán los criterios de entrada para asignar la solicitud. De forma predeterminada, la solicitud se asigna al grupo Gestión de cambios cuando no coincide ninguna condición.
2. El Coordinador de cambios realiza una de las siguientes acciones:
   • Aprobar para la implementación: el Coordinador de cambios aprueba la solicitud para la implementación.
   • Enviar para aprobación del ECAB (todos los aprobadores): todos los miembros del ECAB aprueban la solicitud. 
   • Enviar para aprobación del ECAB (cualquier aprobación o rechazo): uno de los miembros del ECAB aprueba la solicitud.
3. El Gestor de cambios o el Comité asesor de cambios de emergencia (ECAB) realiza una de las siguientes acciones:
   • Aprobar: la solicitud se implementa y se cierra como correcta.
   • Rechazar: se ha producido un fallo en la solicitud y se ha cerrado con excepciones. 

Flujo de proceso de la gestión de cambios de reparación predeterminado

El flujo de proceso de la gestión de cambios de reparación predeterminado se aplica cuando una solicitud necesita corregir un cambio pequeño. El proceso predeterminado se aplica cuando una solicitud no coincide con los criterios de entrada de otros workflows de proceso de cambio de reparación que están activos.

En el siguiente diagrama se muestra el proceso de la gestión de cambios de reparación predeterminado:

Los siguientes pasos explican cómo funciona el flujo de proceso de la gestión de cambios de reparación predeterminado:

1. Cuando se genera una petición de cambio, en función de las condiciones de coincidencia se verificarán los criterios de entrada para asignar la solicitud. De forma predeterminada, la solicitud se asigna al grupo Gestión de cambios cuando no coincide ninguna condición.
2. El Coordinador de cambios envía la solicitud para la revisión de la gestión de cambios.
3. Cuando se actualizan los comentarios de la revisión para la solicitud, el Coordinador de cambios verifica los comentarios y lleva a cabo una de las siguientes acciones:
   • Cerrar la petición de cambio. 
   • Volver a abrir la petición de cambio si los comentarios de la revisión no son satisfactorios. 

Flujo de proceso de la gestión de cambios principal

El flujo de proceso de la gestión de cambios principal define el workflow de proceso básico de una solicitud que está relacionada con un cambio grave. Por ejemplo, una solicitud para implementar una aplicación. El proceso predeterminado se aplica cuando una solicitud no coincide con los criterios de entrada de otros workflows de proceso de cambio que están activos.

En el siguiente diagrama se muestra el proceso de la gestión de cambios principal:

Los siguientes pasos explican cómo funciona el flujo de proceso de la gestión de cambios principal:

1. Cuando se genera una petición de cambio, en función de las condiciones de coincidencia se verificarán los criterios de entrada para asignar la solicitud. De forma predeterminada, la solicitud se asigna al grupo Gestión de cambios cuando no coincide ninguna condición.
2. El Gestor de cambios valora y evalúa la solicitud y la envía para la revisión del equipo de soporte de TI.
3. El equipo de soporte de TI evalúa y envía la solicitud para que el Comité asesor de cambios (CAB) la apruebe. El CAB realiza una de las siguientes acciones:
   • Aprobar: el CAB revisa el plan de implementación y lo envía al equipo de implementación para la implementación. 
   • Rechazar: la solicitud se reasigna al Coordinador de cambios para la reevaluación o se cierra la petición de cambio.
     Nota: El equipo de soporte de TI puede retirar la solicitud de aprobación del CAB y puede reasignarla al Gestor de cambios. 
4. El equipo de implementación realiza una de las siguientes acciones en la solicitud:
   
   • Aprobar: el cambio se implementa y se cierra la solicitud. De forma opcional, si varios equipos están implicados en el proceso de implementación, se crea un proyecto. Si se produce un fallo en la implementación, se volverá a abrir la solicitud y el proceso se repite del paso 2 hasta que se implementa un cambio. 
   • Rechazar: la solicitud se vuelve a abrir y se repite el proceso desde el paso 2 hasta que se implementa un cambio.

Flujo de proceso de gestión de cambios de DevOps

El flujo de proceso de gestión de cambios define el workflow de proceso básico de una solicitud que está relacionada con un cambio de DevOps. Por ejemplo, una solicitud para implementar un cambio en la aplicación de la versión. El proceso predeterminado se aplica cuando una solicitud no coincide con los criterios de entrada de otros workflows de proceso de cambio que están activos.

El proceso de una gestión de cambios de DevOps se muestra en el siguiente diagrama:

Los pasos siguientes explican cómo funciona el flujo de proceso de gestión de cambios de DevOps:

1. Cuando se genera una petición de cambio, en función de las condiciones de coincidencia se verificarán los criterios de entrada para asignar la solicitud. De forma predeterminada, la solicitud se asigna al grupo Gestión de cambios cuando no coincide ninguna condición.
2. El grupo de coordinación de la versión valora y evalúa la solicitud. Un plan se crea para implementar la solicitud y se asigna al Comité asesor de cambios (CAB) para la aprobación.
3. En la aprobación del CAB, se realizan los siguientes pasos:
   1. Iniciar actividad de creación - Conector de SSH: inicia el script de compilación para crear el paquete de software de la versión.
   2. Comprobar estado de la compilación - script del conector de SSH: verifica si el script se ejecuta correctamente. Si se produce un fallo en la compilación, registre la compilación y cierre la solicitud con excepciones. 
   3. Iniciar actividad de prueba - Conector de SSH: invoca los scripts de prueba para verificar si el paquete del software funciona tal y como fue diseñado. 
   4. Comprobar estado de la ejecución de la prueba: conector de SSH: verifica si la prueba es correcta. Si se produce un fallo en la prueba, ejecute el plan de retroceso o actualice como fallo de prueba y cierre la solicitud con excepciones. 
   5. Iniciar implementación: ServiceAide Release Automation: invoca el script de implementación para implementar el paquete.
   6. Recuperar estado de la versión desde ServiceAide Release Automation: recopila la información sobre la versión a partir de la aplicación de la automatización de la versión. 
      Nota: Si se produce un error durante la implementación, ejecute el plan de retroceso y cierre la solicitud con excepciones.
4. La solicitud se implementa y se valida para mantener la coherencia. Se cierra la petición de cambio.