Giorno zero: il caso entra nel sistema
Un sistema interno deve cambiare regole e interfacce, ma viene usato ogni giorno. Fermarlo per una migrazione completa non è compatibile con operations. La cronologia parte da «flussi che non possono fermarsi» e segue lo stesso identificatore fino a «spegnere il percorso precedente con criterio».
L’evoluzione sicura separa il cambiamento tecnico dall’attivazione operativa, così dati e utenti possono migrare per incrementi con possibilità di ritorno. Nel racconto, ogni passaggio deve rispondere a tre domande: chi sa che il caso esiste, quale dato considera valido e quale azione può compiere; il caso operativo si verifica con «rollback non provato».
Il primo punto di rottura
Una correzione tardiva rende incoerenti due viste dello stesso evento. Nel nostro caso emerge rilascio big bang. La reazione abituale è una correzione fuori sistema; proprio questa scorciatoia impedisce di apprendere dal guasto; il controllo associato riguarda «dipendenze fra vecchio e nuovo».
Il riferimento operativo «Feature flag, expand-contract migration, shadow read e rollback» permette invece di mantenere l’identità del caso. Segue una capacità estratta dal monolite attraverso compatibilità, doppia lettura e cutover.
Il passaggio di consegne
Caso isolato: «dipendenze fra vecchio e nuovo». Operazione osservata: «spegnere il percorso precedente con criterio». Deviazione forzata: «rollback non provato».
Bivio operativo: «rollback non provato». L’operatore decide usando «dipendenze fra vecchio e nuovo», non una ricostruzione successiva. Perimetro della prova: «rilasciare per capacità con compatibilità e fallback».
Controprova: «finestre e procedure di rollback». Arresto: «rilascio big bang». Passo ammesso dopo il recupero: «aggiungere compatibilità agli ingressi». Verbale finale: «Come introdurre cambiamenti mentre il processo continua a lavorare?»
Differenza decisiva: «Segue una capacità estratta dal monolite attraverso compatibilità, doppia lettura e cutover». Regola di chiusura: «Il passaggio finale deve essere piccolo perché compatibilità e riconciliazione sono state verificate prima, non perché il rischio è stato ignorato».
Il bivio operativo
Prima di ridisegnare il flusso, l’owner deve chiarire questi elementi; nel perimetro descritto conta «Feature flag, expand-contract migration, shadow read e rollback». Sono i punti in cui due persone ragionevoli potrebbero prendere decisioni diverse; il controesempio viene cercato in «doppia scrittura senza riconciliazione».
Flussi che non possono fermarsi
Qui cambia la persona responsabile. Quando emerge «flussi che non possono fermarsi», il caso conserva identità e contesto. L’owner consulta «dipendenze fra vecchio e nuovo» prima di gestire «rilascio big bang».
Dipendenze fra vecchio e nuovo
Il dato disponibile modifica il percorso. Quando emerge «dipendenze fra vecchio e nuovo», il caso conserva identità e contesto. L’owner consulta «dati da mantenere coerenti» prima di gestire «doppia scrittura senza riconciliazione».
Dati da mantenere coerenti
L’eccezione nasce in questo punto. Quando emerge «dati da mantenere coerenti», il caso conserva identità e contesto. L’owner consulta «finestre e procedure di rollback» prima di gestire «rollback non provato».
Finestre e procedure di rollback
Nel racconto questo è un bivio. Quando emerge «finestre e procedure di rollback», il caso conserva identità e contesto. L’owner consulta «flussi che non possono fermarsi» prima di gestire «vecchio percorso mantenuto indefinitamente».
Il ridisegno, passaggio per passaggio
La nuova sequenza non prova a eliminare ogni intervento umano. Porta fuori dal percorso le decisioni già determinate e rende più ricchi i punti in cui serve giudizio; la decisione resta collegata a «dati da mantenere coerenti».
- 1
Isolare una capacità
Nel racconto, «isolare una capacità» cambia lo stato del caso e registra «flussi che non possono fermarsi». La deviazione «rilascio big bang» viene risolta prima che il percorso raggiunga «aggiungere compatibilità agli ingressi».
- 2
Aggiungere compatibilità agli ingressi
Nel racconto, «aggiungere compatibilità agli ingressi» cambia lo stato del caso e registra «dipendenze fra vecchio e nuovo». La deviazione «doppia scrittura senza riconciliazione» viene risolta prima che il percorso raggiunga «migrare un gruppo limitato».
- 3
Migrare un gruppo limitato
Nel racconto, «migrare un gruppo limitato» cambia lo stato del caso e registra «dati da mantenere coerenti». La deviazione «rollback non provato» viene risolta prima che il percorso raggiunga «confrontare risultati vecchi e nuovi».
- 4
Confrontare risultati vecchi e nuovi
Nel racconto, «confrontare risultati vecchi e nuovi» cambia lo stato del caso e registra «finestre e procedure di rollback». La deviazione «vecchio percorso mantenuto indefinitamente» viene risolta prima che il percorso raggiunga «spegnere il percorso precedente con criterio».
- 5
Spegnere il percorso precedente con criterio
Nel racconto, «spegnere il percorso precedente con criterio» cambia lo stato del caso e registra «flussi che non possono fermarsi». La deviazione «rilascio big bang» viene risolta prima che il percorso raggiunga «isolare una capacità».
Tre minuti dopo: qualcosa va storto
Lo scenario va ripetuto modificando una condizione alla volta. I rischi seguenti mostrano se il nuovo percorso conserva contesto e possibilità di recupero; qui la prova concreta è «finestre e procedure di rollback».
Rilascio big bang
Rischio nominato: «rilascio big bang». Perimetro operativo: «rilasciare per capacità con compatibilità e fallback». Segnale osservato: «finestre e procedure di rollback». Recupero ammesso: «isolare una capacità». Checkpoint finale: «finestre e procedure di rollback».
Doppia scrittura senza riconciliazione
Rischio nominato: «doppia scrittura senza riconciliazione». Perimetro operativo: «rilasciare per capacità con compatibilità e fallback». Segnale osservato: «flussi che non possono fermarsi». Recupero ammesso: «aggiungere compatibilità agli ingressi». Checkpoint finale: «flussi che non possono fermarsi».
Rollback non provato
Rischio nominato: «rollback non provato». Perimetro operativo: «rilasciare per capacità con compatibilità e fallback». Segnale osservato: «dipendenze fra vecchio e nuovo». Recupero ammesso: «migrare un gruppo limitato». Checkpoint finale: «dipendenze fra vecchio e nuovo».
Vecchio percorso mantenuto indefinitamente
Rischio nominato: «vecchio percorso mantenuto indefinitamente». Perimetro operativo: «rilasciare per capacità con compatibilità e fallback». Segnale osservato: «dati da mantenere coerenti». Recupero ammesso: «confrontare risultati vecchi e nuovi». Checkpoint finale: «dati da mantenere coerenti».
Epilogo: che cosa deve essere diverso
Il passaggio finale deve essere piccolo perché compatibilità e riconciliazione sono state verificate prima, non perché il rischio è stato ignorato. Nel nuovo scenario non è necessario che tutto sia automatico; è necessario che un caso fermo sia distinguibile da uno concluso; l’evidenza da conservare è «dipendenze fra vecchio e nuovo».
Il passaggio finale deve essere piccolo perché compatibilità e riconciliazione sono state verificate prima, non perché il rischio è stato ignorato. Il caso può uscire dallo scenario quando «confrontare risultati vecchi e nuovi» mantiene «dati da mantenere coerenti» nel passaggio in cui si manifesta «vecchio percorso mantenuto indefinitamente».
Contesto e limiti
La situazione descritta è fittizia ma plausibile e viene usata per esporre i confini operativi della decisione; il caso operativo si verifica con «flussi che non possono fermarsi». Un esito negativo del test resta un apprendimento valido.
Prossimo passo
Hai un processo che non entra negli strumenti standard?
Porta il vincolo operativo, i sistemi coinvolti e il risultato che vorresti ottenere. Partiamo da lì.