Cos'è il site reliability engineering (SRE)?

Il site reliability engineering (SRE) è un approccio alle operazioni IT basato sull'ingegneria del software, che prevede l'uso di software per la gestione dei sistemi da parte dei team, oltre all'automazione di tali operazioni.

Il metodo SRE affida le attività tradizionalmente eseguite dai team operativi, spesso in modalità manuale, a ingegneri IT che si avvalgono di software e automazione per risolvere i problemi e gestire i sistemi di produzione. 

È una pratica utilissima per la creazione di sistemi software altamente scalabili e affidabili. Poiché la gestione dei sistemi di grandi dimensioni è affidata al codice, offre agli amministratori dei sistemi una soluzione flessibile e sostenibile per gestire centinaia o migliaia di macchine. 

Il concetto di site reliability engineering ha origine dal team di ingegneri di Google e viene attribuito a Ben Treynor Sloss. 

L'approccio SRE aiuta i team a trovare il giusto equilibrio tra rilasciare nuove funzionalità e garantire affidabilità agli utenti.

In questo contesto, la standardizzazione e l'automazione sono due componenti essenziali del modello SRE e i site reliability engineer puntano a ottimizzare e automatizzare le attività operative.

Il metodo SRE consente di migliorare oggi stesso l'affidabilità dei sistemi e di garantirla anche in futuro, a mano a mano che l'ambiente si espande. 

SRE semplifica il lavoro dei team che desiderano passare da un approccio tradizionale alle operazioni IT a un approccio cloud native.

Il site reliability engineer riveste un ruolo unico che richiede un'esperienza come amministratore di sistemi, ovvero uno sviluppatore software con ulteriori competenze operative, oppure un membro del team operativo IT che possiede anche capacità di sviluppo software. 

I team SRE sono responsabili del deployment, della configurazione e del monitoraggio del codice, oltre che di tutte le operazioni legate a disponibilità, latenza, gestione delle modifiche, risposta alle emergenze e gestione della capacità dei servizi in produzione.

I team SRE determinano il lancio delle nuove funzionalità, applicando accordi sul livello di servizio (SLA, Service-Level Agreement) per stabilire l'affidabilità richiesta di un sistema, che viene misurata tramite indicatori del livello del servizio (SLI, Service-Level Indicator) e obiettivi del livello di servizio (SLO, Service-Level Objective). 

Uno SLI misura aspetti specifici del livello di servizio fornito. Gli SLI principali includono i livelli richiesti di latenza, disponibilità, percentuale di errore e produttività dei sistemi. Uno SLO si basa sul valore o sull'intervallo target del livello di servizio specificato, che a sua volta si basa sullo SLI.

Di conseguenza, lo SLO per il livello richiesto di affidabilità dei sistemi è basato sul livello di downtime considerato accettabile. Tale livello di downtime, denominato anche budget di errore, indica la soglia massima consentita per gli errori e i tempi di fermo. 

L'approccio SRE non presuppone un'affidabilità del 100%, ma prevede e si aspetta una percentuale di errore.

Dopo aver determinato il budget di errore, gli sviluppatori possono utilizzarlo per il rilascio delle nuove funzioni. Basandosi sullo SLO e sul budget di errore, il team è pertanto in grado di stabilire se un determinato prodotto o servizio può essere lanciato rispettando il budget di errore a disposizione.

Se l'esecuzione di un servizio rispetta il budget di errore, il team di sviluppo può lanciarlo in qualsiasi momento, ma se il sistema presenta troppi errori o si arresta per più tempo di quello previsto dal budget di errore, non è possibile procedere con i nuovi lanci senza prima riportare gli errori entro i limiti del budget.   

Per dimostrare l'affidabilità del servizio, il team di sviluppo deve effettuare alcuni test operativi automatizzati. 

I site reliability engineer svolgono sia attività operative, sia di progetto. Secondo le procedure consigliate SRE di Google, un site reliability engineer può dedicare fino al 50% del proprio tempo alle operazioni e deve monitorare tale valore per non superarlo.  

Il resto del tempo può essere dedicato ad attività di sviluppo, come la creazione di nuove funzioni, l'espansione dei sistemi e l'implementazione dell'automazione.

Le attività operative in eccesso e i servizi con prestazioni non ottimali possono essere reindirizzati al team di sviluppo, evitando al site reliability engineer di dedicare troppo tempo al funzionamento di un'applicazione o di un servizio. 

L'automazione è una componente importante nel ruolo del site reliability engineer, di conseguenza, se un determinato problema si ripresenta di continuo, è plausibile che ne automatizzerà la soluzione. 

