La speranza non è una strategia: 7 principi di ingegneria dell'affidabilità del sito (SRE)

L'ingegneria dell'affidabilità del sito, o SRE, è un approccio che tratta i problemi operativi come se fossero problemi software. È stato originariamente denominato e descritto nel 2003 da Ben Treynor Sloss, un ingegnere di Google. Come disciplina, l'SRE mira a mantenere la disponibilità, le prestazioni e l'efficienza di un particolare sistema.

L'SRE può essere difficile da definire. È un approccio piuttosto che una serie di compiti prescrittivi e assume forme diverse in base alle esigenze di una determinata organizzazione. Fortunatamente, esistono sette principi di ingegneria dell'affidabilità del sito che possono aiutare un team SRE a raggiungere il successo.

Gran parte dello sviluppo del software è giustamente focalizzato sulla creazione, incluso DevOps, un campo correlato ma distinto, che è maggiormente incentrato sull'intero ciclo di vita di un prodotto. Ma il lavoro è a malapena completo all'avvio del sistema. Nella prefazione della guida di Google all'SRE, gli autori osservano che "dal 40 al 90% dei costi totali di un sistema vengono sostenuti dopo l'avvio". L'SRE si occupa di ciò che accade dopo il lancio, con l'obiettivo di aiutare a garantire che un prodotto rimanga il più utilizzabile possibile.

L'elemento più importante dell'SRE è l'affidabilità del sistema e il tempo di attività. Anche il miglior servizio del mondo è inutile se non è operativo. L'SRE si concentra quindi sulla riduzione al minimo del tempo di inattività e sulla creazione di sistemi affidabili.

I team SRE assicurano anche che tutti gli elementi del prodotto siano aggiornati, attraverso un'attenta gestione degli aggiornamenti del software e della sicurezza. Gli standard e le normative possono cambiare e i team di ingegneri assicurano una conformità continua.

Le pratiche SRE possono anche generare risparmi finanziari. Molti dei principi fondamentali dell'SRE riguardano l'efficienza che può portare a significativi risparmi di costi e sforzi, anche attraverso automazione e gestione delle risorse.

I sette principi dell'SRE includono:    

• Accettazione del rischio
• Obiettivi del livello di servizio
• Eliminazione delle attività ripetitive
• Monitoraggio
• Automation
• Ingegneria del rilascio
• Semplicità

Sebbene l'SRE si preoccupi molto di gestire e limitare il tempo di inattività, questa tendenza non significa che l'obiettivo sia quello di mantenere un servizio perfetto, con un'affidabilità del servizio disponibile al 100%. Infatti, uno dei pilastri chiave dell'SRE è che l'affidabilità al 100% non solo non è realistica, ma non è nemmeno necessariamente il risultato preferibile.

Nell'SRE, il rischio è inteso in modo continuativo, dove la sua riduzione diventa esponenzialmente più difficile e costosa man mano che si avvicina al 100% di affidabilità. Provare a passare da un 99,99% di affidabilità a un 99,999% di affidabilità è molto più difficile che passare dall'80% al 99%. Le risorse necessarie per avvicinarsi sempre di più al 100% riducono la capacità di un team di sviluppo di svolgere altre attività, come introdurre nuove caratteristiche e aggiornamenti. Al contrario, un team dispone di budget di errore per rappresentare le quantità appropriate di malfunzionamenti.

Un altro punto a sfavore dell'affidabilità totale, per quanto controintuitivo possa sembrare, è che i clienti in genere non noteranno miglioramenti dell'affidabilità oltre una certa soglia. Quindi, non solo è costoso, ma offre anche poche ricompense. Idealmente, un obiettivo viene fissato e raggiunto, ma non superato eccessivamente.

L'SRE utilizza invece parametri di disponibilità per misurare l'accettabilità del rischio di tempi di inattività. In una metrica, un anno con affidabilità al 99,99% includerebbe 52,6 minuti di tempo di inattività. Metriche più complesse prendono in considerazione il potenziale di tempi di inattività in una sede o in un elemento di un servizio mentre altri rimangono attivi.

Un team SRE deve valutare ogni servizio e determinare un livello accettabile di inaffidabilità. Quanto tempo di inattività è consentito? I diversi tipi di malfunzionamenti, derivanti da cause principali diverse, hanno effetti diversi sull'esperienza dell'utente? Quanto costerà (in termini sia di manodopera che di denaro) superare tale soglia? Qual è il punto d'equilibrio?

Per un team SRE è fondamentale stabilire degli obiettivi e misurarne l'efficacia e il motivo per cui vengono raggiunti. Un obiettivo del livello di servizio, o SLO, è un obiettivo specifico e misurabile che rappresenta un livello di qualità che un team SRE ha fissato come obiettivo. Questi SLO possono assumere la forma di varie metriche, ma disponibilità, frequenza di query, frequenza di errore e tempo di risposta sono tutti parametri comuni.

Questi obiettivi vengono misurati utilizzando un indicatore del livello di servizio, o SLI, che è una misurazione approssimativa delle prestazioni come la latenza. Quindi, in questo caso, lo SLI sarebbe la metrica della latenza e lo SLO consisterebbe nel mantenere tale metrica al di sotto di una determinata soglia. Gli SLO a loro volta possono far parte di un contratto sul livello di servizio, o SLA, che è un contratto tra fornitore e utente che stabilisce gli SLO e le conseguenze in caso di mancato rispetto degli stessi.

La scelta degli SLO può essere complicata. Idealmente, gli SLO dovrebbero essere strutturati intorno a ciò che è più importante per gli utenti. Per un servizio di cloud gaming, ad esempio, l'SLO potrebbe essere incentrato sulla bassa latenza, ma la latenza non sarebbe così importante per un servizio di contabilità.

Idealmente, un tecnico dell'affidabilità del sito utilizzerebbe relativamente pochi SLO per concentrarsi sul raggiungimento di tali obiettivi, dato che è più importante svolgere correttamente il compito principale. Anche la definizione di obiettivi realistici è importante: come abbiamo discusso in precedenza, la perfezione non è né un obiettivo né realistico né desiderato.

I creatori dell'SRE definiscono le "attività ripetitive" come una categoria di lavoro secondario che si sovrappone a quello primario, ma è essenzialmente diverso. Le attività ripetitive sono quei compiti manuali che crescono in modo lineare e spesso possono essere svolti con l'automazione.

Il lavoro che deve essere svolto più volte è classificato come attività ripetitiva: preferibilmente, un singolo compito dovrebbe richiedere solo uno o due passaggi. Anche il lavoro che non migliora il prodotto è considerato come attività ripetitiva. "Se il tuo servizio rimane nello stesso stato dopo aver terminato un'attività, probabilmente si tratta di un'attività ripetitiva", scrive Vivek Rau di Google. Le correzioni di bug, i miglioramenti delle caratteristiche e le ottimizzazioni non sono propriamente attività ripetitive, ma scaricare manualmente le metriche lo è. La risposta agli incidenti, che può includere un coordinamento significativo tra ingegneri e team operativi, non è un'attività ripetitiva e le strategie di gestione degli incidenti devono essere pianificate prima della release.

Esistono anche le attività ripetitive cognitive. Ti è mai capitato di avere una ricetta base che usi ogni tanto, ma devi cercare ogni volta gli ingredienti e le misure? Questa è un'attività ripetitiva cognitiva: è uno spreco di tempo e fatica dover imparare qualcosa da zero più e più volte. L'SRE, invece, consiglia la creazione di più guide e standard, che eliminano la necessità di ricordare o riapprendere continuamente metodologie e attività.

Una delle parti più importanti dell'ingegneria dell'affidabilità del sito è il monitoraggio: l'utilizzo di strumenti per misurare, analizzare e migliorare continuamente le caratteristiche principali e le prestazioni del sistema. Queste caratteristiche fondamentali spesso includono quelli che vengono definiti i "quattro segnali d'oro" del monitoraggio:

Latenza: in sostanza, quanto tempo ci vuole per soddisfare una richiesta? Tieni presente che il tempo può variare a seconda che la richiesta sia andata a buon fine o meno, a volte un messaggio di errore può richiedere molto più tempo per l'assistenza.

Traffico: qual è il carico o la domanda del servizio? Le unità specifiche possono variare: potrebbero essere visualizzazioni di pagina, transazioni o richieste HTTP.

Errori: in genere misurati in base alla frequenza, gli errori possono includere l'acquisizione di dati errati, l'acquisizione di dati più lentamente di quanto stabilito in uno SLA, o la mancata acquisizione.

Saturazione: in sostanza, la saturazione è una misura di quanto un servizio sia vicino alla capacità. È importante comprendere la saturazione perché alcuni servizi inizieranno a non funzionare più, a rallentare o a generare più errori quando si avvicineranno al 100% di saturazione.

Esistono molti strumenti di monitoraggio in grado di raccogliere dati, impostare benchmark, eseguire il debug e analizzare i problemi, fornire dashboard di observability utili e avvisare gli SRE di potenziali interruzioni o altri problemi. È anche importante fornire report post-mortem affidabili dopo la risoluzione di un incidente, che spieghino il contesto relativo a un incidente, la causa principale, l'impatto, la metodologia di risoluzione e le lezioni per il futuro. Un post-mortem dettagliato e obiettivo può essere prezioso per evitare di ripetere lo stesso errore.

Come per molti altri elementi tecnologici, l'obiettivo dell'automazione in un workflow è quello di liberare gli ingegneri dall'incombenza di compiti ripetitivi che non aggiungono valore. Con il tempo risparmiato, gli ingegneri possono quindi lavorare su attività che l'automazione non può completare: creazione, ideazione, linee guida su larga scala e altro ancora.

L'automazione può essere particolarmente preziosa per i seguenti obiettivi:

Coerenza: l'aspetto negativo delle attività manuali ripetitive non è solo che possono essere noiose e possono sottrarre tempo ad azioni più preziose. Se tali attività, come la creazione di un account utente, vengono eseguite con strumenti di automazione, gli errori e le incongruenze possono essere quasi eliminati. Un nuovo dipendente potrebbe comportarsi in modo diverso rispetto a uno più anziano o un utente potrebbe inserire accidentalmente un valore nel campo sbagliato. Un processo automatizzato (generalmente) eviterà questi errori.

Scalabilità: la scalabilità è un beneficio a lungo termine dell'automazione. Prendiamo il nostro precedente esempio di creazione di account utente. Se la creazione di account aumenta in modo esponenziale, anche il workload per il personale responsabile dell'impostazione dell'account aumenta in modo esponenziale, sottraendo la disponibilità di questo dipendente per altri aspetti del lavoro potenzialmente più preziosi. Un sistema automatizzato non avrà questo problema.

Velocità: alcune attività, come la ricerca e la correzione di bug nel codice, possono richiedere molto tempo a un essere umano. I sistemi software automatizzati hanno la capacità di monitorare enormi quantità di dati e spesso possono rilevare gli errori più rapidamente degli umani attraverso il riconoscimento avanzato dei modelli e altri strumenti. Le correzioni possono essere applicate altrettanto rapidamente, spesso senza alcun coinvolgimento umano.

Naturalmente, ogni processo di automazione comporta anche dei pericoli. Tra cui:

Costi iniziali: le automazioni devono essere create prima di poter essere implementate. Questo può richiedere una quantità significativa di tempo, sforzi e anche costi hardware. Il valore dell'automazione deve essere considerato come un equilibrio tra lo sforzo per crearla e le risorse effettive che farà risparmiare una volta avviata.

Manutenzione: le attività automatizzate possono sembrare in grado di funzionare per sempre, ma spesso non è così. Il codice di automazione deve essere mantenuto aggiornato e sincronizzato con altri aggiornamenti del codice e del sistema. Se vengono aggiunte nuove funzionalità, potrebbe essere necessario aggiornare anche il codice di automazione tramite intervento umano per includere nuove azioni o prevenire errori.

L'intelligenza artificiale offre alcune nuove ed entusiasmanti possibilità per l'SRE, soprattutto nel campo dell'automazione. Sia i costi iniziali che la manutenzione possono teoricamente essere modulati da nuovi modelli AI. Detto questo, l'AI comporta anche nuovi potenziali punti deboli: nello specifico allucinazioni, sicurezza e privacy.

La release engineering è una sottodisciplina dell'ingegneria del software che si concentra in modo specifico sui passaggi necessari per, appunto, rilasciare un software. Queste fasi includono il versioning, le programmazioni di release, le build continue o periodiche, la selezione e la raccolta di metriche di release e altro ancora. Nell'SRE, la release engineering è incorporata all'inizio, piuttosto che in un secondo momento: l'obiettivo è evitare un'assegnazione casuale di compiti di release engineering all'ultimo minuto.

La release engineering, come disciplina, comprende diversi principi chiave. Tra cui:

Automazione e self-service: idealmente, molti processi di release possono essere automatizzati e richiedono un'interazione minima o nulla da parte degli ingegneri. Ciò garantisce release rapide e stabili.

Velocità: nella release engineering, si predilige una filosofia di release rapide e frequenti. Grazie all'implementazione rapida delle release, magari anche ogni ora prima del lancio, si riducono i cambiamenti tra le versioni. Questa velocità consente di facilitare i test e la risoluzione dei problemi.

Costruzioni ermetiche: i processi di compilazione devono essere completamente indipendenti dalla macchina di compilazione stessa, utilizzando i compilatori, le librerie e gli strumenti più diffusi. "Se due persone tentano di creare lo stesso prodotto con lo stesso numero di revisione nel repository del codice sorgente su computer diversi, ci aspettiamo risultati identici", scrive Dinah McNutt di Google.

Standard e politiche: per motivi di sicurezza, è fondamentale controllare determinate attività, tra cui l'implementazione, le modifiche al codice sorgente, le nuove versioni e le modifiche alla configurazione della build.

Gran parte dell'ingegneria dell'affidabilità del sito è al servizio della semplicità. Max Luebbe di Google scrive che il software è "intrinsecamente dinamico e instabile". Con questo in mente, la semplicità è la chiave per ridurre al minimo i potenziali problemi e cercare di frenare quell'instabilità intrinseca.

A tal fine, l'ingegneria dell'affidabilità del sito promuove varie attività che possono semplificare e chiarire un progetto.

1. Selezionare attentamente le caratteristiche da includere è utile, ma può essere altrettanto utile eliminare semplicemente tutte le caratteristiche che non aumentano in modo significativo l'utilità del prodotto. Più caratteristiche equivalgono a più complessità.
2. Release più piccole e frequenti consentono di facilitare il debug e la risoluzione dei problemi. Una nuova versione con dozzine di nuove funzionalità potrebbe introdurre errori estremamente difficili da rintracciare. Mentre in una release con una sola nuova funzionalità i problemi potenziali possono provenire solo da un unico luogo.
3. Allo stesso modo, può essere allettante aggiungere complessità alle API attraverso l'uso di più endpoint, microservizi e altro ancora. Questo sarebbe da evitare. Le API più semplici sono più veloci da configurare, richiedono meno documentazione e riducono tempi e costi di integrazione.