Documentación

Términos y preguntas

Glosario y respuestas a preguntas frecuentes sobre el uso de la aplicación.

Glosario

Switch virtual (VDS / vSwitch)
vSphere Distributed Switch gestionado desde vCenter para todo el clúster, o vSwitch estándar en un único host ESXi. Los enlaces físicos (vmnic) van a un par de switches leaf; la caída de un switch solo supone degradación.
Grupo de puertos
Un grupo de puertos de un switch virtual con una VLAN común y reglas de teaming. La tarjeta de red de una VM se conecta a un grupo de puertos; el grupo de puertos está asociado a una VLAN de la red física. La caída de un grupo de puertos desconecta todas sus VM (una red de copias de seguridad solo se degrada).
FOCUS
FinOps Open Cost and Usage Specification: estándar abierto para el formato de datos de costes (FinOps Foundation). La aplicación trabaja con las columnas de FOCUS 1.x.
EffectiveCost
Coste real (amortizado) tras descuentos. Con él se calculan los resúmenes y las bases de facturación.
ListCost / ContractedCost
Coste según la lista de precios o según el precio contractual. La diferencia con EffectiveCost es el ahorro.
Subcuenta
Suscripción, cuenta, proyecto o clúster en el proveedor (FOCUS SubAccount). En OpenShift, un hosted cluster; en el centro de datos, un servidor IBM Power.
Etiqueta de cliente y proyecto
Etiquetas de Kubernetes / nube eywo.cz/customer y eywo.cz/project, según las cuales se asignan los costes. Una etiqueta renombrada puede vincularse mediante un alias.
Cantidad asignada
En contenedores, máx(request, uso) por hora; en IBM Power, núcleos garantizados × horas. Utilización = consumo real ÷ asignación.
Capacidad garantizada (entitled capacity)
Parte garantizada de núcleos de procesador asignada a una LPAR en IBM Power; base del cálculo de facturación.
Capacity on Demand (CoD)
Núcleos y memoria instalados en el servidor que se activan según se necesiten mediante una clave de licencia.
NPIV
N_Port ID Virtualization: adaptador FC virtual de una LPAR con su propio WWPN, que pasa por el VIOS directamente a la SAN.
WWPN
World Wide Port Name: dirección única de un puerto FC, con la que se realizan el zoning y el mapping.
Zona
Regla en el fabric SAN que permite la comunicación entre los puertos del host y de la cabina de discos.
Thin provisioning
Un volumen solo ocupa en el pool los datos realmente escritos; se factura el tamaño asignado.
HyperShift (hosted control planes)
La capa de control de los clústeres OpenShift de los clientes se ejecuta como pods en un clúster de gestión compartido; el cliente solo tiene los nodos de trabajo.
LAG / LACP
Agregación de varios puertos físicos en un puerto lógico (port-channel); LACP la negocia. vPC / MLAG permite la agregación entre dos switches.
Ventana de mantenimiento
Periodo recurrente (semanal o mensual) en el que el servicio puede no estar disponible (parada) o funcionar con redundancia reducida (degradación). Lo define el responsable del servicio o de la aplicación, incluida la duración máxima de la parada.
RACI
Responsible (ejecuta), Accountable (responde y aprueba, exactamente uno), Consulted (consultado), Informed (informado).
Versión de un elemento
Una instantánea de un elemento de configuración válida desde–hasta. Con cada cambio procedente del descubrimiento, la API o la edición manual se crea una nueva versión.
VLAN, SVI, VRF
Una VLAN separa segmentos L2; una SVI es la interfaz L3 de la VLAN en el switch (puerta de enlace de la subred); VRF separa tablas de enrutamiento.
Ruta de impacto
La cadena de elementos desde la caída simulada hasta cada servicio afectado, incluidos los componentes (puertos, interfaces, zonas, VLAN). El botón Ruta de impacto del panel de análisis de impacto la resalta en el mapa de dependencias.
Síntoma (alerta)
Una alerta explicada por la caída del elemento causa de la situación (según la simulación de caída de la CMDB). Es visible en la situación, no envía notificaciones, se excluye de las métricas de ruido y se resuelve junto con la causa.
Causa inferida
Un elemento sin alerta propia (la monitorización no lo ve) cuya caída simulada explica las alertas de varios elementos dependientes; por ejemplo, un host en el que cinco VM emiten alertas. La gestión de eventos crea con ellas una situación con la causa «inferida de la topología».
Punto único de fallo (SPOF)
Un elemento cuya sola caída inutiliza por completo un servicio o una aplicación. La ficha Alta disponibilidad los encuentra simulando la caída de cada elemento de soporte; los componentes lógicos (aplicaciones, instancias de base de datos, clústeres) se cuentan por separado.
Caída y degradación
Caída = el elemento no funciona. Degradado = funciona sin algunas funciones o con menor rendimiento (por ejemplo, sin la red de gestión de la cabina, sin la copia en cinta de las copias de seguridad, o con el propio soporte degradado). En riesgo = pérdida de redundancia: solo ha fallado uno de los componentes redundantes y el elemento sigue funcionando sin respaldo; el análisis de impacto lo muestra en el elemento dependiente más cercano y en los servicios superiores («sin redundancia») y no se propaga más.
Grupo redundante
Un grupo de soportes que se sustituyen entre sí: clúster de aplicaciones, Db2 HADR, Oracle Data Guard, PowerHA, par de VIOS, copias de volúmenes HyperSwap, nodos Veeam; sin grupo explícito, también componentes de la misma clase (dispositivos de red solo del mismo rol: un switch no sustituye a un cortafuegos; interfaces solo del mismo propósito: una interfaz de datos no sustituye a una de gestión). El elemento dependiente solo cae cuando caen todos los miembros. Los elementos planificados no cuentan como miembros. El descubrimiento envía el grupo en attributes.redundancy_group de la relación.
HyperSwap / HA basada en políticas
Volumen replicado de forma síncrona entre dos cabinas de discos; si una cabina cae, la E/S continúa desde la otra sin interrupción.
Db2 HADR, Oracle Data Guard, PowerHA, SQL Always On
Alta disponibilidad de bases de datos: instancias principal y de respaldo en servidores distintos (aquí también en bastidores y cabinas distintos) con replicación síncrona y conmutación automática.
Par de VIOS
Dos Virtual I/O Servers en un bastidor IBM Power; la LPAR tiene red y discos a través de ambos, de modo que perder un VIOS pone la LPAR en riesgo (funciona sin respaldo) pero no la detiene.
Fabric SAN A/B, switch core y edge, ISL
Dos redes SAN separadas: cada servidor y cada cabina se conectan a ambas. El switch core da servicio a las cabinas y el edge a los hosts; se conectan mediante un ISL (inter-switch link).
Repositorio reforzado (hardened repository)
Servidor Linux con discos locales para copias de Veeam inmutables: el ransomware no puede borrar ni cifrar las copias.
Hace copia / tiene copia
Relación de la plataforma de copias (IBM Storage Protect, Veeam) con el elemento protegido. No afecta a la disponibilidad; a partir de ella se calcula la cobertura de copias de los servidores de producción.
Incidencia
Interrupción o degradación no planificada de un servicio. El objetivo es restablecerlo lo antes posible, no encontrar la causa (de eso se ocupa la gestión de problemas).
Prioridad y SLA
Prioridad P1–P4 = impacto × urgencia. El acuerdo SLA del servicio fija para cada prioridad el plazo de respuesta y de resolución; poner una incidencia en espera desplaza los plazos.
Acuerdo SLA
Nivel de servicio acordado (por ejemplo Gold, Silver, Bronze): plazos de respuesta y resolución por prioridad, horario laboral, cumplimiento exigido y disponibilidad.
Horario laboral (calendario SLA)
El tiempo durante el que corre el tiempo de SLA; por ejemplo, 24×7 o de lunes a viernes de 8:00 a 16:30 sin festivos.
Incidencia grave
Una caída de un servicio importante, coordinada por un gestor de incidencias, de la que se informa continuamente a la dirección y a los responsables de servicio.
Solicitud de servicio
Una solicitud estándar, descrita de antemano en el catálogo de servicios; no es una avería. Tiene formulario, aprobación, plazo y pasos de cumplimiento.
Modelo de cambio
Una plantilla para un tipo de cambio repetido: tipo, aprobación, necesidad de ventana de mantenimiento, antelación, clases de elementos permitidas y pasos.
Cambio estándar, normal y de emergencia
El cambio estándar está preaprobado y es de bajo riesgo (por ejemplo, aplicar parches de forma gradual a los hipervisores). El normal pasa por aprobación. El de emergencia resuelve una incidencia en curso o una vulnerabilidad crítica y puede realizarse fuera de las ventanas.
CAB
Change Advisory Board: los cambios de mayor riesgo los aprueba el gestor de cambios junto con los responsables de los servicios afectados.
Equipo
Un grupo de personas responsables de elementos de configuración, servicios y cambios, que atienden incidencias y solicitudes. El ámbito «equipo» de un rol otorga permisos sobre los elementos del equipo.
Fuente única de verdad
El sistema cuyos datos son válidos. Para la ubicación de VM y particiones es la herramienta de gestión de la virtualización (vCenter, SCVMM, HMC…); una escritura manual no la sobrescribe.
Evento, alerta, situación
Un evento es un único aviso de la monitorización. Una alerta agrupa todas las apariciones del mismo problema en el mismo elemento (deduplicación por huella). Una situación es un grupo de alertas relacionadas; normalmente, una causa y sus consecuencias.
Causa probable (★)
Una alerta en un elemento del que, según el mapa de dependencias de la CMDB, dependen las demás alertas de la situación; por ejemplo, un hipervisor bajo VM no disponibles.
Flapping
Una alerta que cambia repetidamente entre problema y OK; en lugar de decenas de avisos hay una sola situación con el estado «flapping».
Flujo de trabajo
Estados de los registros y transiciones permitidas entre ellos, incluido quién puede realizarlas. Los estados propios se asignan a estados del sistema en los que se basa la lógica de la aplicación.
Regla de notificación
Cuándo (evento y condiciones), qué (plantilla con parámetros), cómo (correo, Slack) y a quién se envía el mensaje.
Contrato de servicio y línea de contrato
Contrato con un proveedor para el soporte de la infraestructura. Una línea = un elemento cubierto por el contrato, con su propio nivel de soporte y periodo de cobertura.
SLA del proveedor (nivel de soporte)
Lo que nos garantiza el proveedor: tiempo de respuesta y de reparación dentro de su horario (por ejemplo, 24×7 con respuesta en 2 horas y reparación en 8, o el siguiente día laborable). Es distinto del SLA que garantizamos a los clientes.
Plazo de preaviso
Cuántos días antes del fin de la vigencia debemos rescindir o decidir la prórroga; el resumen muestra el último día.
Conservación
Periodo de conservación de los registros. El registro de auditoría, 5 años y no modificable; el historial de configuración, según la configuración.

