Documentación

Módulos

Qué hace cada módulo, agrupado por área de la aplicación.

ServiciosMonitorizaciónService deskCambiosConfiguraciónFinanzas y activosAdministración

Servicios

cartera de servicios, niveles de servicio y catálogo de solicitudes

Base de datos de configuración

Modelo general de infraestructura: IBM Power (LPAR, VIOS, HMC), virtualización VMware, Hyper-V y Azure Stack Hub, servidores virtuales en nubes públicas (Azure, AWS, GCP), clústeres de contenedores en cualquier lugar (OpenShift y HyperShift, AKS, EKS, GKE), aplicaciones, plataformas de aplicación y bases de datos, cabinas de discos, SAN y red (routers, switches L3/L2, agregación de puertos LACP y vPC, VLAN, subredes, enrutamiento). En las LPAR verá la ruta de los datos a través de NPIV, la SAN y la zona hasta la cabina de discos. Los costes de la infraestructura on-premise se calculan directamente desde la CMDB. El mapa de dependencias muestra los elementos desde el servicio de negocio hacia abajo como grafo o árbol, con filtro por cliente y entorno. El análisis de impacto simula la caída de un elemento seleccionado y muestra los servicios, aplicaciones y clientes afectados; en elementos redundantes (pares de switches, nodos de clúster, fabrics SAN A/B) distingue entre caída y degradación. Para servicios de negocio, aplicaciones, plataformas y bases de datos, la ficha Alta disponibilidad simula la caída de cada elemento de soporte, enumera los puntos únicos de fallo y muestra los grupos redundantes (clúster de aplicaciones, Db2 HADR, Oracle Data Guard, PowerHA, pares de VIOS, volúmenes HyperSwap). Cada elemento tiene un icono según su tipo (servidor físico, VM, LPAR, aplicación, base de datos, cabina de discos, biblioteca de cintas, switch SAN, router, cortafuegos, switch L2/L3…); el color del icono corresponde a la categoría. Para hipervisores, VIOS y LPAR hay una ficha Ruta de almacenamiento a través de ambos fabrics SAN. Las relaciones muestran los grupos redundantes y las relaciones cuya caída solo supone degradación (por ejemplo, la red de gestión de la cabina o la biblioteca de cintas). La relación «tiene copia de seguridad en» indica qué plataforma de copias protege el elemento. En el teléfono, el mapa se abre como árbol; el grafo se desplaza con un dedo y se amplía con dos. Cada elemento tiene un equipo responsable; en el hardware verá la fecha de instalación, el fin de la garantía y el fin del soporte del fabricante. La ubicación de las VM y particiones (host, clúster, servidor Power) solo la cambia el descubrimiento desde la herramienta de gestión de la virtualización correspondiente (vCenter, SCVMM, Azure Stack Hub, API de la nube, HMC). Desde el detalle de un elemento puede notificar directamente una incidencia o planificar un cambio.

SLA

Gestión de niveles de servicio (Servicios → SLA). Cumplimiento del SLA: proporción de incidencias con respuesta y resolución dentro del plazo por meses y por acuerdo SLA, prioridad, servicio, cliente o equipo, comparación con el objetivo, lista de incumplimientos y cumplimiento de los plazos de solicitudes. Acuerdos SLA (por defecto Gold, Silver, Bronze, Standard): objetivos de respuesta y resolución para P1–P4, horario laboral (se puede sobrescribir por prioridad, por ejemplo P1 24/7), cumplimiento exigido en %, disponibilidad objetivo y cuándo avisar (tras transcurrir un % del plazo). El acuerdo se asigna a un servicio de negocio o a un cliente; se aplica el SLA del servicio → el SLA del cliente → el SLA predeterminado. Horario laboral: ventanas semanales por días, festivos checos (incluidos Viernes Santo y Lunes de Pascua) y otros días libres, vista previa de 14 días. El tiempo de SLA solo corre en horario laboral y no se consume mientras una incidencia está en espera. Plazos de solicitudes: plazo para cumplir cada elemento del catálogo en horas y horario laboral. Los cambios se aplican a nuevas incidencias y solicitudes; las incidencias abiertas pueden recalcularse con un botón. Lo editan el gestor de incidencias y el administrador de la plataforma (sla.manage).

