Procesos

La monitorización (Zabbix, Prometheus, Checkmk, Grafana, Dynatrace, API genérica) envía un evento. La aplicación lo asocia a un elemento de configuración por nombre de host, IP, número de serie o ID de entidad y añade el servicio, el cliente y el equipo. Las reglas de filtrado descartan el ruido.

Los eventos repetidos del mismo problema (misma huella) forman una alerta y solo aumentan su contador. Un mensaje OK resuelve la alerta. Un cambio en curso sobre el elemento suprime la alerta para que no despierte al operador.

Las alertas se agrupan en situaciones mediante una simulación de caída en la CMDB: la causa es solo un elemento cuya caída explica realmente las alertas (caída del hipervisor → sus VM y aplicaciones). Las alertas explicadas son síntomas: sin notificaciones, se resuelven con la causa. Si el soporte común de varios elementos en alerta está en silencio, la aplicación lo deduce de la topología. La agrupación continúa por servicio y tiempo o por cambio relacionado. El operador confirma la situación, la asigna a un equipo, la silencia o crea a partir de ella una incidencia.

Una interrupción no planificada de un servicio. El impacto y el equipo se calculan desde la CMDB (según el impacto real de la caída: la pérdida de redundancia implica un impacto bajo), la prioridad a partir del impacto y la urgencia, y los plazos a partir del SLA. Las alertas siguen vinculadas a la incidencia; su resolución propone resolver la incidencia. Para P1/P2 se puede abrir una war room.

La causa de incidencias recurrentes o graves. Surge de una incidencia, de la evaluación de una incidencia grave, de una revisión posterior a un cambio o de la comprobación diaria de incidencias recurrentes. Un error conocido incluye una solución provisional.

La corrección definitiva la realiza un cambio creado desde el problema o vinculado a él (el cambio de emergencia se crea desde la incidencia). Un cambio puede resolver varias incidencias y problemas. Tras finalizar con éxito, un problema con la causa documentada pasa a Resuelto y se pide verificación a las incidencias vinculadas; un cambio fallido devuelve el problema al análisis.

Durante 24 h tras finalizar un cambio, la aplicación vigila las alertas en sus elementos. Si aparecen, la revisión posterior a la implantación es obligatoria y desde el detalle del cambio puede crear una incidencia que lo registre como causa; de esa incidencia puede surgir otro problema.

El usuario elige un elemento del catálogo (nuevo servidor, capacidad, cortafuegos, acceso…), rellena el formulario y la solicitud pasa por la aprobación según las reglas del elemento.

Una incidencia que no es una avería sino una solicitud de servicio se convierte en solicitud (y viceversa). El nuevo registro asume la descripción, el elemento y quien notificó, el plazo corre desde la conversión y el registro original se anula con un vínculo.

El equipo de resolución asume la solicitud y marca los pasos de cumplimiento dentro del plazo fijado por el catálogo y el horario laboral.

Un elemento que modifica la infraestructura está vinculado a un modelo de cambio. Con un modelo estándar, la aplicación crea y planifica el cambio por sí misma, sin aprobación. Se avisa al solicitante cuando se planifica, inicia y completa; la solicitud solo puede cumplirse cuando el cambio se ha completado.

Un cambio completado pone en servicio los elementos destino (o los retira); el descubrimiento confirma el nuevo estado.

CentOps obtiene por sí mismo los hallazgos de Tenable Vulnerability Management mediante la API de exportación (la primera vez, los hallazgos abiertos; después solo los cambios, incluidos los corregidos). Los resultados de Nessus y Tenable Security Center se cargan como archivo .nessus. Los hallazgos con CVE pasan a la gestión de parches.

Un dispositivo escaneado se asocia en este orden: decisión guardada → FQDN (nombre de host + dominio del SO) → dirección MAC → nombre corto + dominio → IP, esta última solo en dispositivos de red. Solo es automática una coincidencia inequívoca sin contradicciones; otro elemento según otro atributo, un SO que no coincide, otro dominio o un elemento retirado implican conflicto o revisión.

Un dispositivo en revisión se confirma, se asigna a otro elemento o se excluye; la decisión se aplica también a los escaneos posteriores. Los dispositivos no asociados los ve el escáner en la red, pero la CMDB no los conoce.

Los hallazgos de los dispositivos asociados reciben un plazo de corrección según la política (KEV, CVSS) y entran en el plan de parches. Un hallazgo que el escáner ya no notifica se cierra como corregido.

El descubrimiento desde vCenter, HMC, OpenShift, las nubes y la monitorización (Dynatrace) crea y actualiza elementos y relaciones. No se permiten cambios manuales en la ubicación de VM y particiones: la fuente es la verdad.

Los elementos nuevos sin equipo responsable procedentes de la misma ejecución de una fuente se reúnen en un solo cambio.

Un cambio estándar sin aprobación asignado al gestor de configuración: encontrar el responsable, añadir el equipo y el servicio, verificar la clasificación y cerrar. Lo encontrará en Mi trabajo.

Un elemento con responsable cuenta para el impacto de incidencias y cambios, para los costes y para la comprobación de la calidad de datos.