sfida delle metriche di distribuzione pre-DevOps

TL; DR, come si dimostra che devops, in particolare l'automazione della distribuzione, migliora i tassi di errore delle modifiche?

Stiamo tutti cercando di acquisire metriche sugli "errori di distribuzione" utilizzando i mezzi attuali (principalmente manuali). Sfortunatamente, raramente si verifica un "fallimento", giusto? Perché quando qualcosa va storto, il team si riunisce (in genere con eroismo) per risolvere il problema (in genere autorizzazioni, configurazioni perse, conosci l'esercitazione). Quindi ... quando chiediamo come è andata la distribuzione, la risposta è "ha funzionato".

Ma intuitivamente sappiamo tutti che non va bene. Il rapporto sullo stato dei devops del 2017 afferma che c'è circa un 31-45% di " tasso di fallimento delle modifiche " . Nah. Perché vengono riparati abbastanza rapidamente, di solito durante la convalida. È molto più raro ripristinare effettivamente una distribuzione.

Quindi, ci vuole disciplina per segnalare accuratamente i tassi di fallimento. Siamo disincentivati ​​a riferire in questo modo perché vogliamo che le cose funzionino e facciamo quello che serve per realizzarlo.

Quindi, come si dimostra che devops, in particolare l'automazione della distribuzione, migliora i tassi di errore delle modifiche?

(PS ha provato a taggarlo con "# modello-capacità-devops")

Una tecnica che abbiamo usato in passato in situazioni simili è quella di ottenere un "impegno di gestione" che impone queste regole a ogni membro del team:

1. L'accesso per eseguire aggiornamenti alle aree di distribuzione di destinazione (ovvero produzione) è limitato ai sistemi automatizzati selezionati, che dispongono di percorsi di controllo appropriati (= registrazione) di qualsiasi tipo di aggiornamento delle aree che gestiscono.

2. Gli aggiornamenti manuali alle aree di distribuzione di destinazione, per qualsiasi motivo, non sono più consentiti dai membri del team tipici (ID utente) che erano in grado (autorizzati) di eseguire tali aggiornamenti. Verranno invece creati NUOVI ID utente (aggiuntivi) che disporranno di tutte le autorizzazioni necessarie per (ancora) eseguire tali aggiornamenti manuali, quando necessario. Ma per poter effettivamente utilizzare quei nuovi ID utente (= eseguire un accesso con essi), il membro del team che desidera eseguire un accesso con tale nuovo ID utente dovrà eseguire "alcuni" passaggi aggiuntivi per ottenere l'accesso alla password per tale nuovo ID utente. Idealmente questo passaggio aggiuntivo è anche automatizzato (usa la tua immaginazione come dovrebbe apparire), ma se qualcos'altro non riesce: basta contattare (= e-mail, chiamare, ecc.) Il gate-keeper della password richiesta, incluso "quale problema hanno sistemarsi "

3. Mettere in atto un tale guardiano non è un lavoro facile. E la maggior resistenza verrà da ... i membri del team (per ogni sorta di ragioni). Pertanto una variazione di questi nuovi ID utente (come nel passaggio precedente) è che ogni membro del team ottiene un ID utente aggiuntivo (con la password che decide autonomamente), ma con una stringa aggiuntiva allegata ad esso: è consentito solo eseguire un accedere con quell'ID utente (extra) se effettivamente hanno una buona ragione per farlo. E ogni volta che eseguono tale accesso, sono tenuti a presentare un tipo di rapporto su "quale problema sono stati risolti" (simile alla tua domanda).

Con queste procedure in atto, tutto ciò che resta da fare è rivedere periodicamente ciascuno di quei report / motivi per cui è stato richiesto di utilizzare tale ID utente speciale e porre la domanda " È possibile fare qualcosa per automatizzare ulteriormente questo, per ridurre ulteriormente la necessità di un accesso così speciale? ".

Aggiornamento :

Cita dal tuo commento extra sotto questa risposta:

Penso che l'aggiunta di barriere artificiali alla risoluzione di un problema di distribuzione sia controproducente.

È vero che aggiunge un ulteriore ostacolo, ma non sono convinto che sia "artificiale". Perché questo è, per quanto ne sappia, l'unico modo per prendere coscienza di cose che quei membri del team non ti diranno mai, per motivi come:

• sicurezza sul lavoro.
• cose cattive / pratiche che preferiscono tenere nascoste.
• potere che non vogliono perdere.

Il rapporto sullo stato dei devops del 2017 afferma che c'è un 31-45% di "tasso di fallimento delle modifiche". Mentre ciò suona intuitivamente su giusto, sono tracciati come incidenti? Nah. Perché vengono riparati abbastanza rapidamente, di solito durante la convalida.

Un problema che viene risolto rapidamente è ancora un problema. Se non li stai segnalando come tali, questo è un problema.

Quindi, ci vuole disciplina per segnalare accuratamente i tassi di fallimento. Siamo disincentivati ​​a riferire in questo modo perché vogliamo che le cose funzionino e facciamo quello che serve per realizzarlo.

Se il tuo obiettivo è effettivamente far funzionare le cose, allora devi essere onesto sui fallimenti in modo da poterli prevenire in futuro. Suona come la squadra qui sta mentendo (forse a se stessi, di certo alla gestione) sugli errori perché il loro obiettivo è quello di avere le cose sembrano funzionare.

Queste sono cose diverse. Ad esempio, prendi la vecchia battuta che il QA produce bug - "il mio codice andava bene fino a quando il QA non se ne rendeva conto, e poi hanno fatto tutti questi bug!". I bug erano lì da sempre, ma lo sviluppatore ne ignorava. L'obiettivo di un team operativo dovrebbe essere la reale affidabilità e devono essere incentivati ​​come tali dalla loro gestione. Ciò significa che se mettono in atto un maggiore monitoraggio che porta alla scoperta di nuovi problemi, dovrebbero essere premiati, non penalizzati per il successivo calo delle metriche di affidabilità.

TL; DR, come si dimostra che devops, in particolare l'automazione della distribuzione, migliora i tassi di errore delle modifiche?

Se stai cercando di motivare il cambiamento nella tua organizzazione, non dovresti provare a provare nulla, ma fornire prove di ciò che altre organizzazioni dicono delle loro transizioni. Se stai cercando di misurare i processi che hai già in atto e giustificare la loro continua esistenza, allora dovresti tenere traccia delle metriche di affidabilità standard, come il tempo medio di riparazione (MTTR).

Ma i principi di Devops non riguardano semplicemente l'aumento dell'affidabilità. Anche l'ingegneria dell'affidabilità del sito non riguarda semplicemente l'aumento dell'affidabilità. Piuttosto, vuoi raggiungere un livello adeguato di affidabilità - qualcosa che avvantaggia il business ma non ostacola lo sviluppo. E questo fa emergere il vero motivatore in devops, che è quello di potenziare il cambiamento . Volete consentire all'azienda di rispondere più rapidamente agli stimoli del mercato, che si verificano riducendo l'attrito degli sviluppatori, aumentando il tasso di schieramenti, automatizzando i processi manuali, ecc. Rimanendo entro un limite accettabile di affidabilità. Ciò significa che devi misurare l'affidabilità, ma devi anche misurare la velocità, perché il tuo obiettivo è quello di aumentare il secondo mantenendo il primo relativamente statico.