Cos'è un SRE? Il ruolo fondamentale dell'ingegnere dell'affidabilità del sito

Poiché il mondo si è spostato online, l'affidabilità dei siti Web, delle applicazioni cloud e dell'infrastruttura cloud è diventata un imperativo aziendale fondamentale, per tutto, dalle operazioni di e-commerce alle banche globali ai motori di ricerca.

Il modo in cui gestiamo i sistemi e i loro carichi di lavoro è cambiato. Oggi, raramente pensiamo in termini di server preziosi, high-touch e ad alte prestazioni, ma invece rack su rack di server commodity raggruppati insieme tramite la virtualizzazione, con un'architettura software distribuita che impedisce che interruzioni del server causino tempi di inattività. L'attenzione si è spostata dall'hardware all'infrastruttura definita dal software e da processi manuali incoerenti e soggetti a errori ad attività automatizzate coerenti, affidabili e ripetibili.

L'ingegneria dell'affidabilità del sito è la pratica di mantenere quell'infrastruttura programmabile e massimizzare la disponibilità dei carichi di lavoro che vengono eseguiti su di essa. Il ruolo di Site Relancy Engineer (SRE) ha avuto origine nei padiglioni di Google, che, all'inizio del millennio, voleva ridefinire il rapporto tra sviluppatori di software e personale operativo e aiutarli a lavorare insieme per costruire sistemi robusti e flessibili, con miglioramento costante e automazione come principi fondamentali.

Cos'è un SRE?

A livello base, gli SRE apportano principi di ingegneria del software ai problemi di infrastruttura e operazioni, con l'obiettivo di creare sistemi altamente scalabili e affidabili.

"Fondamentalmente, è ciò che accade quando chiedi a un ingegnere del software di progettare una funzione operativa", come spesso afferma Ben Treynor, VP di ingegneria di Google e padrino di SRE.

La principale tra le responsabilità di SRE è stabilire soglie del livello di servizio, spesso manifestate come obiettivi a livello di servizio (SLO), che aiutano a informare se una versione ottiene o meno il semaforo verde. Il Santo Graal è sempre il sacro "cinque nove" o tempo di attività del 99,999%. Migliore è il tempo di attività, più sviluppatori di corda riescono a lanciare nuove fantastiche cose e più dormono gli SRE, portando a una relazione reciprocamente vantaggiosa tra le funzioni, ben lontana dai vecchi tempi di antagonismo tra sviluppatori e operazioni.

Una funzione SRE sarà generalmente misurata su una serie di parametri chiave di affidabilità, vale a dire: prestazioni del sistema, disponibilità, latenza, efficienza, monitoraggio, pianificazione della capacità e risposta alle emergenze.

[Anche su: Monitoraggio delle applicazioni: cosa può fare meglio i devops]

Principali responsabilità lavorative di un SRE

Ogni buon SRE sarà ossessionato da una cosa in particolare: l'automazione.

Come afferma Jason Qualman, SRE presso il fornitore di software di monitoraggio New Relic, in un post sul blog: “Gran parte di questo ruolo è pensare a cose inefficienti e dispendiose in termini di tempo che le persone stanno facendo e metterle fine il prima possibile. Invece di dare calci a una lattina lungo la strada per il lavoro manuale, stai dicendo: "Mi prenderò il tempo per automatizzare questo in questo momento e impedire a chiunque altro di dover fare questa cosa dolorosa." "

Un altro elemento chiave del ruolo di SRE è qualcosa chiamato "ingegneria del rilascio", che implica la definizione di best practice per garantire che le versioni del software siano coerenti e ripetibili.

“Gli ingegneri del rilascio hanno una solida (se non esperta) conoscenza della gestione del codice sorgente, dei compilatori, dei linguaggi di configurazione della build, degli strumenti di build automatizzati, dei gestori di pacchetti e dei programmi di installazione. Il loro set di competenze include una profonda conoscenza di più domini: sviluppo, gestione della configurazione, integrazione dei test, amministrazione del sistema e assistenza clienti ", ha scritto Dinah McNutt, responsabile del programma tecnico di Google, per il libro fondamentale Site Reliability Engineering (pubblicato da O'Reilly in 2016 e scritto dai googler Jennifer Petoff, Niall Richard Murphy, Chris Jones e Betsy Beyer).

Poi c'è la parte di risposta del ruolo, che comprende avvisi, essere di guardia e risoluzione dei problemi, insieme alla risposta in caso di emergenza e incidente e post-mortem.

In sostanza, è importante che gli SRE sappiano come monitorare al meglio i sistemi e reagire quando le cose vanno male, scrivendo e riscrivendo costantemente playbook di risposta per ridurre il tempo necessario per riparare qualsiasi guasto che potrebbe verificarsi. In Google, ciò implica la documentazione di un incidente, la comprensione di tutte le cause alla radice e l'implementazione di future azioni preventive.

"Scrivere un post-mortem non è una punizione, è un'opportunità di apprendimento per l'intera azienda", scrivono i googler John Lunney e Sue Lueder in un capitolo del libro Site Reliability Engineering .

[Anche su: 3 passaggi per applicare metodologie agili nelle operazioni IT]

Ingegneri SRE vs. devops

So cosa stai pensando. Sembra tutto molto simile a devops, ma quando si parla di terminologia, il titolo di lavoro SRE in realtà precede devops engineer di circa cinque anni.

Entrambi si basano su principi simili, ma la differenza è sia sottile che importante. Entrambi i modi di lavorare comportano l'abbattimento delle barriere tra sviluppatori e personale operativo ed entrambi mirano ad aumentare la velocità dei team di sviluppatori mantenendo la resilienza di base di tali servizi.

La differenza fondamentale è che gli ingegneri devops tendono a concentrarsi sul supporto della fornitura continua e della velocità dello sviluppatore, mentre gli SRE si assumono la responsabilità dell'affidabilità e dell'automazione durante tutto il ciclo di vita del software, con un'enfasi sulla distribuzione e il monitoraggio con successo dei rilasci e sul mantenimento dell'infrastruttura definita dal software. L'SRE ha una funzione integrante all'interno del team di ingegneri più ampio: garantire che ci sia un posto specialista al tavolo incentrato sulla costruzione di sistemi stabili.

Come afferma Jayne Groll del Devops Institute: “Devops si concentra sulla fornitura continua di ingegneria fino al punto di distribuzione; SRE si concentra sulla progettazione di operazioni continue nel punto di consumo del cliente ".

La storia di SRE in Google

Riportare i principi SRE alle loro origini in Google all'inizio degli anni 2000 fornisce una lezione fondamentale sulla disciplina.

"Quando sono arrivato a Google, ho avuto la fortuna di far parte di un team parzialmente composto da persone che erano ingegneri del software e che erano inclini a utilizzare il software come un modo per risolvere i problemi che storicamente erano stati risolti manualmente. Quindi, quando è stato il momento di creare un team formale per svolgere questo lavoro operativo, è stato naturale adottare l'approccio "tutto può essere trattato come un problema software" e seguirlo ", ha dichiarato Ben Treynor in un'intervista sul blog interno di Google.

"Quindi SRE sta fondamentalmente facendo un lavoro che è stato storicamente svolto da un team operativo, ma utilizzando ingegneri con esperienza nel software e puntando sul fatto che questi ingegneri sono intrinsecamente predisposti e hanno la capacità di sostituire l'automazione al lavoro umano, "Aggiunge Treynor.

Google pensa anche in modo abbastanza rigido a come mettere insieme un team SRE. Tutti gli SRE di Google devono essere ingegneri di software di Google o "candidati molto vicini alle qualifiche di ingegneria del software di Google". Devono inoltre possedere competenze di gestione dell'infrastruttura, più comunemente "esperienza interna di sistemi Unix e networking (da Layer 1 a Layer 3)".

Le qualifiche SRE tendono ancora a variare da azienda ad azienda, ma per quanto riguarda i principi di base, l'approccio di Google è un solido punto di partenza. I dettagli dipenderanno dalle esigenze aziendali, dai processi stabiliti e dallo stack tecnologico già adottato dall'organizzazione.

Descrizione del lavoro e stipendio SRE

Gli SRE in genere dedicano circa il 50% del loro tempo a svolgere le funzioni operative tradizionali, come essere di guardia e intervenire per risolvere i problemi. L'altro 50% è concentrato sullo sviluppo di software per rendere i sistemi sottostanti più resilienti, automatizzati e autoriparanti nel tempo. Ecco perché il ruolo richiede un solido mix di abilità di ingegneria del software e abilità operative. Sarà organizzato un buon SRE, fresco sotto pressione e risolutore di problemi. I manager SRE sono responsabili delle prestazioni, della strategia e dell'ottimizzazione del team.

Ma per quanto riguarda le organizzazioni in cui il ruolo SRE non esiste? Nel rapporto O'Reilly "Cos'è SRE?" Kurt Andersen di LinkedIn e Craig Sebenik di Split (un fornitore di software per la gestione dei rilasci) consigliano di adottare un approccio "dal basso". Raccomandano di trovare “un team di sviluppo motivato a cambiare e implementare un piccolo team SRE (o individuo) lì. Nel tempo, puoi utilizzare quel successo come esempio positivo per altre squadre ".

Lo stipendio medio annuo per un SRE è di circa $ 130.000 negli Stati Uniti e £ 76.000 nel Regno Unito, secondo il sito di lavoro Indeed.

Risorse SRE

Le risorse abbondano per sviluppare competenze SRE, dalle certificazioni del DevOps Institute ai libri e alle risorse online di O'Reilly, Microsoft e Google. Il già citato colosso di 550 pagine  Site Reliability Engineering  di Jennifer Petoff, Niall Richard Murphy, Chris Jones e Betsy Beyer è il libro di riferimento sull'argomento, pubblicato nel 2016. Il libro è anche disponibile gratuitamente online da Google. 

Altri libri più recenti sull'argomento includono  Training Site Reliability Engineers  di Jennifer Petoff, JC van Winkel e Preston Yoshioka; Cos'è SRE?  di Kurt Andersen e Craig Sebenik; Seeking SRE  di David N. Blank-Edelman e  The Site Reliability Workbook  di Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara e Stephen Thorne.

O'Reilly dispone anche di una libreria completa di risorse online, video ed ebook sull'argomento, curata in modo pratico in questa playlist SRE Essentials dall'ex ingegnere dell'affidabilità del sito di Google Liz Fong-Jones.

Il colosso dell'apprendimento online Coursera offre diversi corsi, tra cui il popolare Site Reliability Engineering: Measuring and Managing Reliability from Google Cloud Training. Questo corso è disponibile anche da Pluralsight, così come il corso per principianti Site Reliability Engineering (SRE): The Big Picture di Elton Stoneman. La Linux Foundation offre un corso autoguidato intitolato DevOps e SRE Fundamentals: Implementing Continuous Delivery.

Jellyfish Training con sede nel Regno Unito offre varie opzioni di corsi di formazione privati ​​di due giorni per la Fondazione SRE (SREF).

Ulteriori informazioni su devops

  • Cos'è devops? Trasformare lo sviluppo del software
  • 3 modi per avviare un programma devops
  • Best practice per Devops: i 5 metodi da adottare
  • 15 KPI per monitorare la trasformazione devops
  • Monitoraggio delle applicazioni: cosa può fare di meglio devops
  • Dove l'ingegneria dell'affidabilità del sito incontra devops
  • 5 principi per diventare un team devops agile e collaborativo
  • 3 passaggi per applicare metodologie agili nelle operazioni IT
  • In che modo i team agili possono supportare la gestione degli incidenti
  • In che modo i dataops migliorano dati, analisi e apprendimento automatico
  • Applicazione di devops in data science e machine learning
  • 7 domande per dare la priorità al tuo backlog devops