Site reliability engineering

Vad är SRE – Site reliability Engineering?

Site reliability engineering (SRE) är ett tillvägagångssätt inom mjukvaruutveckling för IT-drift.  Ett SRE-team använder programvara som verktyg för att hantera system, lösa problem och automatisera driftuppgifter. Konceptet med Site Reliability Engineering kommer från Googles teknikteam och krediteras Ben Treynor Sloss.

SRE tar de uppgifter som historiskt har utförts av driftteam, ofta manuellt, och ger dem istället till ingenjörer eller driftteam som använder mjukvara och automation för att lösa problem och hantera produktionssystem.

Metoden är värdefull att tillämpa när du skapar skalbara och mycket pålitliga programvarusystem. Det hjälper till att hantera stora system genom kod, vilket är mer skalbart och hållbart för systemadministratörer (sysadmins) som hanterar tusentals eller hundratusentals maskiner.

Ytterliga fördelar med SRE är att metoden hjälper teams att hitta en balans mellan att släppa nya funktioner och att säkerställa tillförlitlighet för användarna. I detta sammanhang är standardisering och automatisering två viktiga komponenter i SRE-modellen. Här söker SRE:s att förbättra och automatisera driftuppgifter. På dessa sätt hjälper SRE till att förbättra systemets tillförlitlighet idag – och när det växer över tiden.

SRE stödjer teams som flyttar sin IT-verksamhet från ett traditionellt tillvägagångssätt till ett molnbaserat tillvägagångssätt.

Vad är det en Site reliability engineer gör?

En Site Reliability Engineer är en unik roll som kräver antingen en bakgrund som sysadmin, en mjukvaruutvecklare med driftserfarenhet eller någon i en IT-driftroll som även har kompetens inom mjukvaruutveckling.

Ett SRE-team ansvarar för hur kod distribueras, konfigureras och övervakas, samt tillgänglighet, latens, förändringshantering, nödsituationer och kapacitetshantering av tjänster i produktionen. Teamet bestämmer lanseringen av nya funktioner genom att använda servicenivåavtal (service-level agreements, SLA) för att definiera den nödvändiga tillförlitligheten för system genom servicenivåindikatorer (service-level indicators, SLI) och servicenivåobjekt (service-level objectives, SLO).

En SLI mäter specifika aspekter av tillhandahållna servicenivåer. Nyckel-SLI:er inkluderar begärd latens, tillgänglighet, felfrekvens och systemgenomströmning. En SLO baseras på målvärdet eller intervallet för en specificerad servicenivå baserat på SLI.

En SLO för den nödvändiga systemtillförlitligheten baseras sedan på stilleståndstiden som fastställts vara acceptabel. Denna stilleståndsnivå kallas en errorbudget – den högsta tillåtna tröskeln för fel och avbrott.

Med SRE förväntas inte 100 % tillförlitlighet – misslyckanden planeras för och förväntas.

När det väl är etablerat kan utvecklingsteamet ”spendera” errorbudgeten när en ny funktion släpps. Med hjälp av SLO och erorrbudget bestämmer teamet sedan om en produkt eller tjänst kan lanseras baserat på den tillgängliga errorbudgeten.

Om en tjänst körs inom errorbudgeten kan utvecklingsteamet lansera när teamet vill, men om systemet för närvarande har för många fel eller får ned längre än errorbudgeten tillåter kan inga nya lanseringar ske förrän felen är inom budget.

Utvecklingsteamet genomför automatiserade drifttester för att visa tillförlitlighet.

Site reliability Engineers delar sin tid mellan driftsuppgifter och projektarbete. Enligt SREs bästa praxis från Google kan site reliability engineers endast spendera högst 50 % av sin tid på driften – och de bör övervakas för att säkerställa att de inte går över.

Resten av tiden bör spenderas på utvecklingsuppgifter som att skapa nya funktioner, skala systemet och implementera automatisering.

