Co je potřeba k úspěchu IT společnosti v roce 2019? Přednášející na konferencích a meetupech říkají spoustu hlučných a ne vždy srozumitelných slova pro normální lidi. Boj o čas nasazení, mikroslužby, vzdání se monolitu, DevOps transformace a mnoho dalších věcí. Pokud odhodíme slovní krásu a budeme mluvit jasně a česky, vše se zjednodušuje na prostou tezi: vyvíjejte kvalitní produkt, a to s komfortem pro tým.
To se stalo kriticky důležité. Byznys konečně došel k tomu, že komfortní proces vývoje zvyšuje produktivitu, a pokud je vše seřízeno a funguje jako hodinky, poskytuje ještě nějaký prostor pro manévry v kritických situacích. Někdy pro tento manévr vymyslel jistý chytrý člověk zálohy, ale průmysl se vyvíjí a my jsme dospěli k DevOps inženýrům — lidem, kteří proměňují proces interakce vývoje s externí infrastrukturou na něco adekvátního a nesouvisejícího se šamanismem.
Celá tato historie o 'modulech' je skvostná, ale… Stalo se to, že část administrátorů byla náhle pokřtěna jako DevOps a od samotných DevOps inženýrů se začaly vyžadovat minimálně schopnosti telepatie a jasnovidectví.
Než začneme mluvit o moderních problémech zajištění infrastruktury, ujasněme si, co tímto termínem myslíme. K současnému okamžiku se situace vyvinula tak, že jsme dospěli k dvojznačnosti tohoto pojmu: infrastruktura může být podmíněně externí a podmíněně interní.
Pod externí infrastrukturou rozumíme vše, co zajišťuje funkčnost služby nebo produktu, na jehož vývoji se podílí tým. To jsou servery aplikací nebo webových stránek, hosting a další služby, které zajišťují funkčnost produktu.
Interní infrastruktura zahrnuje služby a zařízení, kterými se využívají sami vývojáři a další zaměstnanci, kterých obvykle není málo. Patří sem interní servery systémů pro správu kódu, lokálně nasazený task-manager a vůbec všechno, co existuje v rámci firemního intranetu.
Co vlastně dělá systémový administrátor ve firmě? Kromě správy firemního intranetu má často na starosti zajištění funkčnosti kancelářského vybavení. Admin je ten kluk, který rychle přinese z úložného prostoru novou desktopovou jednotku nebo připravený záložní laptop, vydá čerstvou klávesnici a bude lézt po čtyřech po kancelářích, aby natáhl Ethernetový kabel. Admin je místní pán a vládce nejen vnitřních a vnějších servery, ale i materiálních záležitostí. Ano, někteří administrátoři mohou pracovat pouze v systémové rovině, bez hardwaru. Je třeba je vyčlenit do samostatné podskupiny "infrastrukturních systémových administrátorů". Jiní se specializují výhradně na údržbu kancelářského vybavení, což je v pořádku, pokud firma zaměstnává více než sto lidí, práce nezkončí nikdy. Ale ani jedni, ani druzí nejsou devops.
A kdo jsou to DevOps? Devops jsou kluci, kteří se zabývají interakcí vývoje software s externí infrastrukturou. Přesněji řečeno, moderní devops jsou mnohem více zapojeni do procesů vývoje a nasazení než kdyby byli administrátoři, kteří jednoduše nahrávali aktualizace na ftp. Jedním z klíčových úkolů DevOps inženýra je dnes zajistit pohodlný a efektivně strukturovaný proces interakce mezi týmy vývoje a infrastrukturou produktu. Právě tito lidé jsou zodpovědní za nasazení systémů rollbacku a nasazení, právě tito lidé odstraňují část zátěže z vývojářů a maximálně se soustředí na své nesmírně důležité úkoly. Přitom devops nikdy nebude natáhnout nový kabel nebo vydávat nový notebook z úložného prostoru (c) KO
Kde je háček?
Když se někdo zeptá: „Kdo je to DevOps?“, polovina pracovníků v oboru začne odpovídat něco jako: „No, to je vlastně takový administrátor, který…“ a pak pokračují. Ano, kdysi, když se profese DevOps inženýra teprve začínala vyvíjet z nejtalentovanějších administrátorů z hlediska správy služeb, rozdíly mezi nimi nebyly všem jasné. Ale nyní, když se funkce DevOps a administrátora v týmu radikálně liší, je neakceptovatelné je plést dohromady nebo dokonce stavět mezi ně rovnítko.
Ale jaký to má dopad na podnikání?
Nábor, o to jde.
Otevíráte inzerát na pozici „Systémový administrátor“ a tam jsou vypsány požadavky jako „spolupráce s vývojem a klienty“, „CI/CD dodací systém“, „údržba serverů a vybavení společnosti“, „administrace interních systémů“ a tak dále; chápete, že zaměstnavatel říká nějaké nesmysly. O to jde, že místo „Systémový administrátor“ by v nadpisu inzerátu mělo být „DevOps inženýr“, a pokud tento nadpis změníte, všechno se dostane na své místo.
Jaký pocit však vyvolává čtení takové inzerce? Že společnost hledá multitaskujícího pracovníka, který rozjede systém pro řízení verzí i monitoring a pak to všechno udělá s víc než jednou rukou…
Aby se však nezvyšoval stupeň zmatků na trhu práce, stačí nazývat pozice správně a jasně chápat, že DevOps inženýr a systémový administrátor jsou dvě různé entity. To ovšem neúprosné učinění některými zaměstnavateli, kteří požadují co nejširší seznam požadavků od kandidáta, vede k tomu, že „klasické“ systémové administrátory přestává chápat, co se kolem nich děje. Co, profese se mění a oni zaostávají?
Ne, ne a znovu ne. Infrastrukturní administrátoři, kteří budou řídit interní servery společnosti nebo zastávat pozice L2/L3 podpory a pomáhat ostatním zaměstnancům, nikam nezmizeli a nemají v plánu odejít.
Mohou se tito specialisté stát DevOps inženýry? Samozřejmě, že mohou. Ve skutečnosti se jedná o příbuzné prostředí, které vyžaduje dovednosti v systémovém administrativě, ale kromě toho zahrnuje práci s monitoringem, doručovacími systémy a celkově úzkou spolupráci s týmem vývoje a testování.
Další problém DevOps
Ve skutečnosti to nekončí pouze náborem a neustálým zmatením mezi administrátory a devopser. V určitém okamžiku se podnik setkal s problémem dodávání aktualizací a spolupráce týmu vývoje s konečnou infrastrukturou.
Možná to bylo tehdy, když na scénu nějaké konference vystoupil člověk s hořícími očima a řekl: „A my to děláme takhle a nazýváme to DevOps. Tihle kluci vyřeší všechny vaše problémy“ — a začal vyprávět, jak dobře se žije ve firmě po implementaci DevOps praktik.
Avšak nestačí jen najmout DevOps inženýra, aby všechno fungovalo „jak má“. Firma by měla projít kompletní DevOps transformací, což znamená, že roli a možnosti našeho devopsera by měly být jasně pochopeny i na straně týmu vývoje a testování produktu. Na toto téma máme „skvělý“ příběh, který plně ilustruje celou občasnou hrůzu, která se děje.
Situace. Od devopsa se požaduje, aby nasadil systém pro vracení verzí, aniž by se příliš zabýval tím, jak bude fungovat. Předpokládejme, že uvnitř systému Users jsou to jednotlivá pole pro jméno, příjmení a heslo. Vyšla nová verze produktu, ale pro vývojáře je „rollback“ jen kouzelná hůlka, která vše opraví, a ani netuší, jak to funguje. Tak například, vývojáři v dalším patche sloučili pole jména a příjmení, vypustili to do produkce a verze kvůli nějakým důvodům zpomaluje. Co se stane? Vedoucí přichází k devopsovi a říká „Přepni spínač!“, tedy ho žádá, aby se vrátil na předchozí verzi. Co dělá devops? Vrátí se na předchozí verzi, ale jelikož se vývojáři nechtěli zabývat tím, jak se tento rollback provádí, nikdo devopsovi neřekl, že je třeba vrátit i databázi. V důsledku toho nám spadne úplně všechno a uživatelé místo zpomalujícího webu vidí chybu „500“, protože stará verze nefunguje s poli nové databáze. Devops o tom netuší. Vývojáři mlčí. Vedoucí začíná ztrácet nervy a peníze a vzpomíná na zálohy, navrhující se vrátit z nich, aby „alespoň něco fungovalo“. V důsledku toho uživatelé ztrácejí všechna svá data za určité období.
Je jasné, že to schytá devops, který „neudělal správný systém rollbacku“, ale to, že v tomto příběhu jsou lozi vývojáři, nikoho nezajímá.
Závěr je jednoduchý: bez normálního přístupu k DevOps jako takovému není z něj moc užitku.
Hlavní věc, kterou je třeba mít na paměti: DevOps inženýr není kouzelník a bez kvalitní komunikace a oboustranné spolupráce s vývojem si neporadí se svými úkoly. Devopsy nelze nechat samotné s jejich „problémy“ nebo jim dát pokyn „nedotýkej se vývojářů, jejich věcí je kódovat“, a pak doufat, že v kritickém okamžiku všechno bude fungovat, jak má. Tak to nefunguje.
V podstatě je DevOps kompetencemi na pomezí mezi managementem a technologiemi. Navíc není vůbec jasné, že v tomto koktejlu technologií by mělo být víc než managementu. Pokud opravdu chcete vybudovat rychlejší a efektivnější procesy vývoje, musíte důvěřovat svému devopsu. On zná potřebné nástroje, realizoval podobné projekty, ví, jak na to. Pomozte mu, naslouchejte jeho radám, nesnažte se ho izolovat do nějakého autonomního oddělení. Pokud administrátoři mohou pracovat sami, devopsové vám v takovém případě budou k ničemu, nemohou vám pomoci stát se lepšími, pokud tuto pomoc sami nechcete přijmout.
A poslední věc: přestaňte urážet administrátory-infrastrukturníky. Mají svůj, nesmírně důležitý pracovní úkol. Ano, administrátor se může stát DevOps inženýrem, ale musí to probíhat podle přání samotného člověka, a ne pod tlakem. A není nic špatného na tom, že systémový administrátor chce zůstat systémovým administrátorem — to je jeho samostatná profese a jeho právo. Pokud ale máte chuť projít profesní transformací, rozhodně nesmíte zapomínat, že budete muset zvyšovat nejen technologické dovednosti, ale také manažerské. Tyto lidi je pravděpodobně potřeba spojit dohromady a naučit je komunikovat ve společném jazyce, a to pravděpodobně budete muset udělat právě vy jako vedoucí.
Zdroj: habr.com
