Na základě chatové diskuze
V poslední době se o definici DevOps a SRE rozhořely skutečné bitvy.
Navzdory tomu, že mi diskuse na toto téma v mnohém již nabraly zuby, včetně mě, rozhodl jsem se svůj pohled na toto téma přinést na soud komunity Habra. Pro zájemce vítejte na kat. A nechť vše začne znovu!
pravěk
V dávných dobách tedy tým vývojářů softwaru a správců serverů žil odděleně. První úspěšně napsal kód, druhý pomocí různých vřelých, láskyplných slov adresovaných prvnímu nastavil servery, pravidelně přicházel k vývojářům a dostával jako odpověď vyčerpávající „na mém počítači vše funguje“. Obchod čekal na software, všechno bylo nečinné, periodicky se kazilo, všichni byli nervózní. Zvláště ten, kdo za celý tento nepořádek zaplatil. Slavná éra lamp. No, už víte, odkud DevOps pochází.
Zrození praktik DevOps
Pak přišli seriózní kluci a řekli - tohle není průmysl, takhle se nedá pracovat. A přinesli modely životního cyklu. Zde je například model V.
Co tedy vidíme? Podnik přichází s konceptem, architekti navrhují řešení, vývojáři píší kód a pak neúspěch. Někdo produkt nějak otestuje, někdo ho nějak doručí koncovému uživateli a někde u výstupu tohoto zázračného modelu sedí osamělý obchodní zákazník čekající na slíbené počasí u moře. Došli jsme k závěru, že potřebujeme metody, které nám umožní tento proces nastolit. A rozhodli jsme se vytvořit postupy, které by je zavedly.
Lyrická odbočka na téma, co je praxe
Praxí mám na mysli kombinaci techniky a disciplíny. Příkladem je praxe popisu infrastruktury pomocí terraformního kódu. Disciplína je způsob, jak popsat infrastrukturu kódem, je to v hlavě vývojáře a technologie je samotná terraforma.
A rozhodli se jim říkat postupy DevOps – myslím, že mysleli od vývoje k provozu. Přišli jsme na různé chytré věci – praktiky CI/CD, praktiky založené na principu IaC, tisíce. A jedeme, vývojáři píší kód, inženýři DevOps transformují popis systému ve formě kódu do fungujících systémů (ano, kód je bohužel jen popis, ale ne ztělesnění systému), dodávka pokračuje, a tak dále. Včerejší administrátoři, kteří si osvojili nové postupy, se hrdě přeškolili na inženýry DevOps a vše šlo odtud. A byl večer a bylo ráno... pardon, ne odtud.
Zase to není dobré, díky bohu
Jakmile se vše uklidnilo a různí vychytralí „metodikové“ začali psát tlusté knihy o postupech DevOps, potichu se rozhořely spory o tom, kdo je notoricky známý inženýr DevOps a že DevOps je produkční kultura, znovu se objevila nespokojenost. Najednou se ukázalo, že dodávka softwaru je naprosto netriviální úkol. Každá vývojová infrastruktura má svůj stack, někde je potřeba sestavit, někde nasadit prostředí, tady Tomcat, tady mazaný a komplikovaný způsob, jak to spustit – obecně se vám třeští hlava. A problém se kupodivu ukázal především v organizaci procesů – tato doručovací funkce jako úzké hrdlo začala procesy blokovat. Navíc nikdo nezrušil Operations. U modelu V to není vidět, ale vpravo je stále celý životní cyklus. Ve výsledku je potřeba nějak udržovat infrastrukturu, monitorovat monitoring, řešit incidenty a také řešit doručování. Tito. sedět jednou nohou ve vývoji i provozu – a najednou se ukázalo, že je to Development & Operations. A pak tu byl všeobecný humbuk pro mikroslužby. A s nimi se vývoj z lokálních strojů začal přesouvat do cloudu – zkuste něco odladit lokálně, pokud existují desítky a stovky mikroslužeb, pak se neustálé doručování stává prostředkem k přežití. Pro „malou skromnou společnost“ to bylo v pořádku, ale přesto? A co Google?
SRE od společnosti Google
Google přišel, snědl největší kaktusy a rozhodl se – tohle nepotřebujeme, potřebujeme spolehlivost. A spolehlivost se musí řídit. A rozhodl jsem se, že potřebujeme specialisty, kteří budou řídit spolehlivost. Nazval jsem je inženýři SR a řekl jsem, to je pro vás vše, dělejte to dobře jako obvykle. Tady je SLI, tady SLO, tady monitorování. A strkal nos do operací. A své „spolehlivé DevOps“ nazval SRE. Vše se zdá být v pořádku, ale je tu jeden špinavý hack, který si Google mohl dovolit – na pozici SR inženýrů najmout lidi, kteří byli kvalifikovaní vývojáři a také dělali trochu domácích úkolů a rozuměli fungování fungujících systémů. Navíc i samotný Google má s najímáním takových lidí problémy - hlavně proto, že tady soutěží sám se sebou - je potřeba někomu popsat obchodní logiku. Dodávka byla zadána release engineerům, SR - inženýři řídí spolehlivost (samozřejmě ne přímo, ale ovlivňováním infrastruktury, změnou architektury, sledováním změn a indikátorů, řešením incidentů). Pěkné, můžeš . Ale co když nejste Google, ale spolehlivost vás stále nějak znepokojuje?
Vývoj nápadů DevOps
Právě tehdy přišel Docker, který vyrostl z lxc, a pak si různé orchestrační systémy jako Docker Swarm a Kubernetes a inženýři DevOps vydechli – sjednocení postupů zjednodušilo doručování. Zjednodušilo to do té míry, že bylo možné dokonce outsourcovat doručování vývojářům – což je deployment.yaml. Kontejnerizace problém řeší. A vyspělost CI/CD systémů je již na úrovni zápisu jednoho souboru a jde se na to – vývojáři si s tím poradí sami. A pak se začneme bavit o tom, jak si můžeme udělat vlastní SRE, s... nebo alespoň s někým.
SRE není na Googlu
No ok, dodávku jsme doručili, zdá se, že si můžeme vydechnout, vrátit se do starých dobrých časů, kdy admini sledovali zátěž procesoru, ladili systémy a tiše v klidu a v pohodě usrkávali z hrnků něco nesrozumitelného... Stop. To není důvod, proč jsme všechno začali (což je škoda!). Najednou se ukazuje, že v přístupu Google můžeme snadno převzít vynikající postupy – není důležité zatížení procesoru, ani to, jak často tam měníme disky nebo optimalizujeme náklady v cloudu, ale obchodní metriky jsou stejně notoricky známé SLx. A nikdo z nich neodstranil správu infrastruktury a potřebují řešit incidenty, být pravidelně ve službě a obecně mít přehled o obchodních procesech. A kluci, začněte programovat postupně na dobré úrovni, Google už na vás čeká.
Shrnout. Najednou, ale už jste unaveni čtením a nemůžete se dočkat, až si odplivnete a napíšete autorovi do komentáře k článku. DevOps jako způsob doručení vždy byl a bude. A nikam to nevede. SRE jako soubor provozních postupů činí tuto dodávku velmi úspěšnou.
Zdroj: www.habr.com