Valutare tutti gli eventuali eventi imprevisti È importante provare la patch nel maggior numero possibile di scenari di utilizzo. Cercate di individuare attentamente gli eventi imprevisti all’interno dell’ambiente di prova, come per esempio: • Guasti a …
Valutare tutti gli eventuali eventi imprevisti
È importante provare la patch nel maggior numero possibile di scenari di utilizzo. Cercate di individuare attentamente gli eventi imprevisti all’interno dell’ambiente di prova, come per esempio:
• Guasti al programma
• Cambiamenti nei permessi
• Servizi disabilitati
• Servizi abilitati
• Servizi interrotti
• Codice colpito negativamente
• Qualsiasi altro guasto nelle applicazioni
Se la procedura di test dà risultati non soddisfacenti, dovete identificare la causa del problema prima di procedere oltre.
I rollout di produzione possono essere considerati una parte supplementare del processo di test. Il rollout iniziale dovrebbe essere sui sistemi meno critici e, se si comportano come previsto, potete continuare con il rollout fino a che tutti i sistemi non sono aggiornati. Il processo di test può essere considerato finito quando l’installazione è completa e non si sono verificati problemi nell’ambito di una settimana.
Anche in un programma di testing, è bene avere un piano di
emergenza che annulli le modifiche apportate nel caso qualcosa vada non vada per
il verso giusto durante, o alla fine, dell’applicazione di una patch o di un
aggiornamento.
La gestione dei cambiamenti è vitale in ogni fase del
processo di applicazione della patch e gli aggiornamenti devono essere
effettuati e tracciati attraverso il sistema di management delle modifiche.
La vostra policy per il controllo delle modifiche dovrebbe descrivere i processi
che saranno usati per identificare e implementare le pacth e la responsabilità
di ogni fase del workflow.
