Saltar al contenido principal
Avanzado•10–16 horas

Simulacro de recuperación y reconciliación de incidentes de IA

Ejecuta un simulacro de producción para caídas del proveedor, regresiones del modelo y efectos secundarios inciertos: contención, preservación de evidencia, recuperación reconcile-first, rollback a estado conocido, failback y conversión del incidente en regresión.

respuesta a incidentes de IAcontenciónreconciliaciónrollbackfailbackregresión post-incidente

Escenario

Tarea

Un workflow de IA llama a un modelo externo y a tools, y después el request termina por timeout. Se desconoce si el efecto secundario del tool ya ocurrió. Un retry ciego puede crear un duplicado, mientras que revertir solo el código de la aplicación no garantiza restaurar la configuración de model, prompt o retrieval. Ejecuta un simulacro en el que el equipo restaura el estado autoritativo en lugar de limitarse a reiniciar el servicio.

Ejecución paso a paso

1. Clasifica el incidente por impacto real

Resultado: La contención prioriza autoridad, exposición de datos y efectos secundarios irreversibles, no el volumen de la alerta.

Tareas

  • →Identificar tareas, usuarios, datos y acciones afectados
  • →Comprobar estado de model/provider/retrieval/tool
  • →Evaluar efectos secundarios unknown o pending
  • →Activar el kill switch o modo degradado más estrecho que sea suficiente

Comprobaciones

  • ✓La contención conserva los artefactos forenses necesarios
  • ✓Un write path de alto impacto puede detenerse por separado de las funciones read-only
  • ✓Un efecto secundario desconocido no se marca como failed sin verificación

2. Conserva evidencia y reconcilia el estado autoritativo

Resultado: El equipo sabe qué ocurrió realmente antes de cualquier retry o compensación.

Tareas

  • →Recopilar correlation/runtime envelope
  • →Contrastar el tool request con el estado del system of record
  • →Comprobar idempotency key e historial de duplicados
  • →Clasificar el resultado como completed, not completed, pending o unknown

Comprobaciones

  • ✓Retry queda bloqueado para pending/unknown hasta reconciliar
  • ✓El sistema autoritativo prevalece sobre el transcript del agente
  • ✓La evidencia no contiene secrets o PII innecesarios

3. Ejecuta rollback, compensación y recuperación gradual

Resultado: El sistema vuelve a un comportamiento known-good y a un estado de negocio consistente.

Tareas

  • →Revertir la envolvente completa de comportamiento
  • →Ejecutar compensación solo para efectos secundarios confirmados
  • →Ejecutar smoke/eval checks
  • →Reabrir tráfico gradualmente con un periodo de observación

Comprobaciones

  • ✓Rollback incluye versiones de model/prompt/retrieval/tool/policy
  • ✓La compensación es idempotente o está reconciliada
  • ✓Recovery PASS exige evidencia del runtime y del estado autoritativo

4. Convierte el incidente en un control de regresión

Resultado: La misma familia de fallos deja de depender de la memoria del equipo.

Tareas

  • →Minimizar el reproductor
  • →Añadir checks deterministas o basados en modelo cuando sea necesario
  • →Vincular el caso a una severidad bloqueante
  • →Actualizar runbook, alerta y responsable

Comprobaciones

  • ✓El test de regresión reproduce la señal de fallo original
  • ✓Un caso crítico derivado del incidente forma parte del release gate
  • ✓El postmortem registra un cambio de control, no solo la instrucción de tener más cuidado

Criterios de aceptación

  • El mapa de incidentes ofrece contención acotada para fallos de model/provider/retrieval/tool/write
  • Un efecto secundario unknown o pending pasa por reconciliación autoritativa antes del retry
  • Rollback restaura la envolvente completa de comportamiento, no solo el commit de código
  • La recuperación se confirma mediante runtime fingerprint y estado de negocio autoritativo
  • Un incidente de producción se minimiza como caso permanente de regresión con responsable y severidad