Gestión de solicitudes

El catálogo de servicios contiene solicitudes estándar (nuevo servidor, ampliación de capacidad, regla de cortafuegos, acceso, restauración desde copia de seguridad, namespace en OpenShift). Cada elemento tiene un formulario, un modo de aprobación (sin aprobación, responsable del servicio del cliente, jefe del equipo de resolución, gestor de cambios), un plazo, un equipo de resolución y pasos de cumplimiento. Una solicitud sin aprobación pasa directamente al cumplimiento. El resolutor asume la solicitud, marca los pasos y la da por cumplida; el solicitante la cierra. Un elemento cuyo cumplimiento modifica la infraestructura está vinculado a un modelo de cambio: de la solicitud se crea un cambio, y la solicitud solo puede cumplirse cuando el cambio se ha completado. El catálogo lo gestiona el gestor de configuración en la pestaña Gestión del catálogo. Para un elemento vinculado a un modelo de cambio estándar, la aplicación crea el cambio por sí misma y lo planifica en el primer hueco libre sin más aprobaciones. La ficha Cambios del detalle muestra los cambios vinculados, y se avisa al solicitante cuando se planifican, inician y completan. Una solicitud que en realidad es una avería la convierte el resolutor con Convertir en incidencia.

Monitorización

eventos de monitorización, su correlación y reglas

Gestión de eventos

Recepción de eventos de la monitorización (Zabbix, Prometheus/Alertmanager, Checkmk, Grafana, Dynatrace, API genérica) y su reducción a aquello a lo que el operador debe reaccionar. Cada evento se asocia a un elemento de configuración (nombre de host, FQDN, IP, número de serie o etiqueta ci_id) y el servicio de negocio afectado, el cliente y el equipo responsable se completan desde la CMDB. Las reglas de filtrado descartan el ruido; las reglas de supresión y los cambios en curso sobre el elemento suprimen la alerta (no despiertan al operador). Los eventos repetidos del mismo problema (misma huella) solo aumentan el contador de la alerta; un mensaje OK resuelve la alerta y, sin él, se resuelve tras un periodo de silencio. Una alerta fluctuante (varios cambios de estado por ventana) se marca como flapping. Las alertas se agrupan en situaciones: topológicamente, según una simulación de caída en la CMDB; solo puede ser la causa un elemento cuya caída explique realmente la alerta (así, un switch de un par no es la causa de la caída de un servidor), y entre varios candidatos gana el que explica más alertas (★). Las alertas explicadas por la causa son síntomas: visibles en la situación, sin notificaciones, excluidas de las métricas de ruido y resueltas junto con la causa. Cuando varios elementos emiten alertas y comparten un soporte común silencioso (por ejemplo, VM en un mismo host), se crea una situación con causa inferida. La agrupación continúa por servicio y tiempo, y por cambio relacionado. La consola ordena las situaciones por criticidad del servicio afectado y gravedad y se actualiza en directo; el operador confirma situaciones, las asigna a un equipo, las silencia temporalmente con un motivo, las fusiona y las divide. Una incidencia creada desde una situación viene precumplimentada (elemento, servicio, impacto según el impacto real en el servicio —caída, degradación o solo pérdida de redundancia— y su criticidad, urgencia según la gravedad, equipo, cronología de alertas, vínculo al cambio) y las alertas siguen vinculadas a la incidencia: se añaden las nuevas alertas de la situación, la resolución de todas las alertas propone resolver la incidencia y un problema que vuelve la reabre. Una regla de incidencia automática crea una incidencia sin operador. La reducción de ruido muestra el embudo eventos → alertas → situaciones → incidencias, las comprobaciones que nunca dieron lugar a una incidencia (sugerencias de ajuste de disparadores) y los hosts sin elemento en la CMDB. Con datos de demostración se pueden simular eventos (caída de hipervisor, base de datos lenta, flapping, ruido). La variante piloto procesa los eventos directamente en la aplicación; para grandes volúmenes, el procesamiento se traslada a Kafka y Flink (véase README).

