La fecha de fin de soporte para un sistema operativo se conoce con años de antelación. Los proveedores de hardware anuncian el fin de soporte con mucho tiempo de antelación. Y sin embargo, la misma escena se repite en muchas organizaciones: unos meses antes de la fecha límite, alguien descubre que decenas de servidores están ejecutando una versión no soportada, y nadie sabe exactamente qué servicios dependen de ellos.
Lo que sigue es un apresuramiento. ¿Quién es el propietario de esta aplicación? ¿Se puede actualizar el servidor o necesita una migración? ¿Quién paga por ello si nunca se presupuestó? El equipo de operaciones pasa semanas construyendo una visión general que debería haber existido desde el principio. Mientras tanto, el gerente de seguridad tiene que explicar por qué los sistemas sin actualizaciones de seguridad todavía están ejecutándose en producción.
Por qué una hoja de cálculo no es suficiente
La herramienta habitual para rastrear el ciclo de vida es una hoja de cálculo. Alguien la creó una vez, llenó las versiones de SO y las fechas de fin de soporte, y la pasó a otra persona. El problema es que una hoja de cálculo comienza a quedar obsoleta desde el momento en que se crea.
- No está vinculada a la realidad. Un servidor se actualiza o se descomisiona, y la hoja de cálculo nunca se entera.
- No está vinculada a los servicios. Lista servidores, no para qué se utilizan. Sin eso, no se puede decidir qué es lo primero.
- No tiene propietario. Cuando nadie es responsable de los datos, nadie los mantiene actualizados.
El resultado es una lista que responde a "¿qué es antiguo?" pero no a "¿qué está en riesgo y para quién?"
Cómo abordar el ciclo de vida
El ciclo de vida no es un registro separado. Es un atributo de los elementos que ya se rastrean. Si su CMDB sabe qué sistema operativo se ejecuta en un servidor y qué hardware es el servidor, todo lo que necesita agregar son las fechas de fin de soporte, y tiene una visión general que se actualiza con cada cambio.
El segundo paso es conectar el ciclo de vida con los servicios. Un servidor no soportado que transporta un servicio de negocio crítico es una prioridad muy diferente a una máquina de prueba sin dependencias. Las decisiones de renovación deben seguir el impacto del servicio, no una lista alfabética de nombres de host.
El tercer paso es mirar hacia adelante. Si puede ver qué alcanza el fin de soporte en uno o dos años, puede poner la renovación en el presupuesto, acordarla con el propietario del servicio y llevarla a cabo en una ventana de mantenimiento regular en lugar de un proyecto de emergencia.
Cómo lo maneja Eywo Stratum
Eywo Stratum rastrea el ciclo de vida de los sistemas operativos, software y hardware directamente en los elementos de la CMDB. Para cada servidor, puede ver qué versión se ejecuta y cuándo termina el soporte para esa versión. La visión general muestra servidores que ya están en versiones no soportadas, así como aquellos que se acercan a la fecha límite.
Debido a que el ciclo de vida es parte de la CMDB, los datos se mantienen actualizados. Los elementos se poblan a través de la API de descubrimiento, importación de CSV o Excel, o sincronización con una CMDB primaria. Cada cambio en un elemento tiene versión con su historial, por lo que puede ver cuándo y desde dónde cambió una versión de SO. Los controles de calidad de datos señalan inconsistencias, como un servidor sin sistema operativo registrado.
El enlace a los servicios es lo que más importa. El mapa de dependencias en capas muestra qué aplicaciones y servicios de negocio dependen de un servidor determinado. Desde la visión general de fin de soporte, puede pasar directamente a las preguntas que cuentan: ¿qué servicios están en riesgo y quién es su propietario? La planificación de renovación comienza entonces con una conversación con una persona específica sobre un servicio específico.
La renovación en sí se ejecuta como un cambio normal: un modelo de cambio, un cálculo de impacto antes de la presentación, una ranura en una ventana de mantenimiento fuera de las congelaciones de cambios y aprobación de interrupción del propietario del servicio afectado. Una actualización de SO no salta el proceso solo porque es urgente.
Conclusión
El fin de soporte no tiene que ser una lucha anual. Cuando el ciclo de vida vive en la CMDB y está conectado a los servicios, lo ve venir, sabe quién se ve afectado y la renovación se puede planificar con calma. Las operaciones no tienen que ensamblar una visión general bajo presión, y los propietarios de servicios se enteran del riesgo a tiempo.
El seguimiento del ciclo de vida para sistemas operativos, software y hardware está incluido en la edición Estándar.
Eywo Stratum Standard
Para organizaciones que desean una CMDB fiable y procesos de ITSM gestionados.