Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Processo di patching
<a name="process"></a>

Gli utenti principali della soluzione di patching sono i team operativi e di sviluppo delle applicazioni. Ogni applicazione viene in genere implementata in più ambienti, ad esempio sviluppo, test (integrazione, accettazione degli utenti e così via) e produzione. I team addetti all'applicazione devono pianificare le pianificazioni di applicazione delle patch per ogni ambiente, quindi quando una patch viene applicata all'ambiente di produzione, è già stata testata e si è stabilito che non ha effetti negativi sull'applicazione.

Il seguente flusso di lavoro fornisce un esempio di come è possibile pianificare l'applicazione di patch alle finestre per un'applicazione distribuita in più ambienti e come configurare i tag.

 ![Patch management workflow](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/patch-management-hybrid-cloud/images/patching-workflow.png) 
+ **Fase 1: ** Ogni team dell'applicazione pianifica le finestre di manutenzione per i propri server all'interno di vari ambienti e imposta di conseguenza i tag che rappresentano i gruppi di patch e le finestre di manutenzione dei server:
  + Il tag **Patch Group** rappresenta i server all'interno di un ambiente applicativo che sono gli obiettivi di una specifica patch baseline. I gruppi di patch aiutano a garantire che le corrette linee di base delle patch vengano distribuite nel set corretto di istanze. I gruppi di patch aiutano anche a evitare di distribuire le patch nell'ambiente di produzione prima che siano state adeguatamente testate.
  + Se i server delle applicazioni includono più sistemi operativi, il team dell'applicazione crea gruppi di patch in base alla combinazione di ambiente e sistema operativo. Un gruppo di patch può essere registrato con una sola patch di base e un'istanza può far parte di un solo gruppo di patch.

    Ad esempio: `{{appname}}-DEV-WIN` e `{{appname}}-DEV-RHEL`
  + Il tag **Maintenance Window** rappresenta la pianificazione per l'applicazione delle patch ai server. **Tutti i server di un gruppo di patch devono trovarsi nella stessa finestra di manutenzione.** Il tag della finestra di manutenzione dovrebbe seguire un formato coerente per le espressioni cron e rate in modo che una funzione Lambda definita possa analizzare facilmente le espressioni. (In questa guida, faremo riferimento a questa funzione Lambda come`automate-patch`.)

    Ad esempio: `{{schedule-duration-cutoff-timezone}}`

    `cron(0 2 ? * SAT#3 *)`rappresenta le 02:00 del terzo sabato di ogni mese. Per informazioni dettagliate sulle espressioni cron e rate, consultate la [documentazione di Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/reference-cron-and-rate-expressions.html).
+ **Fase 2.** Systems Manager Patch Manager rende disponibili regolarmente nuove patch tramite linee di base di patch specifiche del sistema operativo in base alle configurazioni definite.
  + Per ogni sistema operativo, è possibile definire una patch di base personalizzata che includa le regole di approvazione e le patch da applicare alle istanze nell'ambiente cloud.
+ **Fase 3.** Il codice di automazione personalizzato configura Patch Manager per impostare le patch in base ai tag **Patch Group e **Maintenance Window** e applica le patch** all'ambiente di sviluppo.
  + Una volta completata l'applicazione delle patch, i team di sviluppo e supporto dell'applicazione testano l'applicazione e verificano che tutto funzioni correttamente.
  + Se l'applicazione riscontra problemi con la nuova patch, i team applicativi chiedono al team dei servizi cloud di interrompere l'applicazione delle patch ad altri gruppi di patch e altri ambienti, disabilitando le finestre di manutenzione o annullando la registrazione dell'attività di patch.
+ **Fase 4.** Dopo aver applicato correttamente le patch all'ambiente di sviluppo, l'applicazione delle patch viene distribuita in qualsiasi altro ambiente non di produzione. Come per l'ambiente di sviluppo, l'applicazione viene testata e verificata per verificarne il corretto funzionamento in tutti gli ambienti non di produzione. In caso di problemi, i team applicativi chiedono al team dei servizi cloud di interrompere l'applicazione delle patch all'ambiente di produzione.
+ **Fase 5:** Dopo che tutti gli ambienti non di produzione sono stati corretti con successo, l'applicazione delle patch viene applicata all'ambiente di produzione.