quick-edd

Runbook — Assure Quick EDD

Los 10 incidentes más frecuentes en operación de Quick EDD, con síntoma, evidencia, primer paso y criterio de escalado.

Soporte L1Soporte Senior

Runbook — Assure Quick EDD

Para cada incidente: síntoma observable, evidencia mínima a recolectar, flujo de diagnóstico inicial (lo que un L1 puede hacer) y criterio de escalado al senior o al fabricante.

Convenciones: ⚠️ = acción que puede afectar producción, no la haga un L1 sin aprobación.

RB-QE-001 — Apply lag elevado / persistente

Síntoma

Dashboard de Quick EDD muestra lag creciente entre source y target. Alertas por email/SNMP de "apply lag exceeds threshold".

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Confirmar que los apply jobs están activos (no *MSGW ni *HLD).

    WRKACTJOB SBS(QEDDSBSYS)

    → Salida esperada: ver jobs con status ACTIVE. Columna STS debe mostrar RUN o DEQW. Si algún job aparece en MSGW → ese job tiene un mensaje pendiente que bloquea el proceso. Anotar el nombre de job y el mensaje antes de escalar. Si aparece HLD → el job está en hold; capturar joblog antes de liberar.

  2. •

    Verificar utilización de CPU y disco en target.

    WRKSYSACT

    → CPU acumulada al 80% o más sostenida durante más de 10 minutos indica saturación. Presionar F5 para refrescar. Si supera el 90%, notificar al senior inmediatamente.

    WRKDSKSTS

    → Revisar columna % USED de cada unidad de disco (ASP 1). Si supera el 80%, riesgo real. Si supera el 90%, escalación urgente.

  3. •

    Verificar latencia de red entre source y target.

    PING RMTSYS(ip_o_nombre_del_target)

    → Tiempos de respuesta menores a 5 ms son normales en red LAN. Más de 20 ms en una red LAN es anómalo. Si hay pérdida de paquetes (timeout), escalar a redes.

  4. •

    Revisar QSYSOPR en source y target en la franja del incidente.

    WRKMSG MSGQ(QSYS/QSYSOPR)

    → Buscar mensajes con severidad 40 o mayor en la franja del incidente. Anotar IDs de mensaje y timestamps.

  5. •

    Si el lag es por una operación masiva conocida (carga de batch, mass update), documentar y monitorear. → Si el lag supera los 300 segundos y sigue creciendo después de confirmar que los jobs están activos y la infraestructura está sana, escalar al senior.

Criterio de escalado

RB-QE-002 — Apply job inactivo / subsystem caído

Síntoma

Alerta "inactive subsystem" o "process not running". El target deja de aplicar.

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Verificar si el subsystem está down.

    WRKSBS

    → En la lista buscar el subsystem de Quick EDD (nombre típico: QEDDSBSYS o el definido en la instalación del cliente). Columna STATUS debe mostrar ACTIVE. Si dice INACTIVE o no aparece, está caído.

  2. •

    Si está down: capturar el último joblog antes de tomar cualquier acción.

    DSPJOBLOG JOB(nombre_job_subsystem) OUTPUT(*PRINT)

    → Buscar en el joblog el último mensaje con severidad 40+ antes de la terminación. Ese mensaje es el punto de partida para el RCA.

  3. •

    Revisar QSYSOPR para mensajes que dispararon el down.

    WRKMSG MSGQ(QSYS/QSYSOPR) SEQ(*NEW)

    → Buscar mensajes como CPF1080 (subsystem ended), CPF1240 (out of memory), o mensajes de hardware en la franja del incidente.

  4. •

    ⚠️ Reinicio del subsystem solo si hay procedimiento aprobado y ventana operativa OK.

    STRSBS SBSD(QEDD/QEDDSBSYS)

    → Confirmar que el subsystem levantó volviendo a ejecutar WRKSBS. El status debe volver a ACTIVE en menos de 60 segundos. Si no levanta, NO reintentar — escalar.

