Classification des pannes
01Identifiez l'échec avant de décider quoi relancer.
Une automatisation fiable ne place pas toutes les erreurs dans la même boucle. Flower distingue conditions de transport, qualité des données et résultat destination incertain.
Transitoire et relançable
Délais, limitation et indisponibilité temporaire utilisent tentatives bornées, temporisation et budget. L'épuisement devient retard ou alerte visible, jamais boucle infinie.
Permanent et actionnable
Identifiants invalides, droits absents, schéma incompatible ou règle métier échouée ne s'améliorent pas par relance. Arrêtez l'unité, gardez le contexte, isolez et prévenez le responsable.
Incertain, à rapprocher d'abord
La connexion peut tomber après validation destination. Flower vérifie identité, suivi, comptes ou sommes avant relecture afin qu'un résultat inconnu ne devienne pas un doublon.
Boucle de contrôle de reprise
02N'avancez que lorsque l'unité est sûre et prouvée.
La même boucle suit les données de la source à la destination. La reprise transitoire courante est automatique ; les résultats à risque ou incertains gardent leur contexte, suivent la politique et n'alertent que lorsqu'un jugement humain est nécessaire.
Choisissez la limite de reprise
Utilisez objet, fichier, lot déterministe ou plus petite unité sûre. Conservez le point hors de l'exécution transitoire et avancez après confirmation destination.
Conditionnez l'avancement à la validation
La fin du transport n'est qu'un signal. Structure, schéma, comptes, règles métier, intégrité et rapprochement décident publication, révision ou rejet.
Gardez les preuves de reprise liées
Enregistrez tentatives, classe, identités, validation, quarantaine, rapprochement et action finale dans une seule traçabilité. Les alertes donnent le contexte utile.
Façonné en production
03Une fiabilité acquise sous la pression des données réelles.
La fiabilité ne se décrète pas dans une présentation. Flower évolue depuis 2019 au contact de charges continues en production, dont de très grands volumes télécom et des données financières critiques.
La panne devient explicite
Transferts incomplets, enregistrements invalides et violations de politique deviennent des états visibles avec un traitement défini, pas des défauts silencieux en aval.
La reprise reste maîtrisée
Budgets de relance, temporisation, limites de reprise, quarantaine, rapprochement destination et cycle de vie s'adaptent au point et à la charge au lieu d'être improvisés pendant un incident.
Les preuves restent liées
Traçabilité, métadonnées, événements, métriques et alertes aident à reconstituer ce qui a circulé, changé et nécessite une action.
Acceptation de la reprise
04Spécifiez la récupérabilité avant le premier incident.
Une promesse d'auto-réparation ne devient opérationnelle que si l'équipe convient de ce qui peut être relancé, de la preuve qui clôt une unité, du rapprochement de l'incertitude et de l'arrêt de l'automatisation. Transformez ces attentes en tests de version et rejouez-les après tout changement.
Écrivez le contrat de reprise
Pour chaque unité, précisez perte, doublon, changement d'ordre et délai autorisés, ainsi que la preuve destination requise. Un contrat précis évite de déclarer réussi un processus redémarré alors que le résultat des données reste inconnu.
Injectez des classes de panne distinctes
Testez séparément indisponibilité source, interruption du transport, limitation, identifiants invalides, rejet de schéma, charge corrompue, stockage local plein et délai cible. Chacun doit suivre la voie prévue : relance, arrêt, quarantaine ou rapprochement.
Forcez une validation ambiguë
Coupez la connexion après une possible validation destination mais avant réception de la confirmation. Vérifiez qu'identité, comptes, sommes de contrôle ou autre signal durable sont contrôlés avant toute relecture.
Redémarrez au-delà de la limite d'état
Redémarrez worker, hôte et service d'état dépendant à différents moments. Confirmez que points, tentatives en attente, contexte de quarantaine et traçabilité survivent ensemble, et qu'une mise à niveau ou un retour arrière ne réinterprète pas le travail en cours.
Mesurez pression et rattrapage
Laissez un point indisponible assez longtemps pour créer un retard réaliste, puis rétablissez-le. Mesurez âge de file, croissance disque, taux de relance, débit utile de rattrapage, saturation et protection du nouveau trafic.
Prouvez quarantaine et relecture
Envoyez des unités invalides ou hors politique avec du travail valide. Confirmez que les données à risque s'arrêtent sans bloquer le reste, gardent le contexte de diagnostic et peuvent être corrigées puis relues sans contourner la validation ni dupliquer les unités terminées.
Prouvez la restauration de l'état durable
Supprimez ou corrompez le stockage d'état actif, puis restaurez-le depuis la sauvegarde ou la réplique documentée. Mesurez l'écart du point de reprise, rapprochez les preuves source et destination et confirmez que le point reconstruit n'ignore aucun travail admissible ni ne republie silencieusement des unités terminées.
Testez le passage à l'opérateur
Épuisez le budget de relance et déclenchez une panne permanente. L'alerte doit identifier unité, source et cible, dernière limite sûre, tentatives, preuves, responsable et actions approuvées sans reconstruction entre outils isolés.
Conditionnez les versions aux exercices de reprise
Conservez matrice de panne, preuves attendues et temps de reprise dans une suite répétable. Exécutez-la après tout changement de runtime, connecteur, schéma, politique ou infrastructure afin que la récupérabilité soit une propriété testée de la version.