Classificazione dei guasti
01Stabilisci cosa è fallito prima di decidere cosa ripetere.
Un'automazione affidabile non invia ogni errore nello stesso ciclo di retry. Flower mantiene condizioni di trasporto, esiti di qualità e risultati incerti a destinazione come stati operativi distinti.
Transitorio e ritentabile
Timeout, throttling e indisponibilità temporanee usano tentativi limitati, backoff, jitter e un budget. L'esaurimento diventa backlog o alert visibile, mai un ciclo infinito.
Permanente e azionabile
Credenziali errate, permessi mancanti, schema incompatibile o regola business fallita non migliorano ripetendo. Ferma l'unità, conserva il contesto, isola se serve e avvisa il responsabile.
Incerto e da riconciliare
La connessione può cadere dopo il commit a destinazione. Flower controlla identità, tracking, conteggi o checksum prima del replay, evitando che un esito ignoto diventi un duplicato.
Ciclo di controllo del recovery
02Avanza solo quando l'unità è sicura e dimostrata.
Lo stesso ciclo di controllo segue i dati dalla sorgente alla destinazione. Il recovery transitorio ordinario è automatico; gli esiti non sicuri o incerti conservano il contesto, seguono la policy e generano un segnale azionabile solo quando serve giudizio umano.
Scegli il confine di ripartenza
Usa oggetto, file, batch deterministico o altra unità minima sicura. Conserva il checkpoint fuori dallo stato transitorio e avanzalo solo dopo conferma a destinazione.
Subordina l'avanzamento alla validazione
La fine del trasporto è un solo segnale. Struttura, schema, conteggi, regole business, integrità e riconciliazione decidono pubblicazione, revisione o rifiuto.
Mantieni collegate le evidenze di recovery
Registra tentativi, classe, identità sorgente e destinazione, validazione, quarantena, riconciliazione e azione finale in un solo lineage. Gli alert portano il contesto per agire.
Forgiato in produzione
03Affidabilità conquistata sotto la pressione dei dati reali.
L'affidabilità non è una proprietà da presentazione. Flower si evolve dal 2019 su workload continui in produzione, inclusi volumi Telco molto elevati e dati finanziari critici per il business.
Il guasto è esplicito
Trasferimenti incompleti, record non validi e violazioni delle policy diventano stati visibili con una gestione definita, non difetti silenziosi a valle.
Il ripristino è controllato
Budget di retry, backoff, confini di ripartenza, quarantena, riconciliazione a destinazione e azioni di lifecycle si adattano a endpoint e workload invece di essere improvvisati durante un incidente.
Le evidenze restano collegate
Lineage, metadati, eventi, metriche e alert aiutano a ricostruire cosa si è mosso, cosa è cambiato e cosa richiede attenzione.
Accettazione del recovery
04Specifica la recuperabilità prima del primo incidente.
Una promessa di self-healing diventa operativa solo quando il team concorda cosa può essere ripetuto, quali evidenze chiudono un'unità, come si riconcilia l'incertezza e quando l'automazione deve fermarsi. Trasforma queste attese in test di rilascio e ripetili quando cambiano endpoint o policy.
Scrivi il contratto di recovery
Per ogni unità definisci perdita, duplicazione e variazione d'ordine ammesse, ritardo massimo ed evidenza richiesta a destinazione. Un contratto preciso evita di dichiarare riuscito un processo riavviato quando l'esito dei dati resta ignoto.
Inietta classi di guasto distinte
Prova separatamente indisponibilità della sorgente, interruzione del trasporto, throttling, credenziali non valide, rifiuto dello schema, payload corrotto, storage locale pieno e timeout del target. Ognuno deve raggiungere il percorso previsto di retry, stop, quarantena o riconciliazione.
Forza un commit ambiguo
Interrompi la connessione dopo il possibile commit a destinazione ma prima che la conferma raggiunga il mittente. Verifica che identità, conteggi, checksum o un altro segnale durevole siano controllati prima di consentire il replay.
Riavvia oltre il confine dello stato
Riavvia worker, host e servizio di stato dipendente in punti diversi. Conferma che checkpoint, tentativi pendenti, contesto di quarantena e lineage sopravvivano insieme e che upgrade o rollback non reinterpretino il lavoro in corso.
Misura pressione e recupero
Mantieni un endpoint indisponibile abbastanza da creare un backlog realistico, poi ripristinalo. Misura età della coda, crescita del disco, tasso di retry, throughput utile di recupero, saturazione e se il nuovo traffico viene penalizzato o protetto.
Dimostra quarantena e replay
Invia unità non valide o fuori policy insieme a lavoro valido. Conferma che i dati non sicuri si fermino senza bloccare il resto, conservino contesto per la diagnosi e possano essere corretti e riprodotti senza saltare la validazione o duplicare unità concluse.
Dimostra il ripristino dello stato durevole
Rimuovi o corrompi lo store di stato attivo e ripristinalo dal backup o dalla replica documentati. Misura lo scarto del recovery point, riconcilia le evidenze di sorgente e destinazione e conferma che il checkpoint ricostruito non salti lavoro idoneo né ripubblichi silenziosamente unità completate.
Prova il passaggio all'operatore
Esaurisci il budget di retry e genera un guasto permanente. L'alert deve identificare unità, sorgente e destinazione, ultimo confine sicuro, tentativi, evidenze, responsabile e azioni approvate senza ricostruzioni tra strumenti scollegati.
Subordina i rilasci ai recovery drill
Mantieni matrice dei guasti, evidenze attese e tempi di recovery come suite ripetibile. Eseguila dopo modifiche a runtime, connettore, schema, policy o infrastruttura, rendendo la recuperabilità una proprietà verificata del rilascio, non fiducia storica.