Wat is SRE? Hoe verhoudt het zich tot DevOps?

SRE staat voor Site Reliability Engineering. Het bouwt voort op de principes van DevOps om een door engineering geleide benadering van IT-activiteiten te bieden. SRE gebruikt software om de werking van het systeem te automatiseren, problemen te identificeren en oplossingen te implementeren.

Het concept van SRE ontwikkeld bij Google. Het is gebaseerd op het idee dat code en software de meest effectieve manier zijn om grootschalige systemen te beheren. Handmatige procedures die door een apart team worden geïnitieerd, brengen een risico van onoplettendheid en inconsistentie met zich mee.

In dit artikel leert u wat SRE is en hoe het helpt om cloudactiviteiten te stroomlijnen. We zullen ook uitleggen waar SRE overlapt met DevOps, evenals de manieren waarop het verschilt.

Waar doet SRE Inpassen in softwarelevering?

SRE betreft operations management. Het komt in het softwareleveringsproces nadat de code is ontwikkeld, beoordeeld en geïmplementeerd. Betrouwbaarheidstechnici van de site observeren, onderhouden en optimaliseren gewoonlijk de geïmplementeerde services en nemen de verantwoordelijkheden van beheerders over.

Het onderscheidende kenmerk van SRE ten opzichte van traditionele bedrijfsvoering is de nadruk die het legt op automatisering. Infrastructuurcontroles, wijzigingsbeheer, audits en incidentrespons moeten allemaal binnen het model worden geautomatiseerd. De SRE-beoefenaar richt zich op het leveren en uitvoeren van softwaretools die deze taken uitvoeren, in plaats van directe interactie met het systeem zelf.

SRE verenigt ongelijksoortige aspecten van de operationele managementervaring. Door een toolgestuurd proces te gebruiken, zijn er minder plaatsen waar problemen kunnen optreden. Dit helpt de stabiliteit te vergroten naarmate systemen groeien, zelfs als de omvang van het SRE-team statisch blijft.

Wat doen SRE-ingenieurs eigenlijk?< /h2>

SRE-ingenieurs zijn meestal softwareontwikkelaars die ook ervaring hebben met het bedienen van productieservices. Dit geeft hen een holistisch bewustzijn van het leveringsproces, van code commit tot oplossing van incidenten. Ze zullen deze kennis gebruiken om mechanismen te ontwerpen en te implementeren voor het implementeren en bewaken van live-omgevingen.

Als “betrouwbaarheid” staat letterlijk in de naam, SRE-teams zijn ook verantwoordelijk voor het meten van de uptime en het bedenken van manieren om deze te verbeteren. SRE-ingenieurs stellen de serviceniveaudoelstellingen (SLO's) vast die betrouwbaarheidsdoelen voor de organisatie bieden. Ze zullen de serviceniveau-indicatoren (SLI's) vaststellen en observeren die aangeven of de doelstellingen worden bereikt, zoals het foutenpercentage, de verwerkingscapaciteit van aanvragen en het aantal tickets. SRE's zullen worden betrokken bij het schrijven van de Service Level Agreements (SLA's) die ook met klanten worden gedeeld.

SRE-ingenieurs zijn de effectieve poortwachters rond nieuwe implementaties. Hun focus op het behoud van stabiliteit betekent dat ze soms de implementatie vastzetten als een SLO of SLA op het punt staat te worden geschonden. Het SRE-team kan ontwikkelaars instrueren om zich te concentreren op het aanpakken van de oorzaak van incidenten, in plaats van door te gaan met het uitrollen van nieuw werk.

Geen enkele service kan verwachten dat deze met 100% betrouwbaarheid werkt. SRE onderkent dit door ontwikkelaars een “foutbudget” die ze mogen “uitgeven.” Zodra dat budget is overschreden door nieuwe bugs, tickets of storingen, wordt het oplossen van de problemen ieders prioriteit totdat het foutenbudget en de SLO's zijn hersteld.

Het kan een SRE-ingenieur zijn die dit herstelwerk voltooit door nieuwe code te schrijven. Doordat het SRE-team een achtergrond heeft in software engineering, zijn ze toegerust om op eigen initiatief problemen op te lossen. In tijden dat de service goed draait, keren mensen in SRE-rollen terug naar reguliere ontwikkelaars. Van de SRE-ingenieurs van Google wordt verwacht dat ze minstens de helft van hun tijd besteden aan ontwikkelingswerk.

Deze unieke balans tussen ontwikkeling en operaties helpt om het vermogen van de SRE-ingenieur om toezicht te houden op het leveringsproces te behouden. Hun niveau van zichtbaarheid is van onschatbare waarde als het gaat om het herkennen van risico's die een incident kunnen veroorzaken. Het moedigt ingenieurs ook aan om de tijd die aan operationele taken wordt besteed, te minimaliseren door nieuwe tools en geautomatiseerde procedures te implementeren. Dit kan een zichzelf in stand houdende cyclus creëren: een grotere mate van automatisering maakt de service meestal betrouwbaarder, waardoor de ops-werklast voor het SRE-team afneemt. Op hun beurt hebben ingenieurs de tijd om terug te keren naar ontwikkeling, waardoor de doorvoer toeneemt.

Hoe sluit SRE aan bij DevOps?

DevOps is een veelomvattende term die het gebruik van moderne technologieën en methodieken beschrijft om sneller software van hogere kwaliteit te leveren. Dit wordt bereikt door de kloof tussen ontwikkelings- en operationele teams te verkleinen en vervolgens automatisering over het softwareleveringsproces heen te leggen.

