Plan de traspaso · handover

Resumen

Este documento es el plan operacional de traspaso del proyecto Pedido Sugerido. Articula la transición desde el modelo "Tuxpas opera · AJE observa" hacia "AJE opera de forma autónoma · Tuxpas acompaña ante incidentes". Es el complemento natural del Catálogo de Monitoring ([[DOC-AF-08-monitoring]]): este define quién responde y aquél define a qué responde.

El traspaso se materializa en cinco bloques:

1. Sesiones de capacitación (6 sesiones de 2h, distribuidas en sem 9 y 10)
2. Runbooks operacionales (6 runbooks en formato Markdown, versionados en el repo)
3. Documentación entregada (15 artefactos · diagramas · matrices · políticas)
4. Criterios "AJE autónomo" (6 pruebas concretas que validan la autonomía)
5. Acompañamiento post-entrega (2 semanas de garantía + plan de comunicación)

El cierre formal del traspaso lo certifica la Acta de Conformidad ([[DOC-AF-10-acta-conformidad]]).

Filosofía del traspaso

Tres principios

1. Documentación como producto · no como subproducto · Los runbooks no son notas internas; son artefactos versionados, revisados y testeados con AJE en escenarios reales. Si AJE no puede ejecutar un runbook sin asistencia, el runbook no está terminado.

2. Capacitación dialogada · no expositiva · Cada sesión combina 30% explicación, 50% hands-on con el ambiente productivo (en una corrida controlada) y 20% Q&A. AJE conduce los últimos 20 minutos del ejercicio sin Tuxpas guiando.

3. Autonomía progresiva · no instantánea · Durante las 2 semanas de acompañamiento post-entrega, AJE responde primero y Tuxpas valida; no al revés. Tuxpas interviene únicamente si AJE escala o si una alerta Critical no es atendida en SLA.

Riesgo principal y mitigación

El riesgo recurrente en traspasos MLOps es la dependencia residual: AJE acepta el traspaso formal pero, ante el primer incidente real, escala a Tuxpas porque no tiene el contexto profundo del pipeline. Mitigación:

• Sesiones 3 y 4 son conducidas en parte por AJE (Tuxpas observa)
• Durante el acompañamiento, las primeras 2 alertas Critical reales son tratadas por AJE con Tuxpas en modo "silent pair"
• Cada runbook tiene un dry-run obligatorio en la sesión correspondiente

Sesiones de capacitación

Cronograma resumen

Total: 12 horas de capacitación distribuidas en 2 semanas. Sesiones grabadas y almacenadas en S3 (bucket aje-dev-analytics-artifacts-s3, prefix pedido_sugerido/handover/recordings/) con retención de 1 año.

Sesión 1 · Operación diaria del pipeline

Objetivo: AJE entiende qué pasa cada día sin que alguien lo gatille y qué herramienta usar para inspeccionar resultados.

Agenda (2h):

Material entregado:

• Slides PDF de la sesión
• [[RB-01-operacion-diaria]] · runbook
• Diagrama de arquitectura (parte de DOC-AF-05)
• Cheat sheet de comandos (AWS CLI · SM Studio shortcuts)

Criterio de éxito: AJE oncall completa ambos ejercicios sin asistencia en una corrida del día siguiente (martes 21 jul).

Sesión 2 · Monitoreo y respuesta a alertas

Objetivo: AJE distingue Critical / Warning / Info, interpreta correctamente cada alarma del catálogo y ejecuta la mitigación inicial.

Agenda:

Material entregado:

• Slides PDF
• [[RB-02-respuesta-alertas]] · runbook
• Catálogo de alarmas (DOC-AF-08) impreso/encuadernado para referencia
• Plantillas de comunicación al cliente interno (para Warning · Critical)

Criterio de éxito: AJE oncall responde correctamente a una alerta inyectada por Tuxpas en una ventana de 1h posterior a la sesión (sin asistencia).

Sesión 3 · Agregar países nuevos al pipeline

Objetivo: AJE puede onboardar un país nuevo (p. ej. Bolivia · Argentina) sin involucrar a Tuxpas.

Agenda:

Material entregado:

• [[RB-03-agregar-pais]] · runbook (35+ pasos)
• Plantillas de configuración DynamoDB (JSON)
• Checklist impreso (pre-flight · in-flight · post-flight)

