Skip to main content
La Gestione delle Modifiche è il luogo in cui ogni modifica al tuo ambiente viene pianificata, revisionata, approvata ed eseguita sotto controllo. Ogni modifica è registrata come una GMUD (Gestão de Mudança — un record di modifica), e nulla che tocchi un sistema viene eseguito prima che le persone giuste abbiano approvato. È lo stesso principio del resto di Myrmex — l’IA propone, tu approvi — applicato al momento in cui una modifica atterra davvero.
Una GMUD è una singola richiesta di modifica: cosa cambierà, perché, su quali sistemi, quando, come verrà annullata e chi ha firmato. Porta la modifica da una bozza fino a un’esecuzione completata e sottoposta ad audit.

​
Due Tipi di Modifica

La Gestione delle Modifiche gestisce due tipi di modifica, e la differenza sta principalmente in come ciascuno viene eseguito:

Modifica standard

Una modifica che tu (o l’IA) pianifichi — una modifica di configurazione, una variazione di regola di firewall, un’attività di manutenzione. Ha un piano di implementazione e un piano di rollback, e una volta approvata la avvii esplicitamente con Execute. Gli agenti eseguono poi i passaggi.

Patch di aggiornamento

Un rollout di patch di sistema operativo che nasce nell’area Updates. L’IA pianifica le patch in sospeso in una finestra di manutenzione; una volta approvata, l’agente le installa automaticamente in quella finestra — nessun Execute manuale.
Entrambi i tipi condividono lo stesso ciclo di vita, lo stesso gate di approvazione, la stessa finestra di modifica e la stessa traccia di audit. Differiscono solo al momento dell’esecuzione: una modifica standard viene attivata su richiesta, una patch gira all’interno della sua finestra pianificata. Il flusso di approvazione copre entrambi.

​
Il Ciclo di Vita di una Modifica

Una GMUD attraversa un insieme fisso di stati. Il percorso ideale ha sei fasi; alcuni stati di eccezione chiudono una modifica che non si è conclusa normalmente.
1

Bozza

La modifica è in fase di stesura — identificazione, giustificazione, rischio, finestra e passaggi di implementazione/rollback. Completamente modificabile.
2

Sottoposta

Inviata per approvazione. Ora attende gli approvatori secondo la regola di approvazione corrispondente.
3

Approvata

Sono state registrate abbastanza approvazioni. Una modifica standard è ora pronta per Execute; una patch è pronta per girare nella sua finestra.
4

Pianificata

La modifica è in coda per la sua finestra di modifica. Mentre è pianificata, il record si aggiorna automaticamente ogni 60 secondi.
5

In esecuzione

Gli agenti stanno eseguendo i passaggi. Per una patch, i pacchetti si stanno installando sugli host di destinazione.
6

Completata

Ogni passaggio è terminato con successo. La modifica è chiusa e completamente sottoposta ad audit.
Al di fuori del percorso ideale, una modifica può anche terminare come:
Modificare una modifica dopo che è stata sottoposta la reimposta. Modificare una modifica che è sottoposta, approvata o pianificata annulla qualsiasi esecuzione dispatchata e la riporta a Bozza — dovrà essere sottoposta e approvata di nuovo. È intenzionale: una modifica approvata è approvata così com’è scritta.

​
Anatomia di una Modifica

Ogni GMUD è un documento strutturato. Quando ne apri una, è organizzata nelle sezioni che un change-advisory board si aspetterebbe:

Identificazione della Modifica

Titolo, stato, tipo di modifica, categoria tecnica e kind (modifica standard o patch).

Contesto e Giustificazione

Il problema o la motivazione, l’obiettivo e il risultato atteso, e cosa è esplicitamente nell’ambito e fuori ambito.

Valutazione del Rischio e dell'Impatto

Probabilità, impatto e il livello di rischio finale; servizi e utenti impattati, downtime atteso, rischi di sicurezza/compliance e dipendenze.

Sistemi coinvolti (CI)

I dispositivi e le integrazioni che la modifica tocca, ognuno collegato come coinvolto o dipendente — così il raggio d’azione è esplicito.

Finestra di Modifica

Inizio e fine della finestra di manutenzione, più la comunicazione agli stakeholder. Il record mostra quando la finestra si apre e si chiude.

Piani di Implementazione e Rollback

I passaggi ordinati per effettuare la modifica e i passaggi per annullarla — vedi sotto.

​
Passaggi di implementazione e rollback

Il piano è un elenco di passaggi ordinati, ognuno etichettato Implementazione o Rollback. Un passaggio registra l’attività, il suo ordine, un responsabile, una durata attesa e — opzionalmente — un target (un dispositivo o un’integrazione specifica) e un’azione da eseguirvi. Durante l’esecuzione, ogni passaggio mostra il proprio stato, così puoi vedere esattamente fin dove è arrivata la modifica e cosa resta se qualcosa deve essere annullato.
Un solido piano di rollback è ciò che rende una modifica sicura da approvare. Chiedi all’IA di redigerlo per te — “aggiungi un piano di rollback che ripristini questa modifica alla regola del firewall.”

​
Come Arrivarci

Apri Gestione delle Modifiche dal Directory a sinistra della console. Elenca le tue modifiche per il contesto selezionato — modifiche standard e modifiche di patch sono mostrate con icone distinte — e ognuna si apre come una tab nel Workspace. Vederla richiede il permesso gmuds.read. Puoi anche portare una modifica dentro una conversazione: @-menziona una modifica (o una patch) come entità di contesto e chiedi all’IA a riguardo, o chiedile di redigerne o modificarne una.

​
Dove Si Inserisce l’IA

La Gestione delle Modifiche è profondamente legata agli agenti:
  • Redazione — chiedi a Centurion di preparare una modifica e riempirà l’identificazione, il rischio, la finestra e un primo piano di implementazione/rollback per la tua revisione.
  • Proposte di patch — l’IA revisiona gli aggiornamenti in sospeso e propone una modifica patch (una GMUD di tipo patch) con una finestra di manutenzione (vedi Gestione di patch e aggiornamenti).
  • Esecuzione — una volta approvata (e, per una modifica standard, cliccato Execute), gli agenti eseguono i passaggi, guidati dal Workspace.
Per tutto il percorso, tu tieni il gate: nessuna modifica lascia la fase di approvazione senza una decisione umana, e ogni azione — umana, dell’agente o del sistema — è scritta nella cronologia della modifica.

​
Traccia di Attività ed Esportazione

Ogni GMUD porta una timeline di Attività: quando è stata creata e da chi, ogni approvazione o rifiuto (con la motivazione data), ogni passaggio mentre è stato eseguito, e l’ultimo aggiornamento. Risponde “chi ha fatto cosa e quando?” sul record stesso. Puoi anche esportare la modifica in PDF — per un change-advisory board o un auditor — direttamente dal record.

​
Prossimo

Flusso e regole di approvazione

Come funziona submit → approve → execute, e come governare chi deve approvare cosa.

Gestione di patch e aggiornamenti

Revisiona gli aggiornamenti OS in sospeso e approva le pianificazioni di patch proposte dall’IA.