L’era della trasformazione digitale acuisce, rispetto al passato, la criticità di ambiti come lo sviluppo software, e le funzioni aziendali preposte alla gestione del ciclo di vita del software stesso, specie quando le dimensioni dei servizi IT devono scalare verso l’alto, con conseguenti dilatazioni dei costi di amministrazione. Nasce per questo la figura del site reliability engineer.
In ingegneria del sofware, l’obiettivo principale delle organizzazioni è focalizzarsi sulla progettazione e costruzione di sistemi software: tuttavia, su un altro versante, è ugualmente importante padroneggiare quelle competenze, che, invece, si concentrano sulla gestione dell’intero ciclo di vita degli oggetti software. Tradizionalmente dominio delle IT operation, oggi, queste mansioni afferiscono quindi al site reliability engineer. La disciplina viene denominata site reliability engineering (SRE), è una materia che comprende un vasto insieme di conoscenze e competenze, e ha il compito di monitorare e amministrare i sistemi software dall’inizio del progetto, alla fase di deployment e messa in produzione, a quella di aggiustamento e armonizzazione, fino alla dismissione dei sistemi stessi.
Indice degli argomenti
Amministrare l’intero ciclo di vita del software
I concetti fondamentali che abbiamo appena sintetizzato vengono espressi nella prefazione del libro Site Reliability Engineering – How Google Runs Production Systems, in cui i membri del team SRE spiegano in che modo il loro coinvolgimento e impegno nella gestione dell’intero ciclo di vita del software abbia permesso a Google di costruire, implementare, monitorare e manutenere alcuni dei più grandi sistemi software al mondo.
In effetti, il termine site reliability engineer è stato coniato proprio da Google, attorno al 2003, e, in particolare, da Ben Treynor Sloss, attualmente VP Engineering del colosso di Mountain View, che a quell’epoca la società aveva assunto con l’incarico di dirigere un team di ingegneri software per gestire un ambiente di produzione.
Site reliability engineer, chi è e che ruolo ricopre
Il site reliability engineer è un ingegnere che possiede competenze sia nell’ingegneria e nello sviluppo del software, sia nelle aree disciplinari che sono, tipicamente, appannaggio delle IT operation. In effetti, talvolta, il site reliability engineer deve progettare e sviluppare i sistemi di elaborazione e può dover scrivere codice per tali sistemi in collaborazione con i team di sviluppo prodotto; altre volte, invece, deve dedicarsi alla creazione di componenti aggiuntivi richiesti dai sistemi IT, ad esempio per eseguire le operazioni di back-up e load balancing.
Altro aspetto chiave su cui si focalizzano i team SRE è l’affidabilità del sistema, che si può considerare la più importante caratteristica per poterne garantire l’utilizzo. Dunque, compito dei site reliability engineer è anche trovare i modi per migliorare la progettazione e la gestione dei sistemi IT, e per renderli più scalabili, affidabili ed efficienti.
I SRE si concentrano anche sulla gestione di molteplici servizi, che operano su sistemi di elaborazione distribuiti e sono utilizzati da grandi volumi di utenti: nel caso di Google, ad esempio, la parola “site”, nell’espressione site reliability engineer, si riferiva originariamente al compito, del SRE, di mantenere funzionante il sito dell’omonimo motore di ricerca; tuttavia, attualmente, i team SRE, oltre al search engine, devono mantenere attivi molti più servizi: dall’infrastruttura interna, ai servizi dedicati agli sviluppatori esterni, come la Google Cloud Platform (GCP).
Site reliability engineer, il profilo professionale
Il ruolo del SRE va oltre quello del classico amministratore di sistema, e richiede come requisiti base il possesso di un titolo accademico in informatica, o materie affini, abbinato ad esperienza con linguaggi di programmazione, come Java, C/C++, Ruby, Python, in ambienti di produzione. Altre competenze richieste sono, in genere, una solida esperienza nel networking e nell’amministrazione di sistemi Linux/Unix, database, sistemi distribuiti.
Sviluppo e operation, i limiti di un paradigma di gestione
Nelle varie organizzazioni, storicamente, è stato compito degli amministratori di sistema assemblare componenti software, usando i tool esistenti, per costruire servizi, gestirli ed aggiornarli in rapporto agli eventi. Inoltre, poiché i system administrator possiedono un diverso insieme di competenze rispetto agli sviluppatori, “sysadmins” e “developers” appartengono a due team differenti: il reparto “operations” e quello “development”.
Gli svantaggi e inconvenienti di questo modello sono diversi: uno, ad esempio, è che amministrare un servizio IT avvalendosi di un team che si affida a interventi manuali per la gestione dei cambiamenti e degli eventi comporta costi crescenti, in rapporto all’aumento delle dimensioni del servizio stesso o al traffico che genera, in quanto anche le dimensioni del team di supporto devono aumentare di conseguenza.
In aggiunta, va considerato che i tradizionali team delle operation hanno obiettivi tipicamente in conflitto con quelli dei team di sviluppo, perché, da un lato (Dev), la volontà è integrare nel prodotto sempre nuove funzionalità richieste dagli utenti, mentre, dall’altro (Ops), la preoccupazione prioritaria è assicurarsi che il servizio IT non crolli o subisca interruzioni. Siccome, spesso, i malfunzionamenti sono causati dall’introduzione di nuove funzionalità che hanno provocato cambiamenti nel software, la realtà è che i team delle operation e i team dello sviluppo convivono in continua tensione, rallentando la gestione del ciclo di vita dei servizi software.
Proprio per superare questa situazione è stata sviluppata la metodologia DevOps che prevede la creazione di team che comprendono entrambe le competenze.
Site realiability engineering: sposta il focus sull’automazione
Rispetto allo scenario conflittuale poco sopra descritto, il ruolo del site realiability engineer consente di trasformare il paradigma di gestione e d’introdurre efficienza, riducendo i costi ed eliminando i conflitti tra i team.
In sostanza, i team di site reliability engineer vengono costituiti con l’insieme di competenze necessarie per potersi concentrare soprattutto sullo sviluppo di software di automazione, e sulla creazione di sistemi per compiere il lavoro che altrimenti dovrebbe essere eseguito, spesso in modalità manuale, dagli amministratori di sistema.
Dunque, i site reliability engineer svolgono, di fatto, il lavoro compiuto, tradizionalmente, dai team delle operation, ma, possiedono approfondite competenze software e ingegneristiche, naturale predisposizione e capacità, per progettare e implementare sistemi software di automazione in grado di sostituire il lavoro manuale.
Fondare i metodi del site reliability engineering sull’ingegneria del software è il pilastro essenziale della strategia di gestione SRE, perché altrimenti, in mancanza di una costante attività di ingegnerizzazione dei sistemi IT per creare automazione, i costi delle IT operation sarebbero destinati a crescere inevitabilmente, a causa dell’assunzione delle nuove risorse, necessarie per potenziare i team di supporto preposti a sostenere i carichi di traffico ed eventi generati dallo sviluppo dei servizi IT.
