Es jueves por la tarde y el gestor de cambios está revisando un cambio en un clúster de bases de datos. La fecha propuesta parece adecuada. Lo que nadie nota es que una actualización del almacenamiento debajo del mismo clúster está programada para esa misma noche, que la aplicación afectada solo tiene una ventana de mantenimiento los domingos por la mañana, y que se está ejecutando el cierre de mes, un período en el que no se debe tocar la producción en absoluto. Todo esto está escrito en algún lugar. Solo que no en un lugar.
Cualquiera que haya gestionado operaciones sabe cómo termina esto: una llamada telefónica temprana, un propietario del servicio ansioso y un equipo explicando por qué dos cambios chocaron en lugar de hacer el trabajo que habían planeado. Esto rara vez se trata de descuido. Se trata de que las reglas para tocar la producción no son lo suficientemente visibles para las personas que planifican cambios.
Por qué las hojas de cálculo y la buena voluntad no son suficientes
A menudo vemos ventanas de mantenimiento registradas en contratos o documentación de servicio, congelaciones anunciadas por correo electrónico y colisiones detectadas por un colega experimentado que "sabe qué está sucediendo dónde". Esto funciona mientras el volumen de cambios sea bajo y ese colega no esté de vacaciones.
Los puntos débiles son predecibles:
- la ventana de mantenimiento pertenece al servicio, pero el cambio se planifica en un servidor, por lo que alguien tiene que trazar el enlace manualmente,
- se anuncia una congelación pero nunca se hace cumplir,
- se encuentran dos cambios en infraestructura compartida que chocan solo cuando alguien revisa el calendario, si es que lo hace,
- se ejecutan cambios grandes en muchos elementos de una vez, porque una implantación gradual es difícil de planificar.
Cómo abordarlo
La idea central es simple: las reglas deben ser datos, no conocimiento tribal. Una ventana de mantenimiento pertenece a un servicio y debe ser rastreable desde cada elemento del que depende el servicio. Una congelación es un período en el que el sistema no aceptará una fecha de cambio en absoluto. Las colisiones deben ser evaluadas durante la planificación, no detectadas a simple vista.
Es igualmente importante admitir que no todas las situaciones se ajustan a reglas estrictas. Cuando se introduce un nuevo proceso o en una organización que nunca ha definido ventanas de mantenimiento, una excepción deliberada y rastreable es mejor que reglas que todos trabajan alrededor.
Cómo lo maneja Eywo Stratum
En Eywo Stratum, un cambio está vinculado a elementos de la CMDB y, a través del mapa de dependencias, a los servicios que se ejecutan en ellos. Antes de que se envíe un cambio para su aprobación, el sistema calcula su impacto: qué servicios y aplicaciones estarán inactivos o degradados.
Las reglas de programación se basan en ese cálculo:
- ventanas de mantenimiento – un cambio solo se puede programar dentro de las ventanas de los servicios afectados,
- congelaciones de cambios – un cambio no se puede programar durante una congelación,
- colisiones – el sistema señala otros cambios que se superponen en tiempo y alcance,
- ejecución continua – un cambio se puede realizar elemento por elemento, por lo que un servicio redundante no tiene que estar inactivo en su totalidad.
Cada cambio aparece en el calendario de cambios, donde el gestor de cambios y los propietarios del servicio pueden ver qué está sucediendo y cuándo. El propietario del servicio afectado aprueba el tiempo de inactividad y, dependiendo del modelo de cambio, también lo hacen el gestor de cambios o el CAB. Los cambios estándar preaprobados se mueven rápidamente; los cambios normales y de emergencia tienen sus propios pasos y tiempo de entrega.
Para el período de implantación, Eywo Stratum ofrece un modelo de "cambio sin ventana de mantenimiento". Esto permite a una organización comenzar a registrar y aprobar cambios antes de que cada servicio tenga una ventana definida. La excepción permanece visible y rastreable, y una vez que existen las ventanas, los equipos cambian a los modelos estándar.
Calma en lugar de improvisación
Las ventanas de mantenimiento y las congelaciones no son burocracia. Son acuerdos entre operaciones y las personas que dependen de un servicio. Cuando el sistema las hace cumplir, el gestor de cambios puede enfocarse en la sustancia de un cambio en lugar de buscar calendarios, y los ingenieros comienzan su turno nocturno sabiendo que nadie más está trabajando en la misma infraestructura. Todos pueden irse a casa con la cabeza más clara.
Las ventanas de mantenimiento, congelaciones, comprobaciones de colisiones y el calendario de cambios están incluidos en la edición estándar.
Eywo Stratum Standard
Para organizaciones que desean una CMDB fiable y procesos de ITSM gestionados.