Criterio de escalado

RB-QE-003 — Object not journaled (objeto nuevo en producción)

Síntoma

Alerta "object not journaled" o "object cannot be replicated". Aparece tras un release de aplicación.

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Confirmar el estado de journaling del objeto.

    DSPFD FILE(MILIB/MITABLA)

    → Buscar la sección "Journaling information". El campo Journaled debe decir Yes. Si dice No, el archivo no está journaled. Anotar también el nombre del journal y la biblioteca del journal si están listados.

  2. •

    Identificar si es un objeto nuevo (post-release) o uno que se removió del journal.

    DSPOBJD OBJ(MILIB/MITABLA) OBJTYPE(*FILE)

    → El campo Object creation date confirma cuándo se creó. Comparar con la fecha del último release.

  3. •

    Notificar al equipo de aplicación.

  4. •

    ⚠️ Iniciar journaling con STRJRNPF solo bajo procedimiento aprobado y con autoridad correspondiente.

    STRJRNPF FILE(MILIB/MITABLA) JRN(MILIB/MIJRN) IMAGES(*BOTH) OMTJRNE(*OPNCLO)

    → Confirmar éxito con DSPFD FILE(MILIB/MITABLA) — el campo Journaled ahora debe decir Yes.

  5. •

    Documentar en el ticket con el objeto y la causa raíz (release sin STRJRNPF).

Criterio de escalado

RB-QE-004 — Authority error sobre objeto

Síntoma

Alerta "authority not sufficient" en operación normal de Quick EDD. Replicación o auditoría de un objeto falla.

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Verificar las autoridades actuales sobre el objeto.

    DSPOBJAUT OBJ(MILIB/MITABLA) OBJTYPE(*FILE)

    → Buscar la entrada del perfil de Quick EDD (nombre definido en la instalación, típicamente algo como QEDDUSER o el nombre del cliente). El perfil debe tener *CHANGE o *ALL sobre el archivo. Si no aparece o tiene *EXCLUDE, ese es el problema.

  2. •

    Confirmar si es objeto nuevo (release reciente) o histórico.

    DSPUSRPRF QEDDUSER

    → Revisar que el perfil de Quick EDD tiene *ALLOBJ o las autoridades de objeto necesarias según el diseño de seguridad del cliente. También confirmar que el perfil está *ENABLED.

  3. •

    Documentar en ticket. ⚠️ No otorgar autoridades sin procedimiento aprobado.

Criterio de escalado

RB-QE-005 — Receiver threshold (journal receiver lleno)

Síntoma

Alerta "journal receiver near threshold" o "no space" sobre journal receivers en source o target.

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Identificar el journal y listar los receivers.

    WRKJRNRCV JRN(MILIB/MIJRN)

    → La lista muestra todos los receivers con su tamaño y estado. El receiver activo (marcado como ATT) es el que está creciendo. Receivers con estado ONL y libres pueden purgarse según política. Receivers con estado SAV ya fueron salvados.

  2. •

    Verificar el threshold configurado y el tamaño actual.

    DSPJRN JRN(MILIB/MIJRN)

    → Buscar el campo Threshold — es el tamaño máximo permitido antes de que se genere un mensaje de alerta. Comparar con el tamaño actual del receiver activo.

  3. •

    Verificar utilización de disco.

    WRKDSKSTS

    → Si el % USED del ASP donde viven los receivers supera el 80%, el riesgo es alto. Por encima del 85% se debe actuar sin demora.

  4. •

    ⚠️ CHGJRN JRN(...) JRNRCV(*GEN) para encadenar a un receptor nuevo — solo bajo procedimiento aprobado.

    CHGJRN JRN(MILIB/MIJRN) JRNRCV(*GEN)

    → Esto cierra el receiver actual y crea uno nuevo automáticamente. Confirmar con WRKJRNRCV JRN(MILIB/MIJRN) que apareció un nuevo receiver en estado ATT.

  5. •

    Verificar si hay receivers viejos que se pueden purgar (verificar política de retención antes).

    DLTJRNRCV JRNRCV(MILIB/JRNRCV0001) DLTOPT(*IGNINQMSG)

    → Solo ejecutar si el receiver ya está salvado (estado SAV) y si la política de retención lo permite. Confirmar con Quick EDD que ese receiver ya no es necesario para catch-up.