Tot nu toe klinkt dit vergelijkbaar met SRE. SRE heeft echter maar één doel voor ogen – betrouwbaarheid – terwijl DevOps ook rekening houdt met tangentiële problemen, zoals de efficiëntie van ontwikkelaars en leveringssnelheid. Het is opmerkelijk dat DevOps vaak wordt benaderd als een brug tussen ontwikkeling en operaties, terwijl SRE ze samensmelt. In SRE worden dev- en ops-taken door dezelfde mensen uitgevoerd, waarbij ontwikkeling de meeste aandacht krijgt.

Om deze redenen kan SRE worden gezien als een specifieke implementatie van DevOps. Hoewel de algemene doelstellingen vergelijkbaar zijn en sterk op elkaar zijn afgestemd, beschrijft SRE een methode om ze te bereiken: gebruik foutbudgetten, SLO's en SLI's om services te beschermen tegen fouten, en implementeer vervolgens beveiligingen die ervoor zorgen dat de werkbias terugkeert naar ontwikkeling.

< p>Benjamin Treynor Sloss, de Google-ingenieur die de term SRE bedacht, stelt dat SRE kan worden gezien als 'een specifieke implementatie van DevOps met enkele eigenaardige extensies'. Als alternatief kunt u het model omkeren en DevOps benaderen “als een generalisatie van verschillende kernprincipes van SRE naar een breder scala aan organisaties, managementstructuren en personeel.”

Een belangrijke manier waarop SRE verschilt van DevOps is de afhankelijkheid van data. DevOps wordt vaak gezien als een set principes voor het efficiënt verplaatsen van code van werkstations voor ontwikkelaars naar productieomgevingen. Dit betekent werken in termen van commits, merge requests, pipelines en containers. SRE is een strategie voor het implementeren van wijzigingen met maximale betrouwbaarheid en verminderde kans op regressie. Effectieve SRE vereist voortdurende observatie en analyse om uit te zoeken waar fouten zijn opgetreden en hoe deze zich in de toekomst kunnen herhalen. Het is onderzoekender en zelfbewuster dan een typische DevOps-implementatie.

Is SRE een goede carrièrestap?

SRE is pas onlangs begonnen de reguliere aandacht te trekken. Het kan een uitdaging zijn om een SRE-rol te vinden, omdat veel organisaties de voordelen van het model nog niet erkennen. In sommige gevallen kan een vorm van SRE aanwezig zijn binnen een organisatie, maar dit komt mogelijk niet tot uiting in de functies die ze adverteren.

Ondanks het gespecialiseerde karakter is SRE doorgaans een goede carrièrestap. Het vereist een kruising van vaardigheden, variërend van softwareontwikkeling tot servicebeheer en incidentrespons, met een goede mate van diepgang in elk. Er zijn maar weinig kandidaten die dit kunnen bieden, wat betekent dat SRE-functies vaak lucratieve functies zijn.

Een analyse door GitLab in april 2022 vond slechts 21.000 SRE-openingen terwijl er 104.000 DevOps-posities waren. Gegevens van Glassdoor gaven echter een salarisbereik aan tot $ 300.000 voor SRE-werk, in tegenstelling tot $ 234.000 voor DevOps.

Overstappen naar een SRE-rol kan een lonende kans zijn voor individuen die in het ontwikkelingsveld willen blijven terwijl ze praktische ervaring opdoen met servicebeheer. Het is vooral geschikt voor mensen die traditionele beheerdersrollen te repetitief en praktisch vinden. Als SRE wordt van je verwacht dat je operaties automatiseert, zoekt naar mogelijkheden om de servicekwaliteit te verbeteren en bij te dragen aan regelmatige ontwikkelingsinspanningen nadat de incidentpager is stilgevallen.

Conclusie

Site Reliability Engineering gebruikt methoden die vaak worden geassocieerd met softwareontwikkeling om serviceactiviteiten te automatiseren. SRE-engineers zijn ervaren ontwikkelaars die ook bekend zijn met de uitdagingen van het uitvoeren en schalen van services in productie. Ze vormen een toolchain voor het meten en optimaliseren van de betrouwbaarheid en nemen de taken over die voorheen werden uitgevoerd door toegewijde systeembeheerders.

SRE kan worden gezien als een implementatie van DevOps-principes. Het aanstellen van SRE-engineers moet resulteren in een meer veerkrachtige service die snelle veranderingen kan accepteren. Hiermee wordt het DevOps-doel bereikt om de software-implementatie te versnellen zonder dat dit ten koste gaat van de kwaliteit. SRE zet een specifieke strategie uit die hieraan werkt door de nadruk te leggen op het meten van gegevens en op de unificatie van dev- en ops-talent.

Terwijl DevOps nu algemeen wordt begrepen in de gemeenschap, blijft SRE een opkomend aandachtsgebied voor velen organisaties. Openingen kunnen moeilijker te vinden zijn, maar ze zijn meestal lucratiever als ze verschijnen. Dit weerspiegelt de gevarieerde reeks vaardigheden waarover SRE-ingenieurs moeten beschikken. De vraag zal de komende jaren waarschijnlijk snel groeien, dus dit is het moment voor kandidaten en organisaties om aandacht te besteden aan de verschuiving naar SRE.

LEES VOLGENDE

› 8 Tekenen dat de PSU van uw computer defect is
› We wilden een Star Trek Replicator en we kregen alleen Keurig-machines
› Apple iPhone 14 Review: de veilige keuze die het waard is om te kopen
› Hoe op te lossen “Uw systeem heeft geen toepassingsgeheugen meer” op een Mac
› Wat is de goedkoopste streamingdienst voor live sport?