Aprendizaje mediante Incidentes Reales
La documentación técnica es vital, pero nada sustituye la experiencia de resolver un incidente bajo presión. Esta sección documenta casos reales enfrentados por consultores senior, detallando el síntoma, el diagnóstico y la solución final.
Caso 1: El "Fantasma" de la Lentitud en Nómina
Síntoma: La ejecución de nómina mensual, que suele tardar 2 horas, excedió las 8 horas y el sistema quedó bloqueado para el resto de usuarios.
Diagnóstico Técnico:
- ST03N: Reveló que el 90% del tiempo era "Wait Time" para Work Processes de diálogo.
- SM50: Todos los procesos DIA ocupados con acción
SleepoDirect Readde la tablaPA0001. - ST05: Identificó un programa Z disparado por la nómina que hacía un
SELECT *en un bucle sobre 50.000 empleados sin usar el índice dePERNR.
Solución:
Se detuvieron los procesos Z en la SM50. El desarrollador optimizó el código usando
INTO TABLE una sola vez fuera del bucle. El tiempo de ejecución bajó de 8 horas a 15
minutos.
Caso 2: Caída Masiva de Interfaces tras Upgrade
Síntoma: Tras aplicar un Support Package Stack, todas las interfaces salientes hacia el
CRM fallaron con error RFC_COMMUNICATION_FAILURE.
Diagnóstico Técnico:
- SM59: "Connection Test" devolvía
SSL Handshake Failed. - STRUST: Reveló que el PSE de SSL Client se había corrompido durante el upgrade y perdió los certificados raíz del servidor destino.
- ST11 (dev_icm): Confirmó "Peer certificate not trusted".
Solución:
Se re-importaron los certificados raíz en la STRUST, se reinició el ICM
(SMICM -> Signal -> Hard Exit) y las comunicaciones se restablecieron al instante.
Caso 3: Corrupción de Job Log y "File Full"
Síntoma: Todos los jobs en SM37 empezaron a fallar con status "Cancelled"
sin generar dump en ST22 ni log de job.
Diagnóstico Técnico:
- SM21: Mostraba el mensaje
Operating system call 'write' failed (error 28). - Nivel OS (df -h): El sistema de archivos
/usr/sap/SID/SYS/global(donde se guardan los logs físicos de los jobs) estaba al 100% de uso.
Solución:
Se ejecutó el programa estándar RSBTCDEL2 para limpiar logs de jobs antiguos. Se aumentó la
cuota de disco del filesystem para evitar recurrencia.
Caso 4: Saturación de Puertos RFC (WSAENOBUFS)
Síntoma: El servidor de aplicaciones se volvió inalcanzable para nuevas conexiones de usuarios, aunque el servidor estaba encendido y con CPU baja.
Diagnóstico Técnico:
- OS Nivel (netstat): Reveló 65.000 sockets en estado
TIME_WAITapuntando a un sistema externo de BI. - Causa: Un proceso extractor mal configurado abría y cerraba conexiones RFC cada segundo en lugar de usar una Persistent Connection.
Solución:
Se ajustaron los parámetros de TCP a nivel OS para reducir el tiempo de TIME_WAIT y se
corrigió el código del extractor para reutilizar la conexión RFC.
Preguntas Frecuentes (FAQ)
¿Por qué es importante documentar casos reales de troubleshooting?
Porque permite capitalizar la experiencia, reduciendo los tiempos de resolución ante incidentes similares en el futuro y facilitando la formación de nuevos administradores.
¿Qué herramientas se usaron para diagnosticar la lentitud en nómina?
Se utilizaron ST03N para ver el tiempo de espera, SM50 para identificar procesos bloqueados y ST05 para encontrar el código SQL ineficiente.
¿Cómo se resolvió la caída de interfaces SSL?
Re-importando los certificados raíz en la transacción STRUST y reiniciando el servicio ICM para refrescar la configuración de seguridad.