Välkommen
Välkommen
En flotta på webbskala innehåller många maskiner. Vid varje tillfälle är vissa friska, vissa startar, vissa dräneras och vissa är tysta sönder. Flottan överlever detta eftersom varje maskin besvarar två enkla frågor på begäran:
- /health — kan jag just nu hantera riktiga förfrågningar?
- /version — vilken kod kör jag?
Pluss en metrikendpoint (vanligtvis /metrics) som exponerar räknare och mätare för att övervakningsverktyg ska kunna skrapa.
Denna lektion lär dig hur man designar dessa endpoints så att de faktiskt speglar verkligheten, vad de fyra guldsignalerna betyder på en proxy-nivå, och hur observerad data driver kapacitetsbeslut.
Till slut kommer du att:
- Designa en /health-endpoint som upptäcker verkliga fel i spåren, inte bara processlevnad
- Designa en /version-endpoint som låter dig verifiera att en deployment har landat
- Tillämpa de fyra guldsignalerna (latens, trafik, fel, mättnad) på en proxy-nivå
- Koppla observerade spikar i metriker till kapacitetsbeslut: när man ska skala upp, när man ska töra, när man ska ringa
- Resonera om SLO:er och förbränningshastighet för felbudget som den operativa disciplinen bakom 'hur mycket bryr vi oss om?'
De två typerna av hälsokontroll
Liveness vs Readiness
Liveness: Är processen i liv i allmänhet? Används av orkestratorer (Kubernetes, systemd) för att bestämma om processen ska startas om.
Readiness: Är processen redo att hantera verklig trafik just nu? Används av lastbalanserare för att bestämma om begäranden ska skickas.
Detta är olika frågor. En process som är i liv men inte kan nå sin databas är i liv men inte redo. En process som startar är i liv men inte ännu redo.
Shallow vs Deep Health Checks
Shallow: Returnerar {"status": "ok"} om HTTP-hanteraren körs. Trivialt. Detekterar endast om processen är nere.
Deep: Överar faktiskt den verkliga begärandsvägen. Kontrollerar att databasanslutningens pool kan returnera en anslutning, att cachen är nåbar och att nedströma beroenden svarar. Detekterar funktionella avbrott som shallow-kontroller missar.
Avvägningen: djupare kontroller kostar mer (varje kontroll är i praktiken en syntetisk begäran) & kan orsaka kaskadfeil (om varje replikas hälsokontroll bombarderar databasen, gör en långsam databas att alla replikor blir ohälsosamma, vilket tar bort dem från rotationen, vilket i sin tur tar bort all kapacitet).
Bästa praxis: en ytlig kontroll för livskraft (långsam, billig, utan externa beroenden) & en djupare kontroll för beredskap (cachelagrade resultat, trottlat för att undvika att bombardera nedströmskomponenter).
Versionsändpunkter
/version returnerar git-kommiten, byggdatumet & tjänstens namn. Efter en deployment curl https://service.example.com/version & verifiera att den returnerade kommiten matchar det du skickade. Om det inte gör det, misslyckades deploymenten tyst.
Utan /version kan en föråldrad deployment se ut som lyckad & dölja sig i timmar.
Minimalt svarformat: {"service": "my-api", "git_commit": "abc1234", "build_time": "2026-05-19T10:00:00Z"}.
Latens, trafik, fel, mättnad
Fyra tal täcker de flesta driftfrågorna
Från boken Google SRE. Fyra signaler du mäter på varje tjänstenivå. Om du instrumenterar dessa fyra väl, fångar du de flesta produktionsproblem innan användarna gör det.
Latens: hur lång tid tar en begäran? Rapportera fördelningar, inte bara medelvärden. p99 (99:e percentilen för latens) är viktigare än medelvärdet, eftersom svanslatens är det som användare upplever som 'långsamt'. En tjänst med 50 ms medel och 5 000 ms p99 har ett verkligt problem som de flesta användare aldrig märker, men de 1 % som drabbas hårdast absolut märker.
Traffic: hur många begäranden per sekund? Totala begäranden, per endpoint, per statuskod, per region. Baslinjen är känd; varna vid avvikelser (plötsligt fall = ingångsproblem; plötslig ökning = ökning eller attack).
Fel: andel misslyckade begäranden. Skilj 4xx (klientfel, inte ditt fel) från 5xx (serverfel, ditt fel). Spara felprocenten som en procentandel av trafiken, inte som absoluta antal, så att varningar fungerar vid olika lastnivåer.
Mättnad: hur full är systemet? CPU-användning, minne, anslutningspoolens djup, köns längd. Den ledande indikatorn. Mättnaden ökar innan latens eller fel ökar. En nivå vid 90 % mättnad är ett dåligt minut bort från kökollaps.
Vid en proxy-nivå specifikt
Varje signal lyser upp i kantlagret:
- Latens vid proxyn: TLS-handskakningens varaktighet, uppströms anslutningstid, total begäran-svarstid. Mäts separat eftersom de finns på olika delar av vägen.
- Traffic vid proxyn: totala begäranden/sek, fördelning per backend (en het backend signalerar lastbalanser-skew), uppdelning per statuskod.
- Fel vid proxy: 4xx från klienter (dina användare som träffar felaktiga ändpunkter), 5xx från bakändar (dina tjänster som misslyckas), interna proxyfel (502 = bakändan är otillgänglig, 504 = bakändan har tidsgräns).
- Mättnad vid proxy: Antal TLS-sessioner, djupet på anslutningspoolen till upstream, CPU-användning vid själva proxy (TLS-avslutning är CPU-tung).
Proffstips: En plötslig ökning av 502:or med låg bakändelatenstid betyder att bakändan lägger upp innan den svarar (anslutning återställd, krasch, OOM). En ökning av 504:or betyder att bakändan är långsam men fortfarande svarar. Läs felkoden; den berättar var felet ligger.
Läs signalerna
Din instrumentpanel visar följande under de senaste 10 minuterna:
- Trafik: ungefär plan på 800 req/s (ingen ökning)
- Latenstid: p50 stabil på 40 ms, p99 steg från 200 ms till 2 500 ms under 5 minuter & är fortfarande på väg upp
- Fel: 4xx-nivån stabil på 0,3 % (normal bakgrundsnivå); 5xx-nivån steg från 0,1 % till 1,2 % (främst 504 Gateway Timeout)
- Mättnad: backend-CPU steg från 45 % till 78 % under samma 5 minuter; proxy-CPU stabil på 30 %
När ska man skala upp, när ska man tömma, när ska man larma
Kapacitetsbeslut kräver utlösare
Att observera metrik är enkelt. Att veta när man ska agera baserat på dem är disciplinet.
Skala upp när: mättnaden överskrider en beständig tröskel (t.ex. backend-CPU >70 % i 5 minuter), eller när ködjupet växer bortom ett mål, eller när latens p99 överskrider SLO:t. Utlösaren bör aktiveras innan saker går sönder, inte vid det ögonblicket.
Töm en replik när: den konsekvent är långsam eller ger fel medan grannar är friska (en replik som körs "het" är ofta ett problem på värdnivå, inte ett applikationsproblem), eller vid en rullande utgivning av en ny version, eller vid en ordnad nedläggning av en replik.
Larma en människa när: ett SLO bränns snabbare än vad felbudgeten klarar av, eller när en mättnadströskel aktiveras utan att autoskalning absorberar det, eller när ett kaskadmönster syns (både felrate och retry-rate stiger).
Larma inte när: en enskild dålig minut löser sig själv, eller när bakgrundsbatchjobb orsakar förväntade periodiska fluktuationer, eller när brus överskrider tröskeln (tröskeln är felaktig, inte systemet).
SLO:er och felbudgetförbrukning
En SLO (service level objective) definierar acceptabel prestanda: 'framgångsgrad >= 99,9 % över ett 28-dagarsfönster'. Komplementet (0,1 %) är felbudgeten.
Förbrukningstakt (burn rate): hur snabbt du förbrukar felbudgeten. Om du förbrukar 10 % av budgeten på 1 timme, är takten 240 gånger snabbare än vad som är hållbart (1 timme är 1/672 av ett 28-dagarsfönster; att förbruka 10 % under det fönstret = 10 % × 672 = 6 720 % projicerat för hela fönstret, när endast 100 % är tillåtet).
Alerts baserade på förbrukningstakt i flera fönster: skicka larm när både ett kort fönster (5 minuter vid 14,4-gångig takt) och ett långt fönster (1 timme vid 6-gångig takt) förbrukar snabbare än vad som är hållbart. Det fångar både snabba avbrott och långsamma prestandaförsämringar.
Varför detta är viktigt för kapacitet: En tjänst som körs med en SLO på 99,9 % och 1 % marginal kan absorbera mindre avbrott. En tjänst på 99,93 % (som knappt uppfyller SLO:en) är bara en dålig dag från att bryta mot målet. Kapacitetsbeslut bör sikta mot en bekväm SLO-marginal, inte det minimum som uppfyller den.
Ett kapacitetsbeslut under observation
Din tjänst har en SLO på 99,9 % lyckade förfrågningar över 28 dagar. Aktuellt tillstånd från övervakningen under den senaste timmen:
- Framgångsgrad: 99,5 % (upprätthållen i 30 minuter)
- Backend-CPU: genomsnittligt 82 % över hela flottan (mål 70 %)
- p99-lägg: 800 ms (SLO-mål: <500 ms)
- Trafik: 1 400 req/s, upp från baslinjen 1 000 req/s (40 % över normalt; trenden är fortfarande stigande)
- Autoskalning: konfigurerad att lägga till repliker när CPU > 80 % under 5 minuter; just nu pågår en uppskalning som kommer att lägga till 3 repliker på ca 90 sekunder
Designa en plan för observabilitet vid lansering
Syntes
Du kan nu designa en /health-endpoint som fångar verkliga fel, en /version-endpoint som låter dig verifiera utskick, dashboards baserade på de fyra guldstandarderna på proxy-nivå samt kapacitetsutlösare kopplade till SLO-förbrukningshastighet.
Tillämpa alla fyra.
Ditt team lanserar search.example.com (sökservicen från lektionen om felmoder). Teamet vill leverera observabilitet som fångar problem innan användarna märker av dem, med en tydlig matris för beslut om eskalering eller ej. SLO: 99,9 % lyckade förfrågningar, p99-lägre än 300 ms, över ett 28-dagarsfönster.
Avslutning av kursen
Avslutning av kursen
Du har slutfört alla fem lektioner:
- Proxys & Ursprung: den kantlagerstruktur som nästan alla publika webbtjänster använder
- Statelös horisontell skalning: varför ett statelöst lager multipliceras billigt & hur man dimensionerar det
- Separation av inkommande & utgående trafik: varför en enhet blir två, & det felaktiga beteendet som tvingar fram det
- Felaktiga beteenden & påverkningsområde: enskilda felkällor, kaskader, efteranalys, skuldfrifri åtgärder
- Observabilitet & kapacitet (denna): vad man ska mäta så att problem upptäcks innan användare märker av dem
Genomgående tråd: ett webbskalat distribuerat system är inte magi. Det är en liten uppsättning mönster (omvänd proxy, statelösa repliker, inkommande/utgående separation, bulkheads & kretsavbrytare, fyra guldstandarder) som komponeras med omsorg. När du känner igen mönstren ser du dem i varje produktionsarkitektur.
Sällskapslektioner: fem geometri-av-*-lektioner omformulerar samma material som grafteori & geometri. De fungerar bra i vilken ordning som helst.
Bra jobbat.