Site Reliability Engineering

Site Reliability Engineering is een discipline die aspecten van software engineering omvat en deze toepast op infrastructuur en operationele problemen. Aspecten zoals build, test en release. Net zoals build, test en release van software gedaan wordt, bouwen we tegenwoordig ook infrastructuur. De belangrijkste doelen hierin zijn het creëren van schaalbare en zeer betrouwbare softwaresystemen.

Site Reliability Engineering

Wat doet een SRE?

Een SRE houdt zich voornamelijk bezig met werk wat traditioneel door een operationeel team gedaan wordt. Dit zijn engineers die ervaring hebben op het gebied van operations, automatisering of software development. Het leuke is dat deze engineers van nature zowel de neiging als het vermogen hebben, om menselijke arbeid zoveel mogelijk te elimineren door het ’weg‘ te automatiseren. Het automatiseren van traditionele beheertaken zorgt voor minder kans op menselijke fouten, maakt meer tijd vrij voor innovatie en resulteert in een hoger efficiency niveau. En, niet onbelangrijk: dit zorgt in het algemeen voor een hoger niveau van tevredenheid bij de engineers en de eindgebruikers.

In het algemeen is een SRE-team verantwoordelijk voor beschikbaarheid, latentie, prestaties, efficiëntie, verandermanagement, monitoring, reactie op noodsituaties en capaciteitsplanning of een subset hiervan.

Het uiteindelijke doel van SRE's is om, zoals Google het uitdrukt, binnen een jaar hun eigen baan weg te automatiseren. Een belangrijke manier om dit te doen is het bouwen van zelfbedieningstools voor gebruikersgroepen die afhankelijk zijn van hun diensten. Bijvoorbeeld  automatische levering van testomgevingen, logboeken en statistische visualisatie. Hierdoor wordt het uitvoerende werk voor alle partijen minder. De ontwikkelaars kunnen zich vervolgens volledig richten op de ontwikkeling van software. De SRE kan zich daarna richten op de volgende automatiseringslag, waarmee het proces weer van voor af aan begint.

Belangrijke schakel

SRE's werken nauw samen met productontwikkelaars om ervoor te zorgen dat de ontworpen oplossing voldoet aan niet-functionele eisen zoals beschikbaarheid, prestaties, veiligheid en onderhoudbaarheid. Ze werken ook samen met release engineers om ervoor te zorgen dat de software delivery pipeline zo efficiënt mogelijk is.

Er wordt vaak geprobeerd SRE te labelen met als doel een specifieke operationele rol te definiëren die buiten het ontwikkelproces valt. Maar zij zijn net zo belangrijk voor het ontwikkelproces als het hebben van front of backend ontwikkelaars, testers, UX-ers of DBA’ers. Samen dragen zij de verantwoordelijkheid voor het bouwen en deployen van een schaalbare en goed functionerende dienst. Een SRE versterkt een development team met de inzichten, expertise en een gedeelde verantwoordelijkheid om een steeds maar beter product of service te leveren.

Interview met een SRE

HubSpot Video

 

Verschillen DevOps & SRE

Omdat SRE unaniem verbonden is aan DevOps worden deze termen vaak door elkaar gehaald. DevOps richt zich op de vraag wat er gedaan moet worden en SRE richt zich op hoe dat gedaan kan worden. Om het verschil tussen DevOps en SRE uit te leggen, kijken we eerst naar DevOps. DevOps is een mindset; een niet eenvoudige cultuurverandering binnen organisaties. DevOps streeft naar een simpel, maar belangrijk doel om IT eenvoudiger, sneller en goedkoper te maken, om zo sneller meer waarde te bieden aan de business (voor gebruikers, ketenpartners en burgers). Uiteindelijk draait het om een effectievere samenwerking tussen de ontwikkelaars en beheerders. DevOps is samen te vatten in de zin: “Waarom moeilijk doen als het samen kan?”. Waarom de verantwoordelijkheden scheiden als het delen ervan een natuurlijke drijfveer is tot succes?

Verschillende manieren hoe we samenwerken

01. Resourcing

  • Tijdelijke inzet, blijvende impact. Een SRE engineer van HCS Company vergeet je niet snel. Zeer ervaren. Super gemotiveerd. Vakidioot. Tikkeltje bijzonder. Hij brengt je een stap verder.

02. Consulting

De ervaring spat er vanaf! Wij zijn allround: Been there, done that. Gebruik onze kennis bij specifieke, afgebakende onderwerpen en voorkom dat je het wiel zelf gaat uitvinden. 

03. Co-sourcing

Waarom moeilijk doen als het samen kan? Samen één team, één doel. Flexibel op- en afschalen. Bijsturen waar nodig. Altijd nodig. Samenwerken op basis gelijkwaardigheid.