Criterio de éxito: AJE analyst onboarda un país sandbox sin asistencia, antes del final de sem 10.

Sesión 4 · Promoción de modelos en el Registry

Objetivo: AJE entiende el flujo Register → Pending → Approved/Rejected y conduce una aprobación real.

Agenda:

Material entregado:

• [[RB-04-promocion-modelos]] · runbook
• Plantilla de "razón de aprobación" (usada en el campo Description del Model Package)
• Tabla de gates (DOC-AF-04 · sección de criterios)

Criterio de éxito: AJE analyst aprueba y rechaza, respectivamente, dos modelos en una ventana de 24h post-sesión.

Sesión 5 · Reentrenamiento y manejo de drift

Objetivo: AJE sabe cuándo el sistema reentrenará solo (Nivel 3), cuándo debe intervenir y qué hacer ante drift recurrente.

Agenda:

Material entregado:

• [[RB-05-drift-retraining]] · runbook
• Diagrama de árbol de decisión (qué tipo de drift · qué respuesta)
• Lista de feature flags para deshabilitar el retrain (rollback button)

Criterio de éxito: AJE pausa exitosamente un retrain en curso y lo reactiva luego.

Sesión 6 · Troubleshooting y recorrido de runbooks

Objetivo: AJE recorre cada runbook entregado, los ubica en el repo, valida que están comprensibles y los aprueba formalmente.

Agenda:

Material entregado:

• Compilado PDF de los 6 runbooks (versión "as-delivered")
• Acta interna de aprobación de runbooks (firmada por AJE oncall y AJE analyst)

Criterio de éxito: AJE firma el acta interna confirmando que los 6 runbooks están listos para uso productivo.

Runbooks entregados

Todos los runbooks viven en aje-analytics-model-pedido-sugerido/docs/runbooks/ versionados con el código. Cada uno sigue una plantilla común:

# RB-XX · Título
## Cuándo ejecutar
## Pre-requisitos · accesos · credenciales
## Pasos numerados (1, 2, 3...)
## Validación post-ejecución
## Rollback (si aplica)
## Escalamiento (a quién y cuándo)
## Anexos · comandos · queries

RB-01 · Operación diaria del pipeline

Cuándo: Cada mañana, antes de las 10:00 hora Perú, AJE oncall revisa la salud del pipeline del día anterior.

Pasos (resumen, 12 en total):

1. Abrir SageMaker Studio · revisar la lista de ejecuciones del último día (esperadas: 7 países)
2. Confirmar que todas terminaron con estado Succeeded
3. Para cualquier Failed o Stopped · ir a CloudWatch Logs y leer el último log group
4. Validar que los outputs llegaron a s3://aje-dev-analytics-artifacts-s3/pedido_sugerido/output/{pais}/
5. (...)

RB-02 · Respuesta a alertas

Cuándo: Apenas llega una alerta del SNS topic.

Lógica del runbook:

1. Critical (SLA <30 min) · responder de inmediato, escalar si no se resuelve en 60 min
2. Warning (SLA <4h) · documentar en DynamoDB de incidentes
3. Info (sin SLA) · log only

Anexo importante: tabla de mapping alarma → runbook específico (p. ej. alarma 11 schemadrift → RB-03 sección "schemas divergentes").

RB-03 · Agregar país nuevo

Cuándo: Negocio AJE solicita incluir un nuevo país en el pipeline.

Pasos: 35+, agrupados en 5 fases:

RB-04 · Promoción de modelos

Cuándo: Llega notificación de "Model Package registered as Pending".

Pasos: 15, agrupados en 3 fases:

RB-05 · Drift y retraining

Cuándo: Llega alerta de tipo datadrift, schemadrift o ndcgdrop.

Pasos: 20+, con árbol de decisión inicial:

¿Qué tipo de drift?
├─ Schema · halt pipeline · investigar fuente · escalar a AJE analyst
├─ Data · PSI > 0.25 · validar features · permitir retrain automático en Nivel 3
└─ Concept · NDCG dropped 5%+ por 2 semanas · revisar lógica de negocio · forzar retrain

RB-06 · Troubleshooting general

Cuándo: Cualquier escenario no cubierto por los runbooks anteriores.

Es el "manual de bolsillo": índice de los 30 errores más comunes identificados durante el desarrollo Nivel 1 y 2, cada uno con su causa raíz típica y los primeros 3 pasos de diagnóstico.

Documentación entregada

Inventario completo de artefactos entregados al cierre del proyecto. Todos en el repo aje-analytics-model-pedido-sugerido y publicados en https://aje-mlops-docs.tuxpas.com/.

Persistencia post-cierre: todos los artefactos quedan en el repo bajo control de AJE. El dominio aje-mlops-docs.tuxpas.com se traslada a un bucket de AJE en la sem 10, con un redirect activo desde el bucket de Tuxpas por 3 meses.

Criterios "AJE autónomo"

Pruebas concretas que validan que AJE puede operar sin Tuxpas. Estos criterios deben cumplirse antes de firmar la [[DOC-AF-10-acta-conformidad]].

Regla: si al cierre de la sem 10 alguno de los 6 criterios no se cumple, se extiende el acompañamiento post-entrega 1 semana sin costo adicional para AJE. Si al final de esa extensión persiste, se acuerda una propuesta de soporte extendido formal.

Acompañamiento post-entrega

Plan de 2 semanas de garantía

Tras la firma de la Acta de Conformidad y el go-live a producción, Tuxpas acompaña durante 2 semanas calendario (sem 11 y 12) bajo el siguiente modelo:

Qué cubre

• Sí cubre: Bugs en código entregado por Tuxpas · errores de despliegue · alarmas falsas positivas debidas a configuración entregada · documentación con errores
• Sí cubre: Asistencia conceptual ante interpretación de runbooks · interpretación de métricas
• No cubre: Cambios funcionales nuevos (features adicionales)
• No cubre: Bugs causados por modificaciones realizadas por AJE post-entrega
• No cubre: Incidentes derivados de cambios en infraestructura AWS fuera del scope del proyecto

Mecanismo de cierre del acompañamiento

Al final de la sem 12, se realiza una reunión de cierre formal (60 min) con:

• Revisión de los criterios "AJE autónomo" (deben estar todos en verde)
• Inventario de incidentes atendidos durante el warranty con su causa raíz
• Lista de mejoras sugeridas (input para una eventual fase Nivel 4)
• Firma de Acta de Cierre del Acompañamiento (formato corto · 1 página)

Si al cierre quedan issues abiertos, se documentan en el acta con responsable y fecha-objetivo. Tuxpas mantiene best-effort por 30 días adicionales para esos issues específicos.

Plan de comunicación

Canales activos durante el warranty

Reporte semanal de warranty

Plantilla del reporte que Tuxpas envía cada viernes durante las 2 semanas de warranty:

== AJE Pedido Sugerido · Warranty Status · Semana N ==

Incidentes esta semana:
- Critical: X (Y resueltos · Z en curso)
- Warning: X
- Info: X

Tiempo total de Tuxpas en warranty esta semana: X horas

Issues abiertos:
- ID-001 · descripción · responsable · fecha objetivo
- (...)

Próxima semana · foco:
- (...)

Próximos pasos

Acciones inmediatas (durante semana del AF · 18–22 may)

1. Validar este plan con AJE (Sesión 2 · jueves 21 may) · puntos de discusión: cantidad de sesiones, fechas tentativas, modelo de warranty
2. Confirmar disponibilidad de los responsables AJE para las 6 sesiones de capacitación
3. Acordar los canales de comunicación (qué Slack workspace usaremos · creación del channel)
4. Reservar las fechas en calendario AJE ya en el AF, incluso si las agendas detalladas se ajustan después

Acciones durante el proyecto (sem 2–8)

5. Escribir los 6 runbooks en paralelo al desarrollo (cada uno se completa cuando el feature correspondiente está operativo)
6. Validar drafts de cada runbook con AJE en una reunión informal mensual de 30 min
7. Grabar versiones tentativas de las sesiones 1 y 2 a mediados del proyecto, para que AJE las pueda pre-visualizar

Acciones inmediatas pre-traspaso (sem 9 · semana antes de las sesiones)

8. Compilar PDF de los 6 runbooks · entregar como pre-lectura 5 días antes de la primera sesión
9. Confirmar accesos AWS de AJE (SageMaker Studio · CloudWatch · DynamoDB · S3)
10. Smoke test de los 6 ejercicios hands-on en un ambiente espejo

Acción de cierre (viernes sem 10)

11. Firma de la [[DOC-AF-10-acta-conformidad]] · habilitación del warranty