Preguntas frecuentes

¿Cómo conecto Zabbix o Prometheus a la gestión de eventos?

Monitorización → Fuentes de eventos → en la fuente «Cómo conectar»: Zabbix 6.4+ mediante Connectors (streaming de eventos) o webhook, Alertmanager mediante un webhook receiver, y el resto mediante la API genérica. Necesita un token de API para una cuenta de servicio con el rol «Fuente de eventos» (Administración → Accesos y roles) y, en la variante Cloudflare, un token de servicio de Cloudflare Access.

¿Por qué un evento no se convirtió en alerta?

Monitorización → Situaciones y alertas o Reducción de ruido: el evento pudo descartarlo una regla de filtrado (por ejemplo, informativo), suprimirlo una regla de supresión o un cambio en curso sobre el elemento, o es otra aparición de una alerta existente (solo aumenta el contador).

¿Envía la aplicación datos a una IA?

Solo para los casos de uso activados del asistente de IA (Administración → Asistente de IA) y solo lo que la propuesta necesita; los correos, teléfonos, números de identificación personal, números de cuenta y secretos se sustituyen antes por marcadores. Los datos de clientes con la política «solo on-premise» los procesa solo un modelo en su propia infraestructura y, con la política «sin IA», no se usa ningún modelo. Cada llamada queda registrada en el registro de propuestas.

