Continuiamo a parlare di Site Reliability Engineer con Fabio Mora, programmatore e Agile coach freelance entusiasta di Extreme Programming e Linux. Costruire sistemi robusti è fondamentale, in questo articolo capiamo perché questo sia così importante e come muoversi in caso di incidenti.
Costruire sistemi robusti
Se una cospicua fetta di problemi può essere risolta con l’utilizzo del denaro o puntando su particolari professionisti di elevata capacità, non sempre questa soluzione si rivela economica, o sicura dal punto di vista aziendale (per approfondire vedere il concetto di «bus factor»).
È davvero complesso mantenere stabile un sistema che prevede tante operazioni manuali perché è più soggetto a guasti e incline a generare incidenti, tanto da diventare insostenibile nel lungo periodo poiché il rischio è quello di portare il team in condizioni stressanti e di noia – fino forse anche a perderne i componenti. Tuttavia, sistemando mano a mano i piccoli errori e continuando gli interventi di manutenzione senza lasciare che si accumulino, è possibile ottenere un ottimo compromesso.
Shift left strategy
Spesso è più conveniente iniziare a lavorare a un prodotto con un kick-off tecnico su cui riflettere e con cui pianificare le componenti del sistema e la sua architettura software per poi passare da un monolite a un event bus o da architetture a microservizi – con il giusto disegno di API e protocolli per studiare i pattern di utilizzo e individuare i costi delle risorse necessarie.
Questa tecnica è detta shift left strategy: il supporto SRE inizia a partire dal design, non quando il traffico utente è già arrivato, e partendo proprio dal design prosegue nell’implementazione del prodotto. Impiegare le risorse e le persone in modo consapevole è fondamentale: siano essi computer o tempo di software engineering. Questa attività di progettazione cross funzionale è fondamentale e continua, arriva infatti ad occupare gran parte del tempo in una giornata da SRE.
Nella maggior parte dei casi infatti, quando ci si trova di fronte a sistemi “progettati male” ma già messi in opera (ad esempio se gli utenti possono già navigare il sito), l’unica soluzione conveniente consiste nel ri-progettare le parti scadenti e ri-scriverle da zero.
La modalità di svolgere questi compiti per un/una SRE consiste in un genere di programmazione orientata ad “applicare l’informatica all’informatica”: intervenire con una competenza più forte di quella degli altri in questo ambito è il valore che contraddistingue questa figura.
In particolare, è fondamentale la conoscenza dei sistemi operativi, dei protocolli di network, lo studio delle pipeline di rilascio, il controllo della qualità del software, e il sapersi muovere con confidenza tra sistemi di telemetria e allarme. Definire gli obiettivi di SLA/SLO (Service Level Objective), la capacità di gestione della complessità e il lavoro in emergenza richiede conoscenze trasversali: si tratta infatti di scrivere un software che può essere usato per governare altri sistemi software e, non meno importante, migliorarlo a piccoli passi per mantenerlo stabile e semplice.
Interazione tra SRE e altre figure del dev team
L’interazione tra SRE e le altre figure del dev team quindi, non è una banale riallocazione di ruoli, ma un modo diverso di pensare il governo dei prodotti, piuttosto che un gioco a somma zero. Il bilancio è infatti positivo per entrambi i team, se si pensa a fare in modo che le responsabilità di ops siano ridotte al minimo. Il modo per farlo è creare sistemi «continuous», che permettano cambiamenti costanti e sicuri in grosse architetture di sistema, cluster, applicazioni, database, reti – da qualsiasi situazione in cui ci si trovi: in ufficio davanti a una workstation e quattro schermi, o aspettando al gate di un aeroporto con la connessione cellulare. Serve perseguire questo obiettivo affinché un sistema enorme possa diventare gestibile da un piccolo team di normali persone. Fintanto che occorre continuare a chiedersi se l’investimento in tempo SRE abbia più senso, essendo questa un’attività costante e strategica.
Un altro modo di progettare sistemi stabili consiste nel progettare con i team su piattaforme standard e distribuite, che sono più facili da gestire e garantiscono ai professionisti la mobilità tra i team. Pensate ad una compagnia aerea ad esempio: spesso il parco di velivoli e le loro configurazioni sono simili, affinché il personale di terra possa formarsi su pochi generi di macchina e molto precisi; lo stesso vale anche per i piloti con le loro abilitazioni, il personale di volo e i manutentori. Un sistema standard e un panorama di prodotti finiti da mantenere aiuta a creare uno standard e potersi muovere da un team all’altro all’interno della stessa organizzazione.
Questa strategia può non avere effetto diretto per gli utenti, ma serve a tenere i sistemi semplici, ed è la chiave per migliorare. Un buon SRE è innanzitutto un buon Software Engineer: deve essere affezionato alla soluzione di problemi eterogenei e complessi, sapere bene cosa fa un computer a basso livello e conoscere il suo sistema operativo, interagire con i developer, avere competenze in aree interessanti e orizzontali e, infine, una buona predisposizione per il creare automatismi e rimuovere i cosiddetti “colli di bottiglia”.
Lo/la SRE fa da collante tra il team tecnico e i sistemi di produzione, facilita la comprensione della complessità che gli sviluppatori non capiscono immediatamente, in quanto esperti in altri campi. Non è un esercizio privo di rischi però, in quanto necessità di essere rapidi deve essere coniugata con quella di trasferire conoscenza al proprio collega. Quando una cosa funziona e si comprende individualmente, c’è un impulso, un’urgenza di continuare a lavorare per renderla semplice: non ci si può fermare alla prima implementazione, ma serve cercare soluzioni tecniche sempre più semplici. In generale, nel quotidiano, un dev team può non avere urgenza di conoscere il dettaglio di ciò che sta “sotto il cofano” di una cloud, ma nel momento in cui ne emerge la necessità, deve avere gli strumenti per farlo. Inoltre, le persone e i team cambiano, e nell’informatica, per risolvere un problema grosso, non basta aggiungere persone ad un gruppo ma servono processi mentali e procedure di on-boarding lunghe, affiancamento e pair-programming, prima che una persona possa essere produttiva.
Ma non è solo l’SRE ad essere responsabile del prodotto, anzi: principalmente lo è il dev team. Anche i dev infatti devono essere inseriti nella rotazione di turni di reperibilità e vedere ed utilizzare il loro prodotto in azione. A nessuno piace essere svegliati di notte o uscire da un cinema per aprire un laptop e collegarsi alla rete per far funzionare il sistema. La responsabilità del prodotto è sempre del dev team, che ne conosce i dettagli e guida le decisioni. Per essere pronti servono strumenti di diagnostica sui prodotti, bisogna osservare grafici e allarmi, ma soprattutto è necessario fare tanta pratica e svolgere prevenzione con simulazioni e rotture casuali su cui sperimentare ed imparare (c.d. Chaos Engineering).
Incidenti
Quando avviene un incidente, se presente in azienda un NOC (Network Operating Core, il personale che sorveglia il network globale 24/7), anche questo viene coinvolto nella cultura SRE. Non si limita infatti a guardare grafici, ma ha compiti molto più proattivi. Deve facilitare la comunicazione, aprire i bridge in videoconferenza di supporto, tracciare gli uptime e gli eventi, automatizzare le procedure di reporting e di alerting e catalizzare il lavoro degli Ops, oltre a iniziare diagnosi e indirizzare il team, magari con l’ausilio di chatbot e il machine learning. Dall’altra parte dell’alert potrebbe esserci un piccolo disservizio su uno streaming video, oppure un intero ramo di POS o una rete telefonica che bloccano migliaia di utenti.
Quando avviene un incidente gli obiettivi sono due:
- Minimizzare l’impatto al più presto
- Prevenire che accada di nuovo.
Il flusso classico di gestione di un incidente prevede:
- Gestire e mitigare l’evento (troubleshooting)
- Trovare la root cause (triage)
- Affrontare una fase di rimozione dell’impatto (mitigazione)
- Affrontare un processo di post-mortem
- Verificare il consolidamento e l’evoluzione del sistema (fix di lungo periodo).
Post-Mortem
Lo strumento irrinunciabile di un SRE è quindi il Post-Mortem, ovvero la relazione che si scrive quando è successo un incidente o qualcosa è andato storto.
Serve un processo mentale totalmente trasparente e onesto, pena la sua nullità. Non si tratta di un processo accusatorio, ma di una ricostruzione della linea temporale di eventi accaduti, momenti critici, cause, effetti, dati persi e lavoro di ripristino generato – dove siamo stati fortunati e dove no.
L’obiettivo è quello di trovare l’errore scatentante e giugnere ad una soluzione pratica per fare in modo che quella stessa famiglia di problemi non si ripresenti – in conseguenza, aggiustare le procedure. Alla fine del post-mortem si ottiene una lista di bug, tracciati e da risolvere. Questo è il motore del continuous improvement: spiegare bene cosa è andato male, deve fare parte della cultura SRE. Importante è anche ridimensionare in modo sostenibile il lavoro: l’ideale è affrontare pochi incidenti per turno, serve un giusto bilanciamento tra ore di lavoro e riposo. Non si tratta solo di un tema di rispetto ed equilibrio verso sé stessi, ma anche di sicurezza, efficienza e responsabilità verso il team. Una persona stanca infatti, non riesce a corrispondere la giusta attenzione e concentrazione che questa professione richiede, il che rende molto più facile commettere errori. Lo stesso principio indirizza ritmi di piloti, autisti, medici ed altre professioni dove lo human factor è preso in seria considerazione.
Ricapitolando: i post-mortem, le retrospettive e pensiero correttivo sul lungo periodo sono i tre strumenti fondamentali per mettere in pratica un processo di miglioramento. In caso contrario, non avrete modo di imparare dagli errori.
Per approfondire i nostri contenuti a tema SRE leggi anche:
