Opnå den rette balance mellem agilitet og stabilitet med SRE

Hos cVation har vi et stærkt DevOps-fokus, hvor vi stræber efter at håndtere opgaverne udfra en kundecentreret tilgang. Vores primære mål er at forene både udviklernes og operations' interesser, selv når de konflikter (f.eks. i ønsket om lancering af nye features uden restriktioner versus modviljen mod at ændre noget i et ellers velfungerende system).

Site Reliability Engineering (SRE)

SRE blev udviklet og lanceret af Google til at håndtere deres systemer i large scale. Dog er principperne og praksisserne inden for SRE som en ingeniørdisciplin blevet vedtaget af mange andre organisationer for at forbedre pålideligheden af deres software-systemer. SRE er i bund og grund en række praksisser og principper, der kombinerer software engineering og drift for at sikre pålidelighed, ydeevne og tilgængelighed af komplekse software-systemer gennem brug af automatisering, overvågning, håndtering af hændelser og kontinuerlig forbedring.

Site Reliability Engineering (SRE) sigter mod at hjælpe organisationer med at opnå bæredygtige niveauer af pålidelighed i deres systemer. En vigtig aspekt er også at finde den rette balance mellem agilitet og stabilitet for den enkelte virksomhed.

Ansvarsområderne for SRE-teams inkluderer:

Tilgængelighed / pålidelighed / latenstid / performance / effektivitet / change management / overvågning / emergency response og kapacitetsplanlægning af tjenester.

For at give et team mulighed for at gøre dette i stor skala, sigter vi mod at automatisere eller eliminere alle repeterende opgaver. SRE-teamet lægger vægt på, at systemdesignet fungerer pålideligt, selv når der sker hyppige opdateringer fra udviklingsteams.

For at SRE-teamet kan tilpasses til et system under udvikling, skal det være designet med observabilitet for øje, dvs. det skal have en høj grad af overvågning. Med andre ord skal der logges tilstrækkeligt med data i systemet for at der kan foretages ordentlige undersøgelser. Det giver SRE-teamet mulighed for konstant at vurdere nye brugerflows og overvåge kritiske processer for projektet.

Agilitet versus Stabilitet

Historisk set har kløften mellem udvikling og drift ofte kunne resultere i en konflikt om, hvad der er vigtigst: Agilitet for at kunne lancere nye funktioner eller opretholdelse af stabiliten i systemet for kunden.

SRE-konceptet giver os mulighed for at drøfte dette dilemma ved at anvende Service Level Indicators (SLI), Service Level Objectives (SLO) og et resulterende fejlbudget.

SLI kan oversættes til overvågning af vigtige brugerflows, f.eks. i en IoT-opstilling. Her kan det være, når brugeren installerer en sensor og bekræfter, at den er aktiv i et administrationspanel. SLO ville hermed betyde reglerne for latenstid, tilgængelighed og den fejlmargen, som brugeren kan forvente.

SLO giver SRE-teamet og virksomheden mulighed for at kommunikere og blive enige om de konkrete tal for oppetid og ydeevne. Forskellen mellem den opmålte SLI og den definerede SLO er det der kaldes fejlbudgettet. Når der performes bedre end aftalt, er det tilladt for udviklingsteamene at lancere nye funktioner så ofte, som de ønsker. Men så snart budgettet er negativt, har SRE-teamet ansvaret for at stoppe lanceringer, at undersøge problemene og fjerne forhindringer -eller give et udvalgt udviklingsteam opgaven med at fjerne dem. I bund og grund betyder en negativt SLO, at projektet dermed skal fokusere på kvalitet. På den måde kan interesse-konflikten mellem drift og udvikling reduceres til at være over eller under den aftalte SLO.

For eksplicit at definere fejlbudgettet, kan vi fortolke det som, hvor meget "upålidelighed" der er tilladt i den aftalte tidsramme. Dette er et vigtigt begreb, da alle implementeringer uanset hvilke medfører risici for upålidelighed, selv de største virksomheder som fx. Microsoft kan indimellem publicere noget, der på trods af alle tests og alle 'best practises' kan resultere i nedetid.

SRE-teamet bliver måske klandret for kun at fokusere på brugerflows vs. tilgængelighed eller svartid, men et brugerflow kan også ses fra et forretningsmæssigt perspektiv, som fx. indtægt eller churn (kundeafgang). Lad os se på det ud fra følgende eksempel, hvor vi har en Machine Learning set-up, der genererer anbefalinger til brugerne.

På illustrationen ses en pipeline, der kombinerer brugerhændelser og ugentlige køb som basis for at opdatere en Machine Learning model, der genererer anbefalinger. Hvis pipeline'en fejler, vil modellen blive baseret på forældet data og brugeren vil muligvis ikke længere være interesseret i de anbefalede elementer. Dette kan påvirke virksomhedens indtægtsflow én til én. I et sådan scenarie vil den endelige forretningsmæssige konsekvens kunne være faldende konverteringsrater på salg og stigende churn-rater, hvilket er et kritisk brugerflow at overvåge for virksomheden.

Værdien ved SRE-drevne teams

Det er ikke et mål eller en værdi i sig selv at have mange SLO'er, men derimod at have de rigtige SLO'er. En god indikator man kan bruge for at afgøre, om en SLO er relevant, er: "Hvis du aldrig kan vinde en argumentation om prioriteter ved at henvise til en bestemt SLO, er det sandsynligvis ikke værd at beholde den pågældende SLO".

Et SRE-team kan bringe enorm værdi til organisationen ved at standardisere og oversætte forretningskrav til kode. SRE-teamet består af udviklere, der kan bidrage til infrastruktur, CI/CD-pipelines og forretningsfunktioner.

Den værdi, vi har opnået fra vores SRE-teams, er bl.a. kontinuerligt at drive strukturelle forbedringer af projektet. Dette gør det muligt for andre udviklingsteams at levere værdi hurtigere, da de underliggende tekniske krav, der påvirker hele projektet, kan håndteres af ét specifikt team. I forskellige projekter har SRE-teamet bevist deres værdi ved at udføre belastningstests, overvåge SLO'er, fungere som CoE-team samt at implementere tværfunktionelle funktioner for udviklingsteams. Det har gjort det muligt for os at opdage problemer og identificere flaskehalse, inden de manifesteres for brugeren.

Det endelige og vigtigste element for et SRE-teamet er dog, at enhver utilsigtet hændelse straks kan identificeres og prioriteres. Dette betyder ikke, at SRE-teamet nødvendigvis altid skal løse det underliggende problem. De kan uddelegere denne del af arbejdet til andre teams, men de vil fokusere på at bringe produktionen fremad for at sikre, at den fungerer. Du bør altid prioritere fremdrift modsat at rulle ændringer tilbage, for at bevare agiliteten i projektet.

Hvordan kommer man i gang

For at understrege hvilken konkret værdi et SRE-team kan levere, vil jeg opsummere det vigtigste i følgende 3 punkter:

• Opnå en forbedret forståelse for systemet i produktion

• Sikre kort reaktionstid på problemer

• Tydelig kommunikation af krav og performance til forretningen

For at opnå dette i en organisation lægger vi vægt på systematisk automatiseret testning af systemet, der går gennem hele kæden af enhedstests, integrationstests, end-to-end-tests, belastningstests og sidst chaos-engineering. Dette giver jer mulighed for at få et overblik over, hvor godt forberedt I er på problemer og katastrofer. Årsagen til, at vi her hos cVation kan gøre dette i samarbejde med vores kunder, er vores stærke fundament inden for DevOps og SRE.

Vi opnår en høj grad af kontrol og tillid til vores lanceringer, fordi vi fjerner enhver manuel handling eller manuelt trin, som er nødvendig for implementering og stoler fuldt ud på automatisering i CI/CD-pipelines.

SLA-kontrakter

En opmærksom læser vil bemærke, at vi endnu ikke har diskuteret Service Level Agreements (SLA), som de fleste nok er bekendt med. SLA'en er en eksplicit eller implicit kontrakt med dine brugere, der inkluderer konsekvenserne af at opfylde (eller ikke opfylde) dem. SLA'en er en beskrivelse af hele systemet baseret på en enkelt måling rettet mod brugerne, men den kan være svær at omsætte til konkrete handlinger for teamet. SLO'erne er de mål, som teamet skal opfylde for at overholde kontrakten (SLA'en). Endelig er der det præcise tal, som SRE-teamet ser på, SLI'en. SRE-teamet bliver normalt ikke involveret i at konstruere SLA'er, fordi SLA'er er tæt forbundet med forretnings- og produktbeslutninger.

En post-mortem-kultur - uden skyld

Trods alle disse bestræbelser kan det ikke undgåes at der desværre stadig ind imellem opstår problemer i produktionen. For at mindske risikoen for, at et lignende problem opstår, har vi en udviklet en post-mortems-kultur uden skyld. Øvelsen udføres uden at pege fingre, i stedet fokuserer vi på hvad og hvordan.

Derefter følger vi fire trin:

• Definér og beskriv problemet

• Implementér tests, der replikerer problemet

• Skab en løsning

• Implementér løsningen i produktion

På denne måde sikrer vi, at problemet ikke kan opstå efterfølgende og ved at definere problemet kan vi afsløre mangler i vores processer, der skal håndteres. Det resulterer i et klart billede af, hvad der skete. Desuden støtter det op om en direkte og præcis kommunikation til interessenterne og kan forsikre dem om, at vi har identificeret en løsning på de bagvedliggende årsager.

For os er dette en fantastisk måde at drive transformation på og en måde hvorpå vi kan fortsætte fremdriften med store projekter, uanset virksomhedens niveau af modenhed. Værdien I opnår er til at få øje på med det samme og arbejdet kan fortsætte fremad uden de typiske konflikter og diskussioner mellem udvikling og drift.