V poslední době takové reklamy zaplavily internet. I přes příjemný plat se člověk neubrání rozpakům, že je uvnitř napsáno divoké kacířství. Nejprve se předpokládá, že „DevOps“ a „inženýr“ lze nějakým způsobem spojit do jednoho slova, a pak existuje náhodný seznam požadavků, z nichž některé jsou jasně zkopírovány z volného místa sysadmin.
V tomto příspěvku bych chtěl trochu pohovořit o tom, jak jsme se dostali do tohoto bodu života, co to vlastně DevOps je a co s tím teď dělat.
Taková volná místa se dají všemožně odsoudit, ale faktem zůstává: je jich hodně a tak trh v současnosti funguje. Uspořádali jsme konferenci devops a otevřeně prohlašujeme: „ - ne pro inženýry DevOps." Mnohým to bude připadat divné a divoké: proč lidé, kteří dělají zcela komerční akci, jdou proti trhu. Nyní si vše vysvětlíme.
O kultuře a procesech
Začněme tím, že DevOps není inženýrská disciplína. Vše začalo tím, že na kvalitu produktů nefunguje historicky zavedené rozdělení rolí. Když programátoři pouze programují, ale nechtějí nic slyšet o testování, je software plný chyb. Když je správcům jedno, jak nebo proč je software napsán, podpora se změní v peklo.
Například popis rozdílu mezi správcem systému a přístupem SRE ke správě služeb . Uvnitř byly provedeny zajímavé studie — je jasné, že nejlepším vývojářům se nějak podaří nasadit nové změny do produkce rychleji než jednou za hodinu. Testují rukama ne více než 10 % (to lze vidět z ). Jak to dělají? „Excel or die“ říká jeden z nadpisů zprávy. Pro podrobnou diskusi o těchto statistikách v kontextu testování se můžete podívat na hlavní poznámku Barucha Sadogurského na naší další konferenci, Heisenbug.
"Když mezi soudruhy není shoda,
Nebudou dobře fungovat.
A nevyjde z toho, pouze mouka.
Byla jednou labuť, rak a štika...“
Jaká část webových programátorů podle vás skutečně rozumí podmínkám, za kterých se jejich aplikace používají ve výrobě? Kolik z nich půjde za administrátory a pokusí se zjistit, co se stane, když databáze spadne? A kdo z nich půjde za testery a požádá je, aby je naučili správně psát testy? A jsou tam i ochranka, produktoví manažeři a hromada dalších lidí.
Celková myšlenka DevOps je vytvořit spolupráci mezi rolemi a odděleními. Za prvé, toho se nedosahuje nějakým chytře nakonfigurovaným softwarem, ale nácvikem komunikace. DevOps je o kultuře, postupech, metodologii a procesech. Neexistuje žádná technická specializace, která by na tyto otázky mohla odpovědět.
Začarovaný kruh
Kde se tehdy vzala disciplína „devops engineering“? Máme verzi! Nápady DevOps byly dobré – tak dobré, že se staly obětí vlastního úspěchu. Kolem celého tohoto tématu začali vířit nějací stínoví náboráři a obchodníci s lidmi, kteří mají svou atmosféru.
Představte si: včera jste dělali shawarmu v Chimki a dnes jste již velký muž, starší náborář. Je tam celý proces hledání a výběru kandidátů, vše není jednoduché, je potřeba tomu rozumět. Řekněme, že vedoucí oddělení řekne: najděte specialistu na X. Přiřadíme slovo „inženýr“ k X a máme hotovo. Potřebujete Linux? No, tohle je určitě linuxový inženýr, pokud chcete DevOps, tak DevOps inženýr. Volné místo se skládá nejen z titulu, ale musí se do něj zadat i nějaký text. Nejjednodušší je zadat sadu klíčových slov z Googlu, záleží na vaší fantazii. DevOps se skládá ze dvou slov – „Dev“ a „Ops“, což znamená, že musíme spojit klíčová slova související s vývojáři a správci, vše do jedné hromádky. Takto se objevují volná místa ohledně znalostí 42 programovacích jazyků a 20 let současného používání Kubernetes a Swarmu. Pracovní schéma.
Takto se v myslích lidí zakořenila nesmyslná a nemilosrdná představa o jistém „devopsovém“ superhrdinovi, který všechny nastaví tak, aby se nasadili do Jenkinse, a štěstí se dostaví. Ach, kdyby všechno bylo tak jednoduché. "A také takto můžete lovit systémové administrátory," myslí si HR, "je to módní slovo, klíčová slova jsou stejná, měli by vzít návnadu."
Poptávka vytváří nabídku a všechna tato prázdná místa byla zaplněna šíleným množstvím systémových administrátorů, kteří si uvědomili: můžete dělat všechno stejně jako předtím, ale dostanete několikrát více, když si budete říkat „devops“. Stejně jako jste konfigurovali servery přes SSH ručně jeden po druhém, budete je konfigurovat i nadále, ale nyní je to údajně devops praxe. Jedná se o nějaký komplexní fenomén, částečně související s podceňováním klasických adminů a humbukem kolem DevOps, ale obecně se stalo, co se stalo.
Takže máme nabídku a poptávku. Začarovaný kruh, který se živí sám. To je to, proti čemu bojujeme (včetně vytvoření konference Devoops).
Kromě systémových administrátorů, kteří se přejmenovali na „devops“, jsou samozřejmě další účastníci – například profesionální SRE nebo vývojáři Infrastructure-as-Code.
Co lidé dělají v DevOps (skutečně)
Takže se chcete dostat dopředu v učení a aplikaci postupů DevOps. Ale jak to udělat, kterým směrem se dívat? Je zřejmé, že byste se neměli slepě spoléhat na oblíbená klíčová slova.
Pokud existuje práce, někdo by ji měl dělat. Už jsme zjistili, že to nejsou „devops inženýři“, kdo tedy jsou? Správnější se zdá formulovat to nikoli z hlediska pozic, ale z hlediska konkrétních oblastí práce.
Nejprve můžete oslovit jádro DevOps – procesy a kulturu. Kultura je pomalý a obtížný byznys, a i když je to tradičně odpovědností manažerů, každý se na tom tak či onak podílí, od programátorů po administrátory. Před pár měsíci Tim Lister :
„Kultura je určena základními hodnotami organizace. Obvykle si toho lidé nevšimnou, ale jelikož jsme dlouhá léta pracovali v poradenství, jsme zvyklí si toho všimnout. Vstoupíte do společnosti a doslova během pár minut začnete cítit, co se děje. Říkáme tomu "příchuť". Někdy je tato vůně opravdu dobrá. Někdy způsobuje nevolnost. (...) Nemůžete změnit kulturu, dokud nepochopíte hodnoty a přesvědčení za konkrétními činy. Chování je snadné pozorovat, ale hledání přesvědčení je obtížné. DevOps je jen skvělým příkladem toho, jak se věci stávají stále složitějšími.“
Nechybí samozřejmě ani technická část problému. Pokud se váš nový kód otestuje za měsíc, ale bude vydán až o rok později a je fyzicky nemožné to celé urychlit, možná nebudete dodržovat osvědčené postupy. Dobré postupy jsou podporovány dobrými nástroji. Například s myšlenkou Infrastructure-as-Code můžete použít cokoli od AWS CloudFormation a Terraform po Chef-Ansible-Puppet. Tohle všechno musíte vědět a umět, a to už je docela inženýrská disciplína. Důležité je nezaměňovat příčinu s následkem: nejprve pracujete podle principů SRE a až poté tyto principy implementujete v podobě nějakých konkrétních technických řešení. Zároveň je SRE velmi obsáhlá metodika, která neříká, jak nastavit Jenkins, ale o pěti základních principech:
- Vylepšená komunikace mezi rolemi a odděleními
- Přijetí chyb jako nedílná součást práce
- Provádění změn postupně
- Použití nástrojů a další automatizace
- Měření všeho, co se měřit dá
Nejde jen o nějaký soubor prohlášení, ale o konkrétní . Například na cestě k přijetí chyb budete muset porozumět rizikům, měřit dostupnost a nedostupnost služeb pomocí něčeho jako SLI () a SLO (), naučte se psát posmrtné zprávy a zajistěte, aby jejich psaní nebylo děsivé.
V disciplíně SRE je použití nástrojů pouze jednou částí úspěchu, i když důležitou. Musíme se neustále technicky vyvíjet, dívat se na to, co se děje ve světě a jak to lze uplatnit v naší práci.
Cloud Native řešení se nyní stala velmi populární. Jak dnes definuje Cloud Native Computing Foundation, technologie Cloud Native umožňují organizacím vyvíjet a provozovat škálovatelné aplikace v dnešních dynamických prostředích, jako jsou veřejné, soukromé a hybridní cloudy. Příklady zahrnují kontejnery, sítě služeb, mikroslužby, neměnnou infrastrukturu a deklarativní rozhraní API. Všechny tyto techniky umožňují, aby volně spojené systémy zůstaly elastické, ovladatelné a vysoce pozorovatelné. Dobrá automatizace umožňuje inženýrům provádět velké změny často as předvídatelnými výsledky, aniž by to dělalo práci. To vše podporuje hromada známých nástrojů, jako jsou Docker a Kubernetes.
Tato poměrně komplikovaná a široká definice je způsobena tím, že oblast je také poměrně složitá. Na jedné straně se tvrdí, že nové změny do tohoto systému by měly být přidány zcela jednoduše. Na druhou stranu přijít na to, jak vytvořit jakési kontejnerové prostředí, ve kterém volně propojené služby žijí na softwarově definované infrastruktuře a jsou tam dodávány pomocí kontinuálního CI/CD, a kolem toho všeho vybudovat postupy DevOps – to vše vyžaduje více než jeden jíst psa.
Co s tím vším dělat
Každý tyto problémy řeší po svém: můžete například zveřejnit normální volná místa, abyste prolomili začarovaný kruh. Můžete zjistit, co znamenají slova jako DevOps a Cloud Native, a používat je správně a k věci. Můžete se rozvíjet v DevOps a demonstrovat správné přístupy na svém příkladu.
Pořádáme konferenci , která poskytuje příležitost ponořit se hlouběji do věcí, o kterých jsme právě mluvili. K tomu slouží několik skupin přehledů:
- Procesy a kultura;
- Site Reliability Engineering;
- Cloud Native;
Jak si vybrat, kam jít? Je tu jeden jemný bod. Na jedné straně je DevOps o interakci a my opravdu chceme, abyste navštěvovali prezentace z různých bloků. Na druhou stranu, pokud jste vývojový manažer, který se na konferenci přišel soustředit na jeden konkrétní úkol, pak vás nikdo neomezuje – zjevně půjde o blok o procesech a kultuře. Nezapomeňte, že po konferenci (po vyplnění formuláře pro zpětnou vazbu) budete mít nahrávky, takže méně důležité prezentace můžete sledovat později.
Na konferenci samotné samozřejmě nemůžete jít na tři stopy najednou, takže program organizujeme tak, že každý časový úsek má témata pro každý vkus.
Zbývá jen pochopit, co dělat, pokud jste inženýr DevOps! Nejprve se pokuste určit, co vlastně děláte. Obvykle toto slovo rádi nazývají:
- Vývojáři, kteří pracují na infrastruktuře. Skupiny zpráv o SRE a Cloud Native jsou pro vás nejvhodnější.
- Správci systému. Tady je to složitější. DevOops není o správě systému. Naštěstí je na internetu spousta výborných konferencí, knih, článků, videí atd. na téma správy systému. Na druhou stranu, pokud máte zájem rozvíjet se ve smyslu porozumění kultuře a procesům, poznávat cloudové technologie a detaily života s Cloud Native, pak vás rádi uvidíme! Přemýšlejte o tom: děláte administrativu a co potom budete dělat? Abyste se náhle neocitli v nepříjemné situaci, měli byste se to naučit hned.
Existuje další možnost: trváte na tom a budete nadále tvrdit, že jste konkrétně inženýr DevOps a nic jiného, ať už to znamená cokoliv. Pak vás musíme zklamat, DevOops není konference pro inženýry DevOps!
Vyklouznout z v Mnichově
DevOops 2020 Moskva se bude konat 29. až 30. dubna v Moskvě, vstupenky jsou již k dispozici .
Případně můžete do 8. února. Vezměte prosím na vědomí, že při vyplňování formuláře musíte vybrat cílové publikum, které bude mít z vaší zprávy největší prospěch (v seznamu se skrývá překvapení).
Zdroj: www.habr.com