Dos actualizaciones la misma noche, un parche dentro del cierre de mes y un P1 dos horas después de un cambio con éxito: el calendario de cambios antes del CABTwo upgrades on the same night, a patch inside the month-end freeze and a P1 two hours after a successful change: the change calendar before the CAB

El problema

El calendario de cambios de la herramienta de ITSM es una lista, y el CAB aprueba cada cambio por separado. Lo que la lista no enseña es cómo se relacionan los cambios entre sí y con el resto del mes: los cortafuegos del centro de datos y los switches del núcleo actualizados la misma noche por dos equipos distintos, ambos en el camino de la plataforma de trading; un parche de base de datos de la plataforma de trading programado dentro de la congelación del cierre de mes; un cambio de riesgo alto dado de alta dos días antes de su ventana y sin plan de marcha atrás; una actualización de firmware del almacenamiento de servicios críticos registrada como cambio estándar, así que nunca llega al CAB; un equipo que cada mes abre más emergencias por los mismos motivos; y un cambio cerrado con éxito dos horas antes de un P1 en la apertura del mercado, sin revisión posterior programada. La otra mitad del trabajo es la revisión de después, que enlaza con el kit de incidentes mayores que publiqué hace unos días: el incidente que sigue a un cambio es donde debería empezar la revisión del cambio.

Qué he hecho

• Preparación para el CAB: cambios sin plan de marcha atrás, de pruebas o de implementación, con el riesgo sin evaluar o por debajo de lo que indican el impacto y el nivel del servicio, dados de alta dentro del plazo mínimo, sin aprobar cuando empiezan antes del CAB, sin responsable o fuera de la ventana de mantenimiento de su nivel.
• Coincidencias: cambios que se solapan en el mismo elemento de configuración o servicio, cambios que afectan a los mismos servicios críticos a través de las dependencias, demasiados cambios de un equipo en una noche y cambios dentro de una congelación o un periodo de bloqueo sin una excepción aprobada.
• Cambios de emergencia y estándar: el porcentaje de emergencias por mes y sus motivos, cambios estándar usados para trabajos con riesgo y emergencias que nunca se aprobaron después.
• Resultados y equipos: la tasa de éxito del mes pasado y su evolución, cambios fallidos, incidentes vinculados a un cambio o abiertos en el mismo servicio pocas horas después, cambios que se pasaron de su ventana, trabajos sin autorizar, revisiones posteriores pendientes, y los equipos con poca tasa de éxito o con emergencias en aumento.
• report.html con un calendario de dos semanas por día y servicio donde destacan las coincidencias, las congelaciones y los huecos, un estado por área y un veredicto global; cab-pack.md con el orden del día del CAB y la revisión mensual; CSV de cada área; y un exportador de solo lectura en PowerShell para la Table API de ServiceNow (cambios, incidentes, aprobaciones y el mapa de servicios).

Cómo está hecho

Python solo con la librería estándar. La demo es un banco inventado con sala de trading, revisado un lunes por la mañana antes del CAB: 16 servicios de negocio en tres niveles con sus dependencias, 263 peticiones de cambio de nueve equipos (tres meses de histórico y las dos próximas semanas), las aprobaciones, los incidentes y un registro de congelaciones con el cierre de mes y un rebalanceo de índices, con los problemas puestos a propósito. El impacto de cada cambio se calcula a través del mapa de dependencias, así que un cambio en la red troncal coincide con cualquier otro en los servicios que dependen de ella. 15 tests, un runbook para el CAB semanal y la revisión mensual de cambios, y un workflow de GitHub Actions que ejecuta los tests y regenera los datos de la demo y la captura.

Qué aprendí

De ser responsable de los procesos de incidentes, cambios y problemas y de participar en CAB y en revisiones de puesta en producción y aceptación del servicio; de la gestión de versiones, con su planificación, pruebas, marcha atrás y validación después de cada versión; de escribir procedimientos y runbooks de estos procesos y formar a otros para usarlos; de dirigir la respuesta técnica en incidentes mayores y los análisis posteriores; y de ServiceNow, EasyVista y HaloITSM, Jira y Confluence. Las lecciones que dan forma a la herramienta son que dos cambios en el mismo camino la misma noche suponen dos planes de marcha atrás para un solo síntoma; que el impacto de un cambio va por las dependencias, no por el nombre del servicio que pone el formulario; que el plazo mínimo es el tiempo que tienen otros para revisarlo; que un cambio estándar está preaprobado porque es rutinario, y una actualización de firmware del almacenamiento crítico no lo es; que las emergencias repetidas son un problema esperando a que alguien lo registre; y que un cambio seguido de un P1 no es un éxito, se cierre como se cierre.

Siguientes pasos

• Leer el calendario de cambios desde la API de forma programada, para que el informe del CAB esté listo el lunes por la mañana sin exportaciones.
• Leer las congelaciones desde los calendarios de bloqueo de la herramienta de ITSM en lugar de un CSV.
• Comparar cada semana con la anterior: cambios movidos, coincidencias resueltas y revisiones cerradas.

¿Quieres llevarlo a tu entorno o adaptarlo a tu caso? Escríbeme y lo vemos.