# Procesos · Documentación de CentOps > Cómo se encadenan eventos, incidencias, problemas, solicitudes y cambios, y por qué estados pasa cada registro. URL: https://centops.eywo.digital/es/docs/processes/ Language: es Last updated: 2026-10-30 Documentación # Procesos Cómo se encadenan eventos, incidencias, problemas, solicitudes y cambios, y por qué estados pasa cada registro. 1. [Resumen](https://centops.eywo.digital/es/docs/) 2. [Módulos](https://centops.eywo.digital/es/docs/modules/) 3. [Procesos](https://centops.eywo.digital/es/docs/processes/) 4. [Modelo CMDB](https://centops.eywo.digital/es/docs/cmdb-model/) 5. [Términos y preguntas](https://centops.eywo.digital/es/docs/terms/) 6. [Ficha técnica](https://centops.eywo.digital/es/docs/datasheet/) ## Encadenamiento de procesos ### Detectar y restablecer De la señal de monitorización a la corrección definitiva 1. **Evento** 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. 2. **Alerta** 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. 3. **Situaciones** 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. 4. **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. 5. **Problema** 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. 6. **Cambio** 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. 7. **Verificación tras el cambio** 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. ### Solicitar y cumplir De la solicitud del usuario a la infraestructura entregada 1. **Solicitud** 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. 2. **Conversión incidencia ↔ solicitud** 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. 3. **Cumplimiento** 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. 4. **Cambio** 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. 5. **Elemento de configuración** Un cambio completado pone en servicio los elementos destino (o los retira); el descubrimiento confirma el nuevo estado. ### Vulnerabilidades de los escáneres Tenable / Nessus → CMDB → gestión de parches 1. **Escaneo** 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. 2. **Asociación con la CMDB** 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. 3. **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. 4. **Gestión de parches** 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. ### Configuración desde las fuentes Cómo se llena y mantiene la CMDB 1. **Descubrimiento y monitorización** 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. 2. **Elemento sin responsable** Los elementos nuevos sin equipo responsable procedentes de la misma ejecución de una fuente se reúnen en un solo cambio. 3. **Cambio «Añadir responsable»** 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. 4. **Elemento completo** 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. ## Ciclos de vida de los registros ### Incidencias Una incidencia va desde la notificación, pasando por la asignación y la resolución, hasta el cierre. Ponerla en espera detiene el reloj del SLA. Nueva→Asignada→En curso→Resuelta→Cerrada En espera · detiene el reloj del SLAestado secundario · En cursoEsperando al proveedorestado secundario · En cursoAnuladaestado final Transiciones (16) - Nueva → Asignada · Asignar - Nueva → En curso · Asumir y resolver - Asignada → En curso · Asumir y resolver - En espera → En curso · Continuar - Esperando al proveedor → En curso · El proveedor respondió - Asignada → Resuelta · Resolver - En curso → Resuelta · Resolver - En espera → Resuelta · Resolver - Esperando al proveedor → Resuelta · Resolver - En curso → En espera · Poner en espera - En curso → Esperando al proveedor · Esperando al proveedor - En curso → Asignada · Devolver a la cola - Resuelta → Cerrada · Cerrar - Resuelta → En curso · Reabrir - Nueva → Anulada · Anular - Asignada → Anulada · Anular ### Solicitudes Una solicitud se presenta, se aprueba según el catálogo, se cumple y la cierra el solicitante. Presentada→Pendiente de aprobación→En curso→Cumplida→Cerrada Aprobadaestado secundario · Pendiente de aprobaciónRechazadaestado finalAnuladaestado final Transiciones (10) - Pendiente de aprobación → En curso · Aprobar - Pendiente de aprobación → Rechazada · Rechazar - Aprobada → En curso · Asumir - En curso → Cumplida · Cumplida - Cumplida → Cerrada · Cerrar - Cumplida → En curso · Devolver al cumplimiento - Pendiente de aprobación → Anulada · Anular la solicitud - Presentada → Anulada · Anular la solicitud - Aprobada → Anulada · Anular la solicitud - En curso → Anulada · Anular la solicitud ### Problemas El problema se analiza, la causa se convierte en un error conocido con solución provisional y la corrección la realiza un cambio; cuando finaliza con éxito, el problema pasa por sí solo a Resuelto. Nueva→Análisis de la causa→Resuelta→Cerrada Error conocidoestado secundario · Análisis de la causaAnuladaestado final Transiciones (10) - Nueva → Análisis de la causa · Iniciar el análisis - Análisis de la causa → Error conocido · Publicar el error conocido - Análisis de la causa → Resuelta · Resolver - Error conocido → Resuelta · Resolver - Error conocido → Análisis de la causa · Volver al análisis - Resuelta → Cerrada · Cerrar - Resuelta → Análisis de la causa · Reabrir - Nueva → Anulada · Anular - Análisis de la causa → Anulada · Anular - Error conocido → Anulada · Anular ### Cambios Un cambio se redacta, se envía a aprobación, se planifica en una ventana de mantenimiento, se ejecuta y se evalúa. Solo la aplicación lo lleva a los estados de aprobación. Borrador→Pendiente de aprobación→Aprobada→En curso→Cumplida Fallidoestado secundario · En cursoRechazadaestado finalAnuladaestado final Transiciones (7) - Aprobada → En curso · Iniciar los trabajos - En curso → Cumplida · Cumplida - En curso → Fallido · Fallido - Borrador → Anulada · Anular el cambio - Pendiente de aprobación → Anulada · Anular el cambio - Rechazada → Anulada · Anular el cambio - Aprobada → Anulada · Anular el cambio ### Elementos de configuración Un elemento de configuración está planificado, en servicio, en mantenimiento (durante un cambio) o retirado. En las clases controladas, solo un cambio puede modificar el estado. Planificado→En servicio Mantenimientoestado secundario · En servicioRetiradoestado final Transiciones (7) - Planificado → En servicio · Poner en servicio - En servicio → Mantenimiento · Mantenimiento - Mantenimiento → En servicio · Volver a servicio - Retirado → Planificado · Restaurar (volver a planificar) - Planificado → Retirado · Dar de baja - En servicio → Retirado · Dar de baja - Mantenimiento → Retirado · Dar de baja ### Artefactos de arquitectura empresarial Un artefacto de arquitectura empresarial pasa por borrador, aprobación y vigencia hasta su retirada. Borrador→Aprobada→En construcción→En servicio→En retirada Dado de bajaestado finalRechazadaestado final Transiciones (10) - Borrador → Aprobada · Aprobar - Aprobada → Borrador · Volver a borrador - Aprobada → En construcción · Iniciar la construcción - Aprobada → En servicio · Poner en servicio - En construcción → En servicio · Poner en servicio - En servicio → En retirada · Iniciar la retirada - En retirada → En servicio · Cancelar la retirada - En retirada → Dado de baja · Dar de baja - Rechazada → Borrador · Volver a proponer - Borrador → Rechazada · Rechazar El mapa de procesos y el modelo CMDB se generan a partir del estado actual de la aplicación · actualizado 30 de octubre de 2026