Dopo aver approfondito Cos’è il Site Reliability Engineer, in questo articolo Fabio Mora, Software Engineer, Agile Coach, esperto DevOps ed autore, approfondisce alcuni aspetti più pratici e tecnici riguardo questa professione e alcuni concetti fondamentali, in particolare quello di reliability.
Fare SRE
Fare l’SRE significa lavorare alla funzionalità più importante di un sistema: la reliability, una «feature» che precede qualsiasi altra. Se non ne siete convinti, immaginate di avere la necessità di usare un servizio il cui funzionamento si basa, in tutto o in parte, su sistemi informatici, elettronici, telco ed altre industrie affini.
Prendete un servizio online qualsiasi, più o meno critico. Se l’assistant che vi sveglia la mattina e manda in streaming la vostra stazione radio preferita forse non è fondamentale, lo smartphone che vi consente di interagire con parenti, amici, colleghi, gestire documenti e gli appuntamenti, forse è più critico per la qualità delle vostre giornate. Se estratto dalla tasca dicesse «non disponibile» e le app del conto bancario, di Google, i social network e Wikipedia non funzionassero, qualche problema alla vostra routine potrebbe incombere. Con varie sfumature di criticità, si tratta – sotto il cofano – di piattaforme molto sofisticate che interagiscono e funzionano tra loro, si auto-bilanciano e che spesso sono composte da milioni, o miliardi di righe di codice e dispositivi hardware.
Ma a cosa servono tutte queste cose, se invece sono inaffidabili, irraggiungibili, costellate di errori, disservizi, o non reagiscono ai picchi di richieste? Le funzionalità che offrono corrispondono a delle possibilità nel mondo reale; l’idea dunque è che esse siano mantenute efficienti e reattive per chi le usa, con una qualità di servizio commisurata alle necessità.
Possibili inconvenienti
Ci sono molte cose che possono andare storte. Innanzitutto, con il tempo i sistemi diventano intrinsecamente instabili. A causa della loro incredibile complessità tendono a rompersi e serve lavorare continuamente affinché questo non succeda. Le attività di lavoro sui sistemi e il loro aggiornamento non devono essere svolte solo quando avvengono «incidenti», ovvero eventi di carattere eccezionale, devono far parte del business as usual al fine di prevenire inerzia, obsolescenza e debito tecnico. Questi ultimi sono tutti demoni che minacciano non solo la qualità dei servizi, ma anche la possibilità di continuare a introdurre cambiamenti in essi: se da una parte il compito degli SRE è tenere stabili i sistemi, quello dei programmatori è di scrivere e mantenere le funzionalità dei prodotti, con continui rilasci software. Ogni rilascio quindi, potrebbe introdurre nuovi errori, e complessità – l’altra necessaria, ma dispendiosa, caratteristica dei sistemi in gioco.
Se scaricare un file dal vostro Drive può apparire un gesto semplice, dietro si nasconde una sterminata catena di eventi: dalla rete radiomobile, il flusso di dati viaggia incapsulato, criptato, in una fibra ottica, attraverso cavi transoceanici che lo portano nel giro di millisecondi in un datacenter remoto, e ritorno. A loro volta, vi sono collegamenti dati che permettono a queste infrastrutture di comunicare tra loro, fornire servizi di rete, hardware, ma anche energia e gas in rete – ancora più a monte. Dai POS per pagare in negozio, ai servizi di ticketing, alle reti di segnalazione ferroviaria, autostradale, aeronautica e civile, alla chirurgia in remoto, alle diagnosi mediche in cloud. Ma anche la logistica di ogni pacco consegnato tramite corriere, il lavoro dei «rider», le scie termiche del trasporto alimenti e farmaci. Tutte queste sono piattaforme cardine per interi settori e per la qualità della vita personale: industria, comunicazione, istruzione, educazione, marketing, media, sanità, PA, processi democratici – quasi tutto il terziario – e non solo.
Reliability
Ecco perché la reliability è la feature a monte di ogni sistema. Tuttavia, è anche una feature difficile da comunicare perché, quando è presente, può facilmente essere data per scontata, e risulta difficile dare sempre la giusta importanza a questo tema. Per correggere questo piccolo bias cognitivo, i ruoli e le strutture organizzative degli SRE sono sovente autonome rispetto ai Software Engineer, che invece costruiscono i prodotti.
Il valore attribuito all’SRE, dunque è, tenere questi prodotti stabili sui sistemi; senza errori, manutenibili, fruibili per l’utente – non importa cosa stia succedendo.
Il valore che un SRE offre alla sua organizzazione e agli utenti dei suoi prodotti è, in ultimo, quello di garantire la stabilità dei sistemi di produzione, la manutenibilità del software ed un livello di servizio di elevata qualità. Il tutto a prescindere dalle condizioni esterne, siano picchi di traffico o continui rilasci di nuove funzionalità.
Per approfondire leggi anche:
