Gestire gli aggiornamenti automatici con criteri di arresto
L’automazione richiede test dopo l’installazione. Definisca quando fermare il rilascio e chi decide se proseguire.
Gli aggiornamenti automatici possono svolgere attività operative ricorrenti. Un’installazione riuscita, però, non dimostra ancora che l’applicazione e le sue connessioni funzionino come previsto. La decisione di proseguire richiede quindi un caso di test definito.
Il NIST include priorità, installazione e verifica dell’installazione nella gestione delle patch. Per la propria gestione operativa, ne deriva una domanda concreta: quale flusso applicativo deve continuare a funzionare dopo la modifica?
Verificare un collegamento critico
Nell’esempio inventato, una procedura automatica installa un aggiornamento. Il servizio web si avvia, ma l’attività in background J-61 non può più usare la connessione al sistema collegato. Il messaggio di installazione è positivo; il flusso necessario rimane interrotto.
Per questo caso il team prevede di verificare la connessione e il risultato atteso prima di proseguire con il rilascio. Il test viene preparato in un ambiente approvato con dati di prova adeguati. Qui non è stato installato alcun aggiornamento né contattato alcun sistema collegato.
Definire la risposta a un test non superato
Osservazione nell’esempio | Azione prevista | Condizione prima di proseguire |
|---|---|---|
Installazione e flusso critico superano i test concordati. | Proseguire il rilascio previsto con monitoraggio. | Gli esiti dei test sono associati al sistema coinvolto. |
La connessione dell’attività in background non funziona. | Fermare le successive fasi del rilascio e assegnare l’indagine. | La causa o un rimedio adeguato è stato verificato; si decide se proseguire. |
Una correzione di sicurezza urgente richiede una procedura diversa. | Valutare insieme urgenza, impatto e modalità di test disponibile. | Sono definiti una decisione responsabile e il monitoraggio successivo. |
La tabella è un modello di pianificazione, non un rilascio eseguito qui. Fermarsi significa decidere in modo controllato la prossima modifica. La correzione di sicurezza necessaria resta un’attività aperta e richiede un seguito definito.
Pianificare il ritorno e le attività residue
Il ritorno alla vecchia versione del programma deve essere compatibile con lo stato dei dati e le modifiche già eseguite. Chiarisca in anticipo quale procedura di ritorno sia stata testata per quello specifico aggiornamento e chi possa eseguirla. Un vecchio file da solo non costituisce una procedura di ritorno testata.
Registri infine chi gestisce le verifiche non superate e quando vengono rivalutati i casi aperti. L’automazione segue così la procedura concordata, mentre gli scostamenti mantengono un percorso decisionale con un responsabile identificato.
Fonti
Continuate a leggere
Tutti gli articoli
Cloud & gestione con ASES
Hosting, deployment, manutenzione e assistenza