Viktiga principer och metoder för SRE: positiva cykler
Om det verkligen är sant att i någon mening "du är vad du gör", så har vi kommit till hjärtat av den här modulen. I den här lektionen ska vi titta på två av de metoder som ofta anses vara centrala för SRE:s praxis. Båda kommer från principen att det är viktigt att skapa "dygdiga cykler". Positiva cykler i det här sammanhanget är metoder som skapar feedbackslingor i en organisation som hjälper organisationen att bli bättre kontinuerligt. Vi har hela uppföljningsmoduler för exakt dessa två metoder, så vi kommer bara att skumma ytan med en översikt över var och en här.
Positiv cykel 1: Servicenivåindikatorer (SLI) och servicenivåmål (SLO)
Tidigare i den här modulen betonade vi vår poäng om att arbeta mot "lämplig tillförlitlighetsnivå". Det här avsnittet är just den plats där det konceptet kommer att bäras.
Anta att du har en ny tjänst som du planerar att ta med till produktion (antingen en som har konstruerats eller en som fortfarande är i planeringsprocessen). Som en del av den processen är det viktigt att fatta vissa beslut om önskad tillförlitlighet. Om du inte skriver all kod själv fattas dessa beslut (och den här punkten är avgörande) i samarbete med utvecklarna som gör saken.
Det första beslutet att fatta är, vad ska vi använda som indikatorer för tjänstens hälsa (en indikator på tjänstnivå eller SLI)? Ett annat sätt att ställa den här frågan är "Hur vet du när det är igång och fungerar bra?". Det finns många sätt att spåra SLI och vi utforskar några i detalj senare. Men dessa indikatorer är vanligtvis:
- Lyckade jämfört med felmått: Slutför tjänsten en åtgärd i procent av tiden?
- Tidsmått: Returnerade vi ett svar inom en viss tidsperiod?
- Mått på dataflöde: Bearbetade vi en viss mängd data?
Eller någon kombination av alla dessa mått.
Som ett enkelt exempel kan vi anta att en SLI för vår tjänst är hur ofta en åtgärd lyckas, vilket anges via HTTP-kod 200 (i stället för t.ex. 500 eller en annan kod).
Nu när vi har en tydlig indikator som talar om för oss hur tjänsten fungerar vill vi bestämma vilken tillförlitlighetsnivå vi förväntar oss eller önskar av den. Förväntar vi oss till exempel att under en period av en dag se en felfrekvens på 20 % från tjänsten? Vi använder avrundade och stora tal här eftersom det är enklast i början. I senare moduler ökar vi komplexiteten och precisionen för instruktioner som detta ("vilka användare ser felfrekvensen? några av dem? de flesta av dem?" och så vidare). Förväntningen, som definieras i samarbete med tjänstens utvecklare, är servicenivåmålet eller SLO (Service Level Objective).
Ett servicenivåmål måste vara något som kan beräknas och representeras på ett bra sätt i ditt övervakningssystem. Det är tänkt att vara ett mål, väl förstådda mål för tjänstens tillförlitlighet. Vad är det tal som är tillräckligt bra? Det finns inte utrymme för diffusa svar här, som till exempel ”Tja, jag tror att tjänsten har fungerat hyfsat den senaste veckan, men det är lite svårt att veta”. Antingen uppfyller tjänsten sitt servicenivåmål eller så är den inte det. Data bör vara tydliga. Om den inte uppfyller servicenivåmålet (särskilt upprepade gånger under en tidsperiod) betyder det att något är fel och måste åtgärdas.
Felbudgetar
Vi kan förstå att en organisation kan komma att agera om en tjänst inte uppfyller sitt servicenivåmål. SRE tar dock hela det här konceptet ytterligare ett steg framåt för de fall där SLO uppfylls eller överskrids. Vissa organisationer använder servicenivåmål för att skapa så kallade ”felbudgetar”.
För att demonstrera den här idén ska vi använda exempeltjänsten som vi har diskuterat och dess servicenivåmål på 80 % lyckade åtgärder (se det som att tjänsten ”ska vara igång 80 % av tiden”). Med servicenivånivåmål på 80 % drifttid har vi deklarerat att tjänsten måste vara upp till 80 % av tiden. Men vad händer med de återstående 20 procenten? Om tjänsten ligger nere övriga 20 % av tiden så bryr vi oss egentligen inte om det eftersom vi har bestämt att de där ytterligare 20 % inte är viktiga som ett servicemål.
Vad kan vi göra med tjänsten om vi inte bryr oss om vad som händer under den tiden? En sak som vi kan göra är att arbeta med den aktiva tjänsten genom att uppgradera den, kanske med en ny version som lägger till vissa funktioner. Om den nya versionen fungerar och inte medför ökad avbrottstid, så är det bra. Om den nya versionen gör att tjänsten blir mindre stabil och returnerar fel ytterligare 10 % av tiden när den blir debugged, fungerar det fortfarande bra. Vi är fortfarande inom vår budget för tillåten otillförlitlighet.
En felbudget är skillnaden mellan tjänstens potentiella perfekta tillförlitlighet och dess önskade tillförlitlighet (100 % – 80 % = 20 %). I det här fallet ger felbudgeten oss en fond på 20 % otillförlitlig 20 % tid där vi "inte bryr oss om huruvida den är igång eller inte eftersom den fortfarande är i spec". Vi kan utnyttja och spendera den 20 % tid som vi vill (kanske med fler versioner) tills den är uttömd precis som vilken annan budget som helst.
Felbudgetar används också i vissa organisationer i situationer då man inte uppnår servicenivåmålet. I så fall kan du välja att göra något lite strängare än att bara "vidta en åtgärd". Anta att vår tjänst har haft problem och att den bara har varit igång 60 % av tiden, enligt den servicenivåindikator som vi valde tidigare. Vi uppfyllde inte vårt mål (SLO). Vår tjänst har förbrukat dess felbudget. Organisationen kan välja att hålla tillbaka en planerad version eftersom den vet att det sannolikt bara kommer att förvärra tillförlitlighetssituationen om systemet störs ytterligare i det här läget. Vanligtvis beräknas felbudgetar för en viss tidsperiod. en månad, en fjärdedel och så vidare. Detta beräknas löpande, så om tjänstens tillförlitlighet förbättras så returnerar den budgeten.
Under den här tiden av gated releases kan organisationen välja att pivotleda vissa tekniska resurser från funktionsutveckling till tillförlitlighetsarbete. Med målet att hjälpa till att upptäcka och förbättra källan till de problem som gjorde att tjänsten blåste sitt servicemål.
Varför vi säger ”vissa organisationer” när det gäller felbudgetar beror på att deras implementering, särskilt i de fall då den används för att begränsa versionsutgivningen, kräver ett särskilt institutionsbeslut. När du står inför ett lanseringsbeslut måste organisationen vara villig att hålla tillbaka versionen om tjänstens tillförlitlighet hittills inte har varit uppdaterad. Det beslutet är inte ett beslut som alla organisationer är villiga att fatta. Det här beslutet är inte heller det enda möjliga svaret på en uttömd felbudget, men det är den som är mest omtalad.
I en separat modul pratar vi mer detaljerat om SLO:er, SLO:er och felbudgetar. Det är dock värt att lyfta fram den positiva cykelaspekten i dessa metoder. I teorin är det ett sätt för en organisation att beskriva, kommunicera och agera på en tjänsts tillförlitlighet. När du gör det på ett sätt som gör att alla arbetar för bättre tillförlitlighet. Den här feedbackslingan kan vara otroligt viktig.
Positiv cykel 2: Retrospektiv analys utan syndabockar
Tanken på en postmortem – den retrospektiva analysen av en betydande, vanligtvis oönskade händelse – är inte ens fjärransluten specifik för platstillförlitlighetsteknik. Det är inte heller ovanligt i driftsammanhang. Något som däremot är utmärkande inom SRE är uppfattningen att ingen bär skulden. Man fokuserar på bristerna i processen eller tekniken som orsakar incidenten, inte åtgärderna som utförs av specifika individer. ”Vad var det med processen som gjorde att X kunde göra det som ledde till felet? Vilken information saknades eller var inte tillräckligt tydlig, och gjorde att man drog fel slutsats? Vilka skyddsräcken skulle ha varit på plats så att det inte gick att få ett sådant katastrofalt misslyckande?" Dessa frågor är den typ som ställs i en skuldlös postmortem.
Tonen och riktningen på dessa frågor är avgörande. Vi söker efter sätt att förbättra systemen eller processerna, inte sätt att straffa de individer vars användning av dessa system eller processer i god tro bidrog till avbrottet. Det är viktigt att komma ihåg, "Du kan inte utlösa din väg till tillförlitlighet". Enligt vår erfarenhet lär sig inte en organisation som utlöser en person varje gång det uppstår en produktionsincident (med få undantag) av dessa incidenter. Istället lämnas de med en enda individ, skakar i hörnet, rädd för att göra några ändringar i något alls.
En välfungerande process för retrospektiv analys i en organisation skapar däremot en positiv cykel. Det gör att organisationen kan lära sig av sina avbrott och kontinuerligt förbättra sina system (tillhandahålla korrekt analys och uppföljning görs).
Den här relationen till fel och fel som omfamnas av organisationen som möjligheter till inlärning och förbättring är en grundläggande princip för platstillförlitlighetsutveckling. En annan är upprättandet av positiva cykler som utnyttjar dessa möjligheter och som vägleder organisationen mot bättre tillförlitlighet.
Nu ska vi utforska några andra principer och metoder, centrerad på den mänskliga sidan av SRE, i nästa lektion.