SRE (Site Reliability Engineering) är ett tillvägagångssätt för att göra webbprojekt tillgängliga. Det anses vara ett ramverk för DevOps och berättar hur man lyckas med tillämpningen av DevOps-praxis. Denna artikel översätts böcker från Google. Jag förberedde den här översättningen själv och förlitade mig på min egen erfarenhet av att förstå övervakningsprocesser. I telegramkanalen и Jag publicerade också en översättning av kapitel 6 i samma bok om servicenivåmål.
Översättning av katt. Njut av att läsa!
Det är omöjligt att hantera en tjänst om det inte finns någon förståelse för vilka indikatorer som faktiskt spelar roll och hur man mäter och utvärderar dem. För detta ändamål definierar och tillhandahåller vi en viss servicenivå till våra användare, oavsett om de använder en av våra interna API:er eller en offentlig produkt.
Vi använder vår intuition, erfarenhet och förståelse för användarnas önskan att förstå Service Level Indicators (SLIs), Service Level Objectives (SLOs) och Service Level Agreements (SLAs). Dessa dimensioner beskriver de viktigaste mätvärdena som vi vill övervaka och som vi kommer att reagera på om vi inte kan tillhandahålla den förväntade kvaliteten på tjänsten. I slutändan hjälper det att välja rätt mätvärden vägleda rätt åtgärder om något går fel och ger också SRE-teamet förtroende för tjänstens hälsa.
Det här kapitlet beskriver det tillvägagångssätt vi använder för att bekämpa problemen med metrisk modellering, metriskt urval och metrisk analys. Det mesta av förklaringen kommer att vara utan exempel, så vi kommer att använda Shakespeare-tjänsten som beskrivs i dess implementeringsexempel (sök efter Shakespeares verk) för att illustrera huvudpunkterna.
Terminologi på servicenivå
Många läsare är sannolikt bekanta med begreppet SLA, men termerna SLI och SLO förtjänar en noggrann definition eftersom termen SLA i allmänhet är överbelastad och har ett antal betydelser beroende på sammanhanget. För tydlighetens skull vill vi skilja dessa värden åt.
Indikatorer
SLI är en servicenivåindikator – ett noggrant definierat kvantitativt mått på en aspekt av tjänstenivån.
För de flesta tjänster anses nyckel-SLI vara fördröjningsfördröjning - hur lång tid det tar att returnera ett svar på en förfrågan. Andra vanliga SLI:er inkluderar felfrekvens, ofta uttryckt som en bråkdel av alla mottagna förfrågningar, och systemgenomströmning, vanligtvis mätt i förfrågningar per sekund. Mätningar är ofta aggregerade: rådata samlas först in och omvandlas sedan till en förändringshastighet, medelvärde eller percentil.
Helst mäter SLI direkt servicenivån av intresse, men ibland är bara ett relaterat mått tillgängligt för mätning eftersom det ursprungliga är svårt att få eller tolka. Till exempel är latens på klientsidan ofta ett mer lämpligt mått, men det finns tillfällen då latens bara kan mätas på servern.
En annan typ av SLI som är viktig för SRE är tillgänglighet, eller den del av tiden under vilken en tjänst kan användas. Definieras ofta som andelen framgångsrika förfrågningar, ibland kallad avkastning. (Livstid – sannolikheten att data kommer att lagras under en längre tidsperiod – är också viktigt för datalagringssystem.) Även om 100 % tillgänglighet inte är möjlig, är tillgänglighet nära 100 % ofta möjlig; tillgänglighetsvärden uttrycks som antalet "nio" » procentandel av tillgänglighet. Till exempel kan 99 % och 99,999 % tillgänglighet märkas som "2 nior" och "5 nior". Google Compute Engines nuvarande angivna tillgänglighetsmål är "tre och en halv nio" eller 99,95 %.
mål
En SLO är ett servicenivåmål: ett målvärde eller värdeintervall för en servicenivå som mäts av SLI. Ett normalt värde för SLO är "SLI ≤ Target" eller "Lower Limit ≤ SLI ≤ Upper Limit". Till exempel kan vi besluta att vi ska returnera Shakespeares sökresultat "snabbt" genom att ställa in SLO på en genomsnittlig sökfrågefördröjning på mindre än 100 millisekunder.
Att välja rätt SLO är en komplex process. För det första kan du inte alltid välja ett specifikt värde. För externa inkommande HTTP-förfrågningar till din tjänst bestäms QPS-måttet (Query Per Second) främst av dina användares önskan att besöka din tjänst, och du kan inte ställa in en SLO för det.
Å andra sidan kan du säga att du vill att den genomsnittliga latensen för varje begäran ska vara mindre än 100 millisekunder. Att sätta ett sådant mål kan tvinga dig att skriva din frontend med låg latens eller köpa utrustning som ger sådan latens. (100 millisekunder är uppenbarligen ett godtyckligt tal, men det är bättre att ha ännu lägre latensnummer. Det finns bevis som tyder på att snabba hastigheter är bättre än låga hastigheter, och att latens vid bearbetning av användarförfrågningar över vissa värden faktiskt tvingar människor att hålla sig borta från din tjänst.)
Återigen, detta är mer tvetydigt än det kan verka vid första anblicken: du bör inte helt utesluta QPS från beräkningen. Faktum är att QPS och latens är starkt relaterade till varandra: högre QPS leder ofta till högre latenser, och tjänster upplever vanligtvis en kraftig minskning av prestanda när de når en viss belastningströskel.
Att välja och publicera en SLO sätter användarnas förväntningar på hur tjänsten kommer att fungera. Denna strategi kan minska ogrundade klagomål mot tjänsteägaren, såsom långsam prestanda. Utan en explicit SLO skapar användarna ofta sina egna förväntningar på önskad prestanda, vilket kanske inte har något att göra med åsikterna från de personer som designar och hanterar tjänsten. Denna situation kan leda till uppblåsta förväntningar på tjänsten, när användare av misstag tror att tjänsten kommer att vara mer tillgänglig än den faktiskt är, och orsaka misstro när användarna tror att systemet är mindre tillförlitligt än det faktiskt är.
Avtal
Ett servicenivåavtal är ett explicit eller implicit avtal med dina användare som inkluderar konsekvenserna av att uppfylla (eller inte uppfylla) de SLO:er de innehåller. Konsekvenser är lättast att känna igen när de är ekonomiska – en rabatt eller böter – men de kan ta andra former. Ett enkelt sätt att prata om skillnaden mellan SLO och SLA är att fråga "vad händer om SLOs inte uppfylls?" Om det inte finns några tydliga konsekvenser, tittar du nästan säkert på en SLO.
SRE är vanligtvis inte involverad i att skapa SLA eftersom SLA är nära knutna till affärs- och produktbeslut. SRE är dock involverad i att hjälpa till att mildra konsekvenserna av misslyckade SLO:er. De kan också hjälpa till att fastställa SLI: Självklart måste det finnas ett objektivt sätt att mäta SLO i avtalet, annars kommer det att uppstå oenighet.
Google Sök är ett exempel på en viktig tjänst som inte har ett offentligt SLA: vi vill att alla ska använda Sök så effektivt som möjligt, men vi har inte tecknat något kontrakt med världen. Det finns dock fortfarande konsekvenser om sökningen inte är tillgänglig - otillgänglighet leder till ett sämre rykte och minskade annonsintäkter. Många andra Google-tjänster, som Google for Work, har uttryckliga servicenivåavtal med användare. Oavsett om en viss tjänst har ett SLA är det viktigt att definiera SLI och SLO och använda dem för att hantera tjänsten.
Så mycket teori - nu att uppleva.
Indikatorer i praktiken
Med tanke på att vi har kommit fram till att det är viktigt att välja lämpliga mått för att mäta servicenivå, hur vet du nu vilka mått som är viktiga för en tjänst eller ett system?
Vad bryr du dig och dina användare om?
Du behöver inte använda varje mätvärde som en SLI som du kan spåra i ett övervakningssystem; Att förstå vad användarna vill ha av ett system hjälper dig att välja flera mätvärden. Att välja för många indikatorer gör det svårt att fokusera på viktiga indikatorer, medan att välja ett litet antal kan lämna stora delar av ditt system utan uppsikt. Vi använder vanligtvis flera nyckelindikatorer för att utvärdera och förstå ett systems hälsa.
Tjänster kan i allmänhet delas upp i flera delar i termer av SLI som är relevanta för dem:
- Anpassade front-end-system, som sökgränssnitten för Shakespeare-tjänsten från vårt exempel. De måste vara tillgängliga, inte ha några förseningar och ha tillräcklig bandbredd. Följaktligen kan frågor ställas: kan vi svara på begäran? Hur lång tid tog det att svara på begäran? Hur många förfrågningar kan behandlas?
- Förvaringssystem. De värdesätter låg svarslatens, tillgänglighet och hållbarhet. Relaterade frågor: Hur lång tid tar det att läsa eller skriva data? Kan vi få tillgång till uppgifterna på begäran? Finns informationen tillgänglig när vi behöver den? Se kapitel 26 Dataintegritet: Vad du läser är vad du skriver för en detaljerad diskussion om dessa frågor.
- Big data-system som databehandlingspipelines förlitar sig på genomströmning och fördröjning av frågebehandling. Relaterade frågor: Hur mycket data behandlas? Hur lång tid tar det för data att färdas från att man tar emot en förfrågan till att man skickar ett svar? (Vissa delar av systemet kan också ha förseningar i vissa steg.)
Samling av indikatorer
Många servicenivåindikatorer samlas mest naturligt på serversidan, med hjälp av ett övervakningssystem som Borgmon (se nedan). ) eller Prometheus, eller helt enkelt periodvis analysera loggarna, identifiera HTTP-svar med status 500. Vissa system bör dock vara utrustade med insamling av mätvärden på klientsidan, eftersom bristen på övervakning på klientsidan kan leda till att ett antal problem som påverkar användare, men påverkar inte mätvärden på serversidan. Till exempel kan fokus på backend-svarslatens för vår Shakespeare-söktestapplikation resultera i latens på användarsidan på grund av JavaScript-problem: i det här fallet är det ett bättre mått att mäta hur lång tid det tar för webbläsaren att bearbeta sidan.
Aggregation
För enkelhetens och användarvänlighetens skull aggregerar vi ofta råmått. Detta måste göras noggrant.
Vissa mätvärden verkar enkla, som förfrågningar per sekund, men även denna till synes enkla mätning aggregerar implicit data över tiden. Mottages mätningen specifikt en gång per sekund eller beräknas mätningen i genomsnitt över antalet förfrågningar per minut? Det senare alternativet kan dölja ett mycket högre momentant antal förfrågningar som bara varar några sekunder. Tänk på ett system som betjänar 200 förfrågningar per sekund med jämna nummer och 0 resten av tiden. En konstant i form av ett medelvärde på 100 förfrågningar per sekund och två gånger den momentana belastningen är inte samma sak. På samma sätt kan medelvärdesberäkning av frågefördröjningar verka attraktivt, men det döljer en viktig detalj: det är möjligt att de flesta frågor kommer att vara snabba, men det kommer att finnas många frågor som är långsamma.
De flesta indikatorer ses bättre som fördelningar snarare än genomsnitt. Till exempel, för SLI-latens, kommer vissa förfrågningar att behandlas snabbt, medan vissa alltid tar längre tid, ibland mycket längre. Ett enkelt medelvärde kan dölja dessa långa förseningar. Bilden visar ett exempel: även om en typisk begäran tar ungefär 50 ms att leverera, är 5 % av förfrågningarna 20 gånger långsammare! Övervakning och varning endast baserat på genomsnittlig latens visar inte beteendeförändringar under dagen, när det faktiskt finns märkbara förändringar i bearbetningstiden för vissa förfrågningar (översta raden).
Systemlatens på 50, 85, 95 och 99 percentiler. Y-axeln är i logaritmiskt format.
Genom att använda percentiler för indikatorer kan du se formen på fördelningen och dess egenskaper: en hög percentilnivå, som 99 eller 99,9, visar det sämsta värdet, medan 50-percentilen (även känd som medianen) visar det vanligaste tillståndet av måtten. Ju större spridning av svarstid, desto mer långvariga förfrågningar påverkar användarupplevelsen. Effekten förstärks under hög belastning och i närvaro av köer. Undersökningar av användarupplevelser har visat att människor i allmänhet föredrar ett långsammare system med hög svarstidsvarians, så vissa SRE-team fokuserar endast på höga percentilpoäng, på grundval av att om ett måtts beteende vid 99,9 percentilen är bra, kommer de flesta användare inte att uppleva problem .
Anmärkning om statistiska fel
Vi föredrar i allmänhet att arbeta med percentiler snarare än medelvärdet (arithmetiskt medelvärde) av en uppsättning värden. Detta gör att vi kan överväga mer spridda värden, som ofta har betydligt annorlunda (och mer intressanta) egenskaper än genomsnittet. På grund av datorsystemens artificiella natur är metriska värden ofta snedställda, till exempel kan ingen förfrågan få ett svar på mindre än 0 ms, och en timeout på 1000 ms betyder att det inte kan bli framgångsrika svar med värden högre än timeouten. Som ett resultat kan vi inte acceptera att medelvärde och median kan vara lika eller nära varandra!
Utan föregående testning, och om inte vissa standardantaganden och uppskattningar håller, är vi noga med att inte dra slutsatsen att vår data är normalt distribuerad. Om distributionen inte är som förväntat kan automatiseringsprocessen som åtgärdar problemet (till exempel när den ser extremvärden startar om servern med höga fördröjningstider för begäranden) göra det för ofta eller inte tillräckligt ofta (som båda inte gör det mycket bra).
Standardisera indikatorer
Vi rekommenderar att standardisera de allmänna egenskaperna för SLI så att du inte behöver spekulera om dem varje gång. Alla funktioner som uppfyller standardmönster kan uteslutas från specifikationen för en enskild SLI, till exempel:
- Aggregeringsintervall: "i genomsnitt över 1 minut"
- Aggregationsområden: "Alla uppgifter i klustret"
- Hur ofta mätningar görs: "Var 10:e sekund"
- Vilka förfrågningar ingår: "HTTP GET från svarta box-övervakningsjobb"
- Hur data erhålls: "Tack vare vår övervakning uppmätt på servern"
- Dataåtkomstfördröjning: "Tid till sista byte"
För att spara ansträngning, skapa en uppsättning återanvändbara SLI-mallar för varje gemensamt mått; de gör det också lättare för alla att förstå vad en viss SLI betyder.
Mål i praktiken
Börja med att tänka på (eller ta reda på!) vad dina användare bryr sig om, inte vad du kan mäta. Ofta är det svårt eller omöjligt att mäta vad dina användare bryr sig om, så det slutar med att du kommer närmare deras behov. Men om du bara börjar med det som är lätt att mäta, kommer du att sluta med mindre användbara SLOs. Som ett resultat har vi ibland funnit att det fungerar bättre att initialt identifiera önskade mål och sedan arbeta med specifika indikatorer än att välja indikatorer och sedan uppnå målen.
Definiera dina mål
För maximal tydlighet bör det definieras hur SLO:er mäts och under vilka villkor de är giltiga. Till exempel kan vi säga följande (den andra raden är densamma som den första, men använder SLI-standardvärdena):
- 99 % (i genomsnitt över 1 minut) av Get RPC-samtal kommer att slutföras på mindre än 100 ms (mätt på alla backend-servrar).
- 99 % av Get RPC-samtal kommer att slutföras på mindre än 100 ms.
Om formen på prestandakurvorna är viktig kan du ange flera SLO:er:
- 90 % av Få RPC-samtal slutförda på mindre än 1 ms.
- 99 % av Få RPC-samtal slutförda på mindre än 10 ms.
- 99.9 % av Få RPC-samtal slutförda på mindre än 100 ms.
Om dina användare genererar heterogena arbetsbelastningar: bulkbearbetning (för vilken genomströmning är viktig) och interaktiv bearbetning (för vilken latens är viktig), kan det vara värt att definiera separata mål för varje belastningsklass:
- 95 % av kundförfrågningarna kräver genomströmning. Ställ in antalet exekverade RPC-anrop <1 s.
- 99 % av kunderna bryr sig om latensen. Ställ in antalet RPC-samtal med trafik <1 KB och kör <10 ms.
Det är orealistiskt och oönskat att insistera på att SLOs kommer att uppfyllas 100 % av tiden: detta kan minska takten för att introducera ny funktionalitet och implementering och kräva dyra lösningar. Istället är det bättre att tillåta en felbudget – procentandelen av systemavbrottstid som tillåts – och övervaka detta värde dagligen eller veckovis. Ledningen kanske vill ha månatliga eller kvartalsvisa utvärderingar. (Felbudgeten är helt enkelt en SLO för jämförelse med en annan SLO.)
Andelen SLO-överträdelser kan jämföras med felbudgeten (se kapitel 3 och avsnitt ), med skillnadsvärdet som används som input till processen som bestämmer när nya versioner ska distribueras.
Välja målvärden
Att välja planeringsvärden (SLO) är inte en rent teknisk aktivitet på grund av produkt- och affärsintressena som måste återspeglas i de valda SLI:erna, SLO:erna (och eventuellt SLA). Likaså kan information behöva utbytas angående frågor som rör bemanning, time to market, utrustningstillgänglighet och finansiering. SRE bör vara en del av detta samtal och hjälpa till att förstå riskerna och livskraften med olika alternativ. Vi har kommit med några frågor som kan hjälpa till att säkerställa en mer produktiv diskussion:
Välj inte ett mål baserat på nuvarande prestation.
Även om det är viktigt att förstå styrkorna och gränserna för ett system, kan anpassning av mätvärden utan resonemang blockera dig från att underhålla systemet: det kommer att kräva heroiska ansträngningar för att uppnå mål som inte kan uppnås utan betydande omdesign.
Var enkel
Komplexa SLI-beräkningar kan dölja förändringar i systemets prestanda och göra det svårare att hitta orsaken till problemet.
Undvik absoluter
Även om det är frestande att ha ett system som kan hantera en oändligt växande belastning utan att öka latensen, är detta krav orealistiskt. Ett system som närmar sig sådana ideal kommer sannolikt att kräva mycket tid att designa och bygga, kommer att vara dyrt att använda och kommer att vara för bra för förväntningarna hos användare som skulle göra med något mindre.
Använd så få SLO som möjligt
Välj ett tillräckligt antal SLO:er för att säkerställa god täckning av systemattribut. Skydda de SLO:er du väljer: Om du aldrig kan vinna ett argument om prioriteringar genom att specificera en specifik SLO, är det förmodligen inte värt att överväga den SLO. Alla systemattribut är dock inte tillgängliga för SLO:er: det är svårt att beräkna nivån på användarglädje med SLO:er.
Jaga inte perfektion
Du kan alltid förfina definitionerna och målen för SLOs över tid när du lär dig mer om systemets beteende under belastning. Det är bättre att börja med ett flytande mål som du kommer att förfina med tiden än att välja ett alltför strikt mål som måste slappna av när du tycker att det är ouppnåeligt.
SLO:er kan och bör vara en viktig drivkraft för att prioritera arbete för SRE:er och produktutvecklare eftersom de återspeglar en oro för användarna. En bra SLO är ett användbart verkställande verktyg för ett utvecklingsteam. Men en dåligt utformad SLO kan leda till slösaktigt arbete om teamet gör heroiska ansträngningar för att uppnå en alltför aggressiv SLO, eller en dålig produkt om SLO är för låg. SLO är en kraftfull spak, använd den klokt.
Kontrollera dina mått
SLI och SLO är nyckelelement som används för att hantera system:
- Övervaka och mäta SLI-system.
- Jämför SLI med SLO och avgör om åtgärder behövs.
- Om åtgärder krävs, ta reda på vad som måste hända för att uppnå målet.
- Slutför denna åtgärd.
Till exempel, om steg 2 visar att begäran tar slut och kommer att bryta SLO inom några timmar om inget görs, kan steg 3 innebära att testa hypotesen att servrarna är CPU-bundna och att lägga till fler servrar kommer att fördela belastningen. Utan en SLO skulle du inte veta om (eller när) du skulle vidta åtgärder.
Ställ in SLO - då ställs användarens förväntningar
Att publicera en SLO sätter användarnas förväntningar på systemets beteende. Användare (och potentiella användare) vill ofta veta vad de kan förvänta sig av en tjänst för att förstå om den är lämplig att använda. Till exempel kan personer som vill använda en webbplats för fotodelning kanske vilja undvika att använda en tjänst som lovar lång livslängd och låg kostnad i utbyte mot lite mindre tillgänglighet, även om samma tjänst kan vara idealisk för ett arkivhanteringssystem.
För att ställa realistiska förväntningar på dina användare, använd en eller båda av följande taktiker:
- Behåll en säkerhetsmarginal. Använd en striktare intern SLO än vad som annonseras för användarna. Detta ger dig möjlighet att reagera på problem innan de blir synliga utifrån. SLO-bufferten låter dig också ha en säkerhetsmarginal när du installerar utgåvor som påverkar systemets prestanda och säkerställer att systemet är lätt att underhålla utan att behöva frustrera användare med stillestånd.
- Överskrid inte användarnas förväntningar. Användare baseras på vad du erbjuder, inte vad du säger. Om den faktiska prestandan för din tjänst är mycket bättre än den angivna SLO, kommer användarna att förlita sig på den aktuella prestandan. Du kan undvika överberoende genom att avsiktligt stänga av systemet eller begränsa prestandan under lätt belastning.
Att förstå hur väl ett system uppfyller förväntningarna hjälper till att besluta om man ska investera i att påskynda systemet och göra det mer tillgängligt och motståndskraftigt. Alternativt, om en tjänst fungerar för bra, bör en del personaltid ägnas åt andra prioriteringar, såsom att betala av tekniska skulder, lägga till nya funktioner eller introducera nya produkter.
Avtal i praktiken
Att skapa ett SLA kräver att affärs- och juridiska team definierar konsekvenserna och påföljderna för att överträda det. SRE:s roll är att hjälpa dem att förstå de sannolika utmaningarna med att möta SLO:erna i SLA. De flesta av rekommendationerna för att skapa SLO:er gäller även SLA:er. Det är klokt att vara konservativ i vad du lovar användarna för ju mer du har, desto svårare är det att ändra eller ta bort SLA:er som verkar orimliga eller svåra att uppfylla.
Tack för att du läste översättningen till slutet. Prenumerera på min telegramkanal om övervakning и .
Källa: will.com