¿Dónde configuro el SLA?

Servicios → SLA. En la pestaña Acuerdos SLA edita los plazos por prioridad y asigna el acuerdo a servicios y clientes; en el Calendario, el horario laboral y los festivos, y en Plazos de solicitudes, los plazos de los elementos del catálogo. El cumplimiento del SLA está en la primera pestaña.

¿Dónde configuro el flujo de trabajo de incidencias, solicitudes, cambios y elementos?

Administración → Workflow. Elija un tipo de registro (incidencias, solicitudes, cambios, elementos), añada o renombre un estado en la tabla Estados y defina las transiciones en la matriz haciendo clic en una celda: etiqueta del botón, permisos, comentario o campo obligatorio. Los cambios se aplican en el detalle de los registros en menos de un minuto.

¿Cómo activo los avisos por correo y Slack?

En Administración → Notificaciones → Canales. En resumen: para Resend (o SendGrid), verifique el dominio remitente y cree una clave de API; para Slack, cree un webhook para el canal; después, `npx wrangler secret put RESEND_API_KEY`, `npx wrangler secret put SLACK_WEBHOOK_PROVOZ` y `npx wrangler secret put SLACK_WEBHOOK_MAJOR`. El canal mostrará entonces «secreto configurado». Indique como remitente una dirección de su dominio verificado.

