La reunión semanal de operaciones está discutiendo un reemplazo planificado de una matriz de almacenamiento. Alguien pregunta: “¿Qué servicios se verán afectados realmente?” Silencio. El administrador de almacenamiento sabe qué servidores están conectados. El equipo de virtualización tiene una buena idea de qué máquinas virtuales se ejecutan en ellos. Pero ¿quién sabe exactamente qué aplicaciones y servicios de negocio se encuentran encima, y quién necesita ser informado? La respuesta se compone a partir de varias personas y varias hojas de cálculo, y a menudo es incompleta.
La misma pregunta surge en un momento peor. La monitorización informa de un hipervisor fallido, y el servicio de asistencia no puede decir si se trata de un sistema de prueba olvidado o de un servicio del que dependen miles de personas cada mañana. La priorización se estanca, y las personas que podrían solucionar el problema pasan su tiempo averiguando qué ha fallado realmente.
Por qué el impacto rara vez se conoce a tiempo
Las organizaciones tienen conocimiento de las dependencias. Solo que está disperso. Cada equipo ve su propia capa y la entiende bien. Lo que falta es una visión que conecte las capas.
- La documentación de arquitectura se vuelve obsoleta con cada cambio, y pocas personas la mantienen actualizada.
- Una CMDB sin relaciones es solo una lista de elementos. Sin enlaces, no puede decir qué depende de qué.
- La monitorización ve componentes técnicos pero no los servicios de negocio que dependen de ellos.
- El análisis de impacto de cambios se realiza manualmente y depende de la experiencia de quien lo escribe.
El resultado es que el impacto se descubre en el momento del fallo, cuando ya es demasiado tarde para planificar o comunicarse.
Una mejor forma de pensar sobre el impacto
La clave es modelar las dependencias una vez y utilizarlas en todas partes. Si la CMDB sabe cómo se relacionan las capas, desde el servicio de negocio hasta la aplicación, la base de datos y el servidor hasta el hipervisor, el almacenamiento y la red, la misma pregunta se puede hacer en diferentes situaciones:
- Antes de un cambio: ¿qué estará abajo o degradado durante el trabajo?
- Durante una incidencia: ¿qué servicio se ve afectado, y quién es responsable de él?
- Al procesar eventos de monitorización: ¿qué alertas pertenecen juntas, y cuál es la causa probable?
- Al planificar: ¿qué sucede si un componente falla, y sobrevivirá el servicio?
Un mapa de dependencias sirve entonces para la gestión de cambios, los respondedores de incidencias y el equipo de monitorización por igual.
Cómo lo maneja Eywo Stratum
Eywo Stratum muestra un mapa de dependencias en capas: servicios de negocio, aplicaciones, bases de datos, servidores, hipervisores, almacenamiento y red. Para cada elemento, puede ver qué se ejecuta en él y qué ejecuta.
Encima del mapa, puede ejecutar una simulación de interrupción. Seleccione un componente, y Stratum muestra qué servicios y aplicaciones se verían afectados y si alguno de ellos está protegido por redundancia. Otras partes del producto se basan en la misma base:
- Incidencias: cuando se plantea una incidencia a partir de un elemento de la CMDB, Stratum sugiere el servicio afectado, el impacto y el equipo de resolución. La prioridad se deriva entonces del impacto y la urgencia.
- Cambios: antes de que se envíe un cambio, se calcula su impacto, mostrando qué servicios y aplicaciones estarán no disponibles o degradados. El propietario del servicio afectado aprueba entonces una interrupción que entiende realmente.
- Monitorización: en la gestión de eventos, las alertas se agrupan en situaciones basadas en la topología de la CMDB, de modo que ve una causa probable en lugar de docenas de notificaciones separadas.
La pregunta “¿qué se rompe si esto se cae?” se responde entonces a partir de datos que el equipo entiende, no a partir de conjeturas en una reunión.
Conclusión
Puede conocer el impacto de una interrupción antes de que suceda. Requiere una CMDB que conozca las relaciones, no solo los elementos, y una herramienta que ponga ese conocimiento en práctica en cambios, incidencias y manejo de eventos. Para los equipos de operaciones, eso significa menos conjeturas en momentos críticos y más confianza al planificar.
El mapa de dependencias, la simulación de interrupción y el cálculo de impacto para incidencias y cambios son parte de la edición Estándar; la agrupación de alertas basada en la topología viene con la edición Business.
Eywo Stratum Standard
Para organizaciones que desean una CMDB fiable y procesos de ITSM gestionados.