Un switch caído no es un servicio caído

A las dos de la madrugada falla uno de los dos switches de un rack. Los servidores están conectados a ambos, así que los servicios siguen funcionando. Aun así, la monitorización lanza decenas de alertas, el mapa de dependencias se pone en rojo y, en la reunión de la mañana, los responsables de servicio leen que su servicio estuvo «degradado». No lo estuvo. Solo funcionó unas horas sin respaldo.

El caso contrario es peor. Cinco servidores virtuales lanzan alertas mientras el host en el que se ejecutan permanece en silencio, porque la monitorización no lo ve. Aparecen cinco avisos separados, cinco personas empiezan a revisar su servidor y la causa real pasa desapercibida.

Ambos problemas tienen el mismo origen: la herramienta sabe qué está conectado con qué, pero no qué provocaría realmente la caída de una de sus partes.

Alcance no es impacto

La mayoría de las CMDB saben responder qué depende de un elemento. Pero una respuesta honesta necesita algo más que una lista de relaciones:

• La redundancia. Un servidor conectado a dos switches sobrevive a la pérdida de uno. Pero un cortafuegos no sustituye a un switch, y una interfaz de red de administración no sustituye a una interfaz de datos.
• El estado de los elementos. Un segundo switch planificado que aún no está en servicio no respalda nada. Un componente en mantenimiento está, en la práctica, fuera de servicio durante el cambio.
• El tipo de relación. La administración (la consola que controla un servidor), la replicación y la copia de seguridad no propagan una caída. Un servidor no deja de funcionar porque su réplica haya caído.

Si la herramienta no distingue estas situaciones, cada análisis de impacto resulta exagerado. La gente deja de confiar en él y vuelve a las estimaciones en las reuniones.

Tres estados en lugar de dos

Stilla distingue ahora tres situaciones:

• Caída – el elemento no funciona porque han caído todos sus soportes.
• Degradado – el elemento funciona sin parte de sus funciones o con menor rendimiento.
• En riesgo – solo ha caído uno de los componentes redundantes. El elemento sigue funcionando, pero sin respaldo.

«En riesgo» se muestra en el elemento dependiente más cercano y en los servicios que están por encima, marcados como «sin redundancia». No se propaga más allá. La caída de un switch de una pareja ya no marca cientos de elementos, sino solo lo que realmente ha perdido su respaldo. La caída de ambos switches es entonces, correctamente, una caída.

Otras partes del producto se basan en el mismo cálculo. Cuando se planifica un cambio en un componente redundante, el responsable del servicio recibe la información de que el servicio funcionará sin respaldo, pero no tiene que aprobar nada, y el cambio puede hacerse fuera de la ventana de mantenimiento. La comprobación de puntos únicos de fallo trata los elementos planificados como inexistentes, de modo que los puntos débiles ocultos salen a la luz antes de causar problemas.

Un mapa que muestra lo que ocurriría

El mapa de dependencias incorpora tres cambios:

• Las relaciones de administración son una capa aparte, desactivada por defecto. La vista de lo que necesita un servicio muestra así solo las dependencias reales, no todo lo que lo administra.
• La vista de lo que depende de un elemento simula directamente su caída. Los elementos en color se verían afectados; los grises dependen de él solo de forma redundante o a través de la administración.
• La ruta de impacto resalta la cadena desde la causa hasta cada servicio afectado, incluidos los puertos, interfaces y zonas del camino. Se ve cómo una caída llega a un servicio y se puede explicar a la dirección o a un cliente.

Correlación de eventos con la misma lógica

La gestión de eventos agrupa las alertas relacionadas en una sola situación y marca la causa probable. Ahora lo hace mediante una simulación de caída:

• Solo puede ser causa un elemento cuya caída explique realmente las alertas. Por eso una alerta en uno de los dos switches de una pareja no es la causa de la caída del servidor que hay debajo, y el operador no se pone a revisar el elemento equivocado.
• Entre varios candidatos gana el que explica más alertas. Cuando un servidor virtual, su host y su datastore lanzan alertas, la situación recibe la causa más profunda, no la primera en el tiempo.
• Las alertas explicadas por la causa son síntomas. Se ven en la situación, pero no envían notificaciones, quedan fuera de los indicadores de ruido y se resuelven junto con la causa.
• Causa inferida. Cuando varios elementos lanzan alertas y su soporte común permanece en silencio, Stilla lo infiere a partir de la CMDB y crea una situación marcada como «inferida de la topología». El operador sabe por dónde empezar aunque la monitorización no vea ese elemento.

La prioridad de una alerta y de un incidente rellenado previamente sigue el impacto real en el servicio. Una alerta en un componente redundante ya no recibe la prioridad de un servicio crítico al que no amenaza, y la cola del operador se mantiene más limpia.

Procesos que se enlazan

La corrección suele hacerse mediante un cambio. Un mismo cambio puede resolver varios incidentes y un problema, y su resultado se traslada a todos los registros vinculados. Un problema con la causa documentada pasa al estado Resuelto tras un cambio con éxito; un cambio fallido lo devuelve al análisis, y quienes notificaron los incidentes reciben un aviso. Si tras completar el cambio aparecen alertas en sus elementos, la revisión posterior al cambio es obligatoria y el incidente se crea con un clic.

Conclusión

Un análisis de impacto solo tiene valor si la gente confía en él. Por eso debe distinguir una caída de la pérdida de un respaldo, y las mismas cifras deben valer al planificar un cambio, durante un incidente y en el momento en que la monitorización informa de decenas de alertas. Para la operación significa menos llamadas nocturnas por síntomas, un camino más rápido hacia la causa real y reuniones en las que nadie discute sobre el impacto.

El mapa de dependencias, los tres estados de impacto, la ruta de impacto y la vinculación de cambios con incidentes y problemas forman parte de la edición Standard. La correlación de eventos mediante simulación de caída, los síntomas y las causas inferidas pertenecen a la edición Business.