Soporte L16 módulos10-12 días

Track Soporte de Primer Nivel (L1)

Plan de capacitación para soporte L1: operar, monitorear, triagear, recolectar evidencia y escalar bien.

Progreso del track0 / 6 módulos

Objetivos y criterios

Track Soporte de Primer Nivel (L1)

Objetivo del rol

Operar, monitorear, triagear, recolectar evidencia y escalar bien. Un L1 no resuelve root cause: filtra ruido y entrega tickets bien armados al senior o al fabricante (Precisely / M81 / IBM).

Audiencia y perfil

  • •Ingenieros de soporte / mesa de servicios.
  • •Eventualmente ya con experiencia general (Windows/Linux), pero no necesariamente con IBM i.
  • •Expectativa: turno operativo, monitoreo activo, atención a tickets.

Prerequisitos

  • •Onboarding completo y acceso a las herramientas de ticketing.
  • •Acceso al laboratorio compartido (en modo lectura inicial).
  • •Cuenta en portales Precisely Support y M81 con permisos básicos.

Día 0 común

2 horas. Base común de plataforma. Ver modulo-hardware.md y modulo-ibm-i.md.

Plan de capacitación

| Orden | Tema | Duración | Material principal | |---|---|---|---| | 1 | Hardware iSeries / Power | 1 día | Hardware — Para Soporte L1 | | 2 | IBM i (sistema operativo) | 2 días | IBM i — Para Soporte L1 | | 3 | AIX | 1 día | AIX — Para Soporte L1 | | 4 | Assure Quick EDD | 3 días | Quick EDD — Para Soporte L1 | | 5 | Connect CDC | 2 días | Connect CDC — Para Soporte L1 | | 6 | Flash For i | 1 día | Flash For i — Para Soporte L1 |

Total: 10 días lectivos. Hasta 12 días si se incluye semana de práctica supervisada con tickets reales.

Foco práctico del track

Capacidades que un L1 debe demostrar al final:

  1. •Identificación rápida del entorno del cliente — versión IBM i + TR, generación Power, versión de cada aplicativo.
  2. •Lectura de joblog y mensajes (DSPMSG, WRKMSG QSYSOPR, errpt en AIX).
  3. •Reconocimiento de las alertas y errores típicos de cada producto:
    • •Quick EDD: apply lag, inactive subsystem, object not journaled.
    • •Connect CDC: pipeline detenido, error de auth contra destino, tabla nueva sin journaling.
    • •Flash for i: snapshot no disparado, IPL del clon fallido, SAVE21 fallido, log no reintegrado.
  4. •Recolección de evidencia completa para escalar.
  5. •Apertura de case con IBM Support, Precisely Support y M81 con la info correcta.

Laboratorio y simulacros

Durante el track se ejecutan simulacros de incidente:

  • •10 tickets con descripciones reales (anonimizadas).
  • •El L1 debe: clasificar prioridad, identificar el producto involucrado, recolectar evidencia que se pediría, redactar el ticket de escalado.

Entregable de cierre

Simulacro de mesa de ayuda completo. El L1 recibe un set de 10 tickets en un período acotado y debe:

  • •Clasificar prioridad (P1 / P2 / P3 / P4).
  • •Identificar producto y módulo afectado.
  • •Recolectar la evidencia mínima.
  • •Decidir: resolver en L1 (caso simple — runbook) o escalar (caso complejo).
  • •Documentar el ticket con calidad de escalado.

Criterios de aprobación

  • •100% de tickets clasificados correctamente en severidad.
  • •≥80% de tickets con evidencia mínima completa.
  • •≥80% de tickets escalables con calidad para que el senior pueda trabajar sin volver a pedir info.
  • •Manejo correcto del vocabulario de versiones: nunca asumir versión sin verificarla en el ticket.

Runbooks asociados

Como parte del cierre, el L1 colabora en mantener los runbooks de los 10 incidentes más comunes por producto:

  • •Síntoma → evidencia a recolectar → primer paso → criterio de escalado.

Estos runbooks son insumo vivo del equipo y se revisan trimestralmente.

Mentoría

  • •Cada L1 nuevo sigue 1 semana a un senior después del track, observando casos reales antes de tomar guardia solo.
  • •Pareo con mentor durante los primeros 30 días.
  • •Renovación anual: actualización por release notes y nuevos errores/runbooks observados.

Recursos transversales

Módulos del track

Módulo 1

Módulo 1 — iSeries / IBM Power Systems (hardware)

1 día
Módulo 2

Módulo 2 — IBM i (sistema operativo)

2 días
Módulo 3

Módulo 3 — AIX (sistema operativo)

