Benvenuto
Benvenuto
Una flotta di scala web contiene molte macchine. In qualsiasi momento, alcune sono sane, alcune si stanno avviando, alcune stanno scaricando il traffico e altre sono silenziosamente guaste. La flotta sopravvive a questo perché ogni macchina risponde a due semplici domande su richiesta:
- /health — sono attualmente in grado di gestire richieste reali?
- /version — quale codice sto eseguendo?
Più un endpoint di metriche (comune /metrics) che espone contatori e gauge per gli strumenti di monitoraggio da raccogliere.
Questa lezione insegna come progettare questi endpoint affinché riflettano effettivamente la realtà, cosa significano i quattro segnali d'oro a livello di proxy e come i dati osservati guidino le decisioni sulla capacità.
Al termine avrai imparato a:
- Progettare un endpoint /health che rilevi il guasto reale del percorso, non solo la vitalità del processo
- Progettare un endpoint /version che ti permetta di verificare che una distribuzione sia avvenuta
- Applicare i quattro segnali d'oro (latenza, traffico, errori, saturazione) a livello di proxy
- Collegare le metriche di picco osservate alle decisioni sulla capacità: quando scalare verso l'alto, quando scaricare, quando inviare notifiche di emergenza
- Ragionare sugli SLO e sul tasso di consumo del budget di errore come disciplina operativa dietro la domanda "quanto ci importa?"
I due tipi di controllo di salute
Liveness vs Readiness
Liveness: il processo è vivo? Utilizzato dagli orchestratori (Kubernetes, systemd) per decidere se riavviare il processo.
Readiness: il processo è pronto a gestire traffico reale in questo momento? Utilizzato dai bilanciatori di carico per decidere se inviare richieste.
Queste sono domande diverse. Un processo che è vivo ma non può raggiungere il proprio database è vivo ma non pronto. Un processo che si sta avviando è vivo ma non ancora pronto.
Controlli di salute superficiali vs approfonditi
Superficiale: restituisce {"status": "ok"} se il gestore HTTP funziona. Triviale. Rileva solo l'arresto del processo.
Approfondito: esercita effettivamente il percorso della richiesta reale. Verifica che la pool di connessioni al database possa restituire una connessione, che la cache sia raggiungibile e che le dipendenze a valle rispondano. Rileva interruzioni funzionali che i controlli superficiali non individuano.
Il compromesso: i controlli approfonditi costano di più (ciascuno è essenzialmente una richiesta sintetica) e possono causare un fallimento a cascata (se il controllo di salute di ogni replica martella il database, un database lento rende tutte le repliche non sane, il che le rimuove dalla rotazione, eliminando così tutta la capacità).
Buona pratica: un controllo superficiale per la vitalità (rapido, economico, senza dipendenze esterne) e un controllo più approfondito per la prontezza (risultati in cache, con limitazione della frequenza per evitare di sovraccaricare i servizi a valle).
Endpoint di Versione
/version restituisce il commit git, l'ora di build e il nome del servizio. Dopo un deploy, si esegue curl https://service.example.com/version e si verifica che il commit restituito corrisponda a quello spinto. Se non corrisponde, il deploy è fallito in silenzio.
Senza /version, un deploy obsoleto può apparire riuscito e restare nascosto per ore.
Formato di risposta minimo: {"service": "my-api", "git_commit": "abc1234", "build_time": "2026-05-19T10:00:00Z"}.
Latenza, Traffico, Errori, Saturazione
Quattro Numeri Coprono la Maggior Parte delle Operazioni
Dal libro Google SRE. Quattro segnali che misuri su ogni livello di servizio. Se monitori bene questi quattro, cattivi la maggior parte dei problemi di produzione prima che lo facciano gli utenti.
Latenza: quanto tempo richiede una richiesta? Riporta distribuzioni, non solo medie. La p99 (latenza al 99° percentile) è più importante della media, perché la latenza di coda è ciò che gli utenti percepiscono come 'lento'. Un servizio con una media di 50 ms e una p99 di 5.000 ms ha un problema reale che la maggior parte degli utenti non nota mai, ma che l'1% più colpito lo percepisce assolutamente.
Traffico: quante richieste al secondo? Richieste totali, per endpoint, per codice di stato, per regione. Baseline nota; allerta su anomalie (calo improvviso = problema di ingresso; picco improvviso = afflusso o attacco).
Errori: tasso di richieste fallite. Distingui 4xx (errori del client, non colpa tua) da 5xx (errori del server, colpa tua). Traccia il tasso di errore come percentuale del traffico, non come conteggi assoluti, in modo che le allerte funzionino a diversi livelli di carico.
Saturazione: quanto è pieno il sistema? Utilizzo CPU, memoria, profondità della pool di connessioni, lunghezza della coda. L'indicatore anticipato. La saturazione aumenta prima che la latenza o gli errori peggiorino. Un tier al 90% di saturazione è a un minuto cattivo di distanza dal collasso della coda.
Specificamente a un livello Proxy
Ogni segnale si accende al livello edge:
- Latenza al proxy: durata della handshake TLS, tempo di connessione upstream, totale richiesta-risposta. Misurati separatamente perché si trovano in parti diverse del percorso.
- Traffico al proxy: richieste totali/sec, distribuzione per backend (un backend caldo segnala uno squilibrio del load balancer), ripartizione per codice di stato.
- Errori al proxy: 4xx dai client (i tuoi utenti che colpiscono endpoint errati), 5xx dai backend (i tuoi servizi che falliscono), errori interni al proxy (502 = backend non raggiungibile, 504 = timeout del backend).
- Saturazione al proxy: numero di sessioni TLS, profondità della pool di connessioni upstream, CPU del proxy stesso (la terminazione TLS è intensiva in termini di CPU).
Consiglio pratico: un improvviso aumento dei 502 con bassa latenza del backend significa che il backend sta chiudendo la connessione prima di rispondere (reset della connessione, crash, OOM). Un aumento dei 504 significa che il backend è lento ma sta ancora rispondendo. Leggi il codice di errore; ti dice dove si trova il guasto.
Leggere i Segnali
La tua dashboard mostra quanto segue negli ultimi 10 minuti:
- Traffico: approssimativamente stabile a 800 req/s (nessun picco)
- Latenza: p50 stabile a 40ms, p99 è salita da 200ms a 2.500ms in 5 minuti ed è ancora in aumento
- Errori: tasso 4xx stabile al 0,3% (normale di fondo); tasso 5xx salito dallo 0,1% all'1,2% (prevalentemente 504 Gateway Timeout)
- Saturazione: CPU del backend salita dal 45% al 78% negli stessi 5 minuti; CPU del proxy stabile al 30%
Quando Scalare, Quando Svuotare, Quando Avvisare
Le decisioni sulla capacità richiedono trigger
Osservare le metriche è facile. Sapere quando agire su di esse è la disciplina.
Scala verso l'alto quando: la saturazione supera una soglia sostenuta (ad es., CPU del backend >70% per 5 minuti), o la profondità della coda cresce oltre un obiettivo, o la latenza p99 supera l'SLO. Il trigger dovrebbe attivarsi prima che le cose si rompano, non al momento della rottura.
Svuota un replica quando: è costantemente lento / soggetto a errori mentre i pari sono sani (un replica che funziona a pieno regime è spesso un problema a livello di host, non un problema dell'applicazione), o quando si sta distribuendo una nuova versione, o quando si sta ritirando un replica in modo graduale.
Avvisa un umano quando: uno SLO viene consumato più velocemente di quanto il budget di errore possa sostenere, o un trigger di saturazione si attiva senza che l'autoscaling lo assorba, o appare un modello a cascata (tasso di errore + tasso di retry entrambi in aumento).
Non avvisare quando: un singolo minuto difettoso si risolve da solo, o i lavori batch in background causano fluttuazioni periodiche attese, o il rumore supera la soglia (la soglia è errata, non il sistema).
SLO e consumo del budget di errore
Un SLO (Service Level Objective) definisce le prestazioni accettabili: 'tasso di successo >= 99,9% su una finestra di 28 giorni'. Il complemento (0,1%) è il budget di errore.
Tasso di consumo (burn rate): la velocità con cui si sta consumando il budget di errore. Se si consuma il 10% del budget in 1 ora, il tasso è 240 volte più rapido rispetto a quello sostenibile (1 ora è 1/672 di una finestra di 28 giorni; consumare il 10% in quella finestra = 10% × 672 = 6720% proiettato per l'intera finestra, quando è consentito solo il 100%).
Allarmi multi-finestra basati sul tasso di consumo: inviano una notifica (page) quando sia una finestra breve (5 minuti a un tasso di 14,4x) sia una finestra lunga (1 ora a un tasso di 6x) consumano il budget più velocemente del ritmo sostenibile. Rileva sia gli interruzioni rapide sia le degradazioni lente.
Perché questo è importante per la capacità: un servizio che opera con un SLO del 99,9% e un margine di sicurezza dell'1% può assorbire piccoli imprevisti. Un servizio al 99,93% (che soddisfa l'SLO solo di poco) è a un solo giorno negativo dal violare l'obiettivo. Le decisioni sulla capacità dovrebbero puntare a un margine SLO confortevole, non al minimo necessario per soddisfarlo.
Una decisione sulla capacità sotto osservazione
Il tuo servizio ha un SLO del 99,9% di richieste riuscite su 28 giorni. Stato attuale derivato dal monitoraggio dell'ultima ora:
- Tasso di successo: 99,5% (sostenuto per 30 minuti)
- CPU del backend: media dell'82% su tutta la flotta (obiettivo 70%)
- Latenza p99: 800 ms (obiettivo SLO: <500 ms)
- Traffico: 1.400 req/s, in aumento rispetto alla baseline di 1.000 req/s (40% sopra la norma; la tendenza è ancora in crescita)
- Autoscaling: configurato per aggiungere repliche quando la CPU supera l'80% per 5 minuti consecutivi; attualmente è in corso un'operazione di scale-up che aggiungerà 3 repliche in circa 90 secondi
Progetta un piano di osservabilità per il lancio
Sintesi
Ora puoi progettare un /health che rileva guasti reali, un /version che ti consente di verificare i deploy, dashboard a quattro segnali d'oro a livello di proxy e trigger di capacità legati al tasso di consumo degli SLO.
Applica tutti e quattro.
Il tuo team sta lanciando search.example.com (il servizio di ricerca della lezione sui modi di guasto). Il team vuole rilasciare un'osservabilità che rilevi i problemi prima degli utenti, con una chiara matrice decisionale per l'invio di alert. SLO: 99,9% di richieste riuscite, latenza p99 < 300 ms, su una finestra di 28 giorni.
Chiusura del corso
Chiusura del corso
Hai completato tutte e cinque le lezioni:
- Proxy e Origini: la forma dello strato di edge utilizzata da quasi tutti i servizi web pubblici
- Scalabilità Orizzontale Stateless: perché un livello stateless si moltiplica a basso costo e come dimensionarlo
- Separazione Ingresso e Uscita: perché un singolo nodo diventa due, e la modalità di guasto che lo impone
- Modalità di Guasto e Raggio d'Impatto: SPOF, cascate, postmortem, azioni correttive senza colpevolizzazioni
- Osservabilità e Capacità (questo argomento): cosa misurare affinché i problemi emergano prima che lo facciano gli utenti
Il filo conduttore: un sistema distribuito su scala web non è magia. È un piccolo insieme di pattern (proxy inverso, repliche stateless, separazione ingresso/uscita, bulkhead e circuit breaker, quattro segnali d'oro) composti con cura. Una volta riconosciuti i pattern, li si nota in ogni architettura di produzione.
Lezioni complementari: cinque lezioni sulla geometria-* ricalcano lo stesso materiale come teoria dei grafi e geometria. Funzionano bene in entrambi gli ordini.
Ben fatto.