¿Por qué no se envió el aviso?

Administración → Notificaciones → Enviados muestra el motivo: falta el secreto del canal, el destinatario no tiene correo, dirección de prueba (.example), modo demostración (la entrega con datos de demostración está desactivada) o error del servicio (código y texto de respuesta).

¿Cómo averiguo quién repara un servidor averiado y para cuándo?

En la incidencia, la pestaña Proveedor – soporte busca el soporte del elemento y del hardware en el que se ejecuta (VM → host, LPAR → bastidor Power). Muestra el proveedor, el nivel, la línea directa y los escalados; Notificar al proveedor inicia los plazos de respuesta y reparación según el contrato. En el detalle del elemento hay una pestaña Soporte y contratos.

¿Dónde veo el hardware sin soporte y los contratos que vencen?

Finanzas → Resumen de contratos: contratos que vencen y finalizados con el último día de preaviso, cobertura por clase, lista de hardware sin soporte vigente y lo que termina en 90 días. Los avisos por correo se configuran en Administración → Notificaciones (registro Contrato).

¿Cómo desactivo los datos de demostración?

Administración → Configuración → Datos de demostración. El interruptor cambia toda la aplicación a la base de datos de producción; los datos de demostración permanecen en una base separada y pueden activarse en cualquier momento. Solo el administrador de la plataforma puede cambiarlo.

¿Dónde están la CMDB, los sistemas operativos y los cambios tras la modificación del menú?

El menú está organizado por áreas de gestión de servicios de TI: Servicios (cartera de servicios, SLA, catálogo de solicitudes), Monitorización (situaciones y alertas, reducción de ruido, reglas y fuentes de eventos), Service desk (incidencias, problemas, cumplimiento de solicitudes), Cambios (cambios, aprobaciones, parches y vulnerabilidades), Configuración (CMDB, centros de datos, ciclo de vida, calidad de datos, arquitectura empresarial), Finanzas y activos (costes, facturación, activos, compras, proveedores y contratos) y Administración (integraciones, personas y accesos, configuración de la aplicación). Lo más rápido es la búsqueda con Ctrl+K, que también encuentra las páginas del menú.

¿Por qué no puedo cambiar el host de una VM manualmente o desde otra fuente?

La ubicación de VM y particiones se toma de la herramienta de gestión de la virtualización (vCenter, SCVMM, HMC…). Otra fuente o una entrada manual se desviarían de ella; un descubrimiento desde otra fuente recibe un error con el nombre de la herramienta que gestiona la ubicación.

¿Cómo vinculo un cambio a varias incidencias o a un problema?

En el detalle del cambio, ficha Registros resueltos → Vincular: elija el tipo de registro e introduzca su número. Desde el detalle de una incidencia, problema o solicitud, vincule un cambio existente por su número en la ficha Cambios. El vínculo del que nació el cambio no se puede eliminar; los demás pueden desvincularlos el solicitante, el ejecutor, el gestor de cambios o el responsable del registro.

¿Qué pasa con el problema y las incidencias cuando finaliza el cambio correctivo?

Un problema con la causa documentada pasa a Resuelto y remite al cambio correctivo; sin causa, recibe una entrada que pide completarla. Un cambio fallido devuelve el problema al análisis. Las incidencias y solicitudes reciben una entrada con el siguiente paso (verificar y resolver con el código «Resuelto mediante cambio») y se avisa a quienes las notificaron.

Una incidencia notificada es en realidad una solicitud (o al revés). ¿Qué hago?

En el detalle de la incidencia use Convertir en solicitud (elija un elemento del catálogo) y en el detalle de la solicitud, Convertir en incidencia. El nuevo registro asume la descripción, el elemento y quien la notificó, el plazo corre desde la conversión y el registro original se anula con un vínculo al nuevo.

¿Por qué la pérdida de un switch de un par no muestra caída ni degradación?

El servidor está conectado a ambos switches, así que sigue funcionando, solo que sin respaldo. El análisis de impacto lo muestra como «en riesgo» en los elementos dependientes más cercanos y en los servicios superiores («sin redundancia») y no lo propaga más. En un cambio sobre un switch así, se informa al responsable del servicio, pero no tiene que aprobar. Si cayera también el segundo switch, sería una caída.