1 día
Módulo 4

Módulo 4 — Assure Quick EDD

3 días
Módulo 5

Módulo 5 — Connect CDC

2 días
Módulo 6

Módulo 6 — Flash For i

1 día

Agenda día por día

Agenda día por día — Track Soporte L1

Cronograma base de 10 días lectivos (extensible a 12 con semana de tickets supervisados). Bloques estándar: mañana 9:00–13:00, tarde 14:00–17:00.

Track completo: track-soporte-l1.md.

Día 0 — Día común

14:00–16:00 (2 h). Historia, portafolio, vocabulario.

Día 1 — Hardware

Mañana (4 h)

  • •9:00–10:30 Linaje y generaciones (POWER8 a Power11) — solo lo necesario para identificar.
  • •11:00–13:00 Datos a pedir/leer del cliente: modelo, serial, firmware, HMC.

Tarde (3 h)

  • •14:00–15:30 HMC para L1 (vista de servers, partitions, service events). System Reference Codes.
  • •15:30–17:00 Apertura de case con IBM. Recolección de evidencia.

Material: Hardware — Para Soporte L1.

Días 2–3 — IBM i

Día 2

Mañana (4 h)

  • •9:00–10:30 Recordatorio de objetos, bibliotecas, IFS.
  • •11:00–13:00 Comandos del día a día: WRKACTJOB, DSPMSG, WRKMSG QSYSOPR, WRKSPLF, WRKSYSACT, WRKDSKSTS.

Tarde (3 h)

  • •14:00–15:30 ACS y Navigator for i: vista operativa.
  • •15:30–17:00 Lectura de joblog y mensajes (CPF…, MCH…, SQL…).

Día 3

Mañana (4 h)

  • •9:00–10:30 Common pitfalls L1: objeto no journaled, job en MSGW, cola spool llena, subsistema caído.
  • •11:00–13:00 Apertura de case IBM Support con la info correcta.

Tarde (3 h)

  • •14:00–17:00 Lab: 5 tickets prácticos sobre IBM i. Identificar versión + TR, joblog, abrir case ficticio.

Material: IBM i — Para Soporte L1, Cheatsheet de comandos.

Día 4 — AIX

Mañana (4 h)

  • •9:00–10:30 Comandos diarios: oslevel -s, lparstat -i, lsvg, df -g, topas/nmon, errpt.
  • •11:00–13:00 Logs habituales: errpt, /var/adm/ras/, alog.

Tarde (3 h)

  • •14:00–15:30 Recolección con snap -ac.
  • •15:30–17:00 Pitfalls AIX: filesystem lleno, paging, installp pendiente, disco en Defined.

Material: AIX — Para Soporte L1.

Días 5–7 — Assure Quick EDD

Día 5

Mañana (4 h)

  • •9:00–10:30 Operación normal: dashboard, lag, audits.
  • •11:00–13:00 Alertas frecuentes (apply lag, inactive subsystem, object not journaled).

Tarde (3 h)

Día 6

Mañana (4 h)

  • •9:00–13:00 Lab: simular incidentes en lab y aplicar el runbook (con instructor reproduciendo el síntoma).

Tarde (3 h)

  • •14:00–17:00 Recolección de diagnostics. Apertura de case en Precisely Support.

Día 7

Mañana + tarde

  • •Día completo de tickets simulados con cronómetro + revisión cruzada.

Material: Quick EDD — Para Soporte L1.

Días 8–9 — Connect CDC

Día 8

Mañana (4 h)

  • •9:00–10:30 Operación de pipelines, lectura de status, lag.
  • •11:00–13:00 Errores típicos: pipeline detenido, tabla nueva sin journaling, auth, lock destino, mapping mismatch.

Tarde (3 h)

Día 9

Mañana (4 h)

  • •9:00–13:00 Lab: incidentes de CDC reproducidos en lab.

Tarde (3 h)

  • •14:00–17:00 Apertura de case en Precisely Support.

Material: Connect CDC — Para Soporte L1.

Día 10 — Flash For i + entregable de cierre

Mañana (4 h)

  • •9:00–10:30 Operación normal: ciclo, reporte, integración con BRMS.
  • •11:00–13:00 Runbook Flash For i — los 10 incidentes.

Tarde (3 h) — Entregable de cierre

  • •14:00–17:00 Simulacro de mesa de ayuda completo: 10 tickets reales (anonimizados) en tiempo real. Clasificación, evidencia, escalado.

Material: Flash For i — Para Soporte L1, Entregable — Track L1.

Días 11–12 (opcional)

Semana de tickets supervisados en producción real con mentor pareado.

Recursos del track