Vad är site reliability engineering? En praktisk guide

Vad är site reliability engineering? Det är att driva produktionssystem med mjukvaruutveckling i stället för manuellt driftarbete. Ett SRE-team sätter ett numeriskt tillförlitlighetsmål, mäter mot det och automatiserar bort det repetitiva arbete som håller tjänsterna uppe. Om din jourtelefon ringer klockan tre på natten för samma diskvarning varje månad är det precis det problem SRE finns till för att ta bort.

Google började använda begreppet runt 2003. Idag används idén långt utanför Google, från startups med 20 personer till banker. Det som skiljer dem åt är skala, inte kärnmekaniken.

Vad gör en site reliability engineer egentligen?

Ben Treynor Sloss, som startade Googles SRE-team, sammanfattade det i inledningskapitlet i Google SRE-boken: SRE är vad som händer när man ber en mjukvaruingenjör att designa ett driftteam. Jobbet är driftarbete gjort med kod.

En vanlig vecka innebär fyra saker. Du definierar vad "fungerar" betyder för en tjänst. Du bygger övervakningen som talar om när den inte fungerar. Du agerar när den går sönder, och du skriver lagningen så att nästa person inte väcks för samma sak.

Två exempel gör det konkret. Ett team som deployar för hand varje torsdag bygger en pipeline med automatisk rollback. Ett team som startar om en läckande tjänst varje natt hittar läckan. Båda gör ett återkommande slitsamt arbete till ett engångsprojekt, och det är hela poängen.

Den fjärde delen är den som team brukar hoppa över. En SRE som bara svarar på incidenter är en driftingenjör med ny titel. Det tekniska är det som gör rollen annorlunda.

Hur skiljer sig SRE från DevOps?

DevOps är en kultur: utvecklare och driftare delar ansvar för vad som levereras och hur det körs. Det säger att muren mellan teamen är ett problem. Det säger inte hur mycket driftstopp som är acceptabelt eller när man ska sluta leverera.

SRE levererar siffrorna. Den ger dig servicenivåmål (SLO), felbudgetar och ett tak för manuellt arbete. Googles egen beskrivning är att SRE är ett konkret sätt att genomföra DevOps-idéerna.

Skippa debatten om vilket som är bäst. Har du ett team på 8 personer lånar du från båda. Den användbara frågan är om ditt team kan svara i en mening på hur tillförlitlig en given tjänst måste vara.

Vad är SLI, SLO och SLA, och varför spelar de roll?

Tre akronymer bär största delen av vikten i SRE, och folk blandar ihop dem hela tiden.

• SLI (service level indicator): en mätning. Till exempel andelen HTTP-anrop som får ett svar utan 5xx på under 300 ms.

• SLO (service level objective): målet för mätningen. Till exempel att 99.9% av anropen lyckas under en rullande period på 28 dagar.

• SLA (service level agreement): avtalet med konsekvenser, oftast återbetalningar om du missar. Din SLA bör vara lösare än din SLO.

Anledningen att bry sig är att "sajten ska vara snabb och pålitlig" inte går att testa. Ett mål som "99.9% av kassaanropen lyckas under 500 ms" går det att testa, och det ger dig ett sätt att avgöra diskussioner.

Börja med två eller tre SLI:er per tjänst. Fler än så och ingen minns dem.

Var du mäter spelar roll. En server som svarar snabbt kan ändå ge långsamma sidor för användaren om nätverket eller ett CDN-steg ligger mitt emellan. Mät så nära användaren du kan, och jämför med serverloggen när siffrorna inte stämmer.

Välj SLI:er som användare faktiskt märker. CPU-användning är en orsak, inte ett symptom. Misslyckade köp, långsamma sidladdningar och inaktuella data är sådant kunden märker.

Hur fungerar felbudgetar?

En felbudget är den opålitlighet din SLO tillåter. Den är helt enkelt 1 minus SLO. Ett tillgänglighetsmål på 99.9% lämnar 0.1%, vilket är ungefär 43 minuters driftstopp under en 30-dagarsmånad.

Här är en liten version i kod, eftersom aritmetiken är hela idén:

slo = 0.999
window_minutes = 30 * 24 * 60          # 43 200
budget = (1 - slo) * window_minutes    # 43.2 minuter
spent = 31                              # minuter med dålig tjänst hittills
print(f"{budget - spent:.1f} minuter kvar")  # 12.2 minuter kvar

Så länge budget finns kvar levererar teamet snabbt. När den tar slut pausas funktionsreleaser och arbetet går över till tillförlitlighet. Exemplet med felbudgetpolicy i SRE Workbook visar hur ett team skriver ner regeln.

Budgeten gäller också planerat underhåll. Om du planerar en migrering på 20 minuter ska den räknas in i budgeten innan du bestämmer dig, inte efteråt.

Poängen är inte att straffa. Budgeten ersätter det gamla gräljet, där utvecklare vill leverera och driftare vill ha stabilitet, med ett gemensamt tal som båda kan läsa. Det fungerar bara om ledningen i förväg godkänner att pausen gäller. En budgetpolicy som åsidosätts varje kvartal är bara dekoration.

Varför finns regeln om 50 procent toil?