Överskott av operativt arbete och dåligt presterande tjänster kan omdirigeras tillbaka till utvecklingsteamet så att ingenjören för Site Reliability Engineers inte lägger för mycket tid på driften av en applikation eller tjänst.

Automatisering är en viktig del av Site Reliability Engineers roll. Om de upprepade gånger hanterar ett problem, kommer de sannolikt att automatisera en lösning.

Att upprätthålla balansen mellan verksamhet och utvecklingsarbete är en nyckelkomponent i SRE.

DevOps vs. SRE

DevOps är ett förhållningssätt till kultur, automation och plattformsdesign avsett att leverera ökat affärsvärde och lyhördhet genom snabb, högkvalitativ serviceleverans. SRE kan betraktas som en implementering av DevOps.

Liksom DevOps handlar SRE om teamkultur och relationer. Både SRE och DevOps arbetar för att överbrygga gapet mellan utvecklings- och driftteam för att leverera tjänster snabbare.

Snabbare livscykler för applikationsutveckling, förbättrad servicekvalitet och tillförlitlighet samt minskad IT-tid per applikation som utvecklas är fördelar som kan uppnås med både DevOps- och SRE-praxis.

SRE skiljer sig dock fån DevOps eftersom det förlitar sig på Site Reliability Engineers inom utvecklingsteamet som också har en operationsbakgrund för att ta bort kommunikations- och arbetsflödesproblem.

Själva rollen som Site Reliability Engineers kombinerar kompentensen hos utvecklingsteam och driftteam genom att kräva överlappning i ansvar.

SRE kan hjälpa DevOps-teams vars utvecklare är överväldigade av operativa uppgifter och behöver någon med mer specialiserad operativ kompetens.

När man kodar och bygger nya funktioner fokuserar DevOps på att gå igenom utvecklingspipelinen effektivt, medan SER fokuserar på att balansera sitens tillförlitlighet med att skapa nya funktioner.

Här är moderna applikationsplattformar baserade på containerteknologi, Kubernetes och mikrotjänster avgörande för DevOps-praxis, vilket hjälper till att leverera säkerhet och innovativa mjukvarutjänster.

Teknik för att stödja SRE

SRE förlitar sig på att automatisera rutinmässiga driftsuppgifter och standardisering över en apps livscykel. Red Hat Ansible Automation Platform är en omfattande, integrerad plattform som hjälper SRE-team att automatisera för hastighet, samarbete och tillväxt – och erbjuder säkerhet och support över företagets tekniska, operativa och finansiella funktioner.

Specifikt erbjuder Ansible Automation Platform:

• Infrastrukturorkestrering i molnet och på plats för insatser, routing, lastbalansering, brandväggar och mer.
• Infrastrukturoptimering, inklusive molnresurser i rätt storlek och att lägga till eller ta bort resurser som centralprocessor (CPU) och RAM-minne efter behov.
• Molndrift, inklusive applikationsdistributioner med kontinuerlig integration och kontinuerlig leverans (CI/CD) pipelines, korrigering av operativsystem och underhåll.
• Affärskontinuitet, inklusive att flytta och kopiera resurser från molnet, skapa och hantera policyer för säkerhetskopiering och hantera störningar och fel.

SRE förlitar sig också på en grund utformad för en molnbaserad utvecklingsstil. Linux-containers stöder en enhetlig miljö för utveckling, leverans, integration och automatisering.

Och Kubernetes är det moderna sättet att automatisera Linux-containeroperationer. Kubernetes hjälper team att mer effektivt hantera kluster som kör Linux-behållare över offentliga, privata eller hybridmoln.

Som en företagsklar Kubernetes-plattform som stöder SRE-initiativ, hjälper Red Hat OpenShift team att implementera kultur- och processtransformation som moderniserar IT-infrastrukturen och positionerar organisationer för att bättre betjäna sina kunder och uppnå affärsmål.