Mantenere l'equilibro tra le attività operative e quelle di sviluppo è un'esigenza essenziale per un responsabile SRE. 

DevOps è un approccio alla cultura, all'automazione e alla progettazione di piattaforme pensato per offrire all'azienda valore e reattività maggiori attraverso un'erogazione dei servizi efficiente e di qualità elevata. Possiamo considerare la metodologia SRE come un'implementazione di DevOps.

Anche il site reliability engineering si basa su una cultura di collaborazione e condivisione in team. Sia SRE sia DevOps puntano a colmare le lacune tra i team di sviluppo e quelli operativi, accelerando l'erogazione dei servizi. 

Entrambi gli approcci possono offrire vantaggi notevoli tra cui: cicli di sviluppo delle applicazioni più rapidi, qualità e affidabilità migliorata dei servizi, riduzione dei tempi di sviluppo per applicazione.

Tuttavia, a differenza di DevOps, l'approccio SRE si basa sui site reliability engineer del team di sviluppo, che possiedono anche le competenze operative necessarie per risolvere i problemi di comunicazione e flusso di lavoro.

Il ruolo stesso del site reliability engineer unisce le competenze dei team di sviluppo con quelle dei team operativi, richiedendo una sovrapposizione delle relative responsabilità. 

Uno SRE può aiutare i team DevOps quando gli sviluppatori sono sovraccarichi di attività operative e hanno bisogno del supporto di una persona dotata di competenze operative più specifiche. 

Durante la programmazione e la creazione di nuove funzioni, la metodologia DevOps punta soprattutto all'efficienza della pipeline di sviluppo, mentre l'approccio SRE si concentra sulla possibilità di bilanciare la disponibilità del sito con la creazione delle nuove funzioni. 

In questo contesto, le moderne piattaforme applicative basate sulla tecnologia container, su Kubernetes e sui microservizi svolgono un ruolo chiave per le procedure DevOps, poiché consentono di garantire sicurezza e servizi software innovativi.

Sia l'ingegneria della piattaforma sia la site reliability engineering riguardano la creazione e la manutenzione dei sistemi. La differenza tra i due approcci risiede nell'obiettivo di ciascuna pratica. La SRE è orientata ai team dedicati alle operazioni IT e consente loro di utilizzare il software come strumento di gestione dei sistemi, risoluzione dei problemi e automazione delle attività operative.

L'ingegneria della piattaforma, invece, è incentrata sui team di sviluppo e permette loro di creare piattaforme per gestire i sistemi, risolvere i problemi e automatizzare le attività di sviluppo. 

La site reliability engineering fa affidamento sull'automazione delle attività di routine e sulla standardizzazione del ciclo di vita delle applicazioni. Red Hat® Ansible® Automation Platform è una piattaforma completa e integrata che semplifica le attività di automazione dei team SRE, per garantire velocità, collaborazione e capacità di espansione offrendo sicurezza e supporto a tutte le funzioni tecniche, operative e finanziarie dell'ambiente enterprise. 

In particolare, Ansible Automation Platform offre: 

• Orchestrazione dell'infrastruttura, negli ambienti cloud e on premise, per istanze, routing, bilanciamento del carico, firewall e molto altro ancora. 
• Ottimizzazione dell'infrastruttura, che include il dimensionamento corretto delle risorse cloud e l'aggiunta o la rimozione di risorse come CPU e RAM, a seconda delle esigenze. 
• Operazioni cloud, come deployment di applicazioni con le pipeline CI/CD (Continuous Integration/Continuous Delivery, integrazione e distribuzione continue), applicazione delle patch ai sistemi operativi e manutenzione.
• Continuità operativa, che include lo spostamento e la copia delle risorse all'esterno del cloud, la creazione e la gestione delle policy di backup, oltre alla gestione di errori e interruzioni.

SRE fa anche affidamento su una struttura di base concepita per uno stile di sviluppo cloud native. I container Linux® supportano un ambiente unificato per lo sviluppo, la distribuzione, l'integrazione e l'automazione.

Kubernetes offre una strategia moderna per automatizzare le operazioni dei container Linux e aiuta i team a gestire in modo più efficiente i cluster che eseguono i container Linux su cloud privati, pubblici o ibridi.

Essendo una piattaforma Kubernetes enterprise ready che supporta le iniziative SRE, Red Hat® OpenShift® aiuta i team a implementare una trasformazione culturale e procedurale con lo scopo di rinnovare l'infrastruttura IT, permettendo all'azienda di servire più efficacemente i clienti e raggiungere gli obiettivi di business.