Service desk

incidencias, problemas y cumplimiento de solicitudes

Gestión de incidencias

Una incidencia es una interrupción o degradación no planificada de un servicio. Al crearla, elige el elemento de configuración donde se manifiesta el problema; la aplicación calcula qué servicios se ven afectados y propone el servicio afectado, el impacto y el equipo de resolución (equipo responsable del elemento). La prioridad P1–P4 se deriva del impacto y la urgencia; los plazos de respuesta y resolución los define el SLA del servicio afectado (o del cliente, o el predeterminado) dentro de su horario laboral, y el formulario muestra de antemano el SLA vigente y el plazo. Los estados y transiciones los define el flujo de trabajo (Administración → Workflow); por defecto: nueva → asignada → en curso → (en espera, esperando al proveedor) → resuelta → cerrada. Los botones del detalle corresponden a las transiciones que se le permiten; algunas requieren un comentario. La puesta en espera desplaza los plazos del SLA. La resolución requiere un código y una descripción; quien la notificó puede reabrir la incidencia. El gestor de incidencias declara una incidencia grave. En el detalle aparecen el impacto desde la CMDB, los cambios en torno a la apertura de la incidencia (un cambio puede marcarse como causa) y los botones Proponer cambio y Cambio de emergencia. Las incidencias de un elemento se ven en su detalle; la monitorización puede crearlas mediante la API. La ficha Cambios muestra los cambios que resuelven la incidencia: un cambio puede vincularse a varias incidencias y un cambio existente puede vincularse a la incidencia; se avisa a quien la notificó cuando el cambio se planifica, inicia y completa. Si no se trata de una avería sino de una solicitud de servicio, convierta la incidencia con Convertir en solicitud: elija un elemento del catálogo, quien la notificó pasa a ser el solicitante y la incidencia se anula con un vínculo a la nueva solicitud.

War room

Coordinación de una incidencia grave (P1/P2). La war room se abre desde el detalle de la incidencia. La aplicación propone la composición del equipo a partir de los datos —núcleo y refuerzo según las alertas, los cambios candidatos, la cadena de soporte en la CMDB y las incidencias similares— y la compara con un «puente amplio». Registra la asistencia y el coste según las tarifas horarias de los equipos, así como las hipótesis (área descartada → sugerencia de liberar un equipo), y al cerrar escribe un resumen en el registro de trabajo de la incidencia.

Gestión de problemas

Un problema es 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 (el número y el periodo se definen en los parámetros de procesos). La causa se convierte en un error conocido con una solución provisional que los resolutores ven en incidencias posteriores. La corrección definitiva la realiza un cambio creado directamente desde el problema o vinculado a él (ficha Cambios). Cuando el cambio finaliza con éxito, un problema con la causa documentada pasa por sí solo a Resuelto; un cambio fallido lo devuelve al análisis; cierre el problema cuando la corrección esté verificada. Un problema creado a partir de una incidencia principal asume también sus incidencias secundarias.

Cambios

cambios, aprobaciones y parches

Gestión de cambios

