Er is een reeks veelgestelde vragen over de relatie tussen sitebetrouwbaarheidsengineering en DevOps, waaronder 'Hoe zijn ze hetzelfde? Hoe verschillen ze van elkaar? Kunnen we beide in onze organisatie hebben?". Dit artikel probeert enkele van de antwoorden te delen die zijn aangeboden door de SRE- en DevOps-community's die ons dichter bij een goed begrip van deze relatie brengen.
Hoe zijn ze hetzelfde?
SRE en DevOps zijn zowel moderne operationele procedures die zijn gemaakt en ontwikkeld als reactie op uitdagingen die het volgende omvatten:
- een groeiende complexiteit van onze productieomgevingen en ontwikkelingsprocessen
- een groeiende afhankelijkheid van ondernemingen van een continue werking van die omgevingen
- het onvermogen om het personeel lineair te schalen met de grootte van deze omgevingen
- de noodzaak om sneller te gaan terwijl de operationele stabiliteit behouden blijft
Beide werkwijzen waarderen aandacht voor onderwerpen die van cruciaal belang zijn voor het omgaan met deze uitdagingen, zoals bewaking/waarneembaarheid, automatisering, documentatie en hulpprogramma's voor het ontwikkelen van gezamenlijke software.
Er is aanzienlijke overlapping in hulpprogramma's en werkgebieden tussen SRE en DevOps. Zoals de sitebetrouwbaarheidswerkmap het plaatst, gelooft SRE in dezelfde dingen als DevOps, maar om iets andere redenen.
Drie verschillende manieren om de twee werkwijzen voor bewerkingen te vergelijken
De overeenkomsten tussen SRE en DevOps zijn duidelijk. Waar het echt interessant wordt, is hoe de twee verschillen of afwijken. Hier bieden we drie manieren om na te denken over hun relatie als een manier om wat nuances aan deze vraag te brengen. U bent het misschien niet eens met deze antwoorden, maar ze bieden elk een goede startplaats voor discussie.
"Klasse SRE implementeert interface DevOps"
In de sitebetrouwbaarheidswerkmap (vermeld in onze lijst met resourceboeken) worden SRE en DevOps in het eerste hoofdstuk besproken. In dat hoofdstuk wordt de woordgroep 'klasse SRE implementeert interface DevOps' als subtitel gebruikt. Dit is bedoeld om te suggereren (met behulp van een woordgroep die is gericht op ontwikkelaars) dat SRE als een specifieke implementatie van de DevOps-filosofie kan worden beschouwd. Zoals in het hoofdstuk wordt aangegeven, is DevOps relatief stil bij het uitvoeren van bewerkingen op gedetailleerd niveau, terwijl SRE aanzienlijk meer proscriptief is in zijn procedures. Eén mogelijk antwoord op de vraag hoe de twee betrekking hebben op SRE, kan dus worden beschouwd als een van de vele mogelijke implementaties van DevOps.
SRE is van betrouwbaarheid, omdat DevOps is voor levering
Deze vergelijking is een beetje modderig omdat er meerdere definities zijn voor zowel SRE als DevOps, maar het is nog steeds mogelijk nuttig. Het begint met de vraag "Als u elke bewerkingspraktijk moet destilleren in een of twee woorden die de kernvraag weerspiegelen, wat zou het zijn?"
Als we deze definitie van SRE van de sitereliability engineering hub gebruiken:
Site Reliability Engineering is een engineeringsdiscipline die zich richt op het helpen van organisaties om duurzaam de juiste mate van betrouwbaarheid in hun systemen, services en producten te realiseren.
dan zou het gemakkelijk zijn om het woord voor SRE te zeggen is 'betrouwbaarheid'. Omdat het midden in de naam staat, biedt ook een aantal uitstekende bewijzen voor deze claim.
Als we deze definitie van DevOps gebruiken vanuit het Azure DevOps-resourcecentrum:
DevOps is de combinatie van mensen, processen en producten om continu waarde te kunnen bieden aan onze eindgebruikers.
dan kan een vergelijkbare distillatie voor DevOps 'levering' zijn.
Daarom is 'SRE is van betrouwbaarheid naarmate DevOps wordt geleverd'.
Richting van aandacht
Dit antwoord wordt geciteerd of enigszins geparafraseerd op basis van een bijdrage vanThomas Thomas aan het boek Seeking SRE vermeld in onze lijst met resourceboeken. Hij merkt op dat DevOps-technici zich grotendeels richten op de pijplijn voor de levenscyclus van softwareontwikkeling met incidentele verantwoordelijkheden voor productiebewerkingen, terwijl SRE's zich richten op productiebewerkingen met incidentele SDLC-pijplijnverantwoordelijkheden.
Maar belangrijker nog, hij tekent ook een diagram dat begint met het softwareontwikkelingsproces aan de ene kant en de productiebewerkingen aan de andere kant. De twee zijn verbonden door de gebruikelijke pijplijn die is gebouwd om de code van een ontwikkelaar te halen, door het gewenste aantal tests en fases te verplaatsen en die code vervolgens naar productie te verplaatsen.
Limon bedrijfsprocesstroom merkt op dat DevOps-technici beginnen bij de ontwikkelomgeving en stappen voor productie automatiseren. Zodra dit is voltooid, gaan ze terug om knelpunten te optimaliseren.
SRE's richten zich daarentegen op productiebewerkingen en bereiken diep in de pijplijn als een middel om het eindresultaat te verbeteren (in principe in omgekeerde richting werken).
Het is dit verschil in de richting van de SRE- en DevOps-focus die kan helpen deze te onderscheiden.
Co-existentie in dezelfde organisatie
De laatste vraag die we willen aanpakken, is 'Kunt u zowel SRE als DevOps in dezelfde organisatie hebben?'
Het antwoord op deze vraag is een nadrukkelijk "ja!".
We hopen dat de vorige antwoorden een idee geven hoe de twee werkwijzen elkaar overlappen en, wanneer ze niet overlappen, hoe ze elkaar kunnen aanvullen. Organisaties met een gevestigde DevOps-praktijk kunnen op kleine schaal experimenteren met SRE-procedures (bijvoorbeeld sla's en SLO's proberen) zonder dat ze zich hoeven bezig te houden met het maken van SRE-posities of -teams. Dit is een vrij gebruikelijk SRE-acceptatiepatroon.
Volgende stappen
Bent u geïnteresseerd in meer informatie over sitebetrouwbaarheidstechniek of DevOps? Bekijk onze site reliability engineering hub en Azure DevOps Resource Center.