SRE in context
Voordat we enkele van de procedures behandelen die betrekking hebben op SRE, is het goed om een paar van de ideeën die we zojuist in de vorige eenheid hebben geleerd in context te plaatsen. In deze korte les leren we een deel van de geschiedenis achter SRE en hoe het zich verhoudt tot andere werkwijzen waarmee u mogelijk bekend bent. Deze kennis stelt ons later in voor meer succes, omdat deze procedures logischer zijn in de context. Ook, wanneer uw vrienden vragen "Hoe verschilt SRE van ..." je hebt een klaar antwoord.
Historie
Een zeer beknopte geschiedenis van SRE begint met de oorsprong bij Google in 2003. Ben Treynor, nu Treynor Sloss, nam leiding over van het 'productieteam' van Google (dan slechts zeven softwaretechnici). Treynor maakte het idee en beschreef het als 'wat er gebeurt wanneer u een software-engineer vraagt om een operationele functie te ontwerpen'. Het is handig om deze geschiedenis te begrijpen omdat het helpt uitleggen waarom SRE zich zeer 'software-engineering' kan voelen aan operationele mensen die het voor het eerst ontmoeten. SRE heeft waarden en tools van dat vakgebied overgenomen, zoals het belang van programmeren en bronbeheersystemen als fundamentele tool. De oorspronkelijke en huidige implementatie van Google SRE wordt goed gedocumenteerd in hun twee boeken die zijn gepubliceerd door O'Reilly (zie de eenheid Aan de slag).
Toen werknemers van Google het bedrijf verlieten (en personen in het bedrijf meer in het openbaar over hun procedures begonnen te praten), breidde SRE zich naar meer organisaties in de branche uit. Bij de uitbreiding van SRE naar nieuwe organisaties werden de SRE-principes en -procedures aan de lokale cultuur van die organisaties aangepast. Dit uitbreidingsproces heeft veel verschillende implementaties van SRE in het veld opgeleverd.
DevOps en SRE
Ook andere organisaties werden geconfronteerd met dezelfde uitdagingen rond schalen, ontwikkelingssnelheid versus operationele stabiliteit en andere softwareleveringsproblemen die werden voortgebracht door de beweging voor sitebetrouwbaarheidsenigeering. Parallelle inspanningen om deze buiten Google (en enkele grotere bedrijven op dat moment) af te handelen resulteerden in DevOps.
Zie het DevOps-resourcecentrum voor veel goede informatie over DevOps.
Notitie
Het is belangrijk te weten dat DevOps en SRE twee verschillende parallelle pogingen zijn om dezelfde uitdagingen aan te pakken. SRE is niet de volgende evolutionaire stap na DevOps. SRE is niet gemaakt om 'de toekomst van DevOps' te zijn.
Hoe SRE en DevOps verschillen, is een onderwerp dat nog steeds in aanzienlijke discussie op dit gebied wordt behandeld. Er zijn enkele verschillen waarover men het in het algemeen wel eens is, zoals:
- SRE is een technische discipline die zich richt op betrouwbaarheid. DevOps is een culturele beweging die voortkwam uit de drang om de silo's op te splitsen die doorgaans zijn gekoppeld aan afzonderlijke Ontwikkelings- en Operations-organisaties.
- SRE kan de naam van een rol zijn zoals in 'Ik ben een sitebetrouwbaarheidstechnicus (site reliability engineer, SRE)’, DevOps niet. Strikt genomen is niemand van beroep een 'DevOps'.
- SRE is doorgaans meer voorschrijvend, DevOps is dit heel bewust niet. Bijna universele acceptatie van continue integratie/continue levering en flexibiliteitsbeginselen beschrijven dit waarschijnlijk nog het beste.
Bij beide bewerkingenprocedures, DevOps en SRE, gaat het om bewaking en automatisering (al is het misschien om verschillende redenen). Deze samenvloeiing is een van de redenen waarom het vaak eenvoudiger kan zijn om SRE-procedures en -principes in een organisatie te importeren met een bestaande DevOps-praktijk. Dit proces moet met zorg en voor een bepaald doel worden uitgevoerd. Het kan en moet incrementeel worden geïmplementeerd, u hoeft niet plotseling over te schakelen.
Waarschuwing
Het alleen verwisselen van titels voor personen in de organisatie is een implementatiestrategie die bijna geen kans van slagen heeft. Het levert niet de voordelen die SRE te bieden heeft. Zie het gedeelte Aan de slag van deze eenheid voor enkele betere suggesties.
Conclusie
In deze korte eenheid is geprobeerd SRE en DevOps een beetje in context te plaatsen. SRE en DevOps worden het beste beschouwd als aangrenzende scholen van gedachten in operationele procedures.
Nu we kort naar enkele achtergronden achter SRE hebben gekeken, gaan we meteen naar enkele van de belangrijkste principes gaan.