Cos'è il site reliability engineering? Guida pratica

Quindi, cos'è il site reliability engineering? È la pratica di gestire i sistemi in produzione con l'ingegneria del software, invece che con operazioni manuali. Un team SRE fissa un obiettivo di affidabilità numerico, misura il servizio rispetto a quell'obiettivo e automatizza il lavoro ripetitivo che tiene in piedi i servizi. Se il telefono di reperibilità suona alle 3 del mattino per lo stesso allarme sul disco ogni mese, è esattamente il problema che la SRE serve a eliminare.

Google ha coniato il termine intorno al 2003. Oggi l'approccio è usato ben oltre Google, dalle startup da 20 persone alle banche. Ciò che cambia da un contesto all'altro è la scala, non la meccanica di fondo.

Che cosa fa davvero un site reliability engineer?

Ben Treynor Sloss, che ha avviato il team SRE di Google, lo ha spiegato in modo semplice nel primo capitolo del libro SRE di Google: la SRE è ciò che succede quando si chiede a un ingegnere del software di progettare un team di operations. Il lavoro è operations fatto con il codice.

In una settimana normale significa quattro cose. Si definisce che cosa vuol dire "funzionare" per un servizio. Si costruisce il monitoraggio che segnala quando non funziona. Si risponde quando si rompe. E si scrive la correzione, così la persona successiva non viene svegliata per lo stesso problema.

La reperibilità è la parte più visibile del lavoro, ma è anche quella che consuma più energie se non viene organizzata. Turni chiari, un runbook per ogni allarme e una regola condivisa su quando un incidente va escalato sono ciò che impedisce che la reperibilità diventi una punizione. Il lavoro SRE comincia davvero quando il team smette di subire le chiamate notturne e comincia a chiedersi perché arrivano.

Due esempi rendono il concetto concreto. Un team che fa il deploy a mano ogni giovedì costruisce una pipeline con rollback automatico. Un team che riavvia ogni notte un servizio che perde memoria trova la perdita. Entrambi trasformano un compito ricorrente in un progetto una tantum, ed è esattamente questo il punto.

La quarta parte è quella che i team saltano. Un SRE che si limita a rispondere agli incidenti è un ingegnere di operations con un titolo nuovo. È la componente ingegneristica a rendere il ruolo diverso.

In che cosa la SRE si differenzia dal DevOps?

Il DevOps è una cultura: sviluppatori e operatori condividono la responsabilità di ciò che viene rilasciato e di come gira in produzione. Dice che il muro tra i team è un problema. Non dice quanto downtime è accettabile, né quando smettere di rilasciare.

La SRE fornisce i numeri. Offre obiettivi di livello di servizio (SLO), error budget e un limite al lavoro manuale. Secondo l'impostazione stessa di Google, la SRE è un modo concreto di mettere in pratica le idee del DevOps.

Non serve discutere su quale delle due sia "migliore". In un team di 8 persone si prende qualcosa da entrambe. La domanda utile è se il team sa rispondere, in una sola frase, con quale affidabilità deve funzionare ogni servizio.

Che cosa sono SLI, SLO e SLA, e perché contano?

Tre sigle portano gran parte del peso in SRE, e le persone le confondono continuamente.

• SLI (service level indicator): una misurazione. Per esempio, la percentuale di richieste HTTP che restituiscono una risposta non 5xx in meno di 300 ms.

• SLO (service level objective): l'obiettivo per quella misurazione. Per esempio, il 99.9% delle richieste su una finestra mobile di 28 giorni.

• SLA (service level agreement): il contratto con le sue conseguenze, di solito dei rimborsi, se l'obiettivo non viene rispettato. Uno SLA dovrebbe essere meno stringente dello SLO.

Il motivo per farlo è che "il sito deve essere veloce e affidabile" non si può verificare. Un obiettivo come "il 99.9% delle richieste di checkout va a buon fine in meno di 500 ms" sì, e offre un modo per chiudere le discussioni senza aprirne altre.

Conviene partire da due o tre SLI per servizio. Di più, e nessuno se li ricorda.

Vanno scelti SLI che gli utenti possono percepire. L'uso della CPU è una causa, non un sintomo. Checkout falliti, pagine lente e dati non aggiornati sono ciò che un cliente nota davvero.

Come funzionano gli error budget?

Un error budget è l'inaffidabilità che lo SLO consente. È semplicemente 1 meno lo SLO. Un obiettivo di disponibilità del 99.9% lascia lo 0.1%, cioè circa 43 minuti di downtime in un mese di 30 giorni.

Ecco una piccola versione in codice, perché l'aritmetica è tutta l'idea:

slo = 0.999
finestra_minuti = 30 * 24 * 60         # 43.200
budget = (1 - slo) * finestra_minuti   # 43.2 minuti
consumati = 31                          # minuti di servizio degradato finora
print(f"{budget - consumati:.1f} minuti rimasti")  # 12.2 minuti rimasti

Finché resta budget, il team rilascia velocemente. Quando si esaurisce, le release di funzionalità si fermano e il lavoro passa all'affidabilità. L'esempio di error budget policy nel SRE Workbook mostra come un team mette per iscritto questa regola.

Il punto non è la punizione. Il budget sostituisce la vecchia lotta, in cui chi sviluppa vuole rilasciare e chi opera vuole stabilità, con un numero condiviso che entrambi possono leggere. Funziona solo se la leadership accetta in anticipo di rispettare la pausa. Una policy che viene scavalcata ogni trimestre è pura decorazione.

