Un'operazione corretta sul singolo ambiente può essere sbagliata se ricarica un servizio condiviso senza necessità. Questo principio è emerso con chiarezza nel restore: un reload del master PHP-FPM, apparentemente semplice, ha prodotto una risposta 503 su un altro tenant nello scenario di test.
Il workflow è stato modificato per lasciare invariati master, pool e socket e terminare soltanto i processi preesistenti dell'ambiente interessato. Il test di regressione ha verificato il comportamento sullo scenario osservato.
La stessa garanzia non viene attribuita agli altri workflow soltanto perché condividono parte del codice. Creazione, sospensione, riattivazione, cambio PHP e aggiornamento del pool mantengono operazioni globali dove il progetto non ha ancora introdotto un'alternativa tenant-safe.
Sincronizzare ogni file sembrava prudente, ma non rendeva completo un restore interrotto a metà. Fliclic ha scelto di ricostruire e verificare l'albero mentre resta isolato, poi richiedere una barriera di persistenza sul filesystem prima della riapertura.
La barriera finale non crea una transazione distribuita e può coinvolgere I/O di altri servizi sullo stesso filesystem. Rappresenta però il punto logico corretto: il contenuto viene reso disponibile soltanto dopo che dati e metadata sono stati verificati e sincronizzati secondo le garanzie del sistema operativo e dello storage.
Nel progetto, quattro etichette concettuali devono rimanere separate:
Un helper presente nel codice non prova il deployment identico su ogni nodo. Un test su due ambienti non diventa garanzia universale. Una proposta di updater non è un updater installato. Questa precisione evita che il sito trasformi aspirazioni legittime in promesse tecniche false.
Alcune alternative sono state escluse perché introducevano più rischio o complessità:
Conservare le ragioni di queste scelte impedisce di riproporle quando il problema riappare sotto un nome diverso.
