Čo je potrebné na to, aby bola IT spoločnosť úspešná v roku 2019? Lektori na konferenciách a stretnutiach hovoria veľa hlasných slov, ktoré nie sú vždy zrozumiteľné pre normálnych ľudí. Boj o čas nasadenia, mikroslužby, opustenie monolitu, transformácia DevOps a oveľa, oveľa viac. Ak odhodíme verbálnu krásu a hovoríme priamo a v ruštine, potom to všetko vedie k jednoduchej téze: vyrobiť vysoko kvalitný produkt a urobiť to s pohodlím pre tím.
To posledné sa stalo kriticky dôležitým. Business konečne dospel k záveru, že pohodlný proces vývoja zvyšuje produktivitu a ak je všetko odladené a funguje ako hodinky, dáva to aj určitý priestor na manévrovanie v kritických situáciách. Kedysi kvôli tomuto manévru istý šikovný človek vymyslel zálohy, no priemysel sa rozvíja a my sme prišli k DevOps inžinierom – ľuďom, ktorí premieňajú proces interakcie medzi vývojom a externou infraštruktúrou na niečo adekvátne a nesúvisí so šamanizmom.
Celý tento „modulárny“ príbeh je úžasný, ale... Stalo sa, že niektorí správcovia boli náhle nazvaní DevOps a od samotných inžinierov DevOps sa začalo vyžadovať, aby mali aspoň schopnosti telepatie a jasnovidectva.
Predtým, než si povieme niečo o moderných problémoch poskytovania infraštruktúry, definujme si, čo si pod týmto pojmom predstavujeme. V súčasnosti sa situácia vyvinula tak, že sme dosiahli dualitu tohto konceptu: infraštruktúra môže byť podmienene vonkajšia a podmienene vnútorná.
Externou infraštruktúrou rozumieme všetko, čo zabezpečuje funkčnosť služby alebo produktu, ktorý tím vyvíja. Ide o aplikačné alebo webové servery, hosting a ďalšie služby, ktoré zabezpečujú funkčnosť produktu.
Vnútorná infraštruktúra zahŕňa služby a zariadenia, ktoré využíva samotný vývojový tím a ďalší zamestnanci, ktorých je zvyčajne veľa. Sú to interné servery systémov na ukladanie kódu, lokálne nasadený správca úloh a všetko, všetko, všetko, čo existuje v rámci podnikového intranetu.
Čo robí správca systému vo firme? Okrem práce so správou práve tohto podnikového intranetu často nesie bremeno ekonomických starostí o zabezpečenie prevádzkyschopnosti kancelárskych zariadení. Admin je ten istý chlapík, ktorý rýchlo vytiahne novú systémovú jednotku alebo náhradný laptop pripravený na použitie zo zadnej miestnosti, rozdá novú klávesnicu a po štyroch sa plazí po kanceláriách a naťahuje ethernetový kábel. Administrátor je lokálnym vlastníkom a vládcom nielen interných a externých serverov, ale aj obchodným manažérom. Áno, niektorí správcovia môžu pracovať iba v systémovej rovine, bez hardvéru. Mali by byť oddelení do samostatnej podtriedy „správcovia systému infraštruktúry“. A niektorí sa špecializujú na servis výhradne kancelárskej techniky, našťastie, ak má firma viac ako sto ľudí, práca nikdy nekončí. Ale ani jeden z nich nie je devops.
Kto sú DevOps? Devops sú chlapci, ktorí hovoria o interakcii vývoja softvéru s externou infraštruktúrou. Presnejšie povedané, moderní vývojári sú zapojení do procesov vývoja a nasadenia oveľa hlbšie ako správcovia, ktorí jednoducho nahrávali aktualizácie na ftp. Jednou z kľúčových úloh inžiniera DevOps je teraz zabezpečiť pohodlný a efektívne štruktúrovaný proces interakcie medzi vývojovými tímami a produktovou infraštruktúrou. Práve títo ľudia sú zodpovední za nasadzovanie systémov vrátenia a nasadenia; sú to práve títo ľudia, ktorí odbremeňujú vývojárov a sústredia sa čo najviac na ich mimoriadne dôležitú úlohu. Zároveň devops nikdy nezavedie nový kábel alebo nevydá nový laptop zo zadnej miestnosti (c) KO
v čom je háčik?
Na otázku "Kto je DevOps?" polovica pracovníkov v teréne začne odpovedať niečo ako “No skrátka toto je admin, ktorý...” a ďalej v texte. Áno, kedysi dávno, keď sa profesia inžiniera DevOps len rodila z najtalentovanejších správcov v oblasti údržby služieb, rozdiely medzi nimi neboli každému zrejmé. Ale teraz, keď sa funkcie devops a adminov v tíme radikálne líšia, je neprijateľné ich navzájom zamieňať alebo dokonca porovnávať.
Čo to však znamená pre podnikanie?
Nájom, všetko je o tom.
Otvoríte voľné miesto „Správca systému“ a tam uvedené požiadavky sú „interakcia s vývojom a zákazníkmi“, „systém doručovania CI/CD“, „údržba serverov a zariadení spoločnosti“, „správa interných systémov“ atď. zapnuté; chápeš, že zamestnávateľ hovorí nezmysly. Háčik je v tom, že namiesto „Správca systému“ by názov voľného miesta mal byť „DevOps Engineer“ a ak sa tento názov zmení, všetko zapadne na svoje miesto.
Aký dojem však človek získa pri čítaní takéhoto voľného miesta? Že firma hľadá operátora na viacero strojov, ktorý nasadí systém kontroly verzií aj monitorovania a bude zubami žmýkať twister...
Aby sa však nezvyšovala miera drogovej závislosti na trhu práce, stačí nazvať voľné miesta pravým menom a jasne pochopiť, že inžinier DevOps a správca systému sú dva rôzne subjekty. Ale nepotlačiteľná túžba niektorých zamestnávateľov predložiť kandidátovi čo najširší zoznam požiadaviek vedie k tomu, že „klasickí“ správcovia systémov prestávajú rozumieť tomu, čo sa okolo nich deje. Čo, povolanie mutuje a oni zaostávajú za dobou?
Nie nie a ešte raz nie. Správcovia infraštruktúry, ktorí budú spravovať interné servery spoločnosti alebo obsadzovať podporné pozície L2/L3 a pomáhať iným zamestnancom, neodišli a neodídu.
Môžu sa títo špecialisti stať inžiniermi DevOps? Samozrejme, že môžu. V skutočnosti ide o príbuzné prostredie, ktoré si vyžaduje zručnosti správy systému, no okrem toho sa pridáva aj práca s monitorovaním, doručovacími systémami a vo všeobecnosti úzka interakcia s vývojovým a testovacím tímom.
Ďalší problém DevOps
V skutočnosti sa všetko neobmedzuje len na prijímanie zamestnancov a neustály zmätok medzi administrátormi a vývojármi. V určitom momente sa podnik potýkal s problémom poskytovania aktualizácií a interakcie vývojového tímu s finálnou infraštruktúrou.
Možno to bolo, keď sa strýko s iskrivými očami postavil na pódium nejakej konferencie a povedal: „Robíme to a nazývame to DevOps. Títo chlapci vyriešia všetky vaše problémy“ - a začal hovoriť, aký dobrý je život v spoločnosti po implementácii postupov DevOps.
Nestačí však najať si DevOps inžiniera, aby všetko fungovalo tak, ako má. Spoločnosť musí prejsť kompletnou transformáciou DevOps, to znamená, že úloha a schopnosti našich DevOps musia byť jasne pochopené aj na strane tímu vývoja a testovania produktov. Máme „úžasný“ príbeh na túto tému, ktorý plne ilustruje všetku brutalitu, ktorá sa na niektorých miestach deje.
Situácia. DevOps je potrebný na nasadenie systému vrátenia verzie bez toho, aby sa skutočne ponoril do toho, ako to bude fungovať. Predpokladajme, že v systéme Používatelia existujú samostatné polia pre meno, priezvisko a heslo. Vychádza nová verzia produktu, ale pre vývojárov je „rollback“ len čarovným prútikom, ktorý všetko opraví a ani nevedia, ako to funguje. Napríklad v ďalšom patchi vývojári skombinovali polia mena a priezviska, zaviedli to do výroby, ale verzia je z nejakého dôvodu pomalá. Čo sa deje? Manažment príde za devopsom a povie „Pull the switch!“, to znamená, že ho požiada, aby sa vrátil k predchádzajúcej verzii. Čo robí devops? Vracia sa späť na predchádzajúcu verziu, ale keďže vývojári nechceli zistiť, ako sa toto vrátenie vykonalo, nikto tímu devops nepovedal, že je potrebné vrátiť aj databázu. V dôsledku toho nám všetko padá a namiesto pomalého webu sa používateľom zobrazuje chyba „500“, pretože stará verzia nefunguje s poľami novej databázy. Devops o tom nevie. Vývojári mlčia. Vedenie začína strácať nervy a peniaze a pamätá si zálohy a ponúka, že sa od nich vráti, aby „aspoň niečo fungovalo“. V dôsledku toho používatelia po určitom čase stratia všetky svoje údaje.
Oriešky sa, samozrejme, týkajú devops, ktorí „nevytvorili správny systém vrátenia“ a nikoho nezaujíma, že losy v tomto príbehu sú vývojári.
Záver je jednoduchý: bez normálneho prístupu k DevOps ako takému je málo užitočný.
Hlavná vec na zapamätanie: Inžinier DevOps nie je kúzelník a bez kvalitnej komunikácie a obojsmernej interakcie s vývojom nebude zvládať svoje úlohy. Vývojári nemôžu zostať sami so svojimi „problémami“ alebo dostať príkaz „nepleťte sa do vývojárov, ich úlohou je kódovať“ a potom dúfať, že v kritickom momente bude všetko fungovať tak, ako má. Takto to nefunguje.
DevOps je v podstate kompetencia na hranici medzi manažmentom a technológiou. Navyše nie je ani zďaleka zrejmé, že by v tomto kokteile malo byť viac technológií ako manažmentu. Ak skutočne chcete vybudovať rýchlejšie a efektívnejšie vývojové procesy, musíte svojmu vývojárskemu tímu dôverovať. Pozná správne nástroje, realizoval podobné projekty, vie ako na to. Pomôžte mu, počúvajte jeho rady, nesnažte sa ho izolovať do akejsi autonómnej jednotky. Ak môžu správcovia pracovať sami, potom sú devops v tomto prípade zbytoční; nebudú vám môcť pomôcť stať sa lepším, ak vy sami túto pomoc nechcete prijať.
A posledná vec: prestaňte urážať správcov infraštruktúry. Majú svoj vlastný, mimoriadne dôležitý front práce. Áno, správca sa môže stať inžinierom DevOps, ale malo by sa tak stať na žiadosť samotnej osoby a nie pod tlakom. A nie je nič zlé na tom, že správca systému chce zostať správcom systému – je to jeho samostatná profesia a jeho právo. Ak chcete prejsť profesionálnou premenou, potom nikdy nesmiete zabudnúť, že si budete musieť vybudovať nielen technologické zručnosti, ale aj manažérske. S najväčšou pravdepodobnosťou bude na vás ako na lídrovi, aby ste všetkých týchto ľudí spojili a naučili ich komunikovať v rovnakom jazyku.
Zdroj: hab.com