Perché esiste la regola del 50% sul toil?

Il toil è lavoro manuale e ripetitivo che cresce insieme al servizio e non lascia niente di duraturo. Riavviare a mano un worker bloccato è toil. Scrivere l'health check che lo riavvia automaticamente è ingegneria.

L'organizzazione SRE di Google punta a tenere il toil sotto il 50% del tempo di ogni ingegnere, come descritto nel capitolo sull'eliminazione del toil. Il resto va a progetti che riducono il toil futuro o aggiungono funzionalità. Il ragionamento è netto: il toil si espande fino a occupare il 100% del tempo di tutti, se nessuno lo ferma.

Il 50% va considerato un tetto, non un obiettivo. Un team sano su un servizio maturo sta ben al di sotto. Se lo si supera per un trimestre, non si sta facendo SRE: si sta gestendo una coda di operations.

Un modo semplice per iniziare: per due settimane si etichetta ogni ticket e ogni allarme come toil o progetto. Poi si ordina il toil per ore. I primi tre elementi della lista sono il backlog di automazione.

Che cosa cambiano le postmortem senza colpe?

Quando qualcosa si rompe, la postmortem chiede come il sistema ha permesso a una persona di commettere quell'errore, non chi lo ha commesso. La colpa insegna alle persone a nascondere le informazioni. Una revisione senza colpe insegna a metterle per iscritto.

Una postmortem utile è breve e ha quattro parti: una cronologia, le cause concorrenti, ciò che è andato bene e le azioni da compiere, con responsabili e date. Le azioni senza responsabile restano desideri.

Gran parte del valore viene dal follow-up. Le azioni aperte vanno riviste ogni mese. Se la stessa causa compare due volte in sei mesi, la prima postmortem è fallita, qualunque cosa dicesse il documento.

Quali strumenti servono prima a un team SRE?

Non molti. Si parte dai segnali, poi si aggiungono reperibilità e automazione.

1. Metriche e dashboard. Abbastanza per calcolare i propri SLI. Grafana e Prometheus sono un abbinamento open source molto diffuso; Datadog e New Relic rappresentano la strada ospitata.

2. Allarmi legati agli SLO. Si allerta quando il budget si consuma in fretta, non quando un singolo host ha un picco. Meno chiamate, e più utili.

3. Feature flag e rilascio graduale. In parole semplici, la maggior parte delle interruzioni segue una modifica, quindi il guadagno di affidabilità più economico è rendere le modifiche reversibili. LaunchDarkly e Statsig coprono questo punto.

4. Un runbook scritto per ogni allarme. Se un allarme non ha un runbook, lo si scrive oppure lo si elimina.

Si compra o si costruisce in quest'ordine. I team che partono dall'acquisto di uno strumento senza un SLO finiscono con dashboard bellissime che non servono a niente di preciso.

Dove si colloca la lettura di codice sconosciuto nella SRE?

È la parte che nessuno inserisce nella descrizione del lavoro. Durante un incidente, un SRE deve spesso capire un servizio che non ha scritto, in un repository che non apre da mesi. La domanda raramente è astratta. È "dove vive questo ciclo di retry, e che cosa fa in caso di timeout?"

Chiunque l'abbia fatto conosce il metodo: grep, blame, poi scrivere a chi ha toccato il file per ultimo. Su un repository da 80K righe funziona. Su dodici servizi di sei team diversi si mangia i primi 20 minuti di un incidente, e quei minuti pesano sul budget.

È lì che uno strumento di ricerca sul codice, capace di rispondere a domande sul proprio repository, si guadagna il suo posto. Per esempio, chiedendo dove un servizio imposta i timeout e quali chiamanti ne dipendono. Non risolverà l'interruzione. Riduce il tempo speso a leggere prima di poter agire, e quel tempo si può misurare.

La SRE è troppo per il proprio team, e da dove si comincia?

Un team SRE dedicato non serve se si ha un solo servizio, qualche ingegnere e utenti che tollerano un'ora storta ogni tanto. Basta uno SLO, un allarme decente e qualcuno responsabile della reperibilità.

Conviene pensarci quando si verifica una di queste condizioni: le interruzioni costano denaro reale, la reperibilità sta esaurendo le persone, oppure gli sviluppatori sono rallentati da richieste operative improvvisate. Molte aziende iniziano rendendo uno o due ingegneri SRE a tempo parziale, e vedono come va.

Un errore comune è rinominare il team di operations "SRE" senza cambiare il modo in cui lavora. Se il team continua a gestire ticket, deploy manuali e nessun error budget, è cambiato il titolo e nient'altro.

Come iniziare la settimana prossima

Non serve una riorganizzazione. Si sceglie il servizio rivolto agli utenti che fa più male e si fanno cinque cose.

1. Definire uno SLI e uno SLO per quel servizio. Tenerli semplici.

2. Calcolare l'error budget e metterlo su una dashboard che tutto il team vede.

3. Tracciare il toil per due settimane e scegliere la voce principale da automatizzare.

4. Tenere una postmortem senza colpe per il prossimo incidente, con azioni assegnate.

5. Stabilire per iscritto che cosa succede quando il budget arriva a zero.

Se tra un mese il team discute meno su se rilasciare e più su che cosa dicono i numeri, sta funzionando. Se il budget non si muove mai perché lo SLO è troppo largo, lo si stringa.