Come implementare il principio dei quattro occhi per le correzioni di emergenza?

Considera questo scenario (qualsiasi confronto con le situazioni del mondo reale è puramente casuale):

03:07 : chiamata di supporto in arrivo " Qualcosa nella produzione è andato in fumo, ho bisogno del tuo aiuto! ".
3:12 : collegato al sistema (accesso accettato) ... e non c'è tempo per il caffè.
03:15 : fortunatamente tu, subito potresti individuare il problema tramite qualche messaggio di errore da qualche parte.
3:17 : usa il tuo toolbox SCM per afferrare il codice, risolvere il problema, provarlo, fantastico ... la mia correzione funziona!
3:20 : mettiti in contatto con il team ~~Dev~~ Ops per spedire la correzione e far ripartire la produzione.
3:21 : bandiera rossa ... " Per rispettare i quattro occhi , abbiamo bisogno di altri 2 occhi per ottenere l'approvazione per questa correzione ".
3:22 : ggggrrrreat, e adesso, chi altro possiamo chiamare (= sveglia un manager)?

Se hai implementato una procedura di approvazione simile alla mia risposta a " Quali sono le possibili implementazioni (o esempi) del principio dei quattro occhi? ", Allora sei sfortunato ... ecco le tue scelte:

La tua correzione rimarrà bloccata (leggi: la produzione verrà interrotta) fino a quando non verranno coinvolti altri 2 occhi.
Trovi un modo per aggirare gli occhi mancanti.

Quindi, come implementare il principio dei quattro occhi per le correzioni di emergenza? ... In modo che la produzione sia avviata e funzionante al più presto, cioè intorno alle 3:25 ... E in modo che tu possa anche chiudere la chiamata (e tornare da dove sei venuto)?

configuration four-eyes

— Pierre.Vriens
fonte

Hai contattato una squadra , il che significa che avrebbero già dovuto benedire la patch rispetto ai principi di approvazione in atto.

— Comincio

@Tensibai come è possibile "avere benedetto un po 'di patch" (o correggere) in anticipo, non sapendo quale fosse la causa del problema quando "sei stato contattato"? Inoltre, puoi essere più specifico sulla retorica? Non va bene, qualcos'altro?

— Pierre.Vriens

Voglio dire, dici che sei riuscito a contattare la squadra alle 3:20, il che significa che non sei solo tu a spingere la correzione. Uso la retorica come "caso ipotetico, basato sull'esperienza o meno, in cui sai già quale risposta stai aspettando". Più o meno le mie preoccupazioni per i meta mi sento solo non interessato a questo Q / A di "principi generici", quindi probabilmente mi sbaglio. Quello che sono sicuro è che non visiterò due volte un Q / A sui principi generici se fossi un outlander di questa beta.

— Tensibai,

Potrei dire lo stesso delle domande generiche su Jenkins se arrivassero adesso

— Tensibai

Gli impegni non verranno calcolati fino alla beta pubblica, per ora in privato stiamo costruendo ciò che gli utenti "impegnati" ritengono siano domande esemplari per questo sito e penso che avremo un sacco di lavoro nei restanti 12 giorni, o potrei devo passare attraverso le 7 fasi del dolore

— Tensibai

Risposte:

Nel mondo SCM in cui conosco maggiormente, lo scenario di cui sopra è in genere affrontato da quella che viene chiamata la procedura dell'elenco di approvazione " abbreviata " .

Ecco un progetto:

Definisci l'orario di lavoro, ad esempio dalle 8 alle 18.
Definire un completo elenco approvazione (diciamo) 3 livelli di approvazione (per i ruoli X, Y e Z).
Definire un elenco di approvazione abbreviato di (ad esempio) solo 1 livello di approvazione (solo per i ruoli X).
Le modifiche pianificate richiedono sempre tutte le approvazioni dall'elenco completo delle approvazioni.
Per le modifiche non pianificate , l'elenco completo delle approvazioni viene utilizzato anche per raccogliere le approvazioni richieste, a condizione che le approvazioni debbano essere emesse durante l'orario di ufficio definito.
Per eventuali approvazioni di modifiche non pianificate che devono essere emesse al di fuori dell'orario di lavoro definito:
- Solo le approvazioni dall'elenco di approvazioni abbreviato (come il ruolo X sopra) sono necessarie per autorizzare la modifica. E dopo che viene data l'autorizzazione dall'elenco di approvazione abbreviato, verrà effettivamente eseguita la distribuzione della modifica (nell'ambiente di destinazione).
- Ma ulteriori postali -approvals saranno necessarie successivamente (entro un ragionevole lasso di ore / giorni), cioè da tutti i ruoli contenuti nella lista autorizzazioni completa (come ruolo Y e Z sopra), che non sono contenuti anche nella lista autorizzazioni abbreviato (come il ruolo X sopra). E se entro la quantità di ore / giorni concordata (anticipata) non sono state emesse tutte le approvazioni successive (ad esempio perché la correzione ha funzionato "questa" volta, ma era solo come una correzione temporanea), la modifica potrebbe essere soggetta a un rollback . Sebbene sia presente almeno 1 post-approvazione in sospeso, la modifica è contrassegnata come "attesa post approvazioni".

Con tale soluzione in atto, la chiamata può essere chiusa intorno alle 3:23 ... dal momento che non ci sarà più bandiera rossa alle 3:21 ... (al posto del caffè) ... e incrociamo le dita, presto arriveranno le approvazioni post eccezionali ...

— Pierre.Vriens
fonte

Nel caso di riparazioni di emergenza fuori orario, è più pratico richiedere meno firme per le modifiche rispetto alla normale procedura. In genere, è possibile distribuire una correzione e quindi eseguire le approvazioni successive il giorno lavorativo successivo. Se la correzione non viene approvata, può essere ripristinata e sostituita con una soluzione permanente.

Durante una situazione di interruzione, la priorità numero uno dovrebbe essere quella di ripristinare il servizio. Se la tua organizzazione non riconosce questo processo rilassato durante un'interruzione, quindi sì, l'unica opzione è iniziare a svegliare più persone per la firma.

— tayworm
fonte

Sono d'accordo con la tua raccomandazione, che sembra essere simile alla mia raccomandazione (risposta). Riesci a pensare a qualche esempio nel mondo SCM con cui hai familiarità e COME lo implementeresti lì? In tal caso, puoi approfondire questo nella tua risposta?

— Pierre.Vriens