Criterio de escalado

RB-QE-006 — Divergencia detectada por auditoría

Síntoma

Auditoría programada o on-demand reporta diferencia entre source y target sobre uno o más objetos. Quick EDD intenta auto-reparar (típicamente lo hace), pero queda registrado.

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Verificar si la auditoría ya reparó automáticamente. → El reporte de auditoría incluye una sección de "repaired objects". Si el objeto aparece ahí, la auto-reparación funcionó. Documentar de todas formas.

  2. •

    Verificar el estado del objeto en ambos sistemas.

    DSPOBJD OBJ(MILIB/MITABLA) OBJTYPE(*FILE)

    → Ejecutar en source y en target. Comparar Object size, Last change date, y Number of records (para PFs). Si difieren y la auditoría no reparó, escalar.

  3. •

    Revisar journal entries recientes en source para ver qué operaciones ocurrieron sobre el objeto.

    DSPJRN JRN(MILIB/MIJRN) RCVRNG(*CURCHAIN) JRNCDE(R) ENTTYP(PT UB) FILE((MILIB/MITABLA))

    → JRNCDE(R) filtra entradas de tipo record operation. Buscar INSerts, UPDates, DELetes recientes. Si hay operaciones masivas recientes, puede explicar la divergencia.

  4. •

    Notificar al equipo de aplicación si los objetos son productivos críticos.

  5. •

    Si la auto-reparación falló: escalación a senior.

Criterio de escalado

RB-QE-007 — Comunicación caída entre source y target

Síntoma

Alerta "lost connection" o "communication error". Apply lag empieza a crecer indefinidamente.

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Verificar conectividad básica desde source hacia target.

    PING RMTSYS('ip_del_target')

    → Si el ping responde, la conectividad IP básica existe. Anotar el tiempo de respuesta. Si no responde, la conexión está caída — escalar a redes inmediatamente.

  2. •

    Verificar puertos de Quick EDD desde source al target (si hay herramienta disponible).

    STRTCPSVR SERVER(*INETD)
NETSTAT OPTION(*CNN)

    → En NETSTAT *CNN buscar conexiones establecidas hacia la IP del target en el puerto que usa Quick EDD (típicamente definido en la configuración del producto). Si no aparecen conexiones ESTABLISHED, la sesión TCP cayó.

  3. •

    Verificar subsistemas activos en ambos lados.

    WRKSBS

    → Confirmar que el subsystem de Quick EDD está ACTIVE tanto en source como en target.

  4. •

    Consultar change control — ¿hay cambio de red, firewall, certificado? → Si hay un change control activo que involucra red o firewall, coordinarlo con el equipo responsable antes de hacer cualquier reinicio.

  5. •

    Documentar eventos con timestamps exactos.

Criterio de escalado

RB-QE-008 — Switch (role-swap) fallido o incompleto

Síntoma

⚠️ Incidente crítico. Procedimiento de switch no completó las etapas. Producción puede haber quedado en estado inconsistente.

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •No tomar acciones unilaterales. Es incidente de senior + manager + cliente.
  2. •Documentar el estado exacto de cada componente con screenshots y joblogs.
  3. •Notificar al senior y al cliente inmediatamente.

Criterio de escalado

RB-QE-009 — Auto-reparación detenida (audit no repara)

Síntoma

