Qual è la relazione corretta tra rollback / rollforward e metriche MTTR?

Sto cercando di capire il modo migliore per acquisire i dati per iniziare a misurare le metriche Mean Time To Repair (MTTR) e ho bisogno di capire come il "rollback" abbia un impatto positivo o negativo sul MTTR.

scenario 1

Supponendo che sia in atto un solido monitoraggio, viene distribuito un codice che provoca un incidente che viene rilevato piuttosto rapidamente (MTTI basso). Al punto di identificazione, ci sono due principali possibili percorsi (sì, sto semplificando troppo ai fini della discussione):

1. Ripristina la distribuzione, restituendo rapidamente stabilità, ma senza le funzionalità previste nella produzione.

2. Roll-forward con ulteriori modifiche che risolvono l'incidente e mantengono attive le funzionalità desiderate.

In questo scenario, MTTR è piuttosto basso, dato che la stabilità del sito può tornare abbastanza rapidamente. Detto questo, il risultato previsto della modifica non è attivo e quindi il codice / funzione / modifica è ancora bloccato nel processo. Se un obiettivo è un MTTR basso, sembra incentivare il rollback come meccanismo di recupero.

Scenario 2

In questo scenario, MTTR viene misurato rigorosamente da quanto tempo impiega il codice / funzione / modifica previsti per funzionare correttamente nella produzione. Anche se eseguo il rollback, fino a quando il mio cambio di codice "fisso" non entra in prod, il timer MTTR è ancora in esecuzione. In questo caso, MTTR sembra legato alla stabilità dei risultati di business invece che semplicemente "ehi, le cose sono stabili".

Ora, la risposta potrebbe essere semplice come l'MTTR che non viene utilizzato come metrica nel vuoto, ma piuttosto in combinazione con il tasso di errore di cambiamento - un MTTR bassissimo causato da frequenti rollback potrebbe indicare un tasso di errore di cambiamento altissimo. Detto questo, c'è qualcosa che non mi sembra giusto nell'idea di divorziare la misurazione dell'MTTR dal risultato commerciale.

Potrei pensare troppo a questo, ma sono curioso di sapere come gli altri stanno misurando il MTTR e quale sia il punto finale nel tempo per il "recupero". Lo stai usando semplicemente come stabilità o altri fattori determinano cosa significa "recuperato"?

Sì, l'MTTR è / dovrebbe sempre essere legato all'esito del business: se le cose non sono stabili il business stesso è a rischio.

Il fatto che il codice / funzionalità / modifica previsti sia ancora bloccato nel processo nello scenario 1 è irrilevante: la funzionalità non è stabile, quindi non porta nuovi affari, il rollback è il meglio che puoi fare in quel momento dall'azienda prospettiva.

Il rollforward è una scommessa: mantiene l'azienda a rischio in attesa di una potenziale soluzione che in realtà ha cambiamenti statisticamente inferiori di successo (a causa dell'instabilità sarà sempre precipitato rispetto al cambiamento che ha causato l'instabilità in primo luogo senza nemmeno avere tale pressione su di esso). Il rollforward è un'altra versione del codice che non è mai stata verificata prima.

Se vuoi mantenere basso l'MTTR, esegui immediatamente il rollback, senza discussione. Ciò elimina il rischio aziendale e ti dà la possibilità di verificare che la correzione funzioni effettivamente prima di tentare di distribuirla. Suggerirei vivamente di renderlo una politica come sì, quasi sempre ci sarà qualcuno che chiede una correzione invece del rollback e convoca una riunione per negoziare / decidere su di essa - tutto mentre gli affari rimangono a rischio.

Nota a margine: se ti preoccupi di un alto tasso di errore di modifica, suggerirei di verificare il tasso di rollback effettivo invece di derivarlo da un MTRR basso. Forse desideri aggiungere un controllo del gate prima della distribuzione per gli errori più frequenti. Se tale controllo è già automatizzato, perché non includerlo nella verifica dell'elemento della configurazione? Se non ne hai uno, forse è il momento di iniziare a pensarci? :)

Il tempo medio di recupero ha un soggetto implicito - il tempo medio di recupero cosa ? La definizione di questo è la chiave per utilizzare la metrica in modo efficace.

Stai recuperando la disponibilità generale del tuo sito Web di produzione? Stai recuperando la funzionalità di una particolare funzionalità che contiene un bug? Una volta che sai cosa stai effettivamente cercando di misurare, è molto più facile misurarlo!

La spinta generale della tua domanda sembra in realtà circondare gli obiettivi in ​​competizione di funzionalità di spedizione e mantenimento dell'affidabilità, che è una battaglia secolare. Tradizionalmente sono i lavori degli sviluppatori a implementare nuove cose e i lavori degli amministratori di sistema per evitare che le cose si rompano, e questo porta a conflitti dipartimentali, poiché il cambiamento tende a causare rotture. Una delle filosofie spesso associate a DevOps è l'idea che sviluppatori e ingegneri operativi dovrebbero lavorare a stretto contatto insieme per alleviare questa tensione.

Potresti anche essere interessato all'approccio di Google a questo problema, che prevede "budget di errore" da spendere per i team di sviluppo; una volta che hanno penalizzato troppo la stabilità, devono passare il resto del trimestre lavorando solo sulla stabilità. Insieme a questo, gli ingegneri dell'affidabilità del sito hanno obiettivi disponibili e, se superano le riprese, sono incoraggiati a consentire ulteriori cambiamenti; l'idea qui è che il loro obiettivo non deve essere semplicemente quello di mantenere l'affidabilità il più elevata possibile, poiché sarebbero motivati ​​a combattere il cambiamento in ogni situazione.