Clasificación de fallos
01Decide qué falló antes de decidir qué repetir.
Una automatización fiable no envía cada error al mismo bucle. Flower distingue condiciones de transporte, resultados de calidad y destinos inciertos.
Transitorio y reintentable
Timeouts, límites e indisponibilidad temporal usan intentos acotados, espera y presupuesto. El agotamiento se vuelve cola o alerta visible, nunca bucle infinito.
Permanente y accionable
Credenciales inválidas, permisos ausentes, esquema incompatible o regla fallida no mejoran al repetir. Detén la unidad, conserva contexto, aísla y avisa al responsable.
Incierto, reconciliar primero
La conexión puede caer tras el commit. Flower verifica identidad, seguimiento, recuentos o checksums antes de repetir para que un resultado incierto no se duplique.
Ciclo de control de recuperación
02Avanza solo cuando la unidad sea segura y demostrable.
El mismo ciclo acompaña a los datos del origen al destino. La recuperación transitoria rutinaria es automática; los resultados inseguros o inciertos conservan contexto, siguen la política y generan una señal solo cuando hace falta juicio humano.
Elige el límite de reinicio
Usa objeto, archivo, lote determinista u otra unidad mínima segura. Guarda el checkpoint fuera del estado transitorio y avanza tras confirmar destino.
Condiciona el avance a la validación
Completar transporte es una señal. Estructura, esquema, recuentos, reglas, integridad y reconciliación deciden publicación, revisión o rechazo.
Mantén vinculada la evidencia de recuperación
Registra intentos, clase, identidades, validación, cuarentena, reconciliación y acción final en un linaje. Las alertas incluyen contexto para actuar.
Forjado en producción
03Fiabilidad ganada bajo la presión de datos reales.
La fiabilidad no es una propiedad de una presentación. Flower evoluciona desde 2019 con cargas continuas en producción, incluidos volúmenes telco muy elevados y datos financieros críticos.
El fallo es explícito
Transferencias incompletas, registros no válidos e incumplimientos de política se convierten en estados visibles con tratamiento definido, no en defectos silenciosos aguas abajo.
La recuperación está acotada
Presupuestos de reintento, espera, límites de reinicio, cuarentena, reconciliación en destino y ciclo de vida se adaptan al endpoint y la carga en lugar de improvisarse durante un incidente.
La evidencia permanece vinculada
Linaje, metadatos, eventos, métricas y alertas ayudan a reconstruir qué se movió, qué cambió y qué requiere atención.
Aceptación de la recuperación
04Especifica la recuperabilidad antes del primer incidente.
Una promesa de autorreparación solo es operativa cuando el equipo acuerda qué puede repetirse, qué evidencia cierra una unidad, cómo se reconcilia la incertidumbre y cuándo debe detenerse la automatización. Convierte esas expectativas en pruebas de versión y repítelas tras cada cambio.
Escribe el contrato de recuperación
Para cada unidad, indica pérdida, duplicación y cambio de orden permitidos, retraso máximo y evidencia exigida en destino. Un contrato preciso evita considerar correcto un proceso reiniciado cuando el resultado de los datos sigue siendo incierto.
Inyecta clases de fallo distintas
Prueba por separado indisponibilidad del origen, corte de transporte, limitación, credenciales inválidas, rechazo de esquema, carga corrupta, almacenamiento local lleno y timeout del destino. Cada caso debe seguir el camino previsto de reintento, parada, cuarentena o reconciliación.
Fuerza un commit ambiguo
Corta la conexión después de que el destino pueda haber confirmado, pero antes de que el emisor reciba la respuesta. Verifica identidad, recuentos, checksums u otra señal duradera antes de permitir cualquier repetición.
Reinicia más allá del límite de estado
Reinicia worker, host y servicio de estado dependiente en momentos distintos. Confirma que checkpoints, intentos pendientes, contexto de cuarentena y linaje sobreviven juntos y que una actualización o rollback no reinterpreta el trabajo en curso.
Mide presión y recuperación
Mantén un endpoint caído hasta crear una cola realista y restáuralo. Mide edad de cola, crecimiento de disco, tasa de reintentos, rendimiento útil de recuperación, saturación y si el tráfico nuevo queda bloqueado o protegido.
Demuestra cuarentena y repetición
Envía unidades inválidas o fuera de política junto a trabajo válido. Confirma que los datos inseguros se detienen sin bloquear el resto, conservan contexto para diagnóstico y pueden corregirse y repetirse sin saltar validación ni duplicar unidades completadas.
Demuestra la restauración del estado duradero
Elimina o corrompe el almacén de estado activo y restáuralo desde la copia o réplica documentada. Mide la brecha del punto de recuperación, reconcilia evidencias de origen y destino y confirma que el checkpoint reconstruido no omite trabajo pendiente ni republica silenciosamente unidades completadas.
Prueba el traspaso al operador
Agota el presupuesto de reintentos y provoca un fallo permanente. La alerta debe identificar unidad, origen y destino, último límite seguro, intentos, evidencia, responsable y siguientes acciones aprobadas sin reconstruir datos entre herramientas inconexas.
Condiciona versiones a simulacros de recuperación
Conserva la matriz de fallos, evidencia esperada y tiempos de recuperación como suite repetible. Ejecútala tras cambios de runtime, conector, esquema, política o infraestructura para que la recuperabilidad sea una propiedad probada de cada versión.