Los cambios se crean a partir de modelos de cambio. El modelo determina el tipo de cambio (estándar preaprobado, normal o de emergencia), quién aprueba (responsable del servicio afectado, gestor de cambios, CAB o nadie en un cambio estándar), si la fecha debe caer en ventanas de mantenimiento, la antelación necesaria en días, si el cambio puede ejecutarse gradualmente elemento a elemento, si puede realizarse durante una congelación de cambios, a qué clases de elementos se destina y qué pasos tiene. Procedimiento: elija un modelo, luego un servicio de negocio y los elementos de su árbol (o directamente los elementos). La aplicación calcula desde la CMDB qué servicios y aplicaciones quedarán caídos y cuáles solo degradados, busca fechas según las reglas del modelo (ventanas de mantenimiento, congelaciones, colisiones con otros cambios, antelación) y crea las aprobaciones tras el envío. En caso de parada, aprueba el responsable del servicio de negocio (A) y se consulta a los responsables de las aplicaciones (C). El ejecutor inicia el cambio aprobado, marca los pasos y lo finaliza; solo puede finalizarse cuando se han completado todos los pasos. Un cambio para una incidencia (también de emergencia) se crea directamente desde el detalle de la incidencia, un cambio correctivo desde el detalle del problema; el cambio estándar para una solicitud del catálogo lo crea la propia aplicación. Los modelos de cambio los gestiona el gestor de cambios en la pestaña Modelos de cambio, y las ventanas de mantenimiento los responsables de servicio en la pestaña Ventanas de mantenimiento. La ficha Registros resueltos muestra las incidencias, problemas y solicitudes que resuelve el cambio; puede vincular más por número de registro (el vínculo del que nació el cambio no se puede eliminar). Cuando el cambio se planifica, inicia y finaliza, se avisa a quienes notificaron las incidencias vinculadas y a los solicitantes de las solicitudes vinculadas. El resultado se propaga a los registros vinculados: un problema con la causa documentada pasa a Resuelto, un cambio fallido lo devuelve al análisis y las incidencias y solicitudes reciben una entrada con el siguiente paso. Durante 24 h tras la finalización, la aplicación vigila las alertas en los elementos del cambio; si aparecen, la revisión posterior a la implantación es obligatoria. Desde un cambio en curso o fallido, finalizado con problemas o con alertas tras su finalización, el botón Crear incidencia abre una incidencia que registra el cambio como causa.

Gestión de parches

Vulnerabilidades de los servidores, acuerdos de parches con los responsables de servicio y un asistente del coordinador de cambios para el plan de parches: calcula los servicios afectados desde la CMDB y propone huecos en sus ventanas de mantenimiento, fuera de congelaciones y colisiones con otros cambios; los responsables de servicio aprueban la parada. Las vulnerabilidades de un elemento también se muestran en su ficha de la CMDB.

Configuración

CMDB, centros de datos y arquitectura empresarial

Centros de datos

Resumen de los centros de datos (indicadores, salas, lo que requiere atención), plano de la sala y rack con la ubicación del hardware desde la CMDB. Insertar o mover un equipo físico crea un cambio o una solicitud; las posiciones planificadas se muestran en el rack como contorno.

Configuración

Base de datos: datos de producción o datos de demostración separados (se aplica a toda la aplicación y se registra en la auditoría); en modo demostración, los usuarios en checo ven la demo checa y los usuarios en inglés la demo inglesa. Conservación: el registro de auditoría se conserva 5 años y la base de datos no permite borrar ni modificar un registro antes; historial de elementos y relaciones según la configuración (5 años por defecto), ejecuciones de descubrimiento y conexiones durante 13 meses. Equipos: responsables de elementos, servicios y cambios, y resolutores de incidencias y solicitudes, con miembros y jefe. Calidad de datos de la CMDB: incoherencias (ubicación de VM, falta de equipo responsable, detalle de clase, costes) y fuentes de verdad sobre la ubicación. Ciclo de vida del hardware: fin de venta y de soporte de los modelos. Tipos de cambio del Banco Nacional Checo para convertir costes en moneda extranjera.

Arquitectura empresarial

Un modelo ArchiMate: capacidades, actores, procesos, aplicaciones y servicios de aplicación, objetos de datos y tecnología vinculada a la CMDB. Las aplicaciones se evalúan según TIME (Tolerate, Invest, Migrate, Eliminate) y su fase del ciclo de vida; el estado objetivo se describe mediante plateaus y paquetes de trabajo vinculados a cambios. El detalle del artefacto muestra costes, disponibilidad, incidencias, cambios y la cadena hasta la infraestructura. Exportación en formato Open Exchange.

Finanzas y activos

costes, facturación, activos, compras y contratos

Resumen de costes

Costes mensuales de todos los clientes o de uno seleccionado. Los mosaicos muestran costes, capacidad de cómputo asignada, su utilización, memoria y almacenamiento. El gráfico abarca los últimos 12 meses; al hacer clic en una columna se cambia de mes. Al hacer clic en la fila de un cliente, toda la página se limita a ese cliente. El botón Descargar CSV FOCUS exporta las filas en el estándar FOCUS.

Análisis de costes

Vistas de datos propias: para las filas elige hasta 4 dimensiones (cliente, proyecto, clúster, partida…), para las columnas una (normalmente el mes), además de medidas y filtros. La tabla se recalcula al instante. Una tabla guardada está disponible para todos los usuarios; la exportación CSV se abre en Excel (separador punto y coma).

Facturación

Plantillas mensuales para la facturación. En la pestaña Plantillas define la agrupación de filas, el recargo, el descuento y el IVA; en Datos de facturación, el número de empresa (IČO), la dirección y el contrato del cliente. Las plantillas se generan para todo el mes de una vez; un borrador puede regenerarse, una plantilla aprobada queda congelada. Estados: borrador → aprobada → enviada; la anulación es posible en cualquier momento.

Tarifas

Finanzas → Tarifas de servicios. Versiones de tarifas (borrador, vigente, archivo) con precios unitarios por secciones: infraestructura, máquinas virtuales por plataforma (VMware vSphere, Azure Stack Hub, OpenShift Virtualization: vCPU, memoria, disco), sistemas operativos (Windows Server, RHEL, SUSE, Ubuntu), servidores estándar Windows y Linux, niveles de soporte y servicios operativos, cumplimiento de solicitudes (vínculo al catálogo) e implantación de cambios (tipo de cambio, modelo de cambio). Los precios los edita un rol con el permiso rate.manage; la calculadora de servidores virtuales compara plataformas. Cada línea de coste lleva una referencia a la versión de tarifas, de modo que siempre se sabe a qué precio se valoró.

Registro de activos

Fichas de activos vinculadas a elementos de configuración: compra, recepción, facturas, puesta en uso, amortizaciones, centros de costes, almacenes de repuestos y actas de entrega. Un cambio de instalación de hardware cerrado pone la ficha en uso; la baja respeta las amortizaciones contabilizadas.

Licencias de software

Derechos de los contratos de licencia por fabricante y producto, asignación de licencias a servidores, bases de datos y usuarios, y conformidad con las instalaciones encontradas en la CMDB. El consumo es el mayor entre las licencias asignadas y las instalaciones descubiertas; el consumo por encima del derecho se resalta.

Proveedores y contratos de servicio

Finanzas → Proveedores y contratos (contratos de servicio y proveedores). Un proveedor tiene línea directa, portal de soporte, número de cliente y contactos con nivel de escalado (línea directa, 1.º y 2.º escalado, dirección). Un contrato (de soporte, mantenimiento, suscripción o garantía ampliada) tiene vigencia, plazo de preaviso, renovación automática, días de aviso previo, precio y facturación, cliente y administrador del contrato. Los niveles de soporte son los SLA del proveedor: horario del proveedor, plazo de respuesta y reparación, técnico in situ. Los equipos cubiertos son las líneas del contrato: elementos de la CMDB con su propio nivel, número de serie, periodo y, en su caso, precio (si no, el precio del contrato se reparte). Los documentos (contratos, adendas, condiciones, máx. 10 MB) se guardan en la base de datos. El fin de la vigencia se vigila a diario: aviso al administrador del contrato, al equipo y al rol Administrador de contratos al superar el primer umbral, mensaje «finalizado» tras el vencimiento, y los contratos con renovación automática se prorrogan. En una incidencia, la ficha Proveedor encuentra el soporte vigente del elemento o del hardware en el que se ejecuta; Notificar al proveedor (o la transición al estado Esperando al proveedor) inicia los plazos del proveedor, y El proveedor respondió / Reparado los cierra. El resumen de contratos muestra los contratos que vencen con el último día de preaviso, la cobertura de soporte del hardware, el hardware sin soporte, los costes anuales por proveedor y cliente y el cumplimiento de los SLA de los proveedores. Lo gestiona el administrador de contratos (contract.manage); también pueden consultarlo el gestor de incidencias y el gestor de configuración (contract.read).

Administración

integraciones, personas y accesos, configuración de la aplicación

Conexiones

Tenants y cuentas de los que se recogen datos: Azure, Azure Stack Hub, AWS, Google Cloud, Oracle Cloud, OpenShift y centro de datos. Solo se guardan identificadores y referencias al almacén de secretos (kv://, vault://…), nunca contraseñas ni claves; la aplicación se niega a guardarlas.

Importación y API

Carga de archivos FOCUS (CSV/JSON) y documentación de la API REST para scripts de recogida, monitorización (incidencias) e integraciones. Una importación repetida de la misma fuente para el mismo mes sustituye los datos anteriores, no los duplica. Las filas en moneda extranjera se convierten a CZK con el tipo del Banco Nacional Checo del primer día del periodo. Las entradas requieren un administrador o un token de API.

Notificaciones

Mensajes por correo (Resend o SendGrid) y en Slack (webhook entrante a un canal). Regla = registro (incidencia, solicitud, cambio, elemento de configuración) + evento (creación, cambio de estado, asignación, comentario, solicitud de aprobación, decisión, SLA próximos a vencer e incumplidos) + condiciones (prioridad, incidencia grave, estado destino) + plantilla + canales + destinatarios (resolutor, equipo de resolución, quien notifica, solicitante, aprobadores, equipo responsable, titulares de un rol, equipo, usuario, cualquier dirección). La plantilla tiene asunto y texto en un editor enriquecido (negrita, títulos, listas, citas, enlaces, código HTML) y parámetros {{incident.id}}, {{incident.priority_name}}, {{transition.to}}… que se insertan con un botón desde el panel derecho; los valores se completan desde el registro y se escapan. La vista previa muestra el correo y Slack con datos de ejemplo o un registro seleccionado; un envío de prueba verifica el canal. Un canal solo contiene una referencia a un secreto del Worker (env:RESEND_API_KEY, env:SLACK_WEBHOOK_PROVOZ…); la aplicación no guarda claves ni webhooks. Los SLA se comprueban cada 5 minutos (avisos 30 minutos antes del vencimiento y tras el incumplimiento, cada uno una sola vez). Con datos de demostración, los mensajes por defecto solo se registran y las direcciones de dominios de prueba (.example) nunca se entregan. La pestaña Enviados muestra un registro de entrega, incluidos errores y mensajes omitidos.

Accesos y responsabilidades

Roles del personal de TI (administrador de la plataforma, gestor de configuración, responsable de servicio, responsable de aplicación, especialista de infraestructura, gestor de cambios, gestor de incidencias, service desk, auditor, cuenta de servicio de descubrimiento) con ámbito de un cliente, un equipo (según el registro de equipos) o un elemento concreto. La matriz RACI determina quién ejecuta, aprueba, es consultado y es informado sobre los datos de configuración y los cambios; la aplicación garantiza que los roles R y A tengan los permisos correspondientes. Las cuentas de servicio reciben tokens de API; el registro de auditoría recoge cada entrada.

Flujo de trabajo

Estados y transiciones de incidencias, solicitudes, cambios y elementos de configuración. Cada estado pertenece a un estado del sistema en el que se basa la lógica de la aplicación (SLA, aprobaciones, pasos de cambio, retirada de elementos); un estado propio como «Esperando al proveedor» se comporta como En espera y el tiempo de SLA se detiene. Matriz de transiciones: fila = estado inicial, columna = estado destino; al hacer clic en una celda se añade o edita una transición. Para una transición se define la etiqueta del botón, los permisos (evaluados en el ámbito de equipo, cliente o servicio), si pueden usarla quien notifica / el solicitante / quien propone el cambio, si es un paso de aprobación (solicitudes), el comentario y los campos obligatorios (resolución, resolutor) y el aspecto del botón. A los estados de aprobación pendiente, aprobado y rechazado de los cambios solo lleva la aplicación (mediante el envío y las decisiones de los aprobadores). Los estados del sistema no se pueden eliminar, solo renombrar; un estado propio que use algún registro se desactiva. La configuración es común para los datos de producción y de demostración. Lo editan el administrador de la plataforma y el gestor de configuración (workflow.manage).

Asistente de IA

Un modelo de lenguaje ayuda allí donde se trabaja con texto: solo propone, decide una persona. Resumen de la situación (gestión de eventos): qué está pasando, la causa probable con el elemento de la CMDB, los pasos recomendados y un nivel de confianza; se crea automáticamente para situaciones a partir de una gravedad configurada y, si no, con un botón. Precumplimentación de incidencias: al crear una incidencia desde una situación, el botón «Sugerir con IA»; en Notificar una incidencia, el campo «Describa el problema con sus palabras»; el elemento, el servicio y el equipo se eligen solo de la CMDB y la prioridad la calcula siempre la aplicación a partir del impacto y la urgencia. Qué ayudó la última vez: incidencias resueltas similares según el significado del texto y consejos de su resolución. Comunicación: borrador de información de avance para clientes y de informe de cierre; se edita, copia o guarda como comentario, nada se envía automáticamente. Revisión de cambios: comprobaciones basadas en reglas (descripción, vuelta atrás, riesgo frente a parada de un servicio crítico, verificación tras el cambio, comunicación) y un resumen para los aprobadores. Los datos personales y los secretos se enmascaran antes del envío, cada propuesta se registra (Administración → Asistente de IA → Últimas propuestas) y la valoración «¿Le ha ayudado?» mide la calidad. Para clientes con la política «solo on-premise» o «sin IA» no se envían datos al modelo en la nube. Sin modelo, o una vez agotado el límite diario, se muestra una propuesta determinista. Lo gestiona el administrador de la plataforma (ai.manage): interruptores, límite, prompts versionados, política de clientes.

Más

Resumen operativo

Pantalla de inicio para la dirección. Mosaicos: servicios de negocio en operación, servicios sin punto único de fallo, número de servidores, servidores con SO sin soporte, cambios pendientes de aprobación y costes del último mes; cada uno lleva al detalle. Debajo: estado de los servicios de negocio (criticidad, SLA, estado, resiliencia, próxima parada), infraestructura (Power, virtualización, nube, contenedores, aplicaciones, red, SAN, copias de seguridad y cada cabina de discos con su ocupación, número de volúmenes, replicación HA y DR y puertos FC), redundancia (servidores en dos elementos de red, SAN en ambos fabrics, LPAR sobre un par de VIOS, datastores de producción en volúmenes en espejo, servidores de producción con copia de seguridad, servicios sin SPOF), ciclo de vida y parches, cambios y paradas (incluidos cambios vencidos y congelación de cambios), descubrimiento y calidad de datos, y costes. En el teléfono, los servicios se muestran como tarjetas.