Gestión de cambios

Un cambio es cualquier modificación de la infraestructura IT: instalación, actualización, configuración, retiro. La gestión de cambios busca minimizar los riesgos asociados a estas modificaciones.

¿Por qué gestionar los cambios?

• Prevenir incidentes: Muchos incidentes son causados por cambios mal planificados
• Trazabilidad: Saber quién modificó qué y cuándo
• Coordinación: Evitar conflictos entre cambios simultáneos
• Comunicación: Informar a los usuarios de los mantenimientos

Ejemplos de cambios

• Actualización de un servidor
• Despliegue de una nueva aplicación
• Modificación de reglas de firewall
• Reemplazo de un equipo de red
• Migración de base de datos

KaliaOps distingue 3 tipos de cambios según el nivel de riesgo y el proceso de aprobación:

Cambio Standard

Cambio pre-aprobado, de bajo riesgo, siguiendo un procedimiento establecido.

• Aprobación: Automática (pre-aprobado)
• Ejemplos: Reset de contraseña, añadir usuario, instalación de software estándar
• Proceso: Ejecución directa sin CAB

Cambio Normal

Cambio que necesita una evaluación y aprobación por el CAB.

• Aprobación: CAB (Change Advisory Board)
• Ejemplos: Actualización de servidor, modificación de red, nuevo despliegue
• Proceso: Análisis de impacto, envío al CAB, planificación

Cambio Emergency

Cambio urgente que necesita un procedimiento acelerado.

• Aprobación: ECAB (Emergency CAB) o aprobación del manager
• Ejemplos: Parche de seguridad crítico, corrección de incidente mayor
• Proceso: Fast-track con documentación a posteriori

El workflow de gestión de cambios tiene 11 estados:

Diagrama

BORRADOR → ENVIADO → PENDIENTE APROBACIÓN → APROBADO → PLANIFICADO → EN CURSO → TERMINADO → CERRADO
                            ↓                                         ↓
                         RECHAZADO                                   FALLIDO
                            ↓
                        CANCELADO

Descripción de los estados

El CAB (Change Advisory Board) es la instancia de aprobación de cambios normales.

Composición del CAB

Típicamente:

• Responsable de cambios (Change Manager)
• Representantes técnicos (Infraestructura, Aplicaciones)
• Representantes de negocio (si impacto en usuarios)
• Responsable de seguridad (si aplica)

Enviar al CAB

1. Desde un cambio en borrador, haga clic en «Enviar»
2. El cambio pasa a estado «Enviado»
3. Haga clic en «Solicitar aprobación CAB»
4. Indique la fecha de reunión CAB deseada

Decisiones CAB

El CAB puede decidir:

• Approved: Cambio aprobado, puede planificarse
• Rejected: Cambio rechazado (con motivo)
• Deferred: Aplazado, información complementaria requerida

Trazabilidad CAB

Cada decisión CAB se registra con:

• Fecha de la decisión
• Decisión tomada
• Notas y comentarios
• Usuario que registró la decisión

Ventana de mantenimiento

Después de la aprobación, defina la ventana de implementación:

1. Haga clic en «Planificar»
2. Defina:
   • Fecha/hora de inicio planificada
   • Fecha/hora de fin planificada
3. El cambio pasa a estado «Planificado»

Buenas prácticas de planificación

• Evite horas punta: Prefiera horarios de baja utilización
• Coordine cambios: Evite conflictos con otros mantenimientos
• Prevea un margen: El tiempo real suele superar el previsto
• Comunique: Informe a los usuarios afectados

Calendario de cambios

El calendario muestra todos los cambios planificados, permitiendo:

• Visualizar las ventanas de mantenimiento
• Identificar conflictos potenciales
• Planificar los recursos

El plan de rollback describe el procedimiento de vuelta atrás en caso de fallo.

Contenido del plan de rollback

• Condiciones de activación: ¿Cuándo activar el rollback?
• Procedimiento detallado: Pasos para volver al estado inicial
• Puntos de control: Verificaciones en cada paso
• Duración estimada: Tiempo necesario para el rollback
• Responsable: ¿Quién activa y ejecuta el rollback?

Ejemplos de activadores

• Pruebas post-cambio fallidas
• Incidente mayor detectado
• Tiempo de indisponibilidad superado
• Rendimiento degradado más allá del umbral aceptable

Importancia del rollback

Un cambio sin plan de rollback es un riesgo no controlado. Los cambios de riesgo alto o crítico nunca deben aprobarse sin un plan de vuelta atrás documentado y probado.

Iniciar la implementación

1. En la fecha planificada, haga clic en «Iniciar»
2. El cambio pasa a estado «En curso»
3. La fecha de inicio real se registra

Durante la implementación

• Siga el plan de implementación paso a paso
• Documente las desviaciones eventuales
• Ejecute las pruebas de validación

Terminar el cambio

1. Haga clic en «Terminar»
2. Redacte las notas de finalización: resumen de la implementación
3. Confirme

El cambio pasa a estado «Terminado». La fecha de fin real se registra.

Cerrar

Después de un período de observación (verificación de que no han surgido incidentes):

1. Haga clic en «Cerrar»
2. Seleccione el código de cierre
3. El cambio se archiva

Declarar un fallo

Si la implementación falla:

1. Ejecute el plan de rollback
2. Haga clic en «Marcar como fallido»
3. Documente la razón del fallo
4. El cambio pasa a estado «Fallido»

Análisis post-mortem

Después de un fallo, analice:

• Causa del fallo: ¿Técnica, planificación, comunicación?
• Eficacia del rollback: ¿Funcionó como estaba previsto?
• Lecciones aprendidas: ¿Cómo evitar este fallo en el futuro?

Change Success Rate

La tasa de éxito de cambios es un indicador clave:

CSR = (Cambios exitosos / Total cambios) × 100

Objetivo: > 95%

Un CSR bajo indica problemas de proceso o preparación.

KaliaOps detecta automáticamente las correlaciones entre cambios e incidentes.

Correlación automática

El sistema identifica los incidentes ocurridos poco después de un cambio:

• Incidentes en los X minutos siguientes a un cambio
• Incidentes en los mismos activos/aplicaciones que el cambio

Tabla de correlación

Cada correlación registra:

• Cambio e Incidente vinculados
• Tiempo entre el cambio y el incidente
• Fuerza de correlación: Baja, Media, Alta
• Activos/Aplicaciones comunes
• Confirmación: Correlación confirmada o no

Uso

• Investigación de incidentes: «¿Ha habido un cambio reciente?»
• Análisis de cambios: «¿Este cambio ha causado incidentes?»
• Mejora continua: Identificar los tipos de cambios de riesgo

Confirmar una correlación

Durante la investigación de un incidente:

1. Consulte las correlaciones sugeridas
2. Si el cambio es la causa, confirme la correlación
3. Documente para el análisis post-mortem