Site Reliability Engineering (SRE)
Googles tilgang til drift og pålidelighed, hvor softwareingeniører løser operationelle problemer med kode.
Site Reliability Engineering (SRE) er en disciplin inden for softwareudvikling, der anvender ingeniørprincipper på drift og infrastruktur. Konceptet stammer fra Google, hvor Ben Treynor Sloss i 2003 definerede det som "hvad der sker, når man giver en softwareingeniør ansvaret for det, der traditionelt hedder operations."
SRE bygger på en fundamental præmis: driftsopgaver kan og bør løses med software. I stedet for manuelle runbooks skriver SRE-teams kode, der automatiserer incident response, kapacitetsplanlægning og deployment. Målet er at eliminere "toil", det gentagne, manuelle arbejde der ikke skaber varig værdi. Google definerer en øvre grænse: SRE-teams bør bruge maksimalt 50% af deres tid på toil, resten på engineering.
Error budgets er kernekonceptet i SRE. Ingen service er 100% pålidelig, og det bør den heller ikke være. Et error budget definerer den acceptable mængde nedetid. Hvis en service har et SLO (Service Level Objective) på 99.9% oppetid, er error budgettet 0.1%, svarende til cirka 43 minutter per måned. Så længe budgettet ikke er brugt, kan teamet deploye nye features. Overstiger nedetiden budgettet, fryses feature-arbejde til fordel for stabilisering.
SLI, SLO og SLA danner et hierarki af pålidelighed. SLI (Service Level Indicator) er den konkrete måling, f.eks. latency for det 99. percentil. SLO er det interne mål, f.eks. "p99 latency under 200ms for 99.9% af requests." SLA er den juridisk bindende aftale med kunder, typisk mere lempelig end SLO. Et team der lever op til sine SLO'er, vil aldrig bryde sin SLA.
Incident management i SRE følger strukturerede processer. En incident commander koordinerer response, en kommunikationsansvarlig opdaterer stakeholders, og tekniske leads debugger. Post-incident reviews dokumenterer root cause, tidslinje og action items. Google publicerer sine incident reports offentligt for tjenester som Google Cloud, hvilket demonstrerer transparens og accountability.
On-call er en central del af SRE-rollen. SRE-ingeniører har vagt og reagerer på alerts fra monitoring-systemer. Effektiv on-call kræver klare eskaleringsregler, veldokumenterede runbooks, og automatisering der reducerer antallet af alerts. Google anbefaler maksimalt to incidents per 12-timers vagt for at undgå burnout. Kompensation for on-call (ekstra betaling eller afspadsering) er standard.
Kapacitetsplanlægning sikrer, at systemer kan håndtere forventet vækst. SRE-teams modellerer trafikmønstre, udfører load tests og planlægger infrastruktur-skalering i forvejen. Organisk vækst er forudsigelig, men virale events eller nye produktlanceringer kræver ekstra kapacitet. "N+2 redundancy" (systemet kan miste to komponenter og stadig fungere) er en typisk standard.
SRE og DevOps deler mange principper men har forskellige udgangspunkter. DevOps er en bred kulturel bevægelse fokuseret på samarbejde mellem Dev og Ops. SRE er en konkret implementering med specifikke praksisser, metrics og organisationsmodeller. Som Ben Treynor formulerer det: "SRE er en implementering af DevOps." Organisationer der adopterer SRE, får et veldefineret framework med error budgets, SLO'er og on-call-strukturer, der gør de abstrakte DevOps-principper operationelle.