Co je potřeba k tomu, aby byla IT společnost v roce 2019 úspěšná? Přednášející na konferencích a setkáních říkají spoustu hlasitých slov, která normálním lidem nejsou vždy srozumitelná. Boj o čas nasazení, mikroslužby, opuštění monolitu, transformace DevOps a mnohem, mnohem více. Pokud odhodíme verbální krásu a budeme mluvit přímo a rusky, pak se vše zvrhne na jednoduchou tezi: vyrobit vysoce kvalitní produkt a udělat to s pohodlím pro tým.
To poslední se stalo kriticky důležitým. Obchod konečně došel k závěru, že pohodlný vývojový proces zvyšuje produktivitu, a pokud je vše odladěno a funguje jako hodinky, dává také určitý prostor pro manévrování v kritických situacích. Kdysi kvůli tomuto manévru vymyslel jistý chytrý člověk zálohování, ale průmysl se rozvíjí a my jsme se dostali k DevOps inženýrům – lidem, kteří proměňují proces interakce mezi vývojem a externí infrastrukturou v něco adekvátního a nesouvisí se šamanismem.
Celý tento „modulární“ příběh je úžasný, ale... Stalo se, že někteří z adminů byli náhle nazváni DevOps a od samotných inženýrů DevOps se začalo vyžadovat, aby měli alespoň dovednosti telepatie a jasnovidectví.
Než se budeme bavit o moderních problémech poskytování infrastruktury, definujme si, co si pod tímto pojmem představujeme. V současné době se situace vyvinula tak, že jsme dosáhli duality tohoto konceptu: infrastruktura může být podmíněně vnější a podmíněně vnitřní.
Externí infrastrukturou rozumíme vše, co zajišťuje funkčnost služby nebo produktu, který tým vyvíjí. Jedná se o aplikační nebo webové servery, hosting a další služby, které zajišťují funkčnost produktu.
Vnitřní infrastruktura zahrnuje služby a vybavení, které využívá samotný vývojový tým a další zaměstnanci, kterých je obvykle mnoho. Jedná se o interní servery systémů pro ukládání kódu, lokálně nasazeného správce úloh a všeho, všeho, všeho, co existuje v rámci podnikového intranetu.
Co dělá systémový administrátor ve firmě? Kromě práce se správou právě tohoto podnikového intranetu často nese břemeno ekonomických starostí o zajištění provozuschopnosti kancelářského vybavení. Admin je ten samý chlápek, který rychle vytáhne novou systémovou jednotku nebo náhradní notebook připravený k použití ze zadní místnosti, rozdá novou klávesnici a bude se plazit po čtyřech po kancelářích a natahovat ethernetový kabel. Administrátor je místní vlastník a vládce nejen interních a externích serverů, ale také manažer firmy. Ano, někteří správci mohou pracovat pouze v systémové rovině, bez hardwaru. Měli by být rozděleni do samostatné podtřídy „správci systému infrastruktury“. A někteří se specializují na servis výhradně kancelářské techniky, naštěstí pokud má firma více než sto lidí, práce nikdy nekončí. Ale ani jeden z nich není devops.
Kdo jsou DevOps? Devops jsou kluci, kteří mluví o interakci vývoje softwaru s externí infrastrukturou. Přesněji řečeno, moderní vývojáři jsou zapojeni do procesů vývoje a nasazení mnohem hlouběji, než kdy byli zapojeni administrátoři, kteří jednoduše nahrávali aktualizace na ftp. Jedním z klíčových úkolů inženýra DevOps je nyní zajistit pohodlný a efektivně strukturovaný proces interakce mezi vývojovými týmy a produktovou infrastrukturou. Jsou to tito lidé, kteří jsou zodpovědní za nasazování rollback a nasazovacích systémů; jsou to tito lidé, kteří ubírají část zátěže vývojářům a maximálně se soustředí na jejich extrémně důležitý úkol. Zároveň devops nikdy nepovede nový kabel nebo nevydá nový notebook ze zadní místnosti (c) KO
V čem je háček?
Na otázku "Kdo je DevOps?" polovina pracovníků v terénu začne odpovídat něco jako “No, zkrátka tohle je ten admin, který...” a dále v textu. Ano, kdysi dávno, když se profese inženýra DevOps teprve vynořovala z nejtalentovanějších administrátorů z hlediska údržby služeb, nebyly rozdíly mezi nimi každému zřejmé. Ale nyní, kdy se funkce devops a admina v týmu radikálně liší, je nepřijatelné je vzájemně zaměňovat nebo dokonce srovnávat.
Co to ale znamená pro podnikání?
Nábor, o to jde.
Otevíráte volné místo na pozici „Správce systému“ a zde uvedené požadavky jsou „interakce s vývojem a zákazníky“, „systém doručování CI/CD“, „údržba serverů a zařízení společnosti“, „správa interních systémů“ atd. na; chápete, že zaměstnavatel mluví nesmysly. Háček je v tom, že místo „Správce systému“ by měl být název volného místa „DevOps Engineer“, a pokud se tento název změní, vše zapadne na své místo.
Jaký dojem však člověk získá při čtení takového volného místa? Že firma hledá operátora na více strojů, který nasadí jak verzovací, tak monitorovací systém a bude ždímat twister zuby...
Aby se ale nezvyšovala míra drogové závislosti na trhu práce, stačí volná místa nazývat pravými jmény a jasně pochopit, že inženýr DevOps a správce systému jsou dvě různé entity. Ale nepotlačitelná touha některých zaměstnavatelů předložit kandidátovi co nejširší seznam požadavků vede k tomu, že „klasičtí“ správci systému přestávají chápat, co se kolem nich děje. Cože, profese mutuje a oni jsou pozadu?
Ne ne a ještě jednou ne. Správci infrastruktury, kteří budou spravovat interní servery společnosti nebo obsazovat podpůrné pozice L2/L3 a pomáhat ostatním zaměstnancům, neodešli a neodejdou.
Mohou se tito specialisté stát inženýry DevOps? Samozřejmě, že mohou. Ve skutečnosti se jedná o související prostředí, které vyžaduje dovednosti správy systému, ale k tomu se navíc přidává práce s monitoringem, doručovacími systémy a obecně úzká interakce s vývojovým a testovacím týmem.
Další problém s DevOps
Ve skutečnosti se vše neomezuje pouze na najímání a neustálý zmatek mezi adminy a vývojáři. V určitém okamžiku se podnik potýkal s problémem poskytování aktualizací a interakce vývojového týmu s konečnou infrastrukturou.
Možná to bylo, když se strýc s jiskřivýma očima postavil na pódium nějaké konference a řekl: „Děláme to a říkáme tomu DevOps. Tihle kluci vyřeší všechny vaše problémy“ - a začal vyprávět, jak dobrý je život ve společnosti po implementaci postupů DevOps.
Nestačí však najmout DevOps inženýra, aby vše fungovalo, jak má. Společnost musí projít kompletní transformací DevOps, to znamená, že roli a schopnosti našich DevOps musí jasně chápat i tým pro vývoj a testování produktů. Máme na toto téma „úžasný“ příběh, který plně ilustruje veškerou brutalitu, která se na některých místech děje.
Situace. DevOps je nutný k nasazení systému vrácení verzí, aniž by se skutečně ponořil do toho, jak bude fungovat. Předpokládejme, že v systému Uživatelé jsou samostatná pole pro jméno, příjmení a heslo. Vychází nová verze produktu, ale pro vývojáře je „rollback“ jen kouzelnou hůlkou, která vše napraví, a ani nevědí, jak to funguje. Takže například v dalším patchi vývojáři spojili pole jména a příjmení, zavedli to do výroby, ale verze je z nějakého důvodu pomalá. Co se děje? Vedení přichází za devopsem a říká „Pull the switch!“, to znamená, že ho žádá, aby se vrátil k předchozí verzi. Co devops dělá? Vrátí se zpět k předchozí verzi, ale protože vývojáři nechtěli zjistit, jak bylo toto vrácení provedeno, nikdo týmu devops neřekl, že databázi je také třeba vrátit zpět. Tím nám vše spadne a místo pomalého webu se uživatelům zobrazí chyba „500“, protože stará verze nepracuje s poli nové databáze. Devops o tom neví. Vývojáři mlčí. Vedení začíná ztrácet nervy a peníze a pamatuje si zálohy a nabízí, že se od nich vrátí, aby „aspoň něco fungovalo“. Výsledkem je, že uživatelé během určité doby ztratí všechna svá data.
Oříšky se samozřejmě týkají devops, kteří „nevytvořili správný systém vrácení zpět“ a nikoho nezajímá, že losy v tomto příběhu jsou vývojáři.
Závěr je jednoduchý: bez normálního přístupu k DevOps jako takovému je to málo použitelné.
Hlavní věc k zapamatování: inženýr DevOps není kouzelník a bez kvalitní komunikace a obousměrné interakce s vývojem si se svými úkoly neporadí. Vývojáři nemohou být se svými „problémy“ ponecháni sami, ani jim nesmí dát příkaz „nepleťte se do vývojářů, jejich úkolem je kódovat“ a pak doufat, že v kritickém okamžiku bude vše fungovat, jak má. Tak to nefunguje.
DevOps je v podstatě kompetence na hranici mezi managementem a technologií. Navíc není zdaleka zřejmé, že by v tomto koktejlu mělo být více technologií než managementu. Pokud skutečně chcete budovat rychlejší a efektivnější vývojové procesy, musíte svému týmu vývojářů důvěřovat. Zná správné nástroje, realizoval podobné projekty, ví, jak na to. Pomozte mu, poslouchejte jeho rady, nesnažte se ho izolovat do nějaké autonomní jednotky. Pokud admini umí pracovat sami, pak jsou devops v tomto případě k ničemu, nebudou vám moci pomoci stát se lepším, pokud vy sami tuto pomoc nechcete přijmout.
A poslední věc: přestaňte urážet správce infrastruktury. Mají svou vlastní, nesmírně důležitou frontu práce. Ano, administrátor se může stát inženýrem DevOps, ale mělo by se tak stát na žádost samotné osoby, nikoli pod tlakem. A není nic špatného na tom, že správce systému chce zůstat správcem systému – je to jeho samostatná profese a jeho právo. Pokud chcete podstoupit profesní proměnu, pak nikdy nesmíte zapomenout, že si budete muset vybudovat nejen technologické dovednosti, ale i manažerské. S největší pravděpodobností bude na vás jako na vedoucím, abyste všechny tyto lidi spojil a naučil je komunikovat stejným jazykem.
Zdroj: www.habr.com