Il Site Reliability Engineer (SRE) prevede che le attività storicamente svolte in maniera manuale dai team di Operations vengano trattate da ingegneri IT o professionisti in grado di scrivere software, utilizzare l’automazione per gestire sistemi di produzione e risolvere incidenti.
Come nasce il metodo Site Reliability Engineering
Il concetto di Site Reliability Engineer è stato introdotto intorno al 2003 da Ben Treynor Sloss, professionista che all’epoca era alla guida del team di ingegneri IT Google e che attualmente, sempre in Google, ricopre il ruolo di VP Engineering. Si è poi evoluto fino ai giorni nostri, diventando un vasto compendio di conoscenze che Sloss definisce così: «ciò che ottieni quando tratti le operations come un problema software, e assumi dei Software Engineer per lavorarci». Può sembrare controintuitivo affermare di dover “trattare il software come se fosse software software”, ma l’opportunità è apparsa con l’evolversi delle infrastrutture e le crescenti necessità di produzione. Dai pochi server gestiti a mano di qualche decade fa, alle enormi risorse computazionali messe a disposizioni dai data center del c.d. «cloud».
L’introduzione di questo metodo ha permesso al team di Sloss di garantire che le funzionalità rilasciate fossero sempre affidabili.
In un’intervista rilasciata proprio a Google, Sloss ha parlato del Site Reliability Engineer in questi termini:
SRE sta facendo un lavoro che storicamente è stato fatto da un team operativo, ma utilizzando ingegneri con esperienza software e contando sul fatto che questi ingegneri sono intrinsecamente predisposti, e hanno la capacità di sostituire l’automazione per il lavoro umano. In generale, un team SRE è responsabile per disponibilità, latenza, prestazioni, efficienza, gestione del cambiamento, monitoraggio, rispetto alle emergenze e pianificazione della capacità.
Il team SRE
Un team SRE è tendenzialmente composto da ingegneri che hanno competenze in due aree:
- Ingegneria, sviluppo software nel contesto dei sistemi complessi e/o distribuiti;
- Aree disciplinari tipicamente appannaggio delle IT Operations, ad esempio il triage di incidenti e risoluzione, il lavoro in situazioni di forte pressione, talvolta in emergenza.
Nel ciclo di vita del software, ovvero la filiera di procedure che conduce dall’idea di una funzionalità alla sua messa in opera, vi sono due due attività fondamentali svolte dal team:
- il development (Dev), in cui la creazione, la codifica e la prova del software avviene in ambienti detti di non-produzione, dove non ci sono utenti reali — esempi sono il laptop dello sviluppatore, le risorse di computazione riservate a un team interno, al controllo qualità, alle prove di carico;
- le operations (Ops), in cui il software prodotto dal dev viene promosso per la produzione, e da quel momento gli utenti lo toccano con mano, con dati ed impatto nel mondo reale. Le ops durano fintanto che l’organizzazione ha interesse a mantenere in vita tale servizio software.
I membri del team con competenze in ingegneria e sviluppo software hanno come obiettivo principale quello di focalizzarsi su progettazione e costruzione di sistemi software, ma devono anche raggiungere un adeguato livello di competenza per quanto riguarda l’intero ciclo di vita degli oggetti software, che è tendenzialmente esclusivo dominio delle IT Operations.
SRE informatica: standardizzazione e automazione
La standardizzazione e l’automazione sono due componenti essenziali del modello SRE: ingegneri IT e team Ops lavorano affinché i processi vengano automatizzati, soprattutto se si tratta di lavori manuali e ripetitivi che possono condurre ad errori umani.
Applicando la standardizzazione e l’automazione i team SRE riescono ad ottimizzare l’affidabilità di un sistema migliorandolo. La cultura Site Reliability Engineer (SRE) può aiutare i team che intraprendono il passaggio da approccio tradizionale ad approccio cloud native.
«Reliability» Engineer del sistema
La parola reliability non ha un’esatta corrispondenza nella lingua italiana, ma un’approssimazione di tali concetti potrebbe essere la triade di sostantivi: affidabilità, sicurezza, attendibilità. Tra gli obiettivi di un team SRE infatti c’è anche quello di trovare dei modi per migliorare la progettazione e la gestione di sistemi IT al fine di renderli più «reliable».
La definizione data da Microsoft del SRE Engineer è, invece, la seguente:
SRE è una disciplina di ingegneria informatica dedicata ad assistere le organizzazioni nell’ottenimento in modo sostenibile dei livelli di affidabilità appropriati per sistemi, servizi e prodotti.
La creazione di un’applicazione è prima di tutto un costo per un’organizzazione perché impiega diversi professionisti richiedendone tempo e lavoro, se non funziona per l’organizzazione si rivela uno spreco sia monetario che di credibilità.
Allo stesso tempo, bisogna tenere in considerazione che pochi sistemi hanno davvero necessità di offrire un’affidabilità prossima al 100% ed esistono anche poche situazioni in cui sia realmente possibile e utile ottenere una disponibilità prossima a tale obiettivo
Si parla quindi di affidabilità “appropriata”: risorse e lavoro impiegati nello sviluppo di un’applicazione aumentano man mano che aumenta il grado di affidabilità desiderato. La ricerca di affidabilità non necessaria può comportare ingenti sprechi di tempo e denaro, per questo è fondamentale individuare quale sia il livello di affidabilità appropriata che deve essere ricercato per un’applicazione.
SRE, DevOps e ITIL 4
Abbiamo già approfondito il confronto tra i tre framework nel nostro articolo ITIL, SRE, DevOps: quali sono le differenze e quali i punti in comune?, ma è necessario sottolineare che questi tre metodi rappresentano modi diversi di risolvere lo stesso problema e SRE non rappresenta un “passaggio evolutivo” rispetto a DevOps o ITIL, ma solo una metodo diversa per affrontare le sfide. Google stessa definisce la “cultura” SRE come specializzazione particolare di DevOps.
Per approfondire leggi anche:
