SRE i kontext
Innan vi utforskar några av de metoder som är associerade med SRE kan det vara bra att placera några av de idéer vi lärt oss i den föregående enheten i kontext. I den här korta lektionen lär vi oss en del av historiken bakom SRE och hur den relaterar till andra åtgärder som du kanske är bekant med. Den här kunskapen ger oss större framgång senare eftersom dessa metoder är mer meningsfulla i sitt sammanhang. Dessutom, när dina vänner frågar "Hur skiljer sig SRE från ..." du har ett färdigt svar.
Historik
En mycket komprimerad historik över SRE börjar med dess ursprung på Google 2003. Ben Treynor, nu Treynor Sloss, tog över ledarskapet för Googles "Produktionsteam" (då bara sju programvaruingenjörer). Treynor skapade idén och beskrev den som "vad händer när du ber en programvarutekniker att utforma en driftsfunktion". Det är användbart att förstå den här historiken eftersom den hjälper till att förklara varför SRE kan känna sig mycket "programvaruteknik" för driftspersoner som möter den för första gången. Det har hämtat värden och verktyg från det fältet, som vikten av att koda och källkontrollsystem som ett grundläggande verktyg. Den inledande och aktuella implementeringen av Google SRE är väldokumenterad i deras två böcker som publicerats av O'Reilly (se utbildningsenheten Komma igång).
När personer från Google lämnade företaget (och anställda vid företaget började prata om deras metoder mer offentligt), började SRE sprida sig till fler organisationer inom branschen. I takt med att SRE spred sig till nya organisationer, införlivade och implementerade dessa organisationer SRE-principer och metoder efter den lokala kulturen. Den här expansionsprocessen har gett många olika implementeringar av SRE på fältet.
DevOps och SRE
Den större branschen står inför samma utmaningar när det gäller skalning, utvecklingshastighet kontra operativ stabilitet och andra problem med programvarudistribution som gav upphov till SRE-rörelsen. Parallella insatser för att bemöta dem utanför Google (och några få större företag då) gav upphov till DevOps.
Massor av bra information om DevOps finns i DevOps-resurscentret.
Kommentar
Det är viktigt att notera att DevOps och SRE är två olika, parallella försök att lösa samma utmaningar. SRE är inte nästa evolutionära steg efter DevOps. SRE skapades inte för att vara "DevOps framtid".
Hur SRE och DevOps skiljer sig åt är ett ämne som fortfarande diskuteras mycket på fältet. Det finns vissa skillnader som man är överens om, bland annat:
- SRE är ett teknikområde som fokuserar på tillförlitlighet. DevOps är en kulturell rörelse som uppstod ur driften att bryta ned silor som vanligtvis är associerade med separata utvecklings- och driftorganisationer.
- SRE kan vara namnet på en roll som i ”jag är en platstillförlitlighetstekniker”, men det kan inte DevOps vara. Ingen kan kallas sig för ”en DevOps”.
- SRE tenderar att vara mer regelstyrd, syftet med DevOps är att det inte ska vara det. Nästan universellt införande av kontinuerlig integrering/kontinuerlig leverans och flexibla principer är så nära de kommer varandra i det här avseendet.
De två disciplinerna, DevOps och SRE, delar en förkärlek för övervakning/observerande och automatisering (kanske av olika skäl). Den här sammanflödet är en anledning till att det ofta kan vara enklare att importera SRE-metoder och principer till en organisation med en befintlig DevOps-praxis. Den här processen måste göras med försiktighet och avsikt. Det kan och bör också implementeras stegvis, man behöver inte göra en plötslig växel.
Varning
Att bara byta titlar på personer inom organisationen är en implementeringsstrategi som nästan aldrig lyckas. Det ger inte de fördelar SRE har att erbjuda. Se avsnittet Komma igång i den här utbildningsenheten för några bättre förslag.
Slutsats
Den här korta utbildningsenheten har försökt att ge lite kontext runt SRE och DevOps. SRE och DevOps är bäst tänkta som angränsande tankeskolor i driftspraxis.
Nu när vi kort har tittat på en del av bakgrunden bakom SRE, låt oss gå direkt till några av dess kärnprinciper.