Accedi / Registrati Account

DevOps

Cos'è il site reliability engineering (SRE)?

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

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

È una pratica di notevole validità per la creazione di sistemi software altamente scalabili e affidabili. Poiché utilizza il codice per gestire sistemi di grandi dimensioni, offre un metodo flessibile e sostenibile che consente agli amministratori dei sistemi di 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. 

Grazie a questo approccio, il team è riuscito a garantire che le nuove funzionalità rilasciate fossero sempre affidabili per gli utenti.

La standardizzazione e l'automazione sono due componenti essenziali del modello SRE. Gli ingegneri responsabili dell'affidabilità dei siti sono sempre alla ricerca di modalità per migliorare e automatizzare le operazioni IT.

L'approccio SRE consente di ottimizzare l'affidabilità attuale di un sistema e di migliorarlo nel futuro. 

SRE supporta i team che hanno avviato il passaggio da un approccio tradizionale alle attività IT a un approccio cloud native.

Di cosa si occupa un responsabile dell'affidabilità del sito?

Il responsabile dei processi SRE è un ruolo esclusivo che richiede capacità di sviluppo software ed esperienza in ambito operativo, come nel caso di un amministratore di sistema o un membro di un team operativo IT con anche competenze di sviluppatore software. 

I team SRE sono responsabili della distribuzione, della configurazione e del monitoraggio del codice, nonché delle operazioni legate a: disponibilità, latenza, gestione delle modifiche, risposta alle emergenze e gestione della capacità dei servizi in produzione.

La metodologia SRE aiuta i team a stabilire quali siano le nuove funzioni da distribuire e quando, applicando contratti sul livello di servizio (SLA) per stabilire l'affidabilità richiesta di un sistema, che viene misurata tramite indicatori del livello del servizio (SLI) e obiettivi del livello di servizio (SLO). 

Un livello SLI indica, con una misura predefinita, alcuni aspetti specifici dei livelli di servizio forniti. I principali SLI includono latenza della richiesta, disponibilità, percentuale di errore e velocità del sistema. Un obiettivo SLO si basa sul valore o intervallo target di un livello di servizio specificato, che a sua volta si basa sullo SLI.

Ad esempio, uno SLO relativo all'affidabilità di sistema richiesta viene determinato in base ai tempi di inattività concordati come accettabili. Questo livello di inattività viene definito "budget di errore", ovvero la soglia massima accettabile per errori e interruzioni. 

Adottando questa metodologia non si ottiene un'affidabilità del 100%, ma gli errori sono previsti e accettati. 

Gli sviluppatori possono utilizzare il budget di errore per il rilascio di una nuova funzionalità. Utilizzando i valori dell'obiettivo SLO e in base al budget di errore disponibile, possono decidere se un prodotto o un servizio può essere distribuito.

Se l'esecuzione di un servizio rispetta il budget di errore, il team di sviluppo può lanciarlo in qualsiasi momento; se il sistema invece presenta troppi errori o si arresta per un intervallo più lungo di quanto previsto dal budget di errore, non sarà possibile procedere con nuovi lanci se prima gli errori non rientrano nei limiti del budget.   

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

Le attività dei site reliability engineer si suddividono tra operative e di progetto. Secondo le best practice di Google sul site reliability engineering, un responsabile SRE può dedicare solo un massimo del 50% del proprio tempo alle operazioni, un valore che deve essere monitorato affinché non venga superato. 

Il resto del tempo può essere dedicato ad attività di sviluppo quali la creazione di nuove funzioni, il ridimensionamento del sistema e l'implementazione dell'automazione.

Le attività operative in eccesso e i servizi con prestazioni non ottimali possono essere recuperate dal team di sviluppo, evitando così che il responsabile SRE dedichi troppo tempo all'operatività di un problema di un'applicazione o un servizio. 

L'automazione è una componente importante del ruolo del site reliability engineer, che, quando incorre ripetutamente in un problema può automatizzarne la soluzione, contribuendo a fare in modo che le attività operative non superino il 50% del carico di lavoro. 

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

DevOps e 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 lavoro collaborativa e di condivisione. 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.

Il site reliability engineering è tuttavia differente, perché si affida a ingegneri SRE del team di sviluppo che hanno anche competenze in ambito operativo, per superare le problematiche legate alla comunicazione e ai flussi di lavoro.

La figura del site reliability engineer unisce le competenze dei team di sviluppo con quelle dei team operativi, prevedendo una complementarietà dei ruoli. 

Il metodo SRE aiuta i team DevOps alleggerendo il carico delle attività operative dei loro sviluppatori grazie all'integrazione di personale IT con competenze operative specializzate. 

Per quel che riguarda il codice e le nuove funzioni, DevOps si incentra sull'efficienza del flusso di sviluppo, mentre SRE si occupa di trovare il giusto equilibrio tra l'affidabilità del sito e la distribuzione delle nuove funzioni. 

Le pratiche DevOps necessitano di piattaforme applicative moderne basate sulla tecnologia dei container, su Kubernetes e sui microservizi, che permettano di offrire servizi software sicuri e innovativi.

 

Tecnologia a supporto del SRE

Il site reliability engineering fa affidamento sull'automazione delle attività di routine e sulla standardizzazione del ciclo di vita delle applicazioni. I container Linux® garantiscono al tuo team le basi tecnologiche per un approccio allo sviluppo cloud native. I container supportano un ambiente unico per lo sviluppo, l'erogazione, l'integrazione e l'automazione.

E Kubernetes costituisce la strategia moderna per automatizzare le operazioni dei container Linux. Kubernetes ti consente di gestire in modo semplice ed efficace i cluster che eseguono i container Linux su cloud privati, pubblici e ibridi.

Con la piattaforma adeguata, puoi sfruttare al meglio i vantaggi offerti dalla tua nuova cultura aziendale e dai tuoi nuovi processi. Red Hat® OpenShift® è una piattaforma Kubernetes di livello enterprise in grado di supportare le iniziative SRE.

Gli strumenti essenziali per il SRE

Red Hat Ansible Automation

Una tecnologia di automazione semplice e agentless in grado di migliorare i processi esistenti, di garantire l'ottimizzazione attraverso la migrazione delle applicazioni e di fornire un unico linguaggio per le attività di DevOps dell'intera organizzazione.

Red Hat OpenShift

Una piattaforma container per le imprese basata su Kubernetes, che offre operazioni automatizzate in tutto lo stack per gestire deployment di cloud ibridi e multicloud. 

DevOps offre molte altre possibilità