OPS06-BP01 Preparazione di un piano in caso di esito negativo delle modifiche - Principio dell'eccellenza operativa

OPS06-BP01 Preparazione di un piano in caso di esito negativo delle modifiche

Pianifica il ripristino di uno stato corretto noto o la correzione nell'ambiente di produzione nel caso in cui l'implementazione generi un risultato indesiderato. Disporre di una politica per stabilire un piano di questo tipo aiuta tutti i team a sviluppare strategie di ripristino dalle modifiche con esito negativo. Alcune strategie di esempio sono le fasi di deployment e rollback, le politiche di modifica, i flag di funzionalità, l'isolamento del traffico e lo spostamento del traffico. Una singola release può includere più modifiche ai componenti correlati. La strategia dovrebbe fornire la capacità di resistere o ripristinare in caso di guasto generato da qualsiasi modifica dei componenti.

Risultato desiderato: hai preparato un piano di ripristino dettagliato per la modifica in caso di fallimento. Inoltre, hai ridotto le dimensioni della release per ridurre al minimo il potenziale impatto su altri componenti del carico di lavoro. Di conseguenza, hai ridotto l'impatto aziendale abbreviando i potenziali tempi di inattività causati da una modifica non riuscita e aumentando la flessibilità e l'efficienza dei tempi di ripristino.

Anti-pattern comuni:

  • Hai eseguito un deployment e l'applicazione è diventata instabile, ma sembra che ci siano utenti attivi sul sistema. Devi decidere se eseguire il rollback della modifica e influire sugli utenti attivi o aspettare di eseguire il rollback della modifica, sapendo che gli utenti potranno essere comunque influenzati.

  • Dopo aver apportato una modifica di routine, i nuovi ambienti sono accessibili, ma una delle sottoreti è diventata irraggiungibile. Devi decidere se eseguire il rollback di tutto o provare a correggere il problema della sottorete inaccessibile. Mentre prendi tale decisione, la sottorete rimane irraggiungibile.

  • I tuoi sistemi non sono progettati in modo da consentire loro di essere aggiornati con release più piccole. Di conseguenza, è difficile annullare tali modifiche di massa (bulk changes) durante un deployment conclusosi con esito negativo.

  • Non utilizzi l'Infrastruttura come codice (IaC) e hai apportato aggiornamenti manuali all'infrastruttura che hanno portato a configurazioni indesiderate. Non è possibile tracciare e ripristinare in modo efficace le modifiche manuali.

  • Poiché non hai misurato l'aumento della frequenza dei deployment, il tuo team non è incentivato a ridurre le dimensioni delle modifiche e a migliorare i piani di rollback per ogni modifica, con conseguente aumento dei rischi e dei tassi di fallimento.

  • Non misura la durata totale di un'interruzione causata da modifiche con esito negativo. Il tuo team non è in grado di stabilire le priorità e migliorare il processo di deployment e l'efficacia del piano di ripristino.

Vantaggi dell'adozione di questa best practice: Avere un piano per il ripristino dopo le modifiche non riuscite riduce al minimo il tempo medio di ripristino (MTTR) e riduce l'impatto sull'azienda.

Livello di rischio associato se questa best practice non fosse adottata: alto

Guida all'implementazione

Una politica e una pratica coerenti e documentate adottate dai team di rilascio consentono a un'organizzazione di pianificare cosa dovrebbe succedere in caso di modifiche con esito negativo. In circostanze specifiche la politica dovrebbe consentire la possibilità di apportare correzioni per garantire la prosecuzione del processo. In entrambe le situazioni, un piano di correzione (fix forward) o ripristino (rollback) deve essere ben documentato e testato prima dell'implementazione nei sistemi di produzione live, in modo da ridurre al minimo il tempo necessario per ripristinare una modifica.

Passaggi dell'implementazione

  1. Documenta le politiche che richiedono ai team di disporre di piani efficaci per invertire le modifiche entro un periodo di tempo specificato.

    1. Le politiche devono specificare quando è consentita una situazione di applicazione di correzioni per garantire la prosecuzione del processo.

    2. Richiedi un piano di rollback documentato che sia accessibile a tutti i soggetti coinvolti.

    3. Specifica i requisiti per il rollback (ad esempio, quando si rileva che sono state implementate modifiche non autorizzate).

  2. Analizza il livello di impatto di tutte le modifiche relative a ciascun componente di un carico di lavoro.

    1. Consenti che le modifiche ripetibili siano standardizzate, basate su modelli e preautorizzate se seguono un flusso di lavoro coerente che applica le politiche di modifica.

    2. Riduci il potenziale impatto di qualsiasi modifica riducendone le dimensioni, in modo che il ripristino richieda meno tempo e abbia un impatto minore sulle attività aziendali.

    3. Assicurati che le procedure di rollback riportino il codice allo stato corretto noto per evitare incidenti, ove possibile.

  3. Integra strumenti e flussi di lavoro per applicare le tue politiche in modo programmatico.

  4. Rendi visibili i dati sulle modifiche agli altri responsabili di carichi di lavoro per migliorare la velocità di diagnosi di eventuali modifiche con esito negativo che non possono essere ripristinate.

    1. Misura il successo di questa pratica utilizzando dati di modifica visibili e identifica miglioramenti iterativi.

  5. Utilizza gli strumenti di monitoraggio per verificare il successo o il fallimento di un deployment per accelerare il processo decisionale sul rollback.

  6. Misura la durata dell'interruzione durante una modifica con esito negativo per migliorare continuamente i tuoi piani di ripristino.

Livello di impegno per il piano di implementazione: Medio

Risorse

Best practice correlate:

Documenti correlati:

Video correlati: