Cambiare il modo di pensare
Di tutte le unità di questo modulo, questa è certamente una delle più importanti. In questa unità verranno esaminate alcune idee che potrebbero cambiare il modo di pensare in merito a ciò che è importante monitorare e al motivo per cui monitorare. Per alcune persone, questo può significare un radicale cambiamento del modo di concepire il monitoraggio per il miglioramento dell'affidabilità.
Riframing #1: Affidabilità dal punto di vista del cliente
In precedenza abbiamo illustrato gli aspetti dell'affidabilità che è opportuno prendere in considerazione per il monitoraggio. Questo tuttavia sembra solo espandere il possibile set di elementi da monitorare. Ecco un'idea che può aiutare a chiarire gli elementi che è più importante monitorare per migliorare l'affidabilità:
L'affidabilità deve essere misurata dal punto di vista del cliente, non dal punto di vista del componente.
Questo è molto importante. Tanto importante che è consigliabile rileggere la frase. In passato le persone volevano "monitorare tutto". Se era possibile leggere un contatore specifico, tracciare un grafico di una statistica o inserire un valore sul dashboard, si riteneva che fosse necessario monitorare tale elemento. "Misurare dal punto di vista del cliente" è un principio molto più specifico.
Esaminiamo un breve scenario in cui viene illustrato questo punto.
Scenario
Si è responsabili dell'esecuzione del sito Web di e-commerce dell'azienda per cui si lavora. Si dispone di una Web farm con 100 istanze del server. Improvvisamente, 14 di queste 100 istanze smettono di funzionare a causa di un errore del sistema operativo, un aggiornamento del software, una fluttuazione dell'alimentazione o un altro evento imprevisto. Queste 14 istanze sono ora completamente fuori servizio.
Per esaminare: 86 istanze del server sono operative, 14 istanze del server non sono operative.
Quale delle seguenti affermazioni è vera in questa situazione?
R: Non è un grosso problema. È possibile affrontare il problema in seguito, quando si avrà il tempo per risolverlo.
B: È una questione seria. È consigliabile interrompere qualsiasi attività in corso e ripristinare al più presto le 14 istanze del server.
C: È una crisi esistenziale per l'azienda. È necessario informare i dirigenti di massimo livello e coinvolgerli nella gestione del problema il più rapidamente possibile, anche se questo significa svegliarli in piena notte.
Esaminare attentamente questo scenario prima di rispondere, quindi proseguire con la lettura. La risposta corretta è A, B o C?
La risposta corretta non è né A, né B, né C, ma "dipende" o, più precisamente, "dipende dall'esperienza che vivono i clienti per effetto dell'interruzione".
Se il sito è stato progettato in modo che nessun cliente noti l'inattività dei back-end e le altre istanze del server 86 stanno supportando il carico senza problemi, non c'è alcuna crisi. Potrebbe trattarsi di un evento imprevisto di livello SEV-3 o SEV-4 oppure di un semplice ticket di supporto.
Se l'interruzione del servizio ha reso inattiva l'intera azienda, che sta perdendo somme enormi per ogni minuto di inattività dei server, probabilmente questo è un motivo valido per premere il pulsante rosso dell'allarme generale. Potrebbe anche verificarsi una situazione intermedia. In tal caso, la risposta sarà "B".
Anche in questo caso, è necessario misurare l'affidabilità dal punto di vista del cliente, non dal punto di vista del componente. Per questo motivo, il numero di componenti ("14 computer inattivi su 100"), anche se completamente accurato, non è l'informazione più importante in questo scenario dal punto di vista dell'affidabilità.
Questa idea è valida anche nel caso di un monitoraggio più tradizionale basato sui componenti. Se rileviamo che il server di database è in esecuzione al 50% di carico della CPU, è positivo o negativo? Se il livello sale al 90%, la situazione è migliore o peggiore? Se il servizio funziona correttamente e gli utenti sono soddisfatti, il 90% potrebbe essere ottimo, perché significa che l'utilizzo delle risorse è stato migliorato notevolmente. Tuttavia, se gli utenti reclamano per la lentezza con cui l'applicazione veniva eseguita al 50% di carico della CPU, il 90% probabilmente non è un miglioramento.
Riframing n. 2: livelli appropriati di affidabilità
Per comprendere in modo corretto questa idea, è opportuno esaminarne rapidamente l'origine. L'idea deriva dai principi Site Reliability Engineering (SRE). È possibile trarre varie idee utili (inclusa quella su cui è basata questa sezione) semplicemente esaminando la definizione di SRE:
Nota
Site Reliability Engineering (SRE) è una disciplina di ingegneria informatica dedicata ad assistere le organizzazioni che vogliono ottenere con modalità sostenibili livelli di affidabilità appropriati per i sistemi, i servizi e i prodotti.
Questa definizione contiene tre parole importanti:
Affidabilità: l'importanza dell'affidabilità è stata ampiamente descritta nell'unità introduttiva e non verrà trattata ulteriormente in questa sede.
Sostenibilità: in questo contesto, la "sostenibilità" si riferisce al ruolo delle persone rispetto al processo. È essenziale creare procedure operative sostenibili. I sistemi, i servizi e i prodotti affidabili sono creati dalle persone. Se non si adotta alcuna misura per assicurarsi che il lavoro sia sostenibile, se si svegliano le persone ogni notte alle 3:00 con un messaggio, se non si lascia loro del tempo da trascorrere con la famiglia, se non hanno la possibilità di dedicare tempo a occuparsi di se stessi, è impossibile che riescano a realizzare sistemi affidabili. SRE ritiene che sia importante implementare procedure operative sostenibili nel tempo, in modo che le persone possano offrire il loro migliore contributo al lavoro.
Appropriato: è la parola che può essere un elemento di cambiamento per alcuni utenti. In passato, nell'ambito delle operazioni, l'obiettivo era assicurarsi che tutti i sistemi fossero attivi 24 ore su 24, 7 giorni su 7. Si cercava di mantenere tutto online per tutto il giorno, tutta la settimana, tutto il mese e tutto l'anno. Non era mai accettabile che qualcosa fosse inattivo. Uno dei contributi offerti dalla disciplina Site Reliability Engineering alla discussione sulle operazioni è stata la nozione che dovremmo puntare a un livello di affidabilità appropriato.
Esaminiamo questa idea. Un punto chiave è che un livello di affidabilità del 100% non è quasi mai l'obiettivo giusto. Tranne che per alcune eccezioni, come i dispositivi medici o l'aviazione, non è realmente necessario che i sistemi siano affidabili al 100%. Di fatto, un'affidabilità del 100% spesso non è possibile.
Ecco un esempio di "nemmeno possibile": tutti i sistemi attualmente in esecuzione presentano dipendenze da altri sistemi. Si potrebbe eseguire un software che deve effettuare una chiamata a un componente di elaborazione dei pagamenti o un sistema di autenticazione. Se il componente di elaborazione dei pagamenti o il sistema di autenticazione non ha un'affidabilità del 100%, può essere molto difficile per il sistema risultare affidabile al 100%.
L'altra cosa da tenere presente in merito a un obiettivo del 100% di affidabilità è che significa zero tempo di inattività. Significa anche zero possibilità di apportare modifiche che potrebbero comportare eventuali tempi di inattività. Non è possibile avere alcun margine di manovra, un elemento generalmente desiderabile, se non necessario.
È utile iniziare ad affrontare i problemi chiedendosi "Qual è il livello di affidabilità appropriato?" per un particolare sistema che si sta provando a eseguire. Per tornare all'argomento della nostra discussione, il monitoraggio dovrà supportare questo obiettivo.
Tenendo presenti questi due aspetti, possiamo passare alla pratica ed esaminare alcuni strumenti che ci consentiranno di raggiungere i nostri obiettivi.