Una guida per un tecnico dell'affidabilità del sito alla gestione del cambiamento
I tre principi fondamentali per una gestione efficace delle modifiche per gli SRE sono implementazioni progressive, monitoraggio e rollback sicuri e rapidi.
Nel mio articolo precedente ho parlato della gestione degli incidenti (IM), una componente importante dell'ingegneria dell'affidabilità del sito. In questo articolo mi concentrerò sulla gestione del cambiamento (CM). Perché è necessario gestire il cambiamento? Perché non creare semplicemente un ambiente libero in cui chiunque possa apportare modifiche in qualsiasi momento?
Ci sono tre principi fondamentali per una CM efficace. Questo ti fornisce un quadro di previsione per la tua strategia CM:
- Implementazione progressiva delle modifiche: esiste una differenza tra le implementazioni progressive in cui si implementano le modifiche in più fasi e quelle eseguite tutte in una volta. Scoprirai che, anche se il cambiamento progressivo può sembrare positivo sulla carta, ci sono delle insidie da evitare.
- Rilevamento dei problemi con le modifiche: il monitoraggio è estremamente fondamentale affinché il tuo CM funzioni. Discuto e osservo esempi di come impostare un monitoraggio efficace per garantire che sia possibile rilevare i problemi e apportare modifiche il più rapidamente possibile.
- Procedure di rollback: come puoi eseguire il rollback in modo efficace quando le cose vanno male?
Perché gestire il cambiamento?
Si stima che il 75% delle interruzioni della produzione siano dovute a cambiamenti. Modifiche pianificate e approvate che tutti noi eseguiamo. Questo numero è sconcertante e richiede solo che tu controlli CM per assicurarti che tutto sia in ordine prima che venga tentata la modifica. La ragione principale di questi numeri sconcertanti è che ci sono problemi intrinseci ai cambiamenti.
Le infrastrutture e le piattaforme sono in rapida evoluzione. Non molto tempo fa, le infrastrutture non erano così complesse ed erano facili da gestire. Ad esempio, un'organizzazione potrebbe avere alcuni server, dove vengono eseguiti un server delle applicazioni, server Web e server di database. Ma ultimamente l’infrastruttura e la piattaforma sono più complesse che mai.
È impossibile analizzare a posteriori ogni interconnessione e dipendenza causata dai numerosi sottosistemi coinvolti. Ad esempio, il proprietario di un'applicazione potrebbe non conoscere nemmeno la dipendenza di un servizio esterno finché non si interrompe effettivamente. Anche se il team dell'applicazione è a conoscenza della dipendenza, potrebbe non conoscere tutte le complessità e tutti i diversi modi in cui il servizio remoto risponderà a causa del cambiamento.
Non è possibile testare scenari sconosciuti. Ciò risale alla complessità delle attuali infrastrutture e piattaforme. I costi saranno proibitivi in termini di tempo impiegato per testare ogni singolo scenario prima di applicare effettivamente una modifica. Ogni volta che apporti una modifica al tuo ambiente di produzione esistente, che si tratti di una modifica della configurazione o del codice, la verità è che sei ad alto rischio di creare un'interruzione. Allora come gestiamo questo problema? Diamo uno sguardo ai tre principi di un sistema CM efficace.
3 principi di un efficace sistema di gestione del cambiamento per gli SRE
L’automazione è l’aspetto fondamentale di un CM efficace. L'automazione attraversa l'intero processo di CM. Ciò comporta alcune cose:
- Implementazioni progressive: invece di apportare un grande cambiamento, il meccanismo di implementazioni progressive ti consente di implementare il cambiamento in più fasi, riducendo così l'impatto sulla base utenti se qualcosa va storto. Questo attributo è fondamentale soprattutto se la tua base utenti è ampia, ad esempio: aziende su scala web.
- Monitoraggio: è necessario rilevare in modo rapido e accurato qualsiasi problema relativo alle modifiche. Il tuo sistema di monitoraggio dovrebbe essere in grado di rivelare lo stato attuale della tua applicazione e del tuo servizio senza notevoli ritardi nel tempo.
- Rollback sicuro: il sistema CM dovrebbe eseguire il rollback in modo rapido e sicuro quando necessario. Non tentare alcun cambiamento nel tuo ambiente senza avere un piano di rollback a prova di proiettile.
Ruolo dell'automazione
Molti di voi sono consapevoli del concetto di automazione, tuttavia molte organizzazioni non dispongono di automazione. Per aumentare la velocità dei rilasci, che è una parte importante della gestione di un'organizzazione Agile, è necessario eliminare le operazioni manuali. Ciò può essere ottenuto utilizzando l'integrazione continua e la distribuzione continua, ma è efficace solo quando la maggior parte delle operazioni sono completamente automatizzate. Questo elimina naturalmente gli errori umani dovuti a fatica e disattenzione. In virtù, la scalabilità automatica, che è una funzione importante delle applicazioni basate su cloud, non richiede alcun intervento manuale. Questo processo deve essere completamente automatizzato.
Implementazioni progressive per gli SRE: implementazione progressiva delle modifiche
Le modifiche ai file di configurazione e ai file binari hanno gravi conseguenze, in altre parole quando si apporta una modifica a un sistema di produzione esistente, si corre il serio rischio di influire sull'esperienza dell'utente finale.
Per questo motivo, quando si implementano le modifiche in modo progressivo invece che tutte in una volta, è possibile ridurre l’impatto quando le cose vanno male. Se dobbiamo tornare indietro, lo sforzo è generalmente minore quando le modifiche vengono apportate in modo progressivo. L'idea qui è che inizierai il tuo cambiamento con un insieme più piccolo di clienti. Se riscontri un problema con la modifica, puoi ripristinarla immediatamente perché a quel punto la dimensione dell'impatto è ridotta.
Esiste un'eccezione all'implementazione progressiva: puoi implementare la modifica a livello globale in una sola volta se si tratta di una soluzione di emergenza ed è giustificato farlo.
Le insidie delle implementazioni progressive
L'implementazione e il rollback possono diventare complessi perché si hanno a che fare con più fasi di un rilascio. La mancanza di traffico richiesto può compromettere l'efficacia di un rilascio. Soprattutto se nelle fasi iniziali ti rivolgi a un gruppo più piccolo di clienti nel tuo lancio. Il pericolo è che potresti approvare prematuramente un rilascio basato su un insieme più piccolo di client. Rilascia anche una pipeline in cui esegui uno script con più fasi
I rilasci possono durare molto più a lungo rispetto a un singolo (grande) cambiamento. In un'applicazione veramente su scala Web, sparsa in tutto il mondo, una modifica può richiedere diversi giorni per essere completamente implementata, il che in alcuni casi può rappresentare un problema.
La documentazione è importante. Soprattutto quando una fase richiede molto tempo e richiede il coinvolgimento di più team per gestire il cambiamento. Tutto deve essere documentato in dettaglio nel caso in cui sia giustificato un rollback o un roll forward.
A causa di queste insidie, è consigliabile dare uno sguardo più approfondito alla strategia di implementazione del cambiamento della propria organizzazione. Sebbene l'implementazione progressiva sia efficiente e consigliata, se l'applicazione è sufficientemente piccola e non richiede modifiche frequenti, una modifica immediata è la strada da percorrere. Eseguendo tutto in una volta, hai un modo pulito per eseguire il rollback se è necessario farlo.
Panoramica di alto livello dell'implementazione progressiva
Una volta che il codice è stato confermato e unito, iniziamo una "versione Canary", in cui i canarini sono i soggetti del test. Tieni presente che non sostituiscono i test automatizzati completi. Il nome "canarino" deriva dagli albori dell'attività mineraria, quando un canarino veniva utilizzato per rilevare se una miniera conteneva gas velenoso prima che gli esseri umani vi entrassero.
Dopo il test, un piccolo gruppo di client viene utilizzato per implementare le nostre modifiche e vedere come vanno le cose. Una volta che i "canarini" sono stati approvati, vai alla fase successiva, che è la "versione anticipata degli adattatori". Si tratta di un insieme di client leggermente più grande da utilizzare per eseguire l'implementazione. Infine, se i "Primi adattatori" vengono approvati, passa al pacchetto più grande del gruppo: "Tutti gli utenti".
(Robert Kimani, CC BY-SA 4.0)
Il "raggio dell'esplosione" si riferisce alla dimensione dell'impatto se qualcosa va storto. È il più piccolo quando eseguiamo il rollout Canary e in realtà il più grande quando lo implementiamo a tutti gli utenti.
Opzioni per implementazioni progressive
Un'implementazione progressiva dipende da un'applicazione o da un'organizzazione. Per le applicazioni globali, un metodo basato sulla geografia è un'opzione. Ad esempio, puoi scegliere di pubblicare prima nelle Americhe, poi in Europa e nelle regioni dell'Asia. Quando l'implementazione dipende dai dipartimenti all'interno di un'organizzazione, è possibile utilizzare il classico modello di implementazione progressiva, utilizzato da molte aziende su scala web. Ad esempio, potresti iniziare con "Canarie", Risorse umane, Marketing e poi i clienti.
È normale scegliere i dipartimenti interni come primi clienti per implementazioni progressive, per poi passare gradualmente agli utenti esterni.
Puoi anche scegliere un'implementazione progressiva basata sulle dimensioni. Supponiamo di avere mille server che eseguono la tua applicazione. Potresti iniziare con il 10% all'inizio, quindi aumentare l'implementazione al 25%, 50%, 75% e infine al 100%. In questo modo, puoi influenzare solo un insieme più piccolo di server man mano che avanzi nella tua implementazione progressiva.
Ci sono periodi in cui un'applicazione deve eseguire 2 versioni diverse contemporaneamente. Questo è qualcosa che non puoi evitare nelle situazioni di implementazione progressiva.
Pacchetti binari e di configurazione
Esistono tre componenti principali di un sistema: binario: (software), dati (ad esempio un database) e configurazione (i parametri che governano il comportamento di un'applicazione).
È considerata una procedura consigliata mantenere i file binari e di configurazione separati gli uni dagli altri. Si desidera utilizzare la configurazione controllata dalla versione. Le tue configurazioni devono essere "ermetiche". In qualsiasi momento, quando la configurazione viene derivata dall'applicazione, è la stessa indipendentemente da quando e dove vengono derivate le configurazioni. Ciò si ottiene trattando la configurazione come codice.
Monitoraggio degli SRE
Il monitoraggio è una capacità fondamentale di un'organizzazione SRE. Devi sapere se c'è qualcosa che non va nella tua applicazione che influisce sull'esperienza dell'utente finale. Inoltre, il tuo monitoraggio dovrebbe aiutarti a identificare la causa principale.
Le principali funzioni del monitoraggio sono:
- Fornisce visibilità sullo stato del servizio.
- Consente di creare avvisi in base a una soglia personalizzata.
- Analizza le tendenze e pianifica la capacità.
- Fornisce informazioni dettagliate sui vari sottosistemi che compongono l'applicazione o il servizio.
- Fornisce metriche a livello di codice per comprendere il comportamento.
- Fa uso di visualizzazioni e report.
Fonti di dati per il monitoraggio
Puoi monitorare diversi aspetti del tuo ambiente. Questi includono:
- Log grezzi: generalmente non strutturati generati dalla tua applicazione o da un server o da dispositivi di rete.
- Registri eventi strutturati: informazioni facili da consultare. Ad esempio i registri del Visualizzatore eventi di Windows.
- Metriche: una misurazione numerica di un componente.
- Tracciamento distribuito: gli eventi di traccia vengono generalmente creati automaticamente da framework, come la telemetria aperta, o manualmente utilizzando il tuo codice.
- Introspezione degli eventi: aiuta a esaminare le proprietà in fase di esecuzione a un livello dettagliato.
Quando scegli uno strumento di monitoraggio per la tua organizzazione SRE, devi considerare ciò che è più importante.
Velocità
Quanto velocemente puoi recuperare e inviare i dati al sistema di monitoraggio?
- Quanto dovrebbero essere aggiornati i dati? Più i dati sono aggiornati, meglio è. Non vuoi guardare dati vecchi di 2 ore. Desideri che i dati siano il più possibile in tempo reale.
- L'acquisizione dei dati e gli avvisi relativi ai dati in tempo reale possono essere costosi. Potrebbe essere necessario investire in una piattaforma come Splunk o InfluxDB o ElasticSearch per implementarlo completamente.
- Considera il tuo obiettivo del livello di servizio (SLO) per determinare la velocità con cui dovrebbe essere il sistema di monitoraggio. Ad esempio, se il tuo SLO è di 2 ore, non devi investire in sistemi che elaborano i dati della macchina in tempo reale.
- Interrogare grandi quantità di dati può essere inefficiente. Potrebbe essere necessario investire in piattaforme aziendali se è necessario un recupero dei dati molto rapido.
Controllo della risoluzione
Qual è la granularità dei dati di monitoraggio?
- Hai davvero bisogno di registrare i dati ogni secondo? Il modo consigliato è utilizzare l'aggregazione ove possibile.
- Utilizza il campionamento se ha senso per i tuoi dati.
- Le metriche sono adatte per il monitoraggio ad alta risoluzione anziché per i file di registro non elaborati.
Avviso
Quali funzionalità di avviso può fornire lo strumento di monitoraggio?
Garantire che il sistema di monitoraggio possa essere integrato con altri strumenti di elaborazione degli eventi o con strumenti di terze parti. Ad esempio, il tuo sistema di monitoraggio può avvisare qualcuno in caso di emergenza? Il vostro sistema di monitoraggio può integrarsi con un sistema di ticketing?
Dovresti anche classificare gli avvisi con diversi livelli di gravità. Potrebbe essere necessario scegliere un livello di gravità pari a tre per un'applicazione lenta rispetto a un livello di gravità pari a uno per un'applicazione che non è disponibile. Assicurati che gli avvisi possano essere facilmente soppressi per evitare un'ondata di avvisi. L'invio di e-mail o di pagine può distrarre notevolmente l'esperienza On-Call. Deve esserci un modo efficiente per sopprimere gli avvisi.
[Leggi dopo: 7 domande principali sul colloquio di lavoro per Site Reliability Engineer (SRE)]
Controllo dell'interfaccia utente
Quanto è versatile?
- Il tuo strumento di monitoraggio fornisce strumenti di visualizzazione ricchi di funzionalità?
- Può mostrare in modo efficace i dati delle serie temporali e i grafici personalizzati?
- Può essere facilmente condiviso? Questo è importante perché potresti voler condividere ciò che hai trovato non solo con altri membri del team, ma potresti dover condividere determinate informazioni con la leadership.
- Può essere gestito tramite codice? Non vuoi essere un amministratore di monitoraggio a tempo pieno. Devi essere in grado di gestire il tuo sistema di monitoraggio tramite codice.
Metrica
Le metriche potrebbero non essere efficaci nell’identificare la causa principale di un problema. Può dire cosa sta succedendo nel sistema, ma non può dirti perché sta succedendo. Sono adatti per dati a bassa cardinalità, quando non sono presenti milioni di valori univoci nei dati.
- Misura numerica di un immobile.
- Un contatore accompagnato da attributi.
- Efficace da ingerire.
- Efficiente per interrogare.
- Potrebbe non essere efficace nell'identificare la causa principale. Le metriche possono dire cosa sta succedendo nel sistema ma non saranno in grado di dirti perché sta accadendo.
- Adatto per dati a bassa cardinalità: quando non sono presenti milioni di valori univoci nei dati.
Registri
I dati di testo non elaborati sono solitamente testo arbitrario riempito con dati di debug. L'analisi è generalmente necessaria per ottenere i dati. Il recupero e il richiamo dei dati sono più lenti rispetto all'utilizzo delle metriche. I dati di testo non elaborati sono utili per determinare le cause profonde di molti problemi e non esistono requisiti rigidi in termini di cardinalità dei dati.
- Testo arbitrario, solitamente riempito con dati di debug.
- Generalmente è necessaria l'analisi.
- Generalmente più lento delle metriche, sia da acquisire che da recuperare.
- Nella maggior parte dei casi avrai bisogno di registri grezzi per determinare la causa principale.
- Nessun requisito rigoroso in termini di cardinalità dei dati.
Dovresti utilizzare le metriche perché possono essere assimilate, indicizzate e recuperate a un ritmo veloce rispetto ai log. L'analisi con parametri e log è rapida, quindi puoi inviare rapidamente un avviso. Al contrario, i log sono effettivamente necessari per l’analisi delle cause principali (RCA).
4 segnali da monitorare
C'è molto che puoi monitorare e ad un certo punto devi decidere cosa è importante.
- Latenza: cosa riscontrano gli utenti finali in termini di reattività della tua applicazione.
- Errori: possono trattarsi sia di errori gravi come un errore interno del server HTTP:500, sia di errori software, che potrebbero fare riferimento a un errore di funzionalità. Potrebbe anche significare un tempo di risposta lento di un particolare componente all'interno dell'applicazione.
- Traffico: si riferisce al numero totale di richieste in arrivo.
- Saturazione: generalmente si verifica in un componente o in una risorsa quando non è più in grado di gestire il carico.
Monitoraggio delle risorse
I dati devono provenire da qualche parte. Ecco le risorse comuni utilizzate nella creazione di un sistema di monitoraggio:
- CPU: in alcuni casi l'utilizzo della CPU può indicare un problema di fondo.
- Memoria: memoria dell'applicazione e del sistema. La memoria dell'applicazione potrebbe essere la dimensione heap Java in un'applicazione Java.
- I/O del disco: molte applicazioni dipendono fortemente dall'I/O, quindi è importante monitorare le prestazioni del disco.
- Volume disco: monitora le dimensioni di tutti i tuoi file system.
- Banda di rete: è fondamentale monitorare la larghezza di banda di rete utilizzata dalla tua applicazione. Ciò può fornire informazioni su come eliminare i colli di bottiglia nelle prestazioni.
3 migliori pratiche per il monitoraggio degli SRE
Soprattutto, ricorda le tre migliori pratiche per un sistema di monitoraggio efficace nella tua organizzazione SRE:
- Configurazione come codice: semplifica l'implementazione del monitoraggio in nuovi ambienti.
- Dashboard unificati: converge verso un modello unificato che consente il riutilizzo dei dashboard.
- Coerenza: qualunque sia lo strumento di monitoraggio utilizzato, i componenti che crei all'interno dello strumento di monitoraggio dovrebbero seguire una convenzione di denominazione coerente.
Annullamento delle modifiche
Per ridurre al minimo l'impatto sull'utente quando la modifica non è andata come previsto, dovresti guadagnare tempo per correggere i bug. Con il rollback a grana fine, puoi ripristinare solo una parte della modifica che è stata interessata, riducendo così al minimo l'impatto complessivo sull'utente.
Se le cose non vanno bene durante la versione "canary", potresti voler ripristinare le modifiche. Se combinato con implementazioni progressive, è possibile eliminare completamente l'impatto sull'utente quando si dispone di un solido meccanismo di rollback.
Rollback veloce e rollback spesso. Il tuo processo di rollback diventerà a prova di proiettile nel tempo!
Meccanica del rollback
L’automazione è fondamentale. È necessario disporre di script e processi prima di tentare un rollback. Uno dei modi in cui gli sviluppatori di applicazioni ripristinano una modifica è semplicemente attivare/disattivare i flag come parte della configurazione. Una nuova funzionalità nella tua applicazione può essere attivata e disattivata semplicemente cambiando un flag.
L'intero rollback potrebbe essere un rilascio di file di configurazione. In generale, è preferibile un rollback dell'intera release piuttosto che un rollback parziale. Utilizzare un sistema di gestione dei pacchetti con numeri di versione ed etichette chiaramente documentati.
Un rollback è ancora un cambiamento, tecnicamente parlando. Hai già apportato una modifica e la stai ripristinando. La maggior parte dei casi implica uno scenario che non è stato testato prima, quindi devi essere cauto quando si tratta di rollback.
Rotola in avanti
Con il roll forward, invece di ripristinare le modifiche, rilasci una correzione rapida "Hot Fix", un software aggiornato che include le correzioni. L'avanzamento potrebbe non essere sempre possibile. Potrebbe essere necessario eseguire il sistema in uno stato degradato fino a quando non sarà disponibile un aggiornamento in modo che il "roll forward sia completamente completo". In alcuni casi, il roll forward può essere più sicuro del rollback, soprattutto quando la modifica coinvolge più sottosistemi.
Il cambiamento è positivo
L’automazione è fondamentale. Le build, i test e i rilasci dovrebbero essere tutti automatizzati.
Utilizza i "canarini" per individuare tempestivamente i problemi, ma ricorda che i "canarini" non sostituiscono i test automatizzati.
Il monitoraggio dovrebbe essere progettato per soddisfare gli obiettivi del livello di servizio. Scegli attentamente i tuoi strumenti di monitoraggio. Potrebbe essere necessario implementare più di un sistema di monitoraggio.
Infine, ci sono tre principi fondamentali per un sistema di CM efficace:
- Implementazione progressiva: cerca di apportare le modifiche in modo progressivo.
- Monitoraggio: una capacità fondamentale per i tuoi team SRE.
- Rollback sicuri e veloci: esegui queste operazioni adottando processi e automatizzazioni che aumentano la fiducia nelle funzionalità della tua organizzazione SRE.
Nel prossimo articolo, la terza parte di questa serie, tratterò alcuni importanti argomenti tecnici relativi alle migliori pratiche SRE. Questi argomenti includeranno il Circuit Breaker Pattern, i sistemi di autoriparazione, il consenso distribuito, il bilanciamento del carico efficace, la scalabilità automatica e un controllo dello stato efficace.