Toil är manuellt, repetitivt arbete som växer med tjänsten och inte lämnar något bestående kvar. Att starta om en fastnad worker för hand är toil. Att skriva hälsokontrollen som startar om den automatiskt är engineering.

Googles SRE-organisation strävar efter att hålla toil under 50 procent av varje ingenjörs tid, enligt kapitlet om att eliminera toil. Resten går till projekt som minskar framtida toil eller tillför funktioner. Resonemanget är rakt: toil expanderar tills den tar 100 procent av tiden om ingen stoppar den.

Behandla 50 procent som ett tak, inte ett mål. Ett friskt team på en mogen tjänst ligger väl under. Om du ligger över det under ett kvartal gör du inte SRE, du kör en driftkö.

Att mäta toil är svårare än det låter, eftersom mycket av arbetet är små avbrott som ingen registrerar. Tvåveckorsmätningen är värdefull även när siffrorna blir ungefärliga.

Ett enkelt sätt att börja: i två veckor märker du varje ärende och varje jourlarm som toil eller projekt. Rangordna sedan toilen i timmar. De tre främsta posterna är din automationsbacklogg.

Vad ändrar blamefria postmortem?

När något går sönder frågar postmortemet hur systemet tillät att en människa gjorde misstaget, inte vem som gjorde det. Skuld lär folk att gömma information. En blamefri genomgång lär dem att skriva ner den.

Ett användbart postmortem är kort och har fyra delar: en tidslinje, de bidragande orsakerna, vad som gick bra och åtgärdspunkter med ägare och datum. Åtgärdspunkter utan ägare är önskningar.

Mycket av värdet kommer från uppföljningen. Gå igenom öppna åtgärdspunkter varje månad. Om samma orsak dyker upp två gånger på sex månader misslyckades det första postmortemet, oavsett vad dokumentet sa.

Vilka verktyg behöver ett SRE-team först?

Inte många. Börja med signalerna och lägg sedan till jour och automation.

1. Mätvärden och dashboards. Tillräckligt för att räkna ut dina SLI:er. Grafana och Prometheus är en vanlig kombination med öppen källkod. Datadog och New Relic är den hostade vägen.

2. Larm kopplade till SLO:er. Larma när budgeten bränner snabbt, inte när en enskild värd spikar. Färre sidor, bättre sidor.

3. Feature flags och gradvis utrullning. De flesta driftstopp följer grovt sett på en ändring, så den billigaste tillförlitlighetsvinsten är att göra ändringar reversibla. LaunchDarkly och Statsig täcker detta.

4. En skriven runbook för varje larm. Om ett larm saknar runbook skriver du en eller tar bort larmet.

Köp eller bygg i den ordningen. Team som börjar med ett verktygsköp utan SLO slutar med vackra dashboards för ingenting särskilt.

Var passar det att läsa okänd kod in i SRE?

Det här är delen ingen sätter i jobbeskrivningen. Under en incident måste en SRE ofta förstå en tjänst hen inte skrev, i ett repo hen inte öppnat på månader. Frågan är sällan abstrakt. Den lyder: "var bor den här retry-loopen och vad gör den vid timeout?"

Du har gjort det förut: grep, blame, sedan ett meddelande till den som senast rörde filen. På ett repo med 80 000 rader fungerar det. På tolv tjänster ägda av sex team äter det de första 20 minuterna av en incident, och de minuterna räknas mot budgeten.

Där förtjänar ett kodsökverktyg som svarar på frågor om ditt eget repo sin plats, till exempel genom att fråga var en tjänst sätter sina timeouts och vilka anropare som förlitar sig på dem. Det löser inte driftstoppet. Det förkortar tiden du läser innan du kan agera, och den tiden går att mäta.

Är SRE överdrivet för ditt team, och hur börjar du?

Skippa ett dedikerat SRE-team om du har en tjänst, en handfull ingenjörer och användare som tål en och annan dålig timme. Du behöver inget team. Du behöver en SLO, ett vettigt larm och någon som äger jouren.

Överväg det när något av detta stämmer: driftstopp kostar riktiga pengar, jouren sliter ut människor eller utvecklare bromsas av ad hoc-driftsärenden. Många företag börjar med att göra en eller två ingenjörer till deltids-SRE och ser hur det går.

Ett vanligt misstag är att byta namn på driftteamet till "SRE" utan att ändra hur det arbetar. Om teamet fortfarande äger ärenden, manuella deployer och ingen felbudget har titeln ändrats och ingenting annat.

Så börjar du nästa vecka

Du behöver ingen omorganisation. Välj den användarnära tjänst som gör mest ont och gör fem saker.

1. Skriv en SLI och en SLO för den. Håll dem tråkiga.

2. Räkna ut felbudgeten och lägg den på en dashboard som hela teamet ser.

3. Mät toil i två veckor och välj det främsta objektet att automatisera.

4. Håll ett blamefritt postmortem vid nästa incident, med ägda åtgärdspunkter.

5. Kom överens skriftligt om vad som händer när budgeten når noll.

Om teamet några månader senare diskuterar mindre om huruvida man ska leverera och mer om vad siffrorna säger, fungerar det. Om budgeten aldrig rör sig för att SLO:n är för lös, dra åt den.