Välkomna
Välkomna
En webb-skala flotta innehåller många maskiner. I vilket ögonblick som helst är några friska, några startar, några dränerar, några tysta borta. Flottan överlever detta eftersom varje maskin svarar på två enkla frågor på begäran:
- /health — är jag just nu i stånd att hantera verkliga begäranden?
- /version — vilken kod kör jag?
Plus en mätändpunkt (vanligtvis /metrics) som exponerar räknare & indikatorer för övervakningsverktyg att skrapa.
Denna lektion lär dig hur du designar dessa ändpunkter så att de faktiskt speglar verkligheten, vad de fyra gyllene signalerna innebär på en proxy-nivå, & hur observerad data driver kapacitetsbeslut.
Efter avslutad kurs kommer du att:
- Designa en /health ändpunkt som detekterar verklig väg-fel, inte bara process-befinnande
- Designa en /version ändpunkt som låter dig verifiera att en deploy landat
- Tillämpa de fyra gyllene signalerna (svarstid, trafik, fel, översättning) på en proxy-nivå
- Koppla observerade överskottsmätningar till kapacitetsbeslut: när man ska skala upp, när man ska dränera, när man ska ringa
- Fundera över SLO:er & felbudgetens förbrukningshastighet som den operativa disciplinen bakom 'hur mycket bryr vi oss?'
De Båda Hälsokontrollerna
Livskraftig vs Beredskap
Livskraftig: är processen levande överhuvudtaget? Används av orkestrerare (Kubernetes, systemd) för att bestämma om processen ska startas om igen.
Beredskap: är processen redo att hantera verkliga begäranden just nu? Används av lastbalanserare för att bestämma om begärandena ska skickas.
Detta är olika frågor. En process som är levande men inte kan nå sin databas är levande men inte redo. En process som startar upp är levande men ännu inte redo.
Ytlig vs Djupgående Hälsokontroller
Ytlig: returnerar {"status": "ok"} om HTTP-hanteraren kör. Enkel. Detekterar endast process-ned.
Djup: faktiskt utövar den verkliga begäran. Kontrollerar att databasanslutningspoolen kan returnera en anslutning, att cachén är tillgänglig och att beroenden svarar nedströms. Upptäcker funktionella utslag som skalsmissar.
Avvägningen: djupa kontroller kostar mer (varje en kostar i praktiken en syntetisk begäran) & kan orsaka kaskaderande fel (om varje replikas hälsokontroll slår till mot databasen, blir en långsam databas otäck för alla repliker, vilket tar bort dem från rotationsgruppen, vilket tar bort alla kapacitet).
Bästa praxis: ett ytligt kontroll för livsdrift (snabbt, billigt, utan externa beroenden) & ett djupare kontroll för redo (cachade resultat, dämpad för att undvika att slå ned på nedströms).
Version Endpoint
/version returnerar git-commit, byggtid och tjänstnamn. Efter en distribution kollar du curl https://service.example.com/version och bekräftar att det returnerade commit-märket matchar det du skickade. Om det inte gör det, lyckades distributionen tyst.
Utan /version, kan en gammal distribution se ut att lyckas och dölja sig i timmar.
Minsta svarsshape: {"service": "my-api", "git_commit": "abc1234", "build_time": "2026-05-19T10:00:00Z"}.
Latens, Traffic, Fel, Överbelastning
Fyra Siffror täcker flest av Operativet
Från Google SRE-boken. Fyra signaler du mäter på varje tjänstnivå. Om du instrumenterar dessa fyra väl, upptäcker du flest produktionproblem innan användarna gör.
Latens: hur lång tid tar en begäran? Rapportera distributioner, inte bara genomsnitt. P99 (99-teilen latens) är viktigare än medelvärdet, eftersom svanslatens känns av användare som 'såg'. En tjänst med 50 ms genomsnitt och 5,000 ms p99 har ett verkligt problem som de sämst drabbade 1% absolut känner men de flesta andra aldrig märker.
Traffic: hur många begäranden per sekund? Totala begäranden, per-slutpunkt, per-statuskod, per-region. Baslinje känd; alerta på avvikelser (oförändrad drop = ingångsproblem; oförändrad spik = storm eller attack).
Fel: sändningshastighet för misslyckade begäranden. Skilj mellan 4xx (klientfel, inte ditt fel) från 5xx (serverfel, ditt fel). Följ felhastigheten som en procentandel av trafiken, inte som absoluta siffror, så att varningar fungerar över lastnivåer.
Mättnad: hur full är systemet? CPU-utnyttjande, minne, anslutningspoolens djup, kölngd. Ledande indikator. Mättnaden ökar före latens- eller felproblem försämrar sig. En skikt på 90% mättnad är ett dåligt minut bort från kollaps av köer.
Specifikt för en Proxy-skikt
Varje signal tänds upp vid kantlagret:
- Latens på proxy-nivå: TLS-händerstid, upstream-anslutningstid, begäran-svarstotal. Separat mätning eftersom de finns på olika delar av vägen.
- Trafik på proxy-nivå: totalt begäranden per sekund, per-backend-fördelning (ett varmt backend signalerar obalans i lastbalanseraren), per-statuskod-förändring.
- Fel på proxy-nivå: 4xx från klienter (dina användare som träffar fel slutpunkter), 5xx från backends (dina tjänster som misslyckas), proxy-inre fel (502 = bakomliggande osågbar, 504 = bakomliggande timeout).
- Mättnad på proxy-nivå: TLS-sessioner, upstream-anslutningspoolens djup, CPU på proxy (TLS-avslutning är CPU-intensiv).
Pro-tip: en plötslig ökning av 502:or med låg backend-latens innebär att backend-hanteringen avbryts innan svar (anslutning avbruten, krasch, out of memory). En ökning av 504:or innebär att backend är långsam men fortfarande svarar.
Läs signalerna
Din dashboard visar följande de senaste 10 minuterna:
- Trafik: ungefär oförändrad vid 800 begäranden per sekund (inga stormningar)
- Latens: p50 stabil vid 40 ms, p99 steg från 200 ms till 2 500 ms under 5 minuter och fortsätter fortfarande att öka
- Fel: 4xx-säkerheten stabil vid 0,3% (normal bakgrund); 5xx-säkerheten steg från 0,1% till 1,2% (huvudsakligen 504 Gateway Timeout)
- Mättnad: backend-CPU steg från 45% till 78% under samma 5 minuter; proxy-CPU stabil vid 30%
När du ska skala, när du ska tömma, när du ska ringa
Kapacitetsbeslut kräver utlösare
Att mata metriker är lätt. Att veta när man ska agera på dem är disciplinen.
Skala upp när: sättning överskrider en bestående tröskel (t.ex. bakre CPU >70% i 5 minuter), eller ködjup växer bortom ett mål, eller latens p99 överskrider SLO. Utlösningen bör dra igång innan saker och ting går sönder, inte just då de går sönder.
Draina en replika när: den är konsekvent långsam/felaktig medan grannar är friska (en replika som går het är ofta ett problem på servrariv, inte ett programproblem), eller när man lanserar en ny version, eller när man försiktigt lägger ner en replik.
Väcka en människa när: SLO-bryts ned snabbare än felbudget kan bibehållas, eller en sättningstriggre drar igång utan att autoskalning absorberar det, eller ett kaskadmönster uppstår (felfrekvens + omstartsfrekvens båda stiger).
Väck inte när: en enda dålig minut löser sig själv, eller bakgrundsbatchjobb orsakar förväntade periodiska glipor, eller brus överskrider tröskeln (tröskeln är fel, inte systemet).
SLOs & Felbudgets Brytning
En SLO (tjänstnivåmål) definierar acceptabel prestanda: 'lyckade begäranden >= 99,9% under en 28-dagars period'. Komplementet (0,1%) är felbudgeten.
Brytningshastighet: hur snabbt du konsumerar felbudgeten. Om du bryter 10% av budgeten på 1 timme är hastigheten 240 gånger snabbare än hållbar (1 timme är 1/672 av en 28-dagars period; att bryta 10% i den perioden = 10% × 672 = 6720% beräknat för hela perioden, när bara 100% är tillåtet).
Flermåneders brytningshastighet: väck när både en kort period (5 minuter på 14,4x hastighet) & en lång period (1 timme på 6x hastighet) bryts snabbare än hållbar. Fångar både snabba utslag och långsamma försämringar.
Varför det är viktigt för kapacitet: en tjänst som kör på 99,9% SLO med 1% luftgång kan absorbera mindre glipor. En tjänst på 99,93% ( precis inom SLO) är en enda dålig dag ifrån överträdelse. Kapacitetsbeslut bör rikta sig mot ett bekvämt SLO-marginal, inte det minsta som uppfyller det.
En Kapacitetsbeslut Under Observation
Din tjänst har en SLO på 99,9% lyckade begäranden över 28 dagar. Aktuell status från övervakning de senaste 60 minuterna:
- Lyckandegrad: 99,5% (bestående i 30 minuter)
- Bakre CPU: genomsnitt 82% över flottan (målmål 70%)
- p99-latens: 800 ms (målmål: <500 ms)
- Trafik: 1,400 begäranden/s, upp från baslinjen 1,000 begäranden/s (40% över normalnivå; trend fortsätter att öka)
- Autoscaling: konfigurerad för att lägga till repliker när CPU > 80% underhålls i 5 minuter; pågår just nu en skalning upp som kommer att lägga till 3 repliker inom ~90 sekunder
Designa en Lanseringsövervakningsplan
Sammanfattning
Du kan nu designa en /health som fångar verkliga fel, en /version som låter dig verifiera distribueringar, fyra gyllene signal-dashboards på proxy-nivå & kapacitetstrigger kopplade till SLO-bildningshastighet.
Använd alla fyra.
Ditt lag lanserar search.example.com (söktjänsten från förmåga att hantera fel-lektionen). Laget vill skippa övervakning som upptäcker problem före användare gör, med en tydlig sida-eller-inte-beslutsmatris. SLO: 99,9% lyckade begäranden, p99-latency < 300 ms, över en 28-dagars period.
Avsluta kursen
Avsluta kursen
Du har slutfört alla fem lektioner:
- Proxies & Origins: kantringsskiktet som nästan varje offentlig webbtjänst använder
- Stateless Horizontal Scaling: varför ett statlöst skikt multipliceras billigt & hur man dimensionerar det
- Ingress & Egress Separation: varför en box blir två & vilken felmod som tvingar det
- Failure Modes & Blast Radius: SPOFs, kaskader, postmortems, skuldslösa åtgärder
- Observability & Capacity (denna): vilka mått man ska mäta så att problem upptäcks innan användare gör det
Genomgången: En webb-skala distribuerad system är inte magi. Det är en liten uppsättning mönster (omvänd proxy, statlösa repliker, ingress/egress split, bulkheads & säkerhetskopieringskopplingar, fyra guldindikatorer) som satts samman med tanke. När du känner igen mönstren ser du dem i varje produktionarkitektur.
Kompletterande lektioner: Fem geometry-of-* lektioner omformulerar samma material som grafteori och geometri. De passar lika bra i vilken ordning som helst.
Bra gjort.