Il site reliability engineering è quello che ottieni quando tratti le operations come un problema di software: un team di ingegneri che risponde dell'affidabilità di un servizio in produzione, la misura dal lato dell'utente e passa almeno metà del proprio tempo a scrivere codice che elimina lavoro operativo invece di farlo a mano. Un SRE non è un sysadmin con un nome nuovo e non è un DevOps engineer con un pager. Il ruolo ha un perimetro definito, un insieme definito di cose che osserva e una relazione definita con gli sviluppatori. Questo post li copre tutti e tre.

Questa è la Parte 1 di Budget for Failure, una serie in quattro parti su cos'è il site reliability engineering e su come si pratica. Le Parti 1 e 2 sono di livello 101: il ruolo, poi i numeri su cui gira (SLI, SLO, SLA, error budget). Le Parti 3 e 4 sono di livello 201: cosa un SRE deve padroneggiare nel codebase, e cosa controllare dal lato del provider, che sia un cloud o il tuo data center. Gli esempi sono su AWS; la pratica non è specifica di AWS.

Da dove viene il ruolo

Il termine nasce in Google, dove Ben Treynor Sloss ha costruito il primo team nel 2003 e lo ha poi descritto in una riga nel libro SRE: l'SRE è quello che succede quando chiedi a un ingegnere del software di progettare un team di operations. La risposta dell'ingegnere a un servizio in crescita non è stata assumere operatori in proporzione al traffico. È stata automatizzare il lavoro dell'operatore e mettere un tetto rigido alla quantità di lavoro manuale che il team poteva accettare.

La relazione con il DevOps viene riassunta di solito, sempre da Google, come "class SRE implements interface DevOps". Il DevOps è un insieme di principi: ownership condivisa, cambiamenti piccoli, automazione, misurazione. L'SRE è un'implementazione concreta di quei principi, con opinioni annesse, per esempio su come esattamente si misura l'affidabilità e cosa esattamente succede quando la misura dice che un servizio non è abbastanza affidabile.

Di cosa risponde un SRE

Il libro SRE elenca il perimetro in una frase: un team SRE risponde di disponibilità, latenza, prestazioni, efficienza, change management, monitoraggio, risposta alle emergenze e capacity planning dei propri servizi. Tradotto in cosa significa in una settimana di lavoro:

  • Disponibilità e latenza. Definire cosa significa "funziona" per gli utenti sotto forma di numero, misurarlo e difenderlo. La Parte 2 è interamente dedicata a questo.
  • Change management. La maggior parte delle interruzioni è causata da un cambiamento. L'SRE possiede la macchina che rende il cambiamento sicuro: rollout progressivi, rollback automatico e l'evidenza che una release è in salute.
  • Monitoraggio e alerting. Decidere quali segnali meritano un umano alle 03:00 e quali stanno su una dashboard. Un page che non richiede alcuna azione è un difetto dell'alerting, e l'SRE lo corregge come qualsiasi altro difetto.
  • Risposta alle emergenze. Essere in reperibilità (on-call), gestire gli incidenti con una struttura di comando chiara, e ripristinare prima il servizio e diagnosticare dopo.
  • Postmortem. Dopo un incidente, un'analisi scritta e blameless di cosa è successo e di quale correzione sistemica previene quella classe di guasto. Blameless è un requisito tecnico: le persone che si aspettano una punizione smettono di riferire quello che hanno visto.
  • Capacity planning. Sapere quanto margine esiste, come cresce la domanda e quanto tempo serve perché arrivi nuova capacità: minuti su un cloud, mesi on-prem.
  • Efficienza e prestazioni. L'affidabilità comprata con capacità di riserva illimitata non è ingegneria. Anche il costo per richiesta è un numero da SRE.
  • Eliminare il toil. Trattato più sotto, perché è la parte che rende possibile tutto il resto.

Cosa guarda un SRE

Un DevOps engineer che arriva dall'infrastruttura tende a osservare le risorse: CPU, memoria, disco, numero di nodi. Un SRE parte un livello più su, da quello che l'utente ha sperimentato, e usa le metriche delle risorse solo per spiegarlo. L'insieme di partenza standard sono i quattro golden signal del capitolo sul monitoraggio del libro SRE:

SegnaleDomanda a cui rispondeDove vive su AWS
LatenzaQuanto durano le richieste, separate tra successi e fallimenti?Percentili di TargetResponseTime dell'ALB, Latency di API Gateway, trace applicative
TrafficoQuanta domanda c'è sul sistema?RequestCount dell'ALB, messaggi SQS inviati, Invocations di Lambda
ErroriQuale frazione delle richieste fallisce?HTTPCode_Target_5XX_Count e HTTPCode_ELB_5XX_Count dell'ALB, Errors di Lambda
SaturazioneQuanto è piena la risorsa più vincolata?Connessioni RDS rispetto a max_connections, età della coda, CPU reservation di ECS, utilizzo delle service quota

Due dettagli distinguono la lettura di un SRE di questi segnali da una lettura superficiale. La latenza si legge come distribuzione, mai come media: il 99° percentile è dove stanno gli utenti scontenti. E la saturazione si legge rispetto al limite che verrà davvero raggiunto per primo, che raramente è la CPU. È il connection pool del database, l'allocazione delle porte del NAT gateway, la concurrency Lambda a livello di account o il budget IOPS del volume EBS.

Oltre ai quattro segnali, un SRE osserva le cose che predicono l'incidente del mese prossimo: il ritmo e il tasso di fallimento dei cambiamenti, l'età della dipendenza non aggiornata più vecchia, quanto della settimana scorsa è andato in lavoro manuale e quanti page ha ricevuto l'ingegnere in reperibilità.

La regola del 50 percento e il toil

La caratteristica che rende l'SRE diverso da un team di operations con un titolo migliore è un tetto. Nel modello di Google un SRE passa almeno il 50 percento del proprio tempo su lavoro di ingegneria, mediato su qualche trimestre. Il resto può andare in lavoro operativo: ticket, reperibilità, attività manuali.

La parte manuale ha un nome, toil, e una definizione precisa: lavoro legato all'esercizio di un servizio in produzione che tende a essere manuale, ripetitivo, automatizzabile, tattico, privo di valore duraturo, e che scala linearmente con la crescita del servizio. Riavviare un worker bloccato, ruotare un certificato a mano, approvare una richiesta di quota, copiare un database per uno sviluppatore. Ognuna è piccola. Insieme sono il motivo per cui un team di cinque persone non riesce a fare alcuna ingegneria.

Il tetto è ciò che dà all'SRE l'autorità di dire no. Quando il toil supera metà del tempo del team, la risposta non sono gli eroismi. È automatizzare la fonte più grande, o restituire il carico operativo al team che lo genera finché non si riduce. La reperibilità segue la stessa logica: il libro SRE fissa un carico sostenibile intorno a due incidenti per turno, perché ogni incidente ha bisogno di follow-up e di un postmortem, e una persona che riceve cinque page a notte non fa né l'uno né l'altro.

Come un SRE aiuta gli sviluppatori

La versione peggiore di questo ruolo è un cancello: gli sviluppatori lanciano una release oltre un muro e un team di affidabilità decide se può passare. La versione utile tratta gli sviluppatori come il cliente e l'affidabilità come un prodotto che l'SRE costruisce per loro. Quattro forme concrete:

La paved road. Un template di servizio che arriva con logging strutturato, metriche, tracing, health check, una pipeline di deploy con canary e rollback, e allarmi sensati già cablati. Uno sviluppatore che prende il default ottiene un servizio affidabile senza leggere un runbook. È la cosa di maggior valore che un team SRE rilascia.

La production readiness review. Prima che un nuovo servizio prenda traffico reale, l'SRE lo ripercorre con gli sviluppatori: da cosa dipende, cosa succede quando ogni dipendenza è lenta, quali sono i timeout, come si fa il rollback, chi viene chiamato. È una review del design, fatta abbastanza presto da poter cambiare il design. La Parte 3 passa in rassegna cosa cercare.

L'error budget. Un numero condiviso e concordato in anticipo che dice a entrambe le parti quando è sicuro rilasciare in fretta e quando rallentare. Sostituisce la discussione sul fatto che una release sia "troppo rischiosa" con una lettura. La Parte 2 lo costruisce.

Reperibilità condivisa. Gli sviluppatori che portano il pager per il proprio servizio scrivono codice diverso. Molte organizzazioni fanno partire un servizio sulla rotazione degli sviluppatori e lo passano all'SRE solo quando raggiunge un'asticella di affidabilità, e lo restituiscono se scende sotto. Il lavoro dell'SRE è rendere quella rotazione umana, con buoni alert e buoni runbook, non assorbire il dolore perché nessuno a monte lo senta.

SRE e DevOps: dove il lavoro cambia

Se per mestiere gestisci pipeline, Terraform e Kubernetes, la maggior parte degli strumenti si porta dietro. Quello che cambia è la domanda a cui ogni strumento risponde.

Come DevOps engineerCome SRE, in più
Costruisci la pipeline CI/CDDecidi quale evidenza ferma un rollout in automatico, e misuri quanta affidabilità costa ogni release
Imposti allarmi su CPU, memoria e discoChiami qualcuno solo sui sintomi visibili all'utente, e tieni le metriche delle risorse per la diagnosi
Fai provisioning dell'infrastruttura come codiceNe conosci i domini di guasto, le quote e cosa succede quando il control plane del provider è giù
Risolvi l'incidenteGestisci l'incidente, scrivi il postmortem e rilasci la correzione che elimina la classe di guasto
Automatizzi un'attività quando te lo chiedonoTieni traccia del toil come numero e rifiuti di lasciarlo superare metà del tempo del team
Tratti il codice applicativo come territorio degli sviluppatoriLo leggi, ne rivedi timeout e retry, e gli mandi pull request

L'ultima riga è quella che la maggior parte degli ingegneri infrastrutturali sottovaluta. Un SRE che non sa leggere il codice del servizio può solo osservare i guasti dall'esterno. L'affidabilità si decide in come una funzione gestisce una dipendenza lenta, e quello sta nel repository, non nel cluster.

Modalità di guasto e cosa tenere d'occhio

La ridenominazione. Un team di operations a cui danno il titolo SRE e la stessa coda di ticket non ha cambiato nulla. Senza il tetto al toil e l'autorità che ne deriva non c'è tempo per l'ingegneria, e il titolo descrive un'aspirazione.

Il gatekeeper. Un team di affidabilità che approva le release diventa il collo di bottiglia che l'organizzazione aggira. L'influenza viene dalla paved road e dai dati, non da un veto.

L'eroe. Un ingegnere che conosce ogni sistema e risolve ogni interruzione è un single point of failure con uno stipendio. Gli incidenti che finiscono con "a Sam ci sono voluti venti minuti" hanno bisogno di un runbook, non di applausi.

Affidabilità senza un numero. "Il più affidabile possibile" non si può pianificare, dimensionare come team o scambiare con delle feature. Tutto in questo post dipende dal poter dire quanto affidabile dovrebbe essere un servizio e se lo è in questo momento. Quello è il vocabolario di SLI, SLO ed error budget, ed è la Parte 2.

Leggi questo dopo

Per consulenza su AWS, architettura cloud, pratica SRE, pipeline CI/CD, Linux e altro, parti da ercanermis.com.

Riferimenti