Gestione dei cambiamenti

Un cambiamento è l'aggiunta, la modifica o la rimozione di qualsiasi cosa che possa influire sui servizi IT.

Obiettivi della gestione dei cambiamenti

• Minimizzare i rischi: Valutare l'impatto prima dell'implementazione
• Controllare le modifiche: Tracciare tutte le modifiche al SI
• Comunicare: Informare le parti interessate
• Misurare: Seguire il tasso di successo dei cambiamenti

Esempi di cambiamenti

• Aggiornamento di un sistema operativo
• Distribuzione di una nuova versione applicativa
• Modifica di una regola firewall
• Sostituzione di un'apparecchiatura di rete
• Migrazione di un database

KaliaOps distingue 3 tipi di cambiamento con workflow adattati:

Cambiamento standard

• Ripetitivo e ben compreso
• Rischio e impatto bassi
• Procedura documentata
• Esempi: reset password admin, riavvio schedulato

Cambiamento normale

• Richiede analisi d'impatto
• Passa davanti al CAB
• Pianificato in anticipo

Cambiamento d'emergenza

• Per risolvere un incidente critico
• Approvazione accelerata
• Documentazione a posteriori accettabile

Il workflow di gestione dei cambiamenti ha 11 stati:

Diagramma semplificato

DRAFT → SUBMITTED → PENDING_APPROVAL → APPROVED → SCHEDULED → IMPLEMENTING → COMPLETED → CLOSED\n                    ↓\n                  REJECTED

Descrizione degli stati

Il CAB (Change Advisory Board) è il comitato che valuta e approva i cambiamenti.

Composizione tipica

• Change Manager (presiede)
• Rappresentanti tecnici
• Rappresentanti funzionali
• Rappresentanti della sicurezza (se necessario)

Procedura

1. Il cambiamento viene presentato all'ordine del giorno
2. L'autore presenta il cambiamento
3. Il CAB valuta i rischi e gli impatti
4. Discussione e domande
5. Voto: Approvato o Rifiutato
6. La decisione viene tracciata

ECAB (Emergency CAB)

Per i cambiamenti d'emergenza:

• Comitato ristretto (disponibili)
• Riunione rapida o circolare
• Approvazione accelerata

Tracciabilità

Ogni decisione CAB viene registrata con:

• Data della riunione
• Partecipanti
• Decisione (approvato/rifiutato)
• Commenti/condizioni

Finestra di manutenzione

Una finestra di manutenzione è un periodo autorizzato per i cambiamenti.

• Definizione: Giorni e orari di manutenzione consentiti
• Comunicazione: Gli utenti sono avvisati in anticipo
• Rispetto: I cambiamenti devono avvenire in queste finestre

Data pianificata

Alla creazione del cambiamento, indica:

• Data di inizio: Quando iniziare l'implementazione
• Data di fine: Fine prevista

Conflitti

KaliaOps avvisa se:

• Un altro cambiamento è già pianificato nello stesso periodo
• La data è fuori dalla finestra di manutenzione
• Un freeze period è attivo

Freeze Period

Periodi dove nessun cambiamento è autorizzato:

• Fine anno
• Chiusura contabile
• Eventi critici

Piano di implementazione

Descrivi in dettaglio le fasi dell'implementazione:

1. Preparazione dell'ambiente
2. Backup/snapshot
3. Esecuzione del cambiamento
4. Validazione funzionale
5. Comunicazione

Piano di test

Come validare che il cambiamento è riuscito:

• Test funzionali
• Test di performance
• Test di regressione

Piano di rollback

Come annullare il cambiamento se fallisce:

• Procedura di ritorno
• Tempo stimato
• Condizioni di attivazione

Obbligatorio per i cambiamenti normali e d'emergenza.

Avviare l'implementazione

1. Apri il cambiamento pianificato
2. Clicca su «Avvia implementazione»
3. Lo stato passa a «Implementing»

Durante l'implementazione

• Segui il piano di implementazione
• Documenta le azioni effettuate
• Annota gli scostamenti dal piano

Completare

Una volta terminata l'implementazione:

1. Clicca su «Completa»
2. Indica il risultato: Successo o Parziale
3. Aggiungi le note di chiusura

Chiudere

Dopo la revisione post-implementazione:

1. Clicca su «Chiudi»
2. Il cambiamento è archiviato

Rilevare un fallimento

Un cambiamento è considerato fallito se:

• Il test di validazione fallisce
• Si verifica un incidente grave
• Il servizio è degradato

Eseguire il rollback

1. Clicca su «Rollback»
2. Segui il piano di rollback documentato
3. Valida il ritorno alla normalità
4. Lo stato passa a «Rolled Back»

Analisi post-fallimento

• Perché è fallito?
• Cosa può essere migliorato?
• Il piano di rollback è stato efficace?

Indicatori

• Tasso di fallimento: Cambiamenti falliti / Totale
• Tasso di rollback: Rollback / Cambiamenti implementati

KaliaOps correla automaticamente gli incidenti con i cambiamenti recenti.

Rilevamento automatico

Quando si verifica un incidente:

• KaliaOps cerca i cambiamenti implementati nelle ultime 24-48h
• I cambiamenti che riguardano gli stessi asset/applicazioni sono evidenziati
• Il tecnico può confermare o infirmare la correlazione

Correlazione manuale

Dall'incidente:

1. Clicca su «Collega a un cambiamento»
2. Seleziona il cambiamento interessato
3. Indica la forza di correlazione

Indicatori

• Incidenti post-cambiamento: Incidenti correlati ai cambiamenti
• Change Success Rate: % di cambiamenti senza incidenti

Miglioramento continuo

Analizza le correlazioni per:

• Identificare i tipi di cambiamento rischiosi
• Migliorare le procedure di test
• Rinforzare i piani di rollback