Na základě diskuse v chatu
V poslední době se vedou skutečné bitvy o definici pojmů DevOps a SRE.
I když už se mnohé diskuse na toto téma staly poněkud únavnými, i pro mě, rozhodl jsem se předložit své názory komunitě Habr. Pokud vás to zajímá, vítejte pod kat. Ať vše začíná znovu!
Pozadí
Takže, v dávných dobách žily odděleně týmy developerů a administrátorů serverů. První šťastně psali kód, druzí, používající různá vřelá slova vůči prvním, nastavovali servery, občas sešli k developerům a dostávali v odpověď vyčerpávající 'na mém stroji to funguje'. Firmy čekaly na software, všechno stálo, občas se to rozbilo a všichni byli nervózní. Zvlášť ten, kdo za ten nepořádek platil. Slavná lampová éra. Ale to už víte, odkud se berou DevOps.
Zrození praktik DevOps
Pak přišli vážní pánové a řekli - tohle není průmysl, takto fungovat nelze. A přivedli modely životního cyklu. Třeba V-model.
Takže, co vidíme? Firmy přicházejí s konceptem, architekti navrhují řešení, vývojáři píší kód, dále - propad. Někdo nějak testuje produkt, někdo nějak dodává koncovému uživateli a na výstupu tohoto zázračného modelu sedí osamělý obchodní objednavatel a čeká na slíbené zázraky. Došli k závěru - potřebují metody, které tento proces umožní zefektivnit. A rozhodli se vytvořit praktiky, které by je realizovaly.
Lyrické odbočení na téma, co je to praxe
Pod praktikou rozumím spojení technologie a disciplíny. Příklad - praxe popisu infrastruktury kódem v terraformu. Disciplína - to, jak popisovat infrastrukturu kódem, to je v hlavě vývojáře, a technologie - to je vlastně terraform.
A rozhodli se je nazvat DevOps praktikami — myslím, že tím měli na mysli z vývoje do provozu. Vymysleli různé komplikované věci — CI/CD praktiky, praktiky založené na principu IaC, tisíce jich. A začalo to, vývojáři píší kód, DevOps inženýři transformují popis systému v podobě kódu na fungující systémy (ano, kód je bohužel pouze popis, ale nikoli ztělesnění systému), dodávka se rozbíhá, a tak dále. Včerejší administrátoři, kteří se naučili nové praktiky, se hrdě přeškolili na DevOps inženýry, a všechno se rozjelo. A byl večer, a bylo ráno… omlouvám se, to není odtud.
Všechno opět není s Bohem.
Jakmile se vše uklidnilo, začali různí chytrí „metodologové“ psát tlusté knihy o DevOps praktikách, tiše se rozhořely spory o tom, kdo vlastně je pověstný DevOps inženýr a co DevOps — to je kultura výroby, opět vzešlo nesouhlasné hlasy. Najednou se ukázalo, že dodávka softwaru — je naprosto netriviální úkol. Každá vývojová infrastruktura má svůj vlastní stack, někde je potřeba něco sestavit, někde nasadit prostředí, tady je potřeba tomcat, jinde ještě nějaký složitý způsob spuštění — obecně, hlava praská. A ještě problém, jak se ukázalo, je především v organizaci procesů — tato funkce dodávky, jako úzké hrdlo, začala blokovat procesy. Kromě toho provoz (Operations) nikdo nezrušil. V modelu V není vidět, a tam je ještě celý životní cyklus vpravo. Nakonec je třeba nějakým způsobem udržovat infrastrukturu, sledovat monitoring, řešit incidenty, a ještě se věnovat dodávce. Tedy sedět jednou nohou jak v vývoji, tak v provozu — a najednou vznikl takový Development & Operations. A k tomu ještě dorazil masivní hype na mikroservisy. A s nimi také vývoj z lokálních strojů začal přecházet do cloudu — zkus něco odladit lokálně, pokud je mikroservisů desítky a stovky, tady už stálá dodávka se stává prostředkem přežití. Pro „malou skromnou firmu“ ještě jde, ale co Google?
SRE od Google
Přišel Google, snědl největší kaktusy a rozhodl se – tohle nepotřebujeme, potřebujeme spolehlivost. A spolehlivost je třeba řídit. A rozhodl – potřebujeme specialisty, kteří budou spolehlivost řídit. Nazval je SR inženýry a řekl: tady máte všechno, udělejte to, jak jste zvyklí, dobře. Tady máte SLI, tady máte SLO, tady máte monitoring. A ukázal jim na operace. A nazval svůj "spolehlivý DevOps" SRE. Vypadá to všechno dobře, ale existuje jeden špinavý hack, který si Google mohl dovolit – na pozici SR inženýrů najímat lidi s kvalifikací vývojářů, kteří se kromě toho ještě trochu vyznali ve fungování běžících systémů. Potíže s najímáním těchto lidí měl i samotný Google – především proto, že zde soutěží sám se sebou – přece jen je potřeba také popsat byznys logiku. Dodávky přehodil na release inženýry, SR inženýři řídí spolehlivost (jasně, ne přímo, ale ovlivněním infrastruktury, změnou architektury, sledováním změn a ukazatelů, řešením incidentů). Pěkné, že? . A co dělat, když nejste Google a spolehlivost vás přece jen nějak trápí?
Vývoj myšlenek DevOps
Tady právě dorazil Docker, který vyrostl z lxc a poté různé orchestrace jako Docker Swarm a Kubernetes, a DevOps inženýři si oddechli – unifikace praktik zjednodušila dodávku. Zjednodušila to tak, že se dokonce stalo možné svěřit dodávku vývojářům – co by takové deployment.yaml. Containerizace řeší problém. A zralost systémů CI/CD už dosahuje úrovně, kdy stačí napsat jeden soubor a vše jede – vývojáři si s tím poradí sami. A tady začínáme mluvit o tom, jak udělat své SRE, s… kdokoli.
SRE ne v Googlu
Dobře, dopravu jsme vyřídili, zdá se, že můžeme vydechnout a vrátit se k těm dobrým starým časům, kdy administrátoři sledovali zatížení procesorů, ladili systémy a tiše popíjeli něco neznámého z hrnků v tichu a klidu... Zastavte se. Nedělali jsme to všechno kvůli tomu (škoda!). Najednou se ukazuje, že v přístupu Googlu můžeme převzít skvělé praktiky — není důležité zatížení procesorů, ani jak často měníme disky nebo optimalizujeme náklady v cloudu, ale obchodní metriky — všechny ty proslulé SLx. A správa infrastruktury s tím nikdo nezrušil, incidenty je třeba řešit, pravidelně být na stráži a vůbec se orientovat v obchodních procesech. A kluci, začněte už pomalu programovat na dobré úrovni, Googlu se už po vás stýská.
Shrnuto. Náhle, ale už jste unaveni číst a nemůžete se dočkat, až napíšete autorovi článek v komentářích. DevOps jako praktiky dodávání byly, jsou a budou. A nikam nezmizí. SRE jako soubor praktických úkolů pro provozování dělá toto dodávání úspěšným.
Zdroj: habr.com
