Skip to main content
L’approvazione è il cuore della Gestione delle Modifiche. Qualsiasi cosa che alteri un sistema passa attraverso un gate umano prima di essere eseguita — che sia una modifica standard scritta a mano o un lotto di patch di sistema operativo. Questa pagina copre quel gate dall’inizio alla fine e come governarlo con le regole di approvazione.

​
Il Gate, Passo per Passo

1

Sottoporre

L’autore termina la bozza e la sottopone. La modifica passa a Sottoposta e la regola di approvazione corrispondente determina chi deve firmare e quante approvazioni servono.
2

Revisionare e decidere

Gli approvatori aprono la modifica, revisionano giustificazione, rischio, finestra e piano, e Approvano o Rifiutano. Il pannello delle Approvazioni traccia il progresso in tempo reale — per esempio 2 di 3 — e mostra quale regola è in vigore.
3

Approvata

Raggiunto il numero richiesto di approvazioni, la modifica diventa Approvata ed è pronta per essere eseguita.
4

Esecuzione — i due percorsi

Una modifica standard viene avviata esplicitamente con Execute (Approvata → In esecuzione), e gli agenti eseguono i passaggi. Una patch di aggiornamento non ha bisogno di trigger manuale — si installa automaticamente all’interno della sua finestra di manutenzione pianificata.
5

Chiusa e sottoposta ad audit

La modifica termina come Completata (o Parziale / Fallita), e tutta la traccia decisionale è registrata nella sua cronologia.

​
Approvare e rifiutare

  • Approvare registra la tua decisione sotto il tuo utente. Quando la modifica raggiunge il numero richiesto di approvazioni, avanza automaticamente.
  • Rifiutare termina il flusso di approvazione — la modifica passa a Rifiutata. Puoi allegare una motivazione così che l’autore sappia cosa correggere; può poi modificare la modifica (che la riporta a Bozza) e sottoporla di nuovo.
Ogni approvazione e rifiuto è attribuito all’utente che l’ha fatto, con un timestamp, e appare nella cronologia di Attività della modifica — così che il record risponda “chi ha approvato questo, e quando?” da solo.

​
I Due Percorsi di Esecuzione

Il gate di approvazione è identico per entrambi i tipi di modifica; differisce solo ciò che accade dopo l’approvazione.

Modifica standard — tu Esegui

Dopo l’approvazione, una persona clicca Execute per avviare la modifica. Questo mantiene un umano nel controllo di quando il lavoro inizia, anche dopo la firma. Gli agenti eseguono poi i passaggi di implementazione dal Workspace, e il piano di rollback è a portata di mano se necessario.

Patch di aggiornamento — parte nella finestra

Approvare un gruppo di patch autorizza l’agente a installarlo nella prossima finestra di manutenzione. Non c’è Execute manuale — il rollout inizia quando la finestra si apre e procede elemento per elemento. Approvare è registrato sotto il tuo utente.
Per le patch, approvare è l’impegno. La conferma è esplicita: “Questo autorizza l’agente a installare gli aggiornamenti di questo gruppo nella prossima finestra di manutenzione.” Fino ad allora, la vista delle patch in sospeso è di sola lettura e non installa nulla.

​
Regole di Approvazione

Di default, una modifica richiede un’approvazione, e il richiedente può approvare la propria modifica. Va bene per un piccolo team, ma la maggior parte delle organizzazioni vuole una governance più forte. Le regole di approvazione ti permettono di definire, per contesto, esattamente chi deve approvare quali modifiche — una policy valutata automaticamente ogni volta che una modifica è sottoposta. Una regola è composta da: Quando una modifica è sottoposta, Myrmex trova la regola corrispondente (per tipo di modifica, preferendo una regola nominata per quel tipo a una generica) e la applica. Il pannello delle Approvazioni mostra poi la regola in vigore e il progresso verso il suo minimo — per esempio, min. 2.
Le regole sono un livello di policy, non un collo di bottiglia: se nessuna regola corrisponde a una modifica, si applica il default — 1 approvazione, e il richiedente può approvare. Rimuovere una regola fa semplicemente ricadere le sue modifiche su quel default.

​
Gestire le regole

Apri la vista Regole di approvazione dalla Gestione delle Modifiche per creare, modificare, abilitare/disabilitare o eliminare regole. Gestire le regole è un’azione di governance, separata dall’approvare singole modifiche — è gated dal permesso gmuds.admin.
Eliminare una regola non blocca nulla — le modifiche nel suo ambito ricadono sulla policy di default (1 approvazione, il richiedente può approvare). Se hai bisogno di un controllo più rigido, disabilita una regola invece di lasciare un vuoto, o sostituiscila prima di rimuoverla.

​
Chi Può Fare Cosa

La Gestione delle Modifiche è governata da un insieme dedicato di permessi, così puoi separare chi redige le modifiche da chi le approva e chi governa le regole:
Concedi gmuds.create / gmuds.update agli ingegneri che pianificano le modifiche, riserva gmuds.approve ai proprietari delle modifiche o a un comitato di approvazione, e tieni gmuds.admin con il tuo team di governance. Combinato con gli approvatori nominati in una regola, ti dà una separazione dei compiti pulita. Vedi Controllo degli accessi.

​
Correlato

Panoramica della Gestione delle Modifiche

Il modulo, i due tipi di modifica e il ciclo di vita completo.

Gestione di patch e aggiornamenti

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