Cloud o on-prem: cosa verifica un SRE sotto il servizio

Il provider di infrastruttura è la singola dipendenza più grande che qualsiasi servizio abbia, e un SRE lo tratta come ogni altra dipendenza: legge a cosa si impegna davvero, mappa dove fallisce in blocco e verifica cosa succede quando non risponde. Vale sia che il provider sia AWS sia che sia un team di piattaforma che gestisce rack due piani più in basso. Le domande sono identiche su entrambi i lati; quello che cambia è chi risponde. Su un cloud risponde il provider e tu verifichi. On-prem rispondi tu, e non c'è nessuno a verificarti. Questo post è la checklist, in sei aree: l'impegno, i domini di guasto, i control plane, i limiti, la capacità e la manutenzione.

Questa è la Parte 4 di Budget for Failure, la seconda di livello 201 e l'ultima della serie. La Parte 1 ha definito il ruolo, la Parte 2 gli ha dato dei numeri e la Parte 3 l'ha portato dentro il codice applicativo. Questa parte va sotto il codice.

1. L'impegno: le tue dipendenze mettono un tetto al tuo SLO

La Parte 2 ha elencato a cosa si impegnano quattro SLA di AWS. Ora fai l'aritmetica che la maggior parte delle architecture review salta. Una richiesta che deve passare attraverso un load balancer, un livello di calcolo, un database e uno storage a oggetti ha successo solo quando lo hanno tutti e quattro. Se i guasti sono indipendenti, le disponibilità si moltiplicano:

ALB (multi-AZ)      0.9999
EC2 (multi-AZ)      0.9999
RDS (Multi-AZ)      0.9995
S3 Standard         0.9990
------------------------------
product             0.9983   =  99.83%
allowed downtime    about 73 minutes in 30 days

Prima ancora che il tuo codice abbia lanciato una sola eccezione, il pavimento contrattuale sotto questo stack è 99,83 percento. AWS normalmente gira ben sopra i pavimenti dei suoi SLA, quindi la cifra pratica è migliore, ma la conclusione regge: non puoi promettere il 99,99 percento sopra una dipendenza hard che si impegna al 99,9. Abbassi la promessa, oppure rendi soft la dipendenza con una cache, una coda o un fallback, come nella Parte 3.

On-prem non c'è un documento SLA da moltiplicare, quindi costruisci la stessa tabella dalla tua storia: disponibilità misurata dell'array di storage, del cluster hypervisor, della rete core, dell'alimentazione. Se nessuno ha quei numeri, quello è il primo finding della review.

2. Domini di guasto: cosa muore insieme

La moltiplicazione presuppone l'indipendenza. Un dominio di guasto è un insieme di cose che condividono una causa di guasto, e il lavoro dell'SRE è conoscerli e distribuire le repliche tra di essi.

Livello	Cloud	On-prem
Più piccolo	Istanza, host sottostante	Server, disk shelf
Hardware condiviso	Placement group, rack (non visibile di default)	Rack, switch top-of-rack, PDU
Struttura	Availability Zone	Linea di alimentazione, zona di raffreddamento, sala dati
Sito	Region	Data center, campus, area metropolitana
Sopra il sito	Servizi globali, l'account, il provider stesso	Carrier, registrar DNS, identity provider

Tre controlli valgono su entrambi i lati. Le repliche di ogni sistema stateful sono davvero in domini diversi, o tre nodi di un quorum stanno in una zona o in un rack? C'è qualcosa di single-homed sul percorso di qualcosa di multi-homed, come un solo NAT gateway che serve tre zone, o due switch "ridondanti" sulla stessa linea di alimentazione? E dopo che il dominio più grande a cui prevedi di sopravvivere è sparito, la capacità rimanente basta a reggere il carico completo? Sopravvivere alla perdita di una zona con tre zone significa far girare ciascuna a non più di due terzi.

La serie Nothing Fails Alone è fatta di quattro incidenti analizzati esattamente su questo, incluso uno script read-only che trova le concentrazioni single-zone in un account AWS.

3. Control plane e data plane

Ogni piattaforma ha due metà. Il data plane fa il lavoro: le istanze girano, i load balancer inoltrano, il DNS risponde. Il control plane cambia le cose: lancia un'istanza, modifica una rotta, scala un gruppo. I control plane sono più complessi e falliscono più spesso, e tendono a fallire durante i grandi incidenti, cioè esattamente quando un piano di ripristino vuole usarli.

Quindi la domanda per ogni procedura di ripristino è se ha bisogno di una chiamata al control plane per riuscire. Un design che sopravvive alla perdita di una zona perché la capacità è già in esecuzione altrove è staticamente stabile. Uno che sopravvive perché l'autoscaling lancerà dei rimpiazzi dipende dal control plane di EC2 nel momento in cui ogni altro cliente lo sta chiamando. L'articolo dell'Amazon Builders' Library sulla static stability è il riferimento.

On-prem la stessa divisione esiste sotto altri nomi: l'API server di Kubernetes, vCenter, l'automazione IPAM e DNS, l'identity provider da cui dipendono ogni login e ogni service token. Chiediti cosa funziona ancora quando ciascuno è giù, e se gli strumenti usati per risolvere un'interruzione (la VPN, il bastion, la pipeline di deploy, il sistema di chat) girano sull'infrastruttura che dovrebbero riparare.

4. Limiti: l'interruzione che sembra una quota

La saturazione, dai golden signal della Parte 1, ha una forma lato provider che le metriche host non mostrano mai. Su AWS, i limiti che finiscono nei postmortem raramente sono la CPU:

Service quota. vCPU On-Demand in esecuzione per famiglia di istanze, esecuzioni concorrenti Lambda per account, Elastic IP, regole per security group. Uno scale-out che sbatte contro una quota fallisce nel momento peggiore.
Rate limit delle API. Le API del control plane applicano throttling per account e Region. Uno strumento di deploy, un autoscaler e un agente di monitoraggio che chiamano tutti Describe* possono farsi throttling a vicenda.
Spazio di indirizzamento. Una subnet che ha esaurito gli IP liberi blocca nuovi pod, nuove interfacce di rete Lambda e nuove istanze, con un errore che non nomina nessuno di questi.
Tetti per risorsa. IOPS e throughput su un volume EBS, connessioni su una classe di istanza RDS, porte su un NAT gateway.

Tratta ciascuno come uno SLI di saturazione con un allarme ben prima del 100 percento. Per molte quote CloudWatch pubblica l'utilizzo nel namespace AWS/Usage, e la funzione metric math SERVICE_QUOTA() restituisce il limite corrente, così una sola espressione dà la percentuale di quota usata. Per il resto basta uno script di inventario su una schedulazione.

On-prem i limiti sono fisici e più lenti da alzare: unità rack, alimentazione e raffreddamento per rack, porte degli switch, core con licenza, throughput dei controller di storage, la dimensione del piano di indirizzamento fatto cinque anni fa.

5. Capacità: elastico non vuol dire infinito

La promessa del cloud è che la capacità arriva in minuti. Di solito è così, e un SRE pianifica per le volte in cui non lo è. Un tipo di istanza specifico in una zona specifica può restituire InsufficientInstanceCapacity, il più delle volte durante un evento di zona in cui tutti fanno failover verso le stesse zone superstiti. Le difese sono la diversità (diversi tipi di istanza e tutte le zone nell'Auto Scaling group), il pre-provisioning per il caso di failover e le On-Demand Capacity Reservation per i workload che non possono aspettare.

On-prem il lead time va da settimane a mesi, quindi il capacity planning è una disciplina di previsione: crescita misurata, un calendario di acquisti e margine dimensionato come N+1 o N+2 rispetto ai domini di guasto di cui sopra. La decisione che incide di più sull'affidabilità viene presa al momento dell'acquisto, molto prima dell'incidente che la mette alla prova.

In entrambi i mondi, fai load test per trovare il primo limite invece di stimarlo. Il numero che conta è il livello di traffico a cui lo SLI della Parte 2 inizia a degradare, e quale risorsa l'ha causato.

6. Manutenzione: gli incidenti con una data sopra

Una quota rilevante degli incidenti è programmata in anticipo da qualcuno e poi dimenticata. Su un cloud: avvisi di ritiro delle istanze, finestre di manutenzione del database, versioni di engine e di Kubernetes che raggiungono la fine del supporto standard, scadenza dei certificati, runtime deprecati. AWS pubblica la maggior parte di questi per account attraverso AWS Health, che può essere instradato via EventBridge nella stessa coda del resto del tuo lavoro operativo. Non letti, diventano riavvii a sorpresa.

On-prem la lista è più lunga ed è interamente tua: firmware, patching di hypervisor e sistema operativo, sostituzione di dischi e batterie, cicli di rinnovo dell'hardware, contratti di supporto con i vendor, parti di ricambio in sede. Ognuno ha bisogno di un owner e di un calendario. Una piattaforma indietro di tre versioni major sta spendendo error budget in anticipo.

L'ultimo controllo in quest'area è come scopri che il provider sta avendo una brutta giornata. Una status page è scritta da persone durante un incidente ed è in ritardo rispetto a esso. Misura il provider tu stesso, dall'esterno: un canary sintetico che esercita il vero percorso utente da un'altra rete ti parla di un problema regionale prima della dashboard, e tiene vivo il denominatore dello SLI quando il traffico reale non riesce a raggiungerti.

Chi possiede cosa

Ambito	Cloud: la parte dell'SRE	On-prem: la parte dell'SRE
Struttura, alimentazione, raffreddamento	Distribuire tra le zone; fidarsi e verificare	Conoscere le linee di alimentazione e le zone di raffreddamento; posizionare i rack di conseguenza
Guasto hardware	Progettare in modo che la perdita di un'istanza sia un non-evento	Lo stesso, più ricambi, processo di sostituzione, contratti con i vendor
Capacità	Quote, diversità di istanze, reservation	Previsione, lead time di acquisto, margine
Control plane	Non dipenderne per il ripristino	Gestirlo, renderlo ridondante, e comunque non dipenderne
Rete	Routing zonale, NAT, DNS, link privati ridondanti	Tutta: carrier, BGP, firewall, DNS
Patching e ciclo di vita	Seguire le scadenze del provider; possedere OS guest e versioni	Ogni livello, dal firmware all'applicazione
Costo	Costo per richiesta come numero; la capacità di failover inattiva è un'assicurazione	Utilizzo rispetto a un acquisto fisso

Nessuna delle due colonne è più corta perché il lavoro è sparito. Un cloud sposta le righe inferiori a un provider con più pratica di quasi qualsiasi singola azienda, e in cambio ti prendi una dipendenza che non puoi ispezionare. Quello scambio di solito è giusto. Resta uno scambio, e l'SRE è la persona in grado di enunciarne entrambi i lati.

Modalità di guasto e cosa tenere d'occhio

Trattare lo SLA come una previsione. È una clausola di prezzo con un credito annesso. Progetta sul comportamento misurato e sui domini di guasto, non sulla percentuale scritta sulla pagina.

Multi-zone solo sul diagramma. Tre zone nella lista delle subnet e una sola nello stato di esecuzione, o un failover che non è mai stato esercitato. Testalo di proposito, dentro l'error budget.

Ripristino che ha bisogno di ciò che è rotto. Runbook il cui primo passo è un login in console o un'esecuzione di pipeline nella Region colpita.

Limiti scoperti in produzione. Ogni quota e tetto della sezione 4 costa poco da trovare in un load test e molto da trovare durante un lancio.

Dove ti lascia tutto questo

Il percorso della serie, in un passaggio. Possiedi l'affidabilità come problema di ingegneria e metti un tetto al lavoro manuale perché ci sia il tempo di risolverlo (Parte 1). Dichiari quanto affidabile dovrebbe essere il servizio sotto forma di SLO, e spendi la differenza deliberatamente come error budget con una policy firmata (Parte 2). Entri nel repository e correggi i timeout, i retry e i rollout che decidono il numero, e chiami sul burn rate invece che sulla CPU (Parte 3). E sai cosa promette la piattaforma sotto di te, dove fallisce in blocco e cosa farai quando lo fa (Parte 4). Gli strumenti per tutte e quattro sono quelli che la maggior parte degli engineer usa già. Quello che rende il lavoro SRE è che ognuno di essi ora risponde a un'unica domanda: gli utenti stanno ottenendo l'affidabilità che abbiamo concordato, e qual è il modo più economico per mantenerla?

Leggi questo dopo

Parte 3 di questa serie: SRE nel codebase: timeout, retry e alert as code.
La correzione condivide la sorte con l'interruzione: tre incidenti in cui il percorso di ripristino dipendeva dal control plane che era giù.
Your LLM Bill Is an Observability Problem su ercan.ai: lo stesso ragionamento sulla dipendenza dal provider applicato alle API dei modelli, dove quote e costo sono i segnali di saturazione.

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