Nell’articolo Cos’è il Site Reliability Engineer abbiamo raccontato per sommi capi le responsabilità, lo spirito e il ruolo di un professionista che ricopre questo incarico. Ma guardando più da vicino le attività più comuni, nella pratica, come si svolgono le sue “giornate tipo”? Fabio Mora, Software Engineer, Agile Coach, esperto DevOps ed autore, ci racconta in questo articolo come si svolge una tipica giornata nel ruolo di SRE.
Non solo on-call
In una giornata ordinaria – se così si può dire – il turno comincia con il fuso orario del «dev team» in cui si è inseriti. Il dev team è composto dagli sviluppatori responsabili di uno specifico servizio o prodotto. Responsabilità e oneri variano in base alle decisioni manageriali della propria organizzazione, ma – generalmente – si lavora: o come parte di un team di prodotto con un vero proprio “headcount” prestato al ruolo di SRE; oppure ingaggiati per supporto ai developer, su obiettivi specifici. In ogni caso, anche i dev team che non hanno un SRE di riferimento, nelle grandi strutture, spesso hanno un supporto base, che ha anche compiti di roadmap strategici, offre servizi centralizzati, forma i team, assiste per nuovi rilasci o incidenti gravi. E non necessariamente di giorno, dato che spesso, nel caso delle multinazionali ad esempio, utenti e team sono sparsi per tutto il globo – e quindi diverse timezone. Parte integrante del lavoro è anche essere «oncall», ovvero reperibili nel caso in cui fuori dall’orario normale si verifichino incidenti ai servizi.
Si parte quindi dando un’occhiata ai sistemi di tracciamento del lavoro del team, i monitor, che possono essere dashboard, telemetrie, e i sistemi di allarme. Gli allarmi scattano quando una parte dell’infrastruttura entra in uno stato inatteso, e ha bisogno di manutenzione: spazio esaurito, software vecchio, un bug, attività di sicurezza, rotture di apparati… Non tutti gli allarmi sono prioritari ma dipende quali impatti portano: gestire e valutare le priorità è una capacità cruciale per un SRE. Se i problemi riguardano la produzione, può scattare una procedura, di conseguenza una notifica e una telefonata automatica arrivano sul cellulare del professionista reperibile, generando un c.d «incidente». Segue quindi una fase di triage e mitigazione dell’impatto.
Quella dello SRE però non è una figura che fa solo on-call, ma si tratta proprio di un mestiere diverso: certamente si svolgono compiti da sistemisti, ma con il fine di imparare e rendere il sistema migliore, più automatico e semplice
Stand-up meeting
Pratica comune è iniziare le giornate con gli stand-up meeting, ovvero brevi momenti di 15/30′ in cui il team fornisce aggiornamenti rispetto al progresso del lavoro svolto il turno prima, quello pianificato per il successivo, e porta all’attenzione di tutti eventuali blocchi, allarmi o elementi che possono far cambiare i piani. Se ci sono, le discussioni proseguono a fine riunione: l’obiettivo è cercare soluzioni rapide e integrare eventuali nuove informazioni.
Per approfondire leggi anche: Le 5 regole per uno stand-up meeting Agile e impeccabile.
Reliability & Velocity
Come parte integrante in un prodotto software, il compito SRE è cercare la migliore strategia tra reliability e velocity. Da una parte, la reliability: dobbiamo perseguire obiettivi utili all’utente. Il 100% di disponibilità è un valore quasi teorico, utile solo in pochissimi casi critici e che comporta costi elevati in macchine, persone e sistemi. Più spesso, i sistemi ragionano su livelli di servizio detti “nove” seguito da un certo numero. Ad esempio uno SLA (Service Level Agreement) 99.99% è detto “four-nine”, e corrisponde a circa 53 minuti di disservizi in un anno, esempio accettabile per un gran numero di applicazioni non critiche. Esiste uno un SLA per ogni servizio, ovvero l’accordo tra il fornitore di servizi e il cliente che definisce la quantità di “reliability” interessante per lui, ad esempio per uptime o per latenza. Il reliability ha un grande impatto sulle spese in quanto alta disponibilità significa alti costi.
La velocity, invece, ha come sfida la rapidità con cui il dev team lavora e rilascia: si tratta di massimizzare il rilascio sul lungo periodo e garantire che sia facile mantenere il sistema, oltre che la sua semplicità.
Più lo SLA è basso, minore dovrebbe essere la criticità delle funzioni offerte dal prodotto; pensate ad esempio allo SLA di un software per il pronto soccorso rispetto ad una piattaforma di fatturazione. Con a disposizione un maggiore numero di minuti in cui il servizio può essere “non disponibile”, il margine di errore che un team può giocarsi durante le attività rischiose è maggiore (più in generale, è il tema degli error budget). È quindi più economico utilizzare queste minuscole quantità di disservizio che l’utente può sopportare, in feedback dovuto a rilasci di funzionalità e lanci di nuovi servizi, perché potrebbero generare problemi mai visti prima. Un’instabilità di fondo del sistema, invece, genera una serie di disservizi e problemi già visti in precedenza, e da cui è difficile imparare.
Insomma, se proprio devi fare un errore, cerca di commetterne uno che non hai mai incontrato prima, così da imparare sempre qualcosa di nuovo!
I pilastri del mestiere, resi popolari dalla disciplina del già citato Ben Treynor Sloss, in Google, sono:
- Ridurre i «silos»: le competenze necessarie a fare e mantenere il software hanno necessità di essere tutte presenti in un unico team di lavoro, o collaborare tra strutture organizzative diverse – il mondo reale non prevede distinzioni teoriche, la complessità dei sistemi richiede molte competenze diverse.
- Accettare il fallimento come normalità: sempre per via della complessità, il mondo dei sistemi di computer è intrinsecamente poco reliable, un dato di fatto da gestire, catalizzato dal fattore umano, l’errore involontario. La complessità accidentale è un grosso debito tecnico.
- Cambiamenti graduali: i piccoli cambiamenti garantiscono rischi bassi con possibilità di dosarli. Concentrarsi su aspetti e servizi specifici, avere obiettivi precisi e sapere cosa aggiustare e cosa no, serve a fare progressi piccoli e costanti, che devono avere un effetto sull’utente in termini di feature, reliability ed economia.
- Far leva su strumenti e automazione: ogni soluzione manuale può essere automatizzata, ma bisogna capire cosa e come utilizzarne il vantaggio. Gli obiettivi sono stabiliti dal dev team secondo una roadmap. Il SRE ne facilita l’esecuzione. Quando uno stesso team lavora agli stessi sistemi per anni, questi tendono a diventare estremamente elaborati e indissolubilmente legati al team stesso, ma questo non deve accadere. Pipeline e piattaforme di automazione sono ottime armi sia per tenere sotto controllo il debito tecnico, sia per espandere la conoscenza dei processi nel team.
- Misurare: senza dati è impossibile poter dire oggettivamente se vi è stato un miglioramento, ecco perché l’osservabilità dei sistemi è indispensabile per correggere la rotta con feedback tempestivo. Tutto deve essere tracciato, dalle metriche delle azioni che compie il software agli errori utente ed infatti deve essere migliorato il servizio per l’utente, prima che per il dev team. Se il nostro cloud è stabile ma un prodotto genera errori, l’utente sta soffrendo comunque.
Queste indicazioni generali portano poi a principi e tattiche operative e anche a pratiche più precise. Strumenti come la Continuous Delivery, la pragmatica rimozione del debito tecnico, la complessità, le retrospettive, le simulazioni di incidente, i post-mortem, sessioni di workshop formativi, l’organizzazione in stile Lean del lavoro, la rimozione pragmatica dei colli di bottiglia e molto altro. Gestire in modo preciso e tempestivo l’informazione, con tutto questo focus, è una necessità sempre derivata dalla complessità. Se in una situazione fortunata si gestiscono poche decine di servizi, in altre si possono dover affrontare centinaia di servizi nuovi che si rompono nel cuore della notte, progettati da programmatori che non sono più in azienda e in epoche informatiche antecedenti – il c.d. legacy.
Il rischio di asimmetria informativa
Gli SRE infatti non conoscono in dettaglio tutto quello che è online, a volte l’asimmetria informativa è estrema, non conosciamo la codebase e neppure quello che sta succedendo. La capacità di dare un senso generale alle componenti di un sistema (le sue parti) e agli eventi che lo sollecitano è cruciale, soprattutto in uan fase di emergenza. Ma se si perde la conoscenza e il controllo del sistema, possono apparire operazioni manuali non documentate e ripetitive che renderanno molto faticoso e difficile garantire un buon livello di servizio.
Ci sono due modi per raggiungere il più astratto obiettivo di “operare sistemi di produzione funzionanti”. Il primo è quello di costruire sistemi robusti, facili da modificare, estendere e programmare. Il secondo è invece quello di costruire un enorme team di supporto in grado di riavviare i sistemi, osservare grafici, annotare liste infinite di task, ripetere procedure e spegnere gli incendi man mano che le cose vanno a fuoco (il c.d «human toil»).
Per approfondire leggi anche:
