Il ruolo Site Reliability Engineering (SRE) è il lavoro più basilare e importante nell'ambito della risposta agli incidenti e della gestione dell'affidabilità.
Ma cosa fa esattamente un SRE? In che modo un SRE è diverso da uno sviluppatore, un ingegnere DevOps e altri ruoli tecnici? Gli SRE sono team indipendenti o lavorano come parte di altri team? Questo articolo risponde a tutte queste domande per fornire una definizione completa di SRE.
Un SRE, o Site Reliability Engineer, è un ingegnere il cui ruolo principale è massimizzare l'affidabilità dei sistemi IT.
Il ruolo SRE è parte integrante della disciplina di Site Reliability Engineering (che, in modo un po' confuso, è rappresentato anche dall'acronimo SRE). Un SRE, quindi, è qualcuno specializzato in ingegneria dell'affidabilità del sito all'interno di un'ampia organizzazione IT.
Vale la pena notare che il termine "Sito" all'interno di Site Reliability Engineering può essere fuorviante perché implica che gli SRE gestiscono solo l'affidabilità dei siti Web (o, eventualmente, un ufficio locale, se si prende "Sito" per fare riferimento a un cantiere o posizione dei locali). In realtà, gli SRE possono aiutare a gestire qualsiasi tipo di sistema IT.
In generale, le responsabilità lavorative degli SRE possono essere suddivise in due categorie principali.
In primo luogo, gli SRE sono in prima linea nell'assicurare che i sistemi IT siano progettati per essere il più affidabili possibile prima di essere implementati. Un SRE potrebbe aiutare gli sviluppatori a pianificare l' architettura di microservizi ottimale per massimizzare la capacità di un'applicazione di resistere, ad esempio, ai guasti. Oppure, un SRE potrebbe aiutare i team di sviluppo e IT a decidere quale cloud pubblico o cloud utilizzare per ospitare le proprie app, in base alle garanzie SLA e ai record delle prestazioni dei vari cloud. L'obiettivo di attività come queste è ridurre al minimo il rischio che i sistemi falliscano o funzionino in modo insufficiente.
In secondo luogo, gli SRE svolgono un ruolo di primo piano nel rispondere agli incidenti quando qualcosa va storto. Sebbene i team di risposta agli incidenti includano molti altri ruoli (come i responsabili delle comunicazioni e i responsabili dell'assistenza clienti) gli SRE sono in genere, anche, gli esperti che si interfacciano anche ai componenti tecnici principali per le risposte agli incidenti.
Gli SRE possono fare anche una serie di altre cose che non rientrano in nessuna delle categorie sopra descritte. Potrebbero aiutare gli ingegneri del controllo qualità a scrivere test per convalidare l'affidabilità delle applicazioni prima della distribuzione. Potrebbero collaborare con gli ingegneri IT per eseguire l'ingegneria del chaos o interpretare i dati di monitoraggio e risolvere complessi problemi di prestazioni delle applicazioni, anche se tali problemi non sono abbastanza gravi da essere designati come incidenti. Potrebbero persino svolgere un ruolo nel decidere quali sviluppatori di software e ingegneri IT assumere, in base all'esperienza e alla competenza che gli SRE ritengono fondamentali per ottenere un solido track record di affidabilità.
Alla fine della giornata, il ruolo SRE è molto flessibile. Tende ad essere più espansivo e meno definito rispetto a lavori come l'ingegneria del software o il supporto IT. La capacità di essere agili e di applicare soluzioni creative alle sfide dell'affidabilità è parte di ciò che rende gli SRE così preziosi all'interno di un'organizzazione IT più ampia.
Un aspetto del lavoro SRE che può essere un po' confuso è il ruolo che gli SRE svolgono nella gestione delle prestazioni, al contrario dell'affidabilità.
Affidabilità e prestazioni sono concetti distinti ma strettamente correlati. L'affidabilità è la misura della capacità di un sistema di fornire adeguati livelli di funzionalità. Le prestazioni, nel frattempo, misurano quanto bene un sistema raggiunge la funzionalità prevista.
Un sistema potrebbe essere affidabile nel senso che soddisfa i suoi requisiti di funzionalità di base rimanendo disponibile e generalmente responsabile. Ma allo stesso tempo, potrebbe avere prestazioni inferiori perché gestisce le richieste più lentamente di quanto i clienti vorrebbero.
In generale, gli SRE tendono a concentrarsi prima di tutto sull'affidabilità. Il loro obiettivo principale è in genere garantire che la propria organizzazione mantenga i livelli base di funzionalità ai propri utenti negli SLA e negli SLO. Tuttavia, poiché l'ingegneria dell'affidabilità è strettamente correlata alla gestione delle prestazioni, gli SRE in genere supportano anche le operazioni di ottimizzazione delle prestazioni.
C'è un dibattito su come esattamente gli SRE dovrebbero relazionarsi ad altri ruoli tecnici, come sviluppatori, ingegneri IT e ingegneri DevOps. In generale, la maggior parte delle organizzazioni tratta gli SRE come un team separato con un insieme unico di competenze e priorità. Tuttavia, poiché gli SRE in genere necessitano di una combinazione di sviluppo software e competenze di ingegneria IT per svolgere bene il proprio lavoro, non è raro integrare gli SRE direttamente nei team IT o di sviluppo.
Per quanto riguarda le differenze tra SRE e ingegneri DevOps, questo è un argomento importante. Alcune persone ti direbbero che SRE e DevOps significano essenzialmente la stessa cosa. Ma il consenso generale è che si tratta di ruoli in qualche modo diversi perché gli SRE si affidano maggiormente alle competenze di ingegneria del software per progettare l'affidabilità, mentre gli ingegneri DevOps si affidano all'automazione e agli strumenti CI/CD per garantire cicli di consegna del software affidabili.
Anche in questo caso, tuttavia, la linea di fondo è che i ruoli SRE sono intrinsecamente flessibili. Non esistono regole rigide su come strutturare gli SRE all'interno della propria organizzazione o su come distinguerli dagli altri stakeholder tecnici.
La flessibilità del ruolo SRE è parte di ciò che rende gli SRE così potenti. Allo stesso tempo, tuttavia, può rendere gli SRE alquanto difficili da comprendere, soprattutto per le aziende che se la sono cavata bene utilizzando solo i ruoli IT tradizionali, senza aggiungere SRE al team. Tuttavia, nel mondo odierno di applicazioni sempre più complesse, gli SRE sono diventati una risorsa vitale per creare organizzazioni IT agili e pronte a massimizzare l'affidabilità e le prestazioni del software, indipendentemente da come si evolvono i loro sistemi.
Programmatore informatico italiano, mi occupo di sviluppo sia Front-end che Back-end presso una grande azienda. La programmazione è stata la mia passione, insieme allo sport e al teatro che pratico tutt'ora. Ho deciso di aprire questo blog per dare consigli e condividerli con chi, come me, porta con sé questa passione. [..]
