V poslední době se na internetu objevilo mnoho takových inzerátů. I přes lákavou mzdu nemůže nevyvolávat znepokojení, že uvnitř jsou napsány šílené nesmysly. Zpočátku se předpokládá, že lze nějakým způsobem spojit „DevOps“ a „inženýr“ do jednoho slova, a poté následuje náhodný seznam požadavků, z nichž část byla zjevně zkopírována z inzerátu na systémového administrátora.
V tomto příspěvku bych chtěl trochu hovořit o tom, jak jsme se dostali do této situace, co vlastně DevOps je a co s tím nyní dělat.
Takové nabídky lze různě kritizovat, ale fakt zůstává faktem: je jich mnoho a trh je nyní uspořádán takto. Uspořádali jsme konferenci o DevOps a otevřeně prohlašujeme: „ – není určena pro inženýry DevOps“. Zde se mnohým může zdát divné a šílené: proč lidé, kteří organizují zcela komerční akci, jdou proti trhu. Teď 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šechno to začalo tím, že historicky ustavené rozdělení rolí nefunguje na kvalitu produktů. Když programátoři pouze programují, ale nechtějí slyšet o testování – software je zaplaven chybami. Když administrátorům je jedno, jak a proč je software napsán – podpora se mění v peklo.
Například popis rozdílu mezi přístupem systémových administrátorů a SRE k managementu služeb Zajímavý výzkum byl proveden v rámci z něhož jasně vyplývá, že nejlepší vývojáři nějak zvládají nasazovat nové změny do produkce rychleji než každou hodinu. Ruce si testují maximálně 10 % (to je vidět z Jak to dokážou? „Excel or die“ – říká jeden z nadpisů zprávy. Pro podrobné projednání této statistiky v kontextu testování se můžete obrátit na keynote Barucha Sadogurského na naší další konferenci, Heisenbug.
„Když není shoda mezi přáteli,
Na jejich věci nepůjde,
A nakonec to nebude nic, jen muka.
Jednou Labuť, Rak a Štika…“
Jak si myslíte, kolik webových programátorů skutečně rozumí podmínkám, za kterých jsou jejich aplikace nasazeny do produkce? Kolik z nich se půjde zeptat adminů a pokusí se zjistit, co se stane při pádu databáze? A kdo z nich se obrátí na testery a požádá je, aby jim ukázali, jak správně psát testy? A pak jsou tu ještě bezpečnostní specialisté, produktoví manažeři a spousta dalších lidí.
Hlavní myšlenkou DevOps je vytvořit spolupráci mezi rolemi a odděleními. Toho zpravidla nedosáhneme pomocí nějakého super sofistikovaného softwaru, ale praxí komunikace. DevOps se týká kultury, praxe, metodologie a procesů. Neexistuje žádná inženýrská specializace, která by dokázala odpovědět na tyto otázky.
Uzavřený kruh
Odkud se tedy vzala disciplína "devops inženýrství"? Máme hypotézu! Myšlenky DevOps byly tak dobré, že se staly obětí svého úspěchu. Kolem tohoto tématu se začali shromažďovat podivní recruitři a obchodníci s lidmi, kteří mají svou vlastní atmosféru.
Představte si: včera jste v Chimkách prodávali shawarmy, a dnes jste už velká osoba, senior recruiter. To znamená, že je tu celý proces vyhledávání a výběru kandidátů, nic jednoduchého, je třeba pochopit. Řekněme, že vedoucí oddělení říká: najdi odborníka na X. Přidáme k X slovo „inženýr“ a je to. Potřebujete Linux? No, to je určitě Linux inženýr, chcete DevOps — DevOps inženýr. Inzerát se skládá nejen z nadpisu, ale uvnitř je třeba napsat nějaký text. Nejjednodušší je napsat soubor klíčových slov z Googlu, kolik kdo má fantazie. DevOps se skládá ze dvou slov - „Dev“ a „Ops“, což znamená, že je třeba spojit klíčová slova vztahující se k vývojářům a administrátorům do jedné hromady. Tak se objevují inzeráty požadující znalost 42 programovacích jazyků a 20 let používání Kubernetes a Swarm současně. Pracovní schéma.
Tímto způsobem se v povědomí lidí usadil bezsmyslný a neúprosný obraz jakéhosi superhrdiny-„devopsa“, který nastaví všem nasazení na Jenkins, a nastane blaženost. Ach, kdyby to bylo tak jednoduché. „A takto lze lovit administrátory,“ pomyslí si HR, „slovo je módní, klíčová slova jsou stejná, musejí se chytit."
Poptávka vytváří nabídku a na všechny tyto zbytečné nabídky se vrhli neuvěřitelné množství systémových administrátorů, kteří si uvědomili, že mohou dělat to samé jako dříve, ale vydělávat několikrát víc, když se nazvou "DevOps". Jak jsi nastavoval servery přes SSH ručně jeden po druhém, tak pokračuješ v nastavování, ale teď je to údajně DevOps praxe. Je to nějaký složitý jev, částečně spojený s nedocenění klasických administrátorů a s humbukem kolem DevOps, ale celkově — co se stalo, to se stalo.
Takže máme poptávku a nabídku. Uzavřený kruh, který se sám živí. S tímto bojujeme (mimo jiné i vytvořením konference DevOops).
Bezpochyby, kromě systémových administrátorů, kteří se přejmenovali na "DevOps", existují i další účastníci — například profesionální SRE nebo vývojáři Infrastructure-as-Code.
Čím se lidé v DevOps (vlastně) zabývají
Takže se chcete posunout ve studiu a aplikaci praktik DevOps. Ale jak to udělat, na co se zaměřit? Je zřejmé, že není rozumné se slepě řídit populárními klíčovými slovy.
Pokud je práce, někdo se jí musí věnovat. Již jsme zjistili, že to nejsou "DevOps inženýři", tak kdo? Zdá se, že je správnější to formulovat ne v termínech pracovních pozic, ale v termínech konkrétních pracovních směrů.
Za prvé, můžeš se zabývat samotným srdcem DevOps — procesy a kulturou. Kultura — to je časově náročná a obtížná záležitost a ačkoliv to tradičně patří do oblasti odpovědnosti vedoucích, do toho se v určité míře zapojují všichni, od programátorů po administrátory. Před pár měsíci Tim Lister :
"Kultura je určována základními hodnotami organizace. Obvykle si toho lidé nevšimnou, ale my, kteří pracujeme v poradenství mnoho let, jsme si na to zvykli. Vstoupíš do společnosti a doslova během pár minut začneš cítit, co se děje. Nazýváme to 'aromatem'. Někdy je to opravdu dobré. Někdy to vyvolává nevolnost. (...) Nemůžeš změnit kulturu, dokud nejsou uvědoměny hodnoty a přesvědčení, které stojí za konkrétními činy. Chování je snadno pozorovatelné, ale hledat přesvědčení je obtížné. DevOps je právě skvělý příklad toho, jak se všechno stává složitější a složitější."
Existuje také technická stránka problému, samozřejmě. Pokud ti nový kód na testování přijde za měsíc, ale do produkce se dostane až za rok, a urychlení všeho je fyzicky nemožné — je možné, že se dobrých praktik nedožiješ. Dobré praktiky jsou udržovány dobrými nástroji. Například s myšlenkou Infrastructure-as-Code můžeš používat cokoli, od AWS CloudFormation a Terraformu po Chef-Ansible-Puppet. To všechno musíš znát a umět, a to už je zcela inženýrská disciplína. Je důležité nemíchat příčinu a následek: nejdříve pracuješ podle principů SRE a teprve poté tyto principy realizuješ v konkrétních technických řešeních. Přitom SRE je velmi komplexní metodologie, která se nezaměřuje na to, jak nakonfigurovat Jenkins, ale na pět základních principů:
- Zlepšování interakce mezi rolemi a odděleními
- Přijetí chyb jako nedílné součásti práce
- Postupné provádění změn
- Používání nástrojů a jiné automatizace
- Měření všeho, co lze měřit
To není jen nějaká sada tvrzení, ale konkrétní . Například při přijetí chyb bude nutné se vyrovnat s riziky, změřit dostupnost a nedostupnost služeb s pomocí něčeho jako SLI () a SLO (), naučit se psát postmortemy a udělat z toho, abychom je psali, nebylo děsivé.
V disciplíně SRE je používání nástrojů pouze jednou z částí úspěchu, i když neméně důležitou. Musíme se neustále vyvíjet technicky, sledovat, co se děje ve světě a jak to můžeme aplikovat ve své práci.
V současnosti se velmi populárními stávají řešení Cloud Native. Podle současného chápání Cloud Native Computing Foundation umožňují technologie Cloud Native organizacím vyvíjet a spouštět škálovatelné aplikace v moderních dynamických prostředích, jako jsou veřejné, soukromé a hybridní cloudové služby. Jako příklad lze uvést kontejnery, service mesh, mikroservisy, neměnnou infrastrukturu a deklarativní API. Všechny tyto techniky umožňují slabě propojeným systémům zůstat pružnými, spravovanými a dobře sledovanými. Dobrá automatizace umožňuje inženýrům provádět velké změny často a s předvídatelnými výsledky, aniž by to vyžadovalo pekelnou práci. To vše je podporováno sadou známých nástrojů, jako jsou Docker a Kubernetes.
Toto poměrně složité a široké definování souvisí s tím, že oblast je také docela komplikovaná. Na jedné straně se tvrdí, že nové změny do tohoto systému by měly být přidávány dostatečně jednoduše. Na druhé straně, abychom pochopili, jak vytvořit nějaké kontejnerizované prostředí, ve kterém slabě propojené služby žijí na software-defined infrastruktuře a jsou tam dodávány prostřednictvím kontinuálního CI/CD, a vybudovali kolem toho praktiky DevOps — na to je potřeba mít zkušenosti.
Co s tím vším dělat
Každý se těmto problémům věnuje po svém: například je možné publikovat normální inzeráty, abychom roztrhli uzavřený kruh. Můžeme se podívat na to, co znamenají slova jako DevOps a Cloud Native, a používat je správně a k věci. Můžeme se rozvíjet v oblasti DevOps a naším příkladem démonstrovat správné přístupy.
My pořádáme konferenci , která poskytuje příležitost hlouběji se zabývat tématy, o kterých jsme právě hovořili. K tomu existuje několik skupin přednášek:
- Procesy a kultura;
- Site Reliability Engineering;
- Cloud Native;
Jak se rozhodnout, kam jít? Je tu jemný moment. Na jedné straně je DevOps o spolupráci, a máme velkou touhu, abyste se zúčastnili prezentací z různých bloků. Na druhé straně, pokud jste vedoucí vývoje, který přišel na konferenci zaměřit se na konkrétní úkol, nikdo vás neomezuje — očividně to bude blok o procesech a kultuře. Nezapomeňte, že po konferenci vám zůstanou záznamy (po vyplnění feedback formuláře), takže se k méně důležitým prezentacím budete moci podívat později.
Očividně na konferenci nemůžete jít na tři trasy najednou, takže program formujeme tak, aby v každém časovém bloku byly témata pro každého.
Zbývá jen pochopit, co dělat, pokud jste DevOps inženýr! Za prvé, zkuste určit, čemu se opravdu věnujete. Obvykle tímto termínem označujeme:
- Vývojáře, kteří se zabývají infrastrukturou. Pro vás budou nejvhodnější skupiny prezentací o SRE a Cloud Native.
- Systémové administrátory. Tady je to složitější. DevOops — to není o systémovém administraci. Naštěstí je na téma systémové administrace spousta skvělých konferencí, knih, článků, videí na internetu atd. Na druhou stranu, pokud máte zájem rozvíjet své porozumění kultuře a procesům, studovat cloudové technologie a detaily života s Cloud Native, budeme rádi, když vás uvidíme! Zamyslete se nad tímto: vy se zabýváte administrací, a co dál budete dělat? Aby se vám náhle nestalo něco nepříjemného, měli byste se učit už teď.
Je tu ještě jedna možnost: trváte na tom a pokračujete v tom, že jste přesně DevOps inženýrem a jinak to nejde, cožkoliv by to mělo znamenat. Pak vás musím zklamat, DevOops — to není konference pro DevOps inženýry!
Snímek z v Mnichově
DevOops 2020 Moskva se uskuteční 29.-30. dubna v Moskvě, vstupenky je už možné .
Kromě toho můžete do 8. února. Všimněte si, že při vyplnění formuláře musíte vybrat cílovou skupinu, které vaše prezentace přinese největší užitek (uvnitř seznamu je překvapení).
Zdroj: habr.com