Auditoría detecta divergencia y reporta "could not auto-repair". El objeto queda en hold o flag.

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Verificar lock en target — ¿alguien estaba usando el objeto?

    WRKOBJLCK OBJ(MILIB/MITABLA) OBJTYPE(*FILE)

    → Si hay locks de tipo *EXCLRD o *EXCL, algún job tiene el archivo abierto en modo exclusivo. Anotar qué job tiene el lock. Si el lock es transitorio (job de aplicación), esperar y reintentar. Si el lock es persistente, escalar.

  2. •

    Verificar autoridades en target.

    DSPOBJAUT OBJ(MILIB/MITABLA) OBJTYPE(*FILE)

    → El perfil de Quick EDD debe tener al menos *CHANGE sobre el objeto en target para poder reparar.

  3. •

    Verificar integridad del objeto en target.

    CHKOBJ OBJ(MILIB/MITABLA) OBJTYPE(*FILE)

    → Si el comando retorna error (objeto dañado), escalar inmediatamente — no intentar reparar sin senior.

  4. •

    Documentar y escalar.

Criterio de escalado

RB-QE-010 — Upgrade de Quick EDD: post-upgrade check fallido

Síntoma

Tras un upgrade del producto (planeado), aparecen comportamientos anómalos: lag inusual, validación de auditoría fallida, alertas nuevas.

Evidencia a recolectar

Flujo de diagnóstico inicial (L1)

  1. •

    Confirmar que el upgrade ejecutó todos los pasos documentados.

    DSPPTF LICPGM(producto_quickedd)

    → Verificar que los PTFs incluidos en el upgrade están instalados y en estado PRM (permanent). Si alguno está en estado TMP (temporary), el upgrade no se aplicó permanentemente.

  2. •

    Verificar requisitos del nuevo release (versión IBM i, TR, PTFs).

    DSPSYSVAL SYSVAL(QOSPF)
DSPSFWRSC

    → DSPSFWRSC lista los productos instalados con sus versiones. Confirmar que la versión de IBM i y el TR vigente cumplen los requisitos mínimos listados en las release notes del upgrade.

  3. •

    Verificar el subsystem post-upgrade.

    WRKACTJOB SBS(QEDDSBSYS)

    → Los jobs deben estar ACTIVE. Si hay jobs nuevos que no reconocés, consultar las release notes — pueden ser features nuevos del upgrade.

  4. •

    Documentar discrepancias entre lo esperado (release notes) y lo observado.

Criterio de escalado

Anexo — convenciones de escalado a Precisely Support

Cuando se abre un case con Precisely Support — Assure Quick EDD, incluir siempre:

Plantilla de comunicación P1

Usar cuando el incidente es P1 (producción caída o en riesgo real de pérdida de datos). Enviar por email y por el canal de guardia definido en el contrato del cliente.

ASUNTO: [P1] Quick EDD — [cliente] — [descripción breve] — [timestamp]

CLIENTE: [nombre]
PRODUCTO: Assure Quick EDD v[versión]
ENTORNO: Source [hostname/IP IBM i] → Target [hostname/IP IBM i]
INICIO DEL INCIDENTE: [fecha y hora con timezone]
DETECTADO POR: [quién detectó — alerta automática / usuario / soporte]

IMPACTO:
- [Describe el impacto en producción: replicación detenida, riesgo de datos, etc.]
- Lag actual: [valor] segundos / minutos

ESTADO ACTUAL:
- [Qué está pasando ahora mismo]
- Acciones ya ejecutadas: [lista de comandos corridos y resultados]

EVIDENCIA RECOLECTADA:
- [x] Joblog del subsystem Quick EDD — adjunto
- [x] WRKACTJOB output — adjunto
- [x] WRKDSKSTS output — adjunto
- [x] QSYSOPR — adjunto
- [ ] [Lo que aún falta]

PRÓXIMA ACCIÓN:
- Esperando instrucción de [senior / cliente / Precisely Support]

CONTACTO GUARDIA SOPORTE SENIOR: [nombre y celular]
CONTACTO CLIENTE (técnico): [nombre y celular]

Recursos relacionados