Cos'è SRE (Site Reliability Engineering)?
La Site Reliability Engineering, SRE in breve, è uno degli acronimi più "caldi" nel mondo dello sviluppo.
Lo scopo dell’approccio SRE è quello di aumentare l'affidabilità dei sistemi: è un insieme di principi, pratiche e costrutti organizzativi che permette sia di far funzionare l'esistente sia di innovarlo. Questo secondo aspetto è fondamentale, perché uno degli obiettivi di SRE non è solo di mantenere le promesse fatte circa la gestione dei sistemi, ma anche di farlo mentre i servizi vengono costantemente migliorati in maniera incrementale con nuove funzionalità.
Partiamo subito con un’importante specifica: la parola “Site” presente nella definizione non deve indurci a pensare che questo approccio sia applicabile solo alla creazione e gestione di siti. Gli stessi principi sono infatti adatti a migliorare le performance di qualsiasi sistema software (siti, applicazioni web o mobile, ecc). Ogni amministratore di sistema può quindi ambire a portare l’approccio SRE nel proprio team.
Dai un’occhiata a questo video realizzato dal nostro Lead Developer, Marcello Testi, per avere un’overview completa su Site Reliability Engineering:
SRE e Google: dalla nascita ad oggi
Le pratiche SRE nascono e si sviluppano all'interno di Google, a partire dal 2003 circa. Più di recente Google ha deciso di rendere pubblico l'approccio che ha permesso all'azienda di realizzare, monitorare, migliorare e mantenere alcuni tra i servizi online più utilizzati al mondo.
Per comprendere la filosofia SRE ancora prima che gli aspetti più pratici, possiamo citare Ben Treynor Sloss, colui che ha coniato il termine SRE e che oggi è vicepresidente engineering di Google.
“SRE è quel che succede quando si chiede a un software engineer di progettare la funzione delle Operations”, ha detto il manager in un’intervista.
Il team o il responsabile SRE svolge quindi un lavoro che è stato storicamente svolto dal team di Operations, ma lo fa aggiungendo il mindset e le competenze dell’ingegneria del software: punto cardine è la capacità (tipicamente ingegneristica) di sostituire il lavoro umano con l'automazione.
Con queste premesse, è immediato percepire il valore dei principi chiave definiti da Google per le pratiche di SRE, ovvero:
- Una gestione del rischio “neutrale”. ovvero, non fare finta che non si verificheranno mai errori nella vita di un workload applicativo. Piuttosto, accettare questo fatto e tenersi pronti.
- Secondo l’intuizione che chi utilizza il sistema e chi lo mantiene operativo abbiano a cuore obiettivi di servizio diversi, è necessaria per questi ultimi un'attenta definizione e una valutazione condivisa in modo tale da farli convergere sin da subito e che il valore erogato sia correttamente percepito da ciascun stakeholder.
- Minimizzare le attività che non portano valore e quelle ripetitive.
- Predisporre un monitoraggio che permette di avere sempre sotto controllo la situazione anche in contesti distribuiti.
- Progettare delle release che non mettano a rischio l’operatività della piattaforma o sistema.
- Tenere la complessità generale del sistema bassa, permettendo a quest’ultima di aumentare fisiologicamente con il passare del tempo
Ai principi di SRE Google affianca anche una serie di pratiche che applicano i vari principi e cercando di tenere costante l'operatività del sistema. Un team di SRE deve organizzarsi per rispettare quella che secondo Google è la gerarchia di un servizio affidabile.
- Alla base della piramide gerarchica troviamo il monitoraggio e la capacità di identificare un problema prima che se ne accorgano gli utenti.
- Immediatamente sopra abbiamo la capacità del team di rispondere ad un problema con una root cause analysis e delle fix correttive facilmente testabili e applicabili.
- Infine, in cima alla piramide, l’attenzione alla progettazione e alle risorse computazionali che un prodotto affidabile necessita.
Conosci già le potenzialità della Site Reliability Engineering?
Scarica la guida e dai una marcia in più alle tue applicazioni!
Reliability come principio base di una buona architettura
La reliability, o affidabilità, è la capacità di un applicativo di operare in maniera corretta e coerente quando previsto. Secondo AWS, la reliability è uno dei principi cardine del Well-Architected framework. Si tratta di un manuale di best practice e checklist che è opportuno tenere a mente quando si progetta un qualsiasi applicativo Cloud.
AWS stila una serie di linee guida che possono aumentare l’affidabilità di un workload, tra queste:
- la capacità di ripristinare un workload da una situazione anomala in maniera automatica, grazie a strumenti di monitoraggio e procedure di recupero opportunamente testate;
- aumentare la scalabilità orizzontale per diminuire gli impatti dei fallimenti sul singolo nodo o istanza;
- infine, una più diligente analisi e tuning della capacità computazionale allocata sul Cloud, con l'obiettivo di evitare la saturazione delle risorse disponibili e tenere sotto controllo i costi. Osservando e adattando il dimensionamento delle risorse è possibile evitare l'over provisioning, cioè l'utilizzo di risorse sovradimensionate che risultano sprecate per la maggior parte del tempo per cui vengono pagate.
SRE e DevOps: approcci simili, ma non uguali
Arrivati a questo punto non possiamo esimerci dal citare un altro approccio che favorisce la collaborazione tra team Operations e team sviluppo: parliamo, ovviamente, di DevOps. C'è un’innegabile vicinanza tra SRE e DevOps, nonostante le due pratiche si siano sviluppate in maniera indipendente. Entrambe mirano a colmare il divario tra i due team, con l'obiettivo di migliorare il ciclo di vita (quindi di rilascio) e la qualità del prodotto.
Pur avendo obiettivi simili, i due approcci non si escludono a vicenda: possiamo anzi vedere SRE come una concretizzazione dell’approccio DevOps. SRE abbraccia la filosofia DevOps, ma concentra la sua attenzione sullo sviluppo e il consolidamento di pratiche per misurare e raggiungere l'affidabilità.
In altre parole, SRE pone delle regole operative per avere successo nelle varie aree DevOps. Se DevOps di focalizza sul “Cosa”, SRE è decisamente sbilanciata verso il “Come”.
LEGGI ANCHE:
SRE vs platform engineering: spesso confusi, ma ben diversi
Dopo aver parlato della differenza tra SRE e DevOps, è l’ora di un un altro confronto: quello tra SRE e platform engineering. Ebbene, anche in questo caso, pur condividendo l’ambito dell’ingegneria, le due cose sono piuttosto differenti.
Per comprendere la diversa natura delle due discipline partiamo dagli obiettivi che si pongono rispettivamente. Se da un lato l'obiettivo di un team SRE è fornire un'infrastruttura per le applicazioni estremamente affidabile, l'obiettivo del platform engineering è creare e fornire un'infrastruttura esclusivamente per lo sviluppo rapido delle applicazioni.
Se analizziamo attentamente il lavoro di questi team, notiamo che i team SRE si concentrano principalmente sulla costruzione di applicazioni affidabili. I platform engineers, invece, si occupano di garantire un'infrastruttura fluida su cui queste applicazioni possono operare senza problemi.
Tornando al confronto tra DevOps e SRE (e platform engineering), possiamo dire che nel quadro che abbiamo descritto il ruolo di DevOps è quello di accelerare il lavoro degli SRE e platform engineers , creando un insieme di processi che favoriscono la collaborazione tra i team. È quindi fondamentale che queste tre aree lavorino insieme per garantire la fornitura di applicazioni software affidabili.
Strumenti a supporto della SRE
La SRE è una pratica ad alta connotazione tecnologica, per questo con il tempo si è definito uno stack tecnologico di riferimento per i SRE Engineer. Come detto in precedenza, SRE è molto vicino a DevOps, pertanto è possibile assimilare gli strumenti utilizzati da questo tipo di professionalità a quelli di un DevOps Engineer.
Nello specifico, servono:
- strumenti che permettono la pianificazione del lavoro (Jira, Azure Boards);
- la realizzazione del software (Eclipse, Visual Studio Code);
- il packaging degli artefatti di build, (Jenkins, Azure Pipelines);
- la configurazione del software installato (Terraform, Ansible);
- un ambiente di installazione - preferibilmente containerizzato (OpenShift o Azure Kubernetes Service);
- Infine, è fondamentale per ogni team di SRE una suite di monitoraggio in grado di raccogliere, aggregare e presentare metriche e KPI derivanti dall’applicazione (Grafana, Azure Monitor).
Di cosa si occupa un team o un ingegnere SRE?
Il responsabile SRE (o il team SRE) ha in carico una serie molto ampia di funzioni, tra cui la disponibilità dei sistemi, la latenza, la performance, l'efficienza, il monitoraggio, la gestione del cambiamento, la risposta d'emergenza e la pianificazione della capacità.
Per capire quanto sia cruciale questa figura in alcuni progetti, basta leggere la prima frase del profilo LinkedIn di Benjamin Treynor Sloss: “Se Google smette di funzionare, è colpa mia". Ironica, ma non senza un fondo di verità.
Quello di un ingegnere SRE è un ruolo importante, non tanto per le attività che svolge (che potrebbero essere prese in carico anche dagli altri team) quanto nel modus operandi adottato. Il team SRE lavora con i dati, che impara a raccogliere, a leggere e a valorizzare, e con l'automazione dei processi, che permette di aumentare il controllo e normalizzare il codice. Questo approccio consente di ridurre il sovraccarico di attività ripetitive (il cosiddetto “toil”) e gli errori.
Vediamo quali sono le principali aree di responsabilità e lavoro di un site reliability engineer:
Automazione
Come già accennato, gli ingegneri SRE sviluppano strumenti per automatizzare la gestione delle operazioni IT, evitando di svolgere manualmente queste funzioni. Tra di esse rientrano le attività di Continuous Integration e Continuous Delivery, oltre ad altri aspetti come gli alerts e le gestione degli incidenti.
Monitoraggio
Gli ingegneri SRE sono responsabili di garantire che l'infrastruttura di base funzioni correttamente e che i sistemi e gli strumenti siano operativi come previsto. Inoltre, monitorano applicazioni e servizi critici per ridurre al minimo i tempi di inattività e garantire la loro disponibilità.
Risoluzione dei problemi
Gli SRE collaborano strettamente con gli sviluppatori, soprattutto quando si presentano problemi. Offrono supporto nella risoluzione delle problematiche e forniscono consulenza in caso di allarmi. Nel caso uno sviluppatore incontri un problema, l'ingegnere SRE lo investiga e lo risolve. Successivamente, rivede l'incidente per determinare la causa e prevenire ulteriori ripetizioni.
Collaborazione tra team
Gli SRE lavorano con diversi team, in particolare con quelli operativi e di sviluppo. Costruire sistemi affidabili e fornire supporto a questi team permette loro di disporre di più tempo per concentrarsi sulla creazione di nuove funzionalità, accelerando così la consegna ai clienti.
Sei interessato ai framework che sfruttano un approccio data-driven e la collaborazione tra team? Potrebbe interessarti approfondire FinOps e DevSecOps.
L’Error Budget: cos’è e perché è importante
Il team SRE è anche incaricato di calcolare e gestire l'error budget. Si tratta di un concetto strategico fondamentale, che potremmo definire come lo strumento utilizzato da SRE per bilanciare l'affidabilità del servizio con l'innovazione.
Il presupposto di questo approccio è che i sistemi siano oggetti dinamici che si sviluppano e cambiano nel tempo, evolvendosi positivamente ma portando anche un risvolto negativo: le modifiche sono una delle principali fonti di instabilità. L’error budget costituisce un meccanismo di controllo per spostare l'attenzione dall’innovazione alla stabilità quando necessario.
Il team SRE definisce un error budget sulla base di una serie di metriche (le vedremo tra un attimo) e un intervallo di tempo in cui misurarlo. Se gli incidenti aumentano in maniera rilevante rispetto all'error budget a disposizione, la priorità del team SRE diventa immediatamente quella di aiutare a risolvere i problemi facendo convergere e collaborare i team di sviluppo e Operations.
Grazie all'error budget, dunque, è possibile progettare e programmare il cambiamento senza sacrificare eccessivamente la disponibilità.
LEGGI ANCHE: Oltre SRE: cos'è CRE (Customer Reliability Engineering)?
I livelli di servizio: SLI, SLO e SLA
Al fine di allineare tutte le parti in causa sugli obiettivi di affidabilità e disponibilità del servizio, SRE introduce 3 concetti chiave: SLI, SLO e SLA.
- SLI, Service Level Indicators (o indicatori del livello di servizio). Si tratta delle metriche con cui si misurano le performance o in generale il comportamento dell’applicazione. In altre parole, potremmo definirli i KPI da prendere in considerazione. Spesso si tratta di KPI particolarmente rilevanti per gli utenti, come il tempo di risposta o il tasso di errore.
- SLO, Service Level Objectives (o obiettivi di livello di servizio). Sono gli obiettivi da raggiungere per ciascuna metrica, cioè per ogni SLI. Gli obiettivi prefissati devono bilanciare sapientemente la qualità, da valutare in base alle necessità del business, e i costi per ottenerla.
- SLA, Service Level Agreement (o accordo sui livelli di servizio). Include gli aspetti legali che entrano in gioco se il sistema non raggiunge i suoi SLO.
È da notare che uno degli elementi di fondo della filosofia delle SRE è che comunque gli errori siano previsti e accettati da tutti gli attori coinvolti. SLI, SLO e SLA servono a porsi un obiettivo e a renderlo raggiungibile: non evitando del tutto gli errori, ma analizzandoli a posteriori per migliorare l’intero processo (e senza mai puntare il dito).
PER APPROFONDIRE: 6 best practice SRE da conoscere
Site Reliability Engineering: i vantaggi
Investire il proprio tempo nello sviluppo di pratiche SRE può essere davvero conveniente. I vantaggi sono facilmente intuibili:
- Maggiore qualità
- Evoluzione costante del prodotto
- Riduzione degli errori e dei malfunzionamenti
Proviamo a declinare più nel dettaglio questi vantaggi e a capire quali sono le conseguenze positive per il business e per i team di lavoro.
CONTROLLO COSTANTE SUL PROGETTO
La complessità di alcuni progetti è tale da richiedere una visione dall’alto, chiara e focalizzata sugli aspetti davvero rilevanti. È proprio ciò che accade grazie al sistema di monitoring avanzato che SRE richiede di implementare: le metriche selezionate permettono di misurare i parametri chiave senza perdere mai di vista il progetto nella sua interezza.
Ciò che si ottiene è una visione sintetica e puntuale di quello che succede durante tutto il progetto, con informazioni preziose anche per altre aree aziendali. Pensiamo al marketing, alle vendite, al supporto, ma anche ai principali stakeholder aziendali che richiedono di essere allineati sullo status dei lavori e sulle performance.
RISOLUZIONE TEMPESTIVA DEGLI ERRORI
Le pratiche SRE hanno il grande vantaggio di favorire la proattiva individuazione e risoluzione di bug e vulnerabilità del software. In assenza di un sistema di monitoring e automazione come quello favorito da SRE, capita spesso che gli errori entrino in produzione causando ritardi, malfunzionamenti e periodi di inattività dei servizi.
Le conseguenze per il business e per il fatturato possono essere molto pesanti; ecco perché è così importante la selezione dei KPI più rilevanti e il setting di un obiettivo raggiungibile e ponderato per ciascuno SLI.
POTREBBE INTERESSARTI ANCHE:
CHIARIRE E SODDISFARE LE ASPETTATIVE DEI CLIENTI
Un altro grande vantaggio dell’uso di SLA, SLO e SLI è la possibilità di mettere a fuoco fin da subito le aspettative dell’utente finale e di elaborare un piano per riuscire a soddisfarle.
Avere degli obiettivi e delle soglie di servizio chiaramente definiti permette di giudicare costantemente lo stato dei lavori e di allineare proattivamente le azioni da intraprendere rispetto ai KPI predefiniti. Il tutto tenendo a mente l’utente finale e le sue aspettative (con tutti i vantaggi che questo comporta in termini di livello di servizio fornito, e quindi di fatturato generato).
MAGGIORE FOCUS SULLA CREAZIONE DI VALORE
Un sistema più efficiente, con meno problemi e dove le attività ripetitive sono automatizzate, è un sistema che lascia più tempo libero ai team che ci lavorano. E quel tempo va investito in maniera produttiva, ad esempio creando nuove funzionalità o migliorando quelle esistenti. Il team Operations, invece, ha la possibilità di lavorare di più al miglioramento della configurazione e alla creazione di test in grado di identificare eventuali difetti del sistema.
La maggiore disponibilità di tempo e il minore stress dovuto a errori e ritardi porta anche a una maggiore collaborazione tra i team, insieme alla capacità di discutere in maniera più responsabile e creativa le priorità e gli obiettivi.
MIGLIORAMENTO CULTURALE CONTINUO
Esiste un ultimo e importantissimo vantaggio di SRE: la creazione di una cultura della collaborazione tra le persone e tra i team, dove le decisioni vengono prese avendo ben presente non solo il proprio lavoro, ma soprattutto le conseguenze per l’utente e per i colleghi.
SRE favorisce una mentalità aperta e di maggior fiducia tra i team, che si concretizza da un lato in un miglior clima aziendale, dall’altro nella produzione di un output di elevata qualità.
Sviluppo Cloud Native e gestione SRE
L'adozione di un approccio Cloud Native, che implica la creazione di applicazioni come microservizi e la loro implementazione in container, porta con sé numerosi vantaggi in termini di semplificazione dello sviluppo, implementazione e scalabilità delle applicazioni.
Tuttavia, questa modalità di sviluppo introduce anche nuove sfide legate all'amministrazione, alle operazioni e alla gestione di un ambiente sempre più distribuito. È qui che un team SRE diventa fondamentale, in quanto può supportare il rapido ritmo d'innovazione abilitato dall'approccio Cloud Native e assicurare o migliorare l'affidabilità del sistema, senza sovraccaricare ulteriormente i team DevOps.
Nel contesto Cloud Native il team SRE agisce come un punto di riferimento per affrontare la complessità degli ambienti Cloud Native e garantire un funzionamento ottimale delle applicazioni.