¿Qué significa una situación con causa inferida?

Varios elementos emiten alertas a la vez y comparten un soporte (host, datastore, switch) que no emite ninguna alerta: la monitorización no lo ve. La aplicación comprueba en la CMDB que la caída de ese soporte explica todas las alertas y crea una situación con la causa «inferida de la topología». Revise el soporte en la monitorización; desde el detalle de la situación puede simular su caída en el mapa.

¿Por qué no puedo finalizar el cambio?

El modelo de cambio define los pasos del cambio. El cambio solo puede finalizarse cuando todos los pasos están marcados en su detalle.

¿Cómo se calculan los plazos de SLA de una incidencia?

Desde la apertura de la incidencia según la prioridad (por ejemplo, P2: respuesta 30 min, resolución 8 h). El tiempo en espera se suma a los plazos. La respuesta se cumple al asumir la incidencia para resolverla.

¿Cómo llegan a la CMDB los cambios del descubrimiento?

Los scripts de recogida (HMC, vCenter, SCVMM, API de la nube, OpenShift, almacenamiento, SAN, red) envían los elementos a POST /api/cmdb/discovery con el token de API de una cuenta de servicio. Cada cambio de atributo crea una nueva versión; en el detalle del elemento hay un historial con comparación de valores y estado en cualquier fecha. En una sincronización completa, los elementos no encontrados por el descubrimiento se marcan y se eliminan tras un periodo establecido.

¿Por qué no encuentro fecha para aplicar parches?

Algún servicio afectado no tiene ventana de mantenimiento, su parada máxima es más corta que el cambio o las ventanas de los servicios no se solapan. Pruebe con un horizonte más largo, una intervención más corta o la aplicación gradual de parches a elementos individuales con redundancia.

¿Por qué han cambiado los costes de un mes que ya terminó?

Los proveedores (sobre todo Azure y AWS) recalculan los costes varios días después de fin de mes. Genere las bases de facturación después del día 5 del mes siguiente y apruébelas antes de enviarlas: una base aprobada ya no cambia.

¿Y si el cliente no tiene etiqueta?

Las filas sin etiqueta se muestran como «(sin cliente)» o «(sin proyecto)». Añada la etiqueta en el namespace / la fuente o añada un alias.

¿Puedo corregir una base de facturación tras aprobarla?

Devuélvala a borrador, corrija los datos o la plantilla y vuelva a generarla. Una base enviada solo puede anularse y generarse de nuevo; recibirá un número nuevo.

¿Cómo cargo datos desde mi propio script?

Envíe las líneas FOCUS a POST /api/ingest/focus con un token de administrador (véase Importación y API). Para varias partes de un mismo archivo, envíe el mismo upload_id.

¿Qué significa «Sin punto único de fallo»?

La aplicación ha simulado la caída de cada elemento en el que se apoya el servicio (servidores, bastidores, VIOS, invitados, datastores, volúmenes, cabinas de discos, SAN y red) y ninguna caída aislada ha detenido el servicio, solo lo ha degradado. La aplicación no examina combinaciones de caídas simultáneas; puede comprobarlas en el análisis de impacto seleccionando varios elementos.

¿Por qué el servidor de producción aparece sin copia de seguridad?

No tiene la relación «tiene copia de seguridad»: el descubrimiento no encontró para él ningún agente de IBM Storage Protect o Veeam. Las VM en la nube no se cuentan en la cobertura, porque las copia el proveedor.

¿Por qué la caída de la red o de la biblioteca de cintas solo degrada el servicio?

La cabina de discos sirve los datos a través de la SAN; sin la red de gestión pierde la administración, la monitorización y la replicación IP al DR, pero sigue funcionando. Sin la biblioteca de cintas, las copias continúan a disco y solo faltan las copias en cinta. Estas relaciones llevan el indicador «solo degradación».

¿Cómo uso la aplicación en el teléfono?

El menú se abre con el botón Menú arriba a la derecha; también contiene la selección de rol y tema. Las tablas anchas se desplazan en horizontal: un borde difuminado indica que continúan. El mapa de dependencias se abre como árbol; en la vista Grafo, deslice para moverse y pellizque con dos dedos para ampliar.

¿Dónde se guardan las contraseñas de la nube?

En ningún lugar de la aplicación. La conexión solo contiene un vínculo al almacén de secretos; los scripts de recogida cargan los secretos por sí mismos.