SRE v kontextu
Než začneme zkoumat některé postupy spojené se SRE, bude dobré si zasadit do souvislostí pár myšlenek, se kterými jsme se seznámili v předchozí lekci. V této krátké lekci se dozvíme o historii SRE a o tom, jak souvisí s jinými provozními postupy, se kterými se můžete seznámit. Tyto znalosti nás později nastaví pro větší úspěch, protože tyto postupy mají větší smysl v kontextu. Také, když se vaši přátelé zeptat "Jak se SRE liší od ..." máte připravenou odpověď.
Historie
Velmi zhuštěná historie SRE začíná v roce 2003 ve společnosti Google. Ben Treynor, nyní Treynor Sloss, převzal vedení "produkčního týmu" Společnosti Google (pak pouze sedm softwarových inženýrů). Treynor vytvořil myšlenku a proslavně ji popsal jako "co se stane, když požádáte softwarového inženýra o návrh provozní funkce". Je užitečné pochopit tuto historii, protože pomáhá vysvětlit, proč se SRE může cítit velmi "softwarové inženýrství" provozním lidem, kteří ji poprvé potkali. Přejala totiž z téhle oblasti hodnoty a nástroje, jako jsou například důležitost kódování nebo systémy kontroly zdrojového kódu jako základní nástroj. Původní a současná implementace SRE společnosti Google je velice dobře popsaná v jejich dvou knihách vydaných nakladatelstvím O'Reilly (viz jednotka Začínáme).
S tím, jak lidé z Googlu přecházeli do jiných společností (a lidé ze společnosti mluvili o postupech SRE více veřejně), začala se SRE šířit do dalších organizací. SRE se rozšířila do nových organizací, které přijaly a přizpůsobily si principy SRE tak, aby vyhovovaly jejich místní kultuře. Tento proces rozšíření přinesl v terénu mnoho různých implementací SRE.
DevOps a SRE
Celé softwarové odvětví čelilo obdobným výzvám ohledně škálování, rychlost vývoje versus provozní stabilita a další záležitosti týkající se dodávání softwaru, které stály u zrodu hnutí SRE. Paralelní úsilí o řešení těchto problémů mimo Google (a několik tehdy větších společností) přineslo principy DevOps.
Spoustu dobrých informací o DevOps najdete v centru prostředků DevOps.
Poznámka:
Tady je nutné poznamenat, že DevOps a SRE jsou dva různé paralelní přístupy k řešení stejných problémů. SRE není dalším vývojovým stupněm po DevOps. SRE se nevytvořilo tak, aby se jednalo o budoucnost DevOps.
Jak se SRE a DevOps liší, je téma, které je stále pod značným popisem v dané oblasti. Tady uvádíme pár rozdílů, o kterých panuje obecně shoda:
- SRE je technická disciplína, která se zaměřuje na spolehlivost. DevOps je kulturní hnutí, které vzniklo z nutkání rozdělit sila obvykle spojená s samostatnými organizacemi pro vývoj a provoz.
- O SRE by se dalo mluvit jako o určité roli na pracovišti („Dělám u nás SRE...“), což u DevOps moc nejde. Jeden člověk může dělat SRE, ale jeden člověk nemůže dělat DevOps.
- SRE je obecně direktivnější, DevOps záměrně naopak. Téměř univerzální přijetí kontinuální integrace a dodávání a principů Agile jsou v tomto ohledu nejblíž.
Tyto dva provozní postupy, DevOps a SRE, sdílejí zaujetí pro monitorování/pozorovatelnosti a automatizaci, i když patrně z různých důvodů. Tento soutok je jedním z důvodů, proč může být často jednodušší importovat postupy a principy SRE do organizace s existující praxí DevOps. Tento proces je třeba provést opatrně a promyšleně. Může a měla by být implementována přírůstkově, není nutné provést náhlé přepnutí.
Upozorňující
Pouhé prohození názvů pracovních pozic je strategie implementace, která je téměř vždy odsouzena k nezdaru. Nepřinese to výhody, které jinak může SRE nabídnout. V části Začínáme této jednotky naleznete další zajímavé návrhy.
Závěr
V této krátké jednotce jsme se pokusili zasadit SRE a DevOps do trochu širšího kontextu. SRE a DevOps se nejlépe považují za sousední školy myšlení v provozních postupech.
Teď, když jsme se krátce podívali na některé pozadí za SRE, pojďme přejít přímo na některé z jeho základních principů.