Unidad Didáctica 4 · Monitorización de dispositivos físicos
01El Estándar IPMI y la Gestión Fuera de Banda
IPMI (Intelligent Platform Management Interface) es un estándar creado por Intel, Dell, HP y NEC para vigilar y gestionar un servidor de forma independiente de su CPU, de su sistema operativo y de si está encendido o no. Se apoya en un microcontrolador de la placa base, el BMC (Baseboard Management Controller), con alimentación propia y, normalmente, su propio puerto de red.
Sensores
Temperaturas, tensiones, velocidad de ventiladores, estado de fuentes, intrusión en el chasis.
SEL (System Event Log)
Registro de eventos de hardware: errores de memoria ECC, fallos de fuente, sobrecalentamientos.
Control de energía
Encender, apagar o reiniciar el servidor a distancia.
Consola remota
Serie sobre LAN (SOL) o KVM gráfico en las implementaciones de los fabricantes.
Inventario FRU
Datos de las piezas sustituibles: número de serie, modelo, fabricante.
Los fabricantes ofrecen versiones ampliadas del BMC con interfaz web: Dell iDRAC, HPE iLO, Lenovo XClarity Controller, Supermicro IPMI. El estándar moderno que sustituye a IPMI es Redfish (DMTF), una API REST sobre HTTPS más segura y fácil de integrar.
# ipmitool: local o remoto (-I lanplus -H IP -U usuario -P clave)
sudo ipmitool sensor list # todos los sensores y umbrales
sudo ipmitool sdr type Temperature # solo temperaturas
sudo ipmitool sel list # registro de eventos de hardware
ipmitool -I lanplus -H 10.0.99.21 -U monitor -P '***' chassis power status
# Redfish (API REST)
curl -k -u monitor:*** https://10.0.99.21/redfish/v1/Systems/1
SeguridadEl BMC da control total del servidor. Su red debe estar separada de la de usuarios, con contraseñas propias (nunca las de fábrica), firmware actualizado y, si es posible, IPMI sobre LAN desactivado en favor de Redfish o HTTPS.
02Herramientas de Monitorización en Distintas Plataformas
| Plataforma | Herramientas integradas | Herramientas habituales añadidas |
|---|---|---|
| Windows / Windows Server | Administrador de tareas, Monitor de recursos (resmon), Monitor de rendimiento (perfmon), Visor de eventos, Get-Counter | Agente de Zabbix o Checkmk, Sysinternals (Process Explorer), Windows Admin Center |
| Linux | top, htop, vmstat, iostat, sar (sysstat), free, df, ss, journalctl | Agente Zabbix, node_exporter de Prometheus, Netdata, Glances |
| macOS | Monitor de Actividad, top, vm_stat, iostat, Consola | Agentes multiplataforma |
| Hipervisores | vCenter (VMware), Proxmox VE, Hyper-V Manager | Plantillas específicas en la plataforma |
| Electrónica de red e impresoras | Interfaz web y SNMP del propio equipo | LibreNMS, plantillas SNMP |
| Servidores físicos | iDRAC, iLO, XClarity (BMC) | Plantillas IPMI o Redfish |
La plataforma central (Zabbix, Nagios, Prometheus) unifica todas estas fuentes: un mismo panel muestra el disco de un Linux, la temperatura de un iDRAC y el tóner de una impresora.
03Monitorización de Recursos
| Recurso | Métrica | Umbral orientativo de aviso / crítico | Órdenes de consulta |
|---|---|---|---|
| Carga del procesador | % de uso; carga media (load average) por núcleo | 80 % / 95 % sostenido 5-10 min | top, uptime, mpstat · Get-Counter '\Processor(_Total)\% Processor Time' |
| Espacio libre en filesystems | % y GB libres; también inodos en Linux | < 20 % / < 10 % libre | df -h, df -i · Get-PSDrive, Get-Volume |
| Memoria física | Memoria disponible, uso de swap o paginación | < 15 % / < 5 % disponible | free -h, vmstat · Get-Counter '\Memory\Available MBytes' |
| Operaciones de E/S | IOPS, latencia (await), % de uso, cola | Latencia > 20 ms en HDD o > 5 ms en SSD | iostat -x · '\PhysicalDisk(*)\Avg. Disk sec/Transfer' |
| Ficheros abiertos | Descriptores en uso frente al límite | > 80 % del límite | lsof | wc -l, cat /proc/sys/fs/file-nr, ulimit -n · handle.exe (Sysinternals) |
| Impresoras | Estado, nivel de consumibles, atascos, cola | Fungible < 15 %; cola detenida | SNMP Printer MIB, lpstat, Get-PrintJob |
| Otros recursos | Temperatura, ventiladores, fuentes, SAI (carga y autonomía) | Según el fabricante | sensors, ipmitool, upsMIB |
# Linux: foto rápida de recursos
uptime # carga media de 1, 5 y 15 minutos
free -h ; vmstat 1 5
df -hT -x tmpfs ; df -i
iostat -xz 2 3
cat /proc/sys/fs/file-nr # descriptores asignados / libres / máximo
sudo lsof -u www-data | wc -l # ficheros abiertos por un usuario
Interpretar la carga mediaEn Linux, una carga media de 4 en un equipo de 4 núcleos significa que está ocupado al completo; una de 8 indica que hay procesos esperando. Compara siempre la carga con el número de núcleos (nproc).
04Monitorización de la Infraestructura: SAI, PDU y Sensores Ambientales
Los «otros recursos» del programa incluyen lo que rodea a los equipos: si falla la alimentación o la climatización, caen todos a la vez. Esta infraestructura también se vigila desde la plataforma.
| Elemento | Qué vigilar | Cómo | Alarma típica |
|---|---|---|---|
| SAI | Estado (red o batería), carga %, autonomía restante, estado de la batería, temperatura | Tarjeta de red SNMP (upsMIB o MIB del fabricante) o USB con NUT o el software del fabricante | «En batería», autonomía < 10 min, batería a sustituir |
| PDU gestionable | Consumo por toma y total (A, kW), estado de cada toma | SNMP o web | Consumo cercano al límite de la línea |
| Sensores ambientales | Temperatura y humedad en la entrada de los armarios, fugas de agua, humo, puerta abierta | Sondas SNMP o Modbus, o sensores del propio SAI o PDU | Más de 27 °C en la entrada, agua detectada, puerta abierta fuera de horario |
| Climatización | Estado, alarmas, temperatura de impulsión y retorno | Integración BMS o contactos secos | Unidad parada |
| Grupo electrógeno | Combustible, estado, pruebas | Contactos o SNMP | Arranque fallido en la prueba |
# NUT (Network UPS Tools) en Linux con un SAI USB
sudo apt install -y nut
# /etc/nut/ups.conf: [sai1] driver = usbhid-ups port = auto
sudo upsdrvctl start && sudo systemctl restart nut-server
upsc sai1@localhost | grep -E 'ups.status|battery.charge|battery.runtime|ups.load'
# ups.status: OL = en red · OB = en batería · LB = batería baja
Apagado ordenadoLa monitorización del SAI no solo avisa: el software del SAI (NUT, PowerChute, Eaton IPM) debe apagar de forma ordenada los servidores y las máquinas virtuales antes de que se agote la batería. Esa secuencia hay que probarla, no basta con configurarla.
05Monitorización del Uso de Servicios de Red
Un equipo puede estar encendido y sano pero con su servicio caído. Por eso se comprueban también los servicios, simulando lo que haría un cliente.
| Servicio | Puerto | Qué se comprueba | Comprobación manual |
|---|---|---|---|
| SMTP (envío de correo) | 25, 587, 465 | Que responde con su saludo 220, tiempo de respuesta, cola de correo pendiente | nc -v servidor 25 · Test-NetConnection servidor -Port 587 |
| POP3 / IMAP (recepción) | 110/995 · 143/993 | Respuesta +OK (POP3) o * OK (IMAP), validez del certificado TLS | openssl s_client -connect servidor:995 |
| HTTP / HTTPS | 80 / 443 | Código de respuesta 200, tiempo de carga, texto esperado en la página, caducidad del certificado, conexiones abiertas | curl -o /dev/null -s -w '%{http_code} %{time_total}\n' https://web |
| SSH (conexión remota segura) | 22 | Banner SSH, sesiones abiertas, intentos fallidos | ssh -v usuario@servidor · who · ss -tn state established '( dport = :22 or sport = :22 )' |
| Otros: DNS, bases de datos, LDAP, SMB | 53, 3306, 389, 445 | Resolución correcta, consulta de prueba, autenticación | dig @servidor dominio · Test-NetConnection -Port 445 |
# Conexiones HTTP abiertas en un servidor web
ss -tan state established '( sport = :443 )' | wc -l
REM Windows
Get-NetTCPConnection -LocalPort 443 -State Established | Measure-Object
06Parámetros de Configuración y Rendimiento de los Dispositivos Físicos
Optimización de la memoria caché
- Caché de disco del sistema operativo: Linux usa toda la RAM libre como caché de páginas (aparece en buff/cache y se libera sola cuando hace falta). No es memoria «perdida».
- Parámetros de Linux como vm.swappiness (tendencia a usar la swap) o vm.dirty_ratio (cuántos datos pendientes de escribir se acumulan) ajustan este comportamiento.
- Caché de escritura de las controladoras RAID: write-back (más rápida, requiere batería o flash de protección) frente a write-through (más segura y lenta).
- Caché de escritura en disco en Windows: Administrador de dispositivos → disco → Directivas.
Tamaño del fichero de paginación (swap)
- Windows: pagefile.sys, gestionado automáticamente por el sistema por defecto. Si hay que fijarlo, una referencia es entre 1 y 1,5 veces la RAM, y suficiente para el volcado de memoria que se quiera conservar.
- Linux: partición o fichero swap. En servidores con mucha RAM basta con unos pocos GB; si se usa hibernación, debe ser al menos igual a la RAM.
- Un uso de paginación alto y constante no se arregla con una swap mayor, sino con más RAM o con menos carga.
REM Windows: ver el fichero de paginación
Get-CimInstance Win32_PageFileUsage | Select Name,AllocatedBaseSize,CurrentUsage,PeakUsage
# Linux
swapon --show ; cat /proc/sys/vm/swappiness
sudo sysctl vm.swappiness=10 # temporal; persistente en /etc/sysctl.d/
Memoria dedicada a la máquina virtual Java (JVM)
Muchas aplicaciones de servidor (Tomcat, Elasticsearch, Jenkins, consolas de gestión) se ejecutan sobre Java, que reserva su propia memoria (heap). Si es pequeña, la aplicación pasa mucho tiempo liberando memoria (garbage collector) o falla con OutOfMemoryError; si es demasiado grande, quita memoria al resto del sistema.
# Parámetros típicos de arranque de la JVM
java -Xms2g -Xmx2g -XX:+UseG1GC -jar aplicacion.jar
# -Xms = memoria inicial -Xmx = memoria máxima del heap
# Tomcat: en bin/setenv.sh -> CATALINA_OPTS="-Xms1g -Xmx2g"
jcmd <PID> GC.heap_info # uso actual del heap
Otros parámetros: el número máximo de ficheros abiertos (ulimit -n), los planes de energía de la CPU, el tamaño de los búferes de red y la MTU, y el número de hilos o procesos trabajadores de los servicios.
07Alarmas Activas y Pasivas, Eventos y Alertas
| Concepto | Definición | Ejemplo |
|---|---|---|
| Evento | Cualquier cambio de estado significativo que se registra | El disco pasa del 79 % al 81 % |
| Alarma activa (sondeo / polling) | La plataforma pregunta periódicamente y compara con un umbral | Cada 60 s se consulta el espacio libre |
| Alarma pasiva (trap / push) | El propio equipo envía el aviso cuando ocurre algo | Trap SNMP del SAI: «funcionando con batería» |
| Alerta | Notificación dirigida a una persona o a un sistema porque un evento requiere atención | Correo y mensaje al operador de guardia |
| Umbral | Valor que separa lo normal de lo anómalo; puede ser fijo, dinámico (según la línea base) o de tendencia | Aviso al 85 %, crítico al 95 % |
| Histéresis | Margen para no oscilar entre alarma y recuperación | Salta al 90 % y solo se recupera por debajo del 85 % |
| Dependencia | Relación que evita alertas en cascada | Si cae el router de la sede, no se alerta de cada equipo de esa sede |
# Ejemplos de expresiones de disparo (trigger) en Zabbix
last(/SRV-WEB/vfs.fs.size[/,pfree])<10 # menos de un 10 % libre
avg(/SRV-WEB/system.cpu.util,10m)>90 # CPU media de 10 min > 90 %
nodata(/SRV-WEB/agent.ping,5m)=1 # el agente no informa en 5 min
timeleft(/SRV-BD/vfs.fs.size[/datos,pfree],7d,0)<14d # se llenará en menos de 14 días
Unidad Didáctica 5 · Modelos de gestión y monitorización: gestión de servicios según ITIL
08Estructura de Procesos en ITIL y Relación entre Ellos
El BOE de 2011 se basa en ITIL v3, que organizaba la gestión en cinco fases del ciclo de vida del servicio. ITIL 4 (2019), la versión vigente, mantiene los mismos procesos clave pero los llama prácticas y los integra en un sistema de valor del servicio.
| Fase ITIL v3 | Procesos principales |
|---|---|
| Estrategia del servicio | Gestión financiera, de la demanda, de la cartera de servicios |
| Diseño del servicio | Niveles de servicio, catálogo, capacidad, disponibilidad, continuidad, seguridad, proveedores |
| Transición del servicio | Gestión de cambios, de la configuración y activos, de versiones y despliegues, del conocimiento |
| Operación del servicio | Gestión de eventos, de incidencias, de peticiones, de problemas y de accesos; función del Centro de Servicio al Usuario |
| Mejora continua | Proceso de mejora en siete pasos |
Prácticas que más afectan al operador
| Práctica | Objetivo | Se relaciona con… |
|---|---|---|
| Monitorización y gestión de eventos | Detectar y clasificar los cambios de estado | Genera incidencias cuando el evento lo merece |
| Gestión de incidencias | Restablecer el servicio normal lo antes posible | Usa la CMDB; puede abrir un problema |
| Gestión de peticiones de servicio | Atender solicitudes normales (alta de usuario, nuevo PC, cambio de tóner) | Catálogo de servicios |
| Gestión de problemas | Encontrar la causa raíz de incidencias repetidas y eliminarla | Errores conocidos; propone cambios |
| Habilitación del cambio (gestión de cambios) | Que los cambios se hagan con el mínimo riesgo | Configuración, versiones |
| Gestión de la configuración | Mantener la CMDB fiable | Todas las demás |
| Gestión de niveles de servicio | Acordar y vigilar los SLA | Informes de la monitorización |
Incidencia frente a problemaUna incidencia es una interrupción o degradación concreta (la impresora de RR. HH. no imprime). Un problema es la causa, a menudo desconocida, de una o varias incidencias (el controlador instalado el martes falla con esa impresora). La incidencia se resuelve rápido, a veces con una solución temporal; el problema se investiga a fondo.
09Gestión de Eventos, de Problemas y del Conocimiento
Gestión de eventos
- Detección: la plataforma recibe o genera el evento.
- Filtrado: se descartan los puramente informativos.
- Correlación y agrupación: varios eventos con una misma causa se unen en uno (dependencias, deduplicación).
- Respuesta: registrar, ejecutar una acción automática, abrir una incidencia o una petición de cambio, o escalar.
- Revisión y cierre: se comprueba que la respuesta fue la adecuada.
Gestión de problemas
| Concepto | Definición | Ejemplo |
|---|---|---|
| Problema | Causa, real o potencial, de una o varias incidencias | Las impresoras de planta se desconectan cada pocos días |
| Error conocido | Problema analizado con la causa identificada, aunque aún no esté resuelto | El firmware 2.1 de las impresoras pierde la IP al renovar DHCP |
| Solución temporal (workaround) | Forma de reducir o eliminar el impacto mientras no hay solución definitiva | Reservar IP fijas en el DHCP |
| Base de datos de errores conocidos (KEDB) | Registro de errores conocidos y sus soluciones | La consulta el nivel 1 para resolver al primer contacto |
| Enfoque | Cuándo |
|---|---|
| Reactivo | Tras incidencias repetidas o una incidencia grave |
| Proactivo | Analizando tendencias de la monitorización y de los tiques antes de que haya incidencias |
Gestión del conocimiento
- Artículos de la base de conocimiento: síntoma, causa, solución paso a paso, a quién escalar.
- Redactados con el vocabulario del usuario («no me sale el tique de caja»), no solo con el técnico.
- Revisados y con fecha; se retiran los obsoletos.
- Indicador: porcentaje de incidencias resueltas con un artículo de la base.
10El Centro de Servicio al Usuario: Funciones, Niveles y Responsabilidades
El Centro de Servicio al Usuario (CSU, Service Desk, CAU) es el punto único de contacto entre los usuarios y el departamento de TI. Recibe todas las incidencias y peticiones, las registra, las resuelve o las deriva y mantiene informado al usuario.
Modelos de organización
- Local: en la misma sede que los usuarios.
- Centralizado: uno solo para toda la organización, a menudo con soporte remoto.
- Virtual: personal repartido en varios lugares que trabaja como uno solo gracias a la herramienta común.
- Follow the sun: centros en distintos husos horarios para dar servicio 24 horas.
Niveles de soporte
| Nivel | Quién | Funciones |
|---|---|---|
| Nivel 0 (autoservicio) | El propio usuario | Portal, base de conocimiento, restablecimiento de contraseña, chatbot |
| Nivel 1 | Operadores del CSU | Registro, clasificación, priorización, solución de lo conocido, escalado, comunicación con el usuario |
| Nivel 2 | Técnicos especialistas | Incidencias que requieren conocimientos o permisos mayores: sistemas, red, aplicaciones |
| Nivel 3 | Expertos, desarrollo o fabricantes | Fallos complejos, errores de software, garantías y sustitución de hardware |
Responsabilidades del personal
- Atender con amabilidad y registrar TODAS las peticiones, incluso las que se resuelven en un minuto.
- Clasificar y priorizar correctamente.
- Aplicar los procedimientos y la base de conocimiento.
- Escalar a tiempo, con toda la información.
- Informar al usuario del avance y confirmar con él el cierre.
- Detectar tendencias (muchas llamadas por lo mismo) y comunicarlas.
11Procesos y Procedimientos del Centro de Servicio al Usuario
- 1. Detección y registro: llega por teléfono, correo, portal, chat o desde la plataforma de monitorización. Se crea un tique con fecha, usuario, equipo afectado (del inventario o CMDB) y descripción.
- 2. Clasificación: tipo (incidencia o petición), categoría (hardware > impresora > atasco) y servicio afectado.
- 3. Priorización: según impacto y urgencia (matriz de prioridad).
- 4. Diagnóstico inicial: preguntas guiadas, base de conocimiento, errores conocidos.
- 5. Escalado: funcional (a otro grupo más especializado) o jerárquico (a un responsable, por gravedad o por riesgo de incumplir el SLA).
- 6. Investigación y diagnóstico: por el grupo asignado.
- 7. Resolución y recuperación: se aplica la solución y se comprueba que el servicio funciona.
- 8. Cierre: se confirma con el usuario, se documenta la solución y la categoría final, y se mide la satisfacción.
Matriz de prioridad
| Impacto \ Urgencia | Alta | Media | Baja |
|---|---|---|---|
| Alto (muchos usuarios o un servicio crítico) | P1 · Crítica | P2 · Alta | P3 · Media |
| Medio (un departamento) | P2 · Alta | P3 · Media | P4 · Baja |
| Bajo (un usuario, con alternativa) | P3 · Media | P4 · Baja | P5 · Planificada |
| Prioridad | Tiempo de respuesta orientativo | Tiempo de resolución orientativo |
|---|---|---|
| P1 | 15 minutos | 4 horas |
| P2 | 30 minutos | 8 horas |
| P3 | 2 horas | 2 días laborables |
| P4 | 1 día | 5 días laborables |
Incidencia grave (major incident)Una P1 que afecta a toda la organización sigue un procedimiento especial: un responsable coordina, se informa a dirección y a los usuarios a intervalos fijos, y al final se hace una revisión para aprender de lo ocurrido.
Unidad Didáctica 6 · Técnicas de diagnóstico de incidencias y alarmas del subsistema físico
12Clasificación de Incidencias y Alarmas de los Dispositivos Físicos
| Tipo | Ejemplos | Señales habituales |
|---|---|---|
| Caídas del sistema | Pantallazo azul (BSOD), kernel panic, reinicios espontáneos, cuelgues | El equipo deja de responder al ping y al agente; SEL con errores de memoria o temperatura |
| Servicios no disponibles | Web, correo o carpetas compartidas que no responden aunque el equipo esté vivo | Fallan las comprobaciones de servicio; el ping sí responde |
| Alertas automáticas de fallos de periféricos | Disco averiado, fuente caída, ventilador detenido, impresora sin tóner, librería atascada | Traps SNMP, correos del BMC, LED ámbar |
| Umbral de uso de disco excedido | Volumen de datos al 95 %, registros (logs) que crecen sin control | Alarma de espacio libre; tendencia de llenado |
| Rendimiento degradado | Lentitud por un disco en RAID degradado, CPU con limitación térmica (throttling) | Latencias altas; temperaturas altas |
| Infraestructura | Corte eléctrico, SAI en batería, climatización averiada | Traps del SAI, sensores de temperatura de la sala |
| Otras | Intrusión en el chasis, cambio de hardware no autorizado | Sensor de intrusión, cambios en el inventario |
13Estrategias y Herramientas para Detectar y Diagnosticar Anomalías
Estrategias para detectar situaciones anómalas
- Comparar con la línea base y con equipos iguales (si un servidor de un cluster va más lento que sus gemelos, el problema está en él).
- Buscar cambios recientes: casi la mitad de las incidencias siguen a un cambio (actualización, traslado, nuevo cable).
- Correlacionar en el tiempo: qué más pasó a la misma hora.
- Vigilar tendencias, no solo umbrales: crecimiento de sectores reasignados, de temperatura o de errores CRC.
- Revisar los registros de forma proactiva, no solo cuando hay una queja.
Métodos de diagnóstico
| Método | Cómo se aplica |
|---|---|
| De lo general a lo particular | ¿Afecta a todos o a uno? ¿A todo el servicio o a una función? |
| Por capas (modelo OSI) | Físico (cable, LED, alimentación) → enlace → red → aplicación |
| Divide y vencerás | Partir el camino en dos y probar en el punto medio |
| Sustitución | Cambiar el componente sospechoso por uno que funciona (cable, fuente, módulo de memoria) |
| Reproducción | Provocar de nuevo el fallo de forma controlada para confirmar la causa |
| Base de conocimiento | Consultar errores conocidos, notas del fabricante y casos anteriores |
Herramientas de diagnóstico de dispositivos físicos
# Registros
journalctl -p err -b # errores del arranque actual (Linux)
dmesg -T | tail -50 # mensajes del núcleo: discos, memoria, USB
sudo ipmitool sel elist # eventos de hardware del BMC
REM Windows
Get-WinEvent -LogName System -MaxEvents 50 | Where Level -le 2
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'}
REM (WHEA = errores de hardware: CPU, memoria, PCIe)
# Pruebas de componentes
memtest86+ (arranque) · smartctl -t long · stress-ng --cpu 4 --timeout 60s
Métodos establecidos para solucionar incidencias
- Solución temporal (workaround): restablece el servicio aunque la causa siga ahí (mover la cola a otra impresora).
- Solución definitiva: elimina la causa (cambiar el fusor).
- Procedimiento documentado: pasos aprobados para incidencias frecuentes, que el nivel 1 puede aplicar.
- Escalado al fabricante: abrir caso con los registros (SEL, logs de la controladora, informe TSR o AHS), número de serie y contrato.
14Análisis de Causa Raíz
Resolver la incidencia restablece el servicio; encontrar la causa raíz evita que se repita. Tres técnicas sencillas cubren la mayoría de los casos.
Los cinco porqués
- ¿Por qué se cayó la web de reservas? Porque el servidor se quedó sin espacio en disco.
- ¿Por qué se quedó sin espacio? Porque el log de la aplicación ocupaba 180 GB.
- ¿Por qué ocupaba tanto? Porque el log no se rotaba.
- ¿Por qué no se rotaba? Porque al actualizar la aplicación cambió la ruta del log y la configuración de logrotate apuntaba a la antigua.
- ¿Por qué no se detectó? Porque el procedimiento de actualización no incluía revisar la rotación ni había alarma de tendencia de llenado. → Causas raíz: procedimiento incompleto y falta de alarma predictiva.
Diagrama de Ishikawa (espina de pescado)
Se dibuja el problema en la «cabeza» y, en las espinas, las categorías de causas posibles, para no olvidar ninguna. En TI se suelen usar estas seis:
Hardware
Componentes, firmware, envejecimiento.
Software
Versiones, parches, configuración, errores conocidos.
Red
Enlaces, DNS, cortafuegos, latencia.
Personas
Formación, errores humanos, carga de trabajo.
Procesos
Procedimientos incompletos, cambios sin control.
Entorno
Alimentación, temperatura, proveedores.
Línea temporal
Ordenar cronológicamente todos los sucesos relacionados (cambios, alarmas, quejas, acciones tomadas) con la hora exacta. Suele revelar qué cambió justo antes del problema. Requiere que todos los equipos tengan la hora sincronizada por NTP.
Revisión sin culpablesEl análisis se centra en qué falló en el sistema y en los procedimientos, no en buscar a quién culpar. Si las personas temen ser señaladas, ocultan información y las causas reales nunca salen a la luz.
15Herramientas de Gestión Remota de Dispositivos
| Herramienta | Tipo | Uso |
|---|---|---|
| iDRAC, iLO, XClarity, IPMI | Consola fuera de banda (BMC) | Ver la pantalla del servidor, montar una ISO virtual, encender y apagar, aunque el SO no arranque |
| KVM sobre IP | Hardware | Teclado, vídeo y ratón de varios equipos a distancia |
| Servidor de consolas serie | Hardware | Acceso a los puertos de consola de switches y routers |
| Escritorio remoto (RDP), VNC | Terminal remoto gráfico | Administrar servidores y puestos Windows o Linux |
| SSH | Terminal remoto seguro | Administración por línea de comandos |
| Asistencia remota (Quick Assist, AnyDesk, RustDesk, TeamViewer) | Control remoto con permiso del usuario | Soporte de nivel 1 a usuarios |
| PowerShell Remoting, Windows Admin Center | Gestión remota | Ejecutar órdenes y administrar muchos equipos a la vez |
| PDU gestionables | Hardware | Apagar y encender un enchufe concreto a distancia |
Buenas prácticasAccesos remotos siempre con cuentas personales (no compartidas), autenticación multifactor, a través de VPN o de un bastión, con registro de las sesiones y, en el soporte a usuarios, con su consentimiento expreso.
16Herramientas de Gestión de Incidencias: Registro, Valoración y Cierre
Las herramientas de gestión de incidencias (ticketing) registran todo el ciclo de vida de cada incidencia. Ejemplos: GLPI (incluye inventario), osTicket, Zammad, Request Tracker, Jira Service Management, ServiceNow, Freshservice.
Registro de incidentes y su valoración
| Campo del tique | Contenido |
|---|---|
| Identificador y fechas | Número único, apertura, primera respuesta, resolución, cierre |
| Solicitante y contacto | Usuario afectado, teléfono, ubicación |
| Elemento afectado | Equipo o servicio vinculado al inventario o CMDB |
| Origen | Teléfono, correo, portal, monitorización |
| Categoría | Hardware > Disco, Red > Wi-Fi… |
| Impacto, urgencia y prioridad | Valoración según la matriz |
| Grupo y técnico asignados | Quién la tiene en cada momento |
| Seguimiento | Notas internas y comunicaciones con el usuario, con fecha y autor |
| Solución y causa | Qué se hizo; si fue temporal o definitiva |
| Tiempo invertido | Minutos de actuación de cada técnico |
Estados y cierre
| Estado | Significado |
|---|---|
| Nueva | Registrada, sin asignar |
| Asignada / En curso | Un técnico trabaja en ella |
| En espera (pendiente) | Se espera al usuario, a un proveedor o a una pieza; el reloj del SLA puede pararse |
| Resuelta (cierre temporal) | Se ha aplicado una solución y se espera la confirmación del usuario, o se ha aplicado una solución temporal |
| Cerrada (cierre definitivo) | El usuario confirma, o pasa el plazo establecido sin respuesta; ya no se puede modificar |
| Reabierta | El usuario indica que el problema sigue |
Cierre temporal frente a definitivoSi se ha resuelto con una solución temporal, la incidencia puede cerrarse para el usuario, pero hay que abrir un problema vinculado para que alguien busque la causa. Si no, la incidencia volverá.
17Control de Tiempos, Rechazos, Reclamaciones e Informes
Rechazar o reclamar incidencias
- Rechazar: el grupo que la recibe la devuelve porque no le corresponde, está duplicada o no es una incidencia (es una petición o una consulta). Debe hacerse siempre con un motivo, nunca dejarla «muerta».
- Reclamar: el usuario o un responsable insiste porque no se ha resuelto o se ha cerrado mal; puede elevar la prioridad o provocar un escalado jerárquico.
- Reasignación: si pasa de grupo en grupo sin dueño (efecto ping-pong), el CSU debe tomar el control y coordinar.
Registro del tiempo de actuación y control de tiempos máximos
| Medida | Definición |
|---|---|
| Tiempo de primera respuesta | Desde la apertura hasta el primer contacto o asignación |
| Tiempo de resolución | Desde la apertura hasta la solución (sin contar los tiempos en espera si el SLA lo permite) |
| Tiempo de actuación | Tiempo real de trabajo de los técnicos (para costes y cargas) |
| Cumplimiento del SLA | % de incidencias resueltas dentro del tiempo máximo de su prioridad |
Las herramientas muestran avisos cuando una incidencia se acerca al límite (por ejemplo, al 75 % del tiempo) y escalan automáticamente si se supera.
Elaboración de informes
| Indicador (KPI) | Para qué sirve |
|---|---|
| N.º de incidencias por categoría, equipo y sede | Detectar puntos débiles y candidatos a problema |
| Tiempo medio de respuesta y de resolución por prioridad | Vigilar el cumplimiento del SLA |
| % resuelto en primer contacto (FCR) | Eficacia del nivel 1 y de la base de conocimiento |
| Incidencias reabiertas | Calidad de las soluciones |
| Disponibilidad de cada servicio | Informe a dirección y clientes |
| Satisfacción del usuario | Calidad percibida |
| Top 10 de equipos con más incidencias | Decidir sustituciones |
Un buen informeBreve, con gráficos de tendencia, comparado con el mes anterior y con los objetivos, y que termine con conclusiones y acciones propuestas, no solo con números.
18Caso Práctico Resuelto: de la Alarma al Cierre
Martes, 09:12. La plataforma de monitorización genera dos alertas casi a la vez en una empresa de distribución con 120 empleados.
| Hora | Suceso o acción | Quién |
|---|---|---|
| 09:12 | Alerta Alta: «SRV-ERP: latencia de disco > 50 ms durante 5 min». Alerta Media: «SRV-ERP: RAID degradado» | Plataforma |
| 09:13 | Se abre automáticamente la incidencia 2026-1184 vinculada al servidor en la CMDB (servicio ERP, 95 usuarios) | Integración monitorización-tiques |
| 09:15 | El operador reconoce las alertas; prioridad P2 (impacto alto, el servicio sigue funcionando degradado) | Nivel 1 |
| 09:18 | Consola iDRAC: disco 3 en fallo, disco de reserva en reconstrucción (avance 2 %). SEL: «Drive 3 removed from array» | Nivel 1 |
| 09:20 | Comunicado a los usuarios: el ERP puede ir lento durante unas horas | Nivel 1 |
| 09:25 | Escalado funcional a Sistemas (nivel 2) y apertura de caso de garantía con el fabricante con el informe del controlador | Nivel 1 |
| 13:40 | Reconstrucción completada; latencia normal. La incidencia pasa a «En espera» del disco de repuesto | Nivel 2 |
| Jueves 10:05 | Llega el disco; se sustituye en caliente siguiendo el procedimiento; pasa a ser el nuevo disco de reserva | Nivel 2 |
| Jueves 10:30 | Se actualiza el inventario (números de serie), se registra el tiempo invertido (95 min) y se resuelve | Nivel 2 |
| Viernes | El usuario responsable confirma; cierre definitivo | CSU |
Análisis posterior
- Tiempo de primera respuesta: 3 minutos (SLA de P2: 30 min). Cumplido.
- Tiempo de resolución del servicio (vuelta al rendimiento normal): 4 h 28 min (SLA: 8 h). Cumplido.
- El SMART del disco 3 mostraba sectores reasignados en aumento desde hacía tres semanas: no había alarma de tendencia sobre ese atributo. Se abre el problema PRB-0042 para añadir la vigilancia SMART predictiva a la plantilla de los servidores.
- Se redacta el artículo «Sustitución de disco en caliente en servidores PowerEdge» en la base de conocimiento.
19Glosario de la Parte II
- IPMI / BMC
- Estándar y controlador de gestión fuera de banda del servidor, independiente del sistema operativo.
- SEL
- Registro de eventos de hardware del BMC.
- Redfish
- API REST moderna para gestionar servidores, sucesora de IPMI.
- Alarma activa
- Se genera porque la plataforma consulta periódicamente y compara con un umbral.
- Alarma pasiva
- La envía el propio equipo cuando ocurre algo (trap, syslog).
- Histéresis
- Margen entre el umbral de disparo y el de recuperación para evitar oscilaciones.
- ITIL 4
- Marco de buenas prácticas de gestión de servicios de TI organizado en 34 prácticas.
- CSU / Service Desk
- Punto único de contacto entre usuarios y TI.
- Incidencia
- Interrupción o degradación no planificada de un servicio.
- Petición de servicio
- Solicitud normal de un usuario (alta, cambio de tóner, nuevo equipo).
- Problema / error conocido
- Causa de incidencias / problema con la causa ya identificada.
- Escalado funcional / jerárquico
- Pasar a un grupo más especializado / a un responsable con más autoridad.
- SLA
- Acuerdo de nivel de servicio con tiempos de respuesta y resolución.
- FCR
- Porcentaje de incidencias resueltas en el primer contacto.
- Causa raíz
- Origen último de un problema; si se elimina, no se repite.
20Autoevaluación de la Parte II
¿Por qué el BMC debe estar en una red separada?
Porque da control total del servidor (encender, apagar, consola, montar ISO) aunque el sistema operativo esté caído. Si se compromete, el atacante controla el hardware.
En Linux, una carga media de 6 en un servidor de 4 núcleos, ¿qué indica?
Que hay más procesos listos para ejecutarse que núcleos: hay procesos esperando CPU, o bien muchos procesos bloqueados esperando E/S. Hay que mirar también el %wa (espera de E/S).
¿Qué diferencia hay entre una alarma activa y una pasiva? Pon un ejemplo de cada una.
Activa: la plataforma pregunta y compara (consultar el espacio libre cada minuto). Pasiva: el equipo avisa por su cuenta (trap del SAI al pasar a batería).
¿Para qué sirve configurar dependencias entre desencadenadores?
Para evitar alertas en cascada: si cae el switch de una planta, se avisa de él y no de los 40 equipos que dependen de él.
¿Cuál es la prioridad de una incidencia de impacto bajo y urgencia alta según la matriz vista?
P3 · Media.
¿Qué diferencia hay entre un cierre temporal y uno definitivo?
En el temporal se ha aplicado una solución (a veces provisional) y se espera la confirmación del usuario; en el definitivo el usuario confirma o vence el plazo y la incidencia ya no se puede modificar.
¿Qué indicador revela que las soluciones del nivel 1 no son buenas?
El número de incidencias reabiertas.
Una impresora se desconecta cada semana y siempre se soluciona reiniciándola. ¿Qué deberías hacer además de reiniciarla?
Registrar un problema para buscar la causa raíz (firmware, DHCP, ahorro de energía) y, cuando se conozca, registrar el error conocido y su solución en la base de conocimiento.
¿Qué información incluirías al escalar un fallo de hardware al fabricante?
Modelo y número de serie, contrato o garantía, descripción del síntoma, registros (SEL, log de la controladora, informe de diagnóstico del fabricante), pruebas ya hechas y datos de contacto.