Ti piace DevOps? Aspetta di conoscere SRE

Che diavolo è SRE?

Ben Treynor, mente di Google dietro SRE, non ha ancora pubblicato una definizione di una sola frase, ma descrive l'affidabilità del sito come "ciò che accade quando un ingegnere del software deve occuparsi di quelle che una volta si chiamavano operazioni".

Il problema di fondo è il seguente: i team di sviluppo vogliono rilasciare nuove fantastiche funzionalità alle masse e vederle decollare alla grande. I team operativi vogliono assicurarsi che queste funzionalità non violino le regole. Storicamente, questo ha causato una grande lotta di potere, con Ops che cerca di frenare il maggior numero possibile di rilasci e Dev alla ricerca di nuovi modi intelligenti per aggirare i processi che li frenano. (Scommetto che ti ci rivedi).

SRE elimina le congetture e il dibattito su cosa può essere lanciato e quando. Introduce una formula matematica per i lanci con luci verdi o rosse e assegna un team di persone con competenze Ops (opportunamente chiamate Service Reliability Engineer o SRE) alla supervisione costante dell'affidabilità del prodotto. Come lo descrive Andrew Widdowson, SRE di Google, "Il nostro lavoro è come far parte della squadra di meccanici più veloci del mondo. Cambiamo le gomme di un'auto da corsa mentre va a 200 km all'ora".

Non ti sembra così rivoluzionario? Gran parte della magia sta nel modo in cui funziona. Ecco alcuni dei principi fondamentali, che sono anche alcune delle maggiori deviazioni dalle operazioni IT tradizionali.

Innanzitutto, i nuovi lanci ricevono il via libera in base alle prestazioni attuali del prodotto.

La maggior parte delle applicazioni non raggiunge il 100% di uptime. Quindi, per ogni servizio, il team SRE stabilisce un contratto sul livello di servizio (SLA) che definisce l'affidabilità del sistema per gli utenti finali. Se il team è d'accordo su uno SLA del 99,9%, il budget di errore è dello 0,1%. Il budget di errore è, come dice il nome, la soglia massima consentita per errori e interruzioni.

Suggerimento: puoi convertire facilmente gli SLA in "minuti di tempo di inattività" con questa fantastica scheda di riferimento sui tempi di attività.

Ecco il punto decisivo: il team di sviluppo può "spendere" questo budget per gli errori nel modo che preferisce. Se il prodotto funziona in modo impeccabile, con pochi o nessun errore, possono avviare quello che vogliono, quando vogliono. Al contrario, se hanno raggiunto o superato il budget di errore e operano allo stesso livello di servizio definito o al di sotto dello SLA definito, tutti i lanci vengono congelati fino a quando non riducono il numero di errori a un livello che consenta al lancio di procedere.

Il genio? Sia gli SRE che gli sviluppatori sono fortemente incentivati a collaborare per ridurre al minimo il numero di errori.

Anche gli SRE possono programmare

Nel vecchio modello, metti le persone davanti a un problema di affidabilità e continui a spingere (a volte per un anno o più) finché il problema non scompare o ti esplode in faccia.

In SRE è diverso. Entrambi i team di sviluppo e SRE condividono un unico pool di personale, quindi per ogni SRE assunto è disponibile uno sviluppatore in meno (e viceversa). Questo pone fine all'infinita battaglia sull'organico tra Dev e Ops e crea un sistema di autocontrollo in cui gli sviluppatori vengono ricompensati con più colleghi se hanno scritto un codice con prestazioni migliori (cioè un codice che richiede meno supporto da parte di un numero inferiore di SRE).

Anche gli sviluppatori si sporcano le mani

In Google, Ben Treynor ha dovuto lottare per questo, ed è contento di averlo fatto. In effetti, nel suo discorso su SRE presso SREcon14 sottolinea che ottenere questo impegno da parte dei dirigenti prima del lancio di SRE dovrebbe essere obbligatorio.

Fondamentalmente, il team di sviluppo gestisce il 5% di tutto il carico di lavoro delle operazioni (gestione dei ticket, fornitura di supporto su chiamata, ecc.). Ciò consente loro di rimanere strettamente connessi al loro prodotto, vedere come sta funzionando e prendere decisioni migliori sulla programmazione e sul rilascio.

Inoltre, ogni volta che il carico operativo supera la capacità del team SRE, l'overflow viene sempre assegnato agli sviluppatori. Quando il sistema funziona bene, anche gli sviluppatori iniziano ad autoregolarsi, scrivendo codice robusto e lanciandolo con attenzione per prevenire problemi futuri.

Gli SRE sono agenti liberi (e possono essere ritirati, se necessario)

Per garantire la soddisfazione dei team nel tempo, Treynor consiglia di consentire agli SRE di passare ad altri progetti come desiderano, o addirittura di trasferirsi in un'altra organizzazione. SRE incoraggia un lavoro di squadra altamente motivato, dedicato ed efficace, quindi a nessun membro del team dovrebbe essere impedito di perseguire i propri obiettivi personali.

Se un intero team di SRE e sviluppatori non riesce ad andare d'accordo e sta creando più problemi di un codice affidabile, c'è un'ultima misura drastica che puoi prendere: allontanare l'intero team SRE dal progetto e assegnare tutto il carico di lavoro delle operazioni direttamente al team di sviluppo. Treynor lo ha fatto solo un paio di volte in tutta la sua carriera e la minaccia di solito è sufficiente per convincere entrambi i team a instaurare un rapporto di lavoro più positivo.

SRE racchiude molto di più di quello che è possibile trattare in un unico articolo, ad esempio il modo in cui previene gli imprevisti di produzione, il modo in cui sono composti i team di supporto su chiamata e le regole che seguono per ogni turno, ecc.

La nostra opinione

L'IT è pieno di termini in voga e tendenze. Un minuto prima è il cloud, un minuto dopo è DevOps o l'esperienza del cliente o la gamification. SRE si trova in una posizione che può consentirgli di diventare molto più di questo, soprattutto perché riguarda molto più le persone e i processi che la tecnologia alla base di essi. Sebbene la tecnologia possa certamente (cosa che probabilmente farà) adattarsi al concetto man mano che matura e sempre più team la adottano, tu non hai bisogno di nuovi strumenti per allineare le tue organizzazioni di sviluppo e operative ai principi di Site Reliability Engineering.

Nei prossimi articoli, esamineremo proprio questo: azioni pratiche per fare un passo avanti verso SRE e il ruolo che la tecnologia può svolgere.