🥇Kto sú DevOps?

V súčasnosti je to azda najdrahšia pozícia na trhu. Hlavný zhon okolo „DevOps“ inžinierov prekonáva všetky predstaviteľné hranice, a tým horšie s Senior DevOps inžiniermi.
Pracujem ako vedúci oddelenia integrácie a automatizácie, uhádnite anglický prepis — DevOps Manager. Odráža anglický prepis našu každodennú činnosť — sotva, ale slovenská verzia je v tomto prípade presnejšia. V súvislosti s mojou prácou je prirodzené, že musím pohovoriť s budúcimi členmi môjho tímu a za posledný rok prešlo cez mňa asi 50 ľudí, a ďalších toľko sa odstránilo na preskrine s mojimi zamestnancami.

Stále hľadáme kolegov, pretože za označením DevOps sa skrýva veľmi veľká vrstva rôznych inžinierov.

Všetko, čo je napísané nižšie, je môj osobný názor, nemusíte sa s ním súhlasiť, avšak predpokladám, že to môže pridať odtieň k vášmu vzťahu k téme. Napriek riziku, že sa dostanem do nemilosti, publikujem svoj názor, pretože si myslím, že má svoje miesto.

Spoločnosti rôzne chápu, kto sú DevOps inžinieri, a kvôli rýchlemu náboru zdrojov prikladajú tento štítok všetkým. Situácia je dosť zvláštna, pretože spoločnosti sú ochotné platiť nepredstaviteľné odmeny týmto ľuďom, pričom v mnohých prípadoch dostávajú len administrátora-nástrojistu.

Kto teda sú DevOps inžinieri?

Začnime s príbehom vzniku — Development Operations vzniklo ako ďalší krok k optimalizácii interakcie v malých tímoch s cieľom zvýšiť rýchlosť výroby produktu ako očakávaný dôsledok. Myšlienkou bolo posilniť vývojový tím znalosťami o praktikách a prístupoch v správe produktového prostredia. Inými slovami, vývojár by mal chápad a vedieť, ako jeho produkt funguje v rôznych podmienkach, mal by vedieť, ako nasadiť svoj produkt, aké charakteristiky prostredia upraviť na zvýšenie výkonu. Tak sa v priebehu času objavili vývojári s prístupom DevOps. DevOps vývojári písali skripty na zostavovanie a balenie na zjednodušenie svojej činnosti a fungovania produktívneho prostredia. Avšak zložitost architektúry riešení a vzájomný vplyv komponentov infraštruktúry v priebehu času začali zhoršovať pracovné výkony prostredí, s každou iteráciou sa vyžadovali stále hlbšie porozumenia rôznym komponentom, čo znižovalo produktivitu samotného vývojára kvôli dodatočným nákladom na porozumenie komponentom a ladeniu systémov na konkrétnu úlohu. Vlastné náklady vývojára stúpali, cena produktu spolu s nimi, nároky na nových vývojárov v tíme prudko vzrástli, pretože museli pokrývať aj povinnosti "hviezdy" vývoja a prirodzene, "hviezdy" sa stávali čoraz menej dostupnými. Rovnako treba poznamenať, že z mojej skúsenosti je málo ktorých vývojárov zaujíma špecifiká spracovania paketov jadrom operačného systému, pravidlá smerovania paketov, aspekty bezpečnosti hostiteľa. Logickým krokom bolo angažovať administrátora, ktorý sa s týmto oboznamuje a priznať podobné povinnosti práve jemu, čo, vďaka jeho skúsenostiam, umožnilo dosiahnuť rovnaké výsledky s nižšími nákladmi v porovnaní s nákladmi "hviezdy" vývoja. Takíto administrátori boli zaradení do tímu a ich hlavnou úlohou bolo spravovať testovacie a produktívne prostredia podľa pravidiel konkrétneho tímu, s prostriedkami pridelenými práve tomuto tímu. Tak sa vlastne objavili DevOps v predstavách väčšiny.

Čiastočne alebo úplne, s časom, systémoví administrátori začali chápať potreby tejto konkrétnej vývojárskej skupiny, ako uľahčiť život vývojárom a testerom, ako nasadiť aktualizáciu a nezostať v piatok v kancelárii, opravujúc chyby nasadenia. Čas plynul, a teraz „hviezdami“ sa stávali systémoví administrátori, ktorí pochopili, čo vývojári chcú. S cieľom minimalizovať dopad sa začali používať nástroje na správu, všetci si spomenuli na staré a osvedčené metódy izolačnej úrovne OS, ktoré umožnili minimalizovať požiadavky na zabezpečenie, riadenie sieťovej časti, a konfiguráciu hostiteľa ako celku, a, ako následok, znížiť požiadavky na nových „hviezd“.

Objavila sa „úžasná“ vec – Docker. Prečo úžasná? Len preto, že vytvorenie izolácie v chroot alebo jail, rovnako ako OpenVZ, si vyžadovalo netriviálne znalosti OS, zatiaľ čo prostredníctvom nástroja je možné jednoducho vytvoriť izolované prostredie aplikácie na určitom hostiteľovi so všetkým potrebným vo vnútri a znovu odovzdať opraty vývoju, pričom systémový administrátor ovláda iba jeden hostiteľ, zabezpečujúc jeho bezpečnosť a vysokú dostupnosť – logické zjednodušenie. Ale pokrok nestojí na mieste a systémy sa opäť stávajú čoraz zložitejšími, komponentov je čoraz viac a jeden hostiteľ už nespĺňa potreby systému, a je potrebné budovať clustre, opäť sa vraciame k systémovým administrátorom, ktorí sú schopní postaviť tieto systémy.

Cyklicky sa objavujú rôzne systémy, ktoré zjednodušujú vývoj a/alebo administráciu, objavujú sa systémy orchestrácie, ktoré, pokiaľ nie je potrebné odísť od štandardného procesu, sú jednoduché na používanie. Mikroslužbová architektúra sa taktiež objavila s cieľom zjednodušiť všetko vyššie uvedené – menej vzájomných väzieb, jednoduchšie na správu. Vo svojej skúsenosti som nezažil úplne mikroslužbovú architektúru, povedal by som 50 na 50 – 50 percent mikroslužieb, čierne skrinky, prišlo na vstup, vyšlo spracované, ďalších 50 – roztrhnutý monolit, služby neschopné pracovať oddelene od iných komponentov. To všetko opäť uložilo obmedzenia na úroveň znalostí ako vývojárov, tak administrátorov.

Takéto "hojdania" na úrovni expertných znalostí daného zdroja pokračujú až dodnes. Ale trochu sme sa odklonili, je veľa aspektov, ktoré stojí za to osvetliť.

Build Engineer/Release Engineer

Veľmi špecializovaní inžinieri, ktorí sa objavili ako prostriedok naštandardizovania procesov zostavovania softvéru a jeho vydaní. V procese zavedenia masového Agile sa zdalo, že prestali byť potrební, čo však nie je pravda. Táto špecializácia vznikla ako prostriedok naštandardizovania práve zostavovania a dodávky softvéru vo veľkom, t.j. využívaním štandardných techník pre všetky produkty spoločnosti. S príchodom DevOps vývojári čiastočne stratili funkcie, pretože práve vývojári sa začali pripraviť na dodávku produktu, a berúc do úvahy meniaciu sa infraštruktúru a prístup k maximálne rýchlej dodávke bez ohľadu na kvalitu sa časom premenili práve na brzdu zmien, nakoľko dodržiavanie štandardov kvality nevyhnutne spomaľuje dodávky. Tak, postupne, časť funkčnosti Build/Release inžinierov prešla na plecia systémových administrátorov.

Opsy sú také rôzne

Posúvame sa ďalej a opäť prítomnosť širokého spektra povinností a nedostatok kvalifikovaných pracovníkov nás vedie k silnej specializácii, ako huby po daždi sa objavujú rôzne Operations:

TechOps — systémoví administrátori enikei aka HelpDesk Engineer
LiveOps — systémoví administrátori, prevažne zodpovední za produktívne prostredia
CloudOps — systémoví administrátori špecializujúci sa na verejné "oblačnosti" Azure, AWS, GCP, atď.
PlatOps/InfraOps/SysOps — systémoví administrátori infraštruktúry.
NetOps — sieťoví administrátori
SecOps — systémoví administrátori špecializujúci sa na informačnú bezpečnosť — PCI compliance, CIS compliance, patchovanie, atď.

DevOps — osoba, ktorá teoreticky rozumie všetkým procesom vývojového cyklu — vývoju, testovaniu, rozumie architektúre produktu, dokáže posúdiť riziká bezpečnosti, je oboznámená s prístupmi a prostriedkami automatizácie, aspoň na vysokej úrovni, a okrem toho rozumie aj pred- a post-release podpore produktu. Osoba schopná zastávať úlohu advokáta pre Operations aj Development, čo umožňuje vytvoriť priaznivú spoluprácu medzi týmito dvoma piliermi. Rozumie procesom plánovania prác tímami a manažovania očakávaní zákazníka.

Na vykonávanie takéhoto druhu prác a povinností by mala mať táto osoba prostriedky na riadenie nielen procesov vývoja a testovania, ale aj riadenia infraštruktúry produktu a plánovania zdrojov. DevOps v tomto význame nemôže byť len v IT, ani v R&D, ani dokonca v PMO, musí mať vplyv vo všetkých týchto oblastiach — technický riaditeľ spoločnosti, Chief Technical Officer.

Je to tak vo vašej spoločnosti? — Pochybujem. V mnohých prípadoch je to buď IT, alebo R&D.

Nedostatok prostriedkov a možnosti vplyvu aspoň na jednu z týchto troch oblastí činnosti spôsobí posun ťažiska problémov smerom, kde je jednoduchšie tieto zmeny uplatniť, ako napríklad uplatnenie technických obmedzení na release v súvislosti s "špinavým" kódom podľa údajov systémov statickej analýzy. To znamená, že keď PMO stanoví prísny termín na vydanie funkčnosti, R&D nemôže počas týchto časových rámcov vydať kvalitný výsledok a vydá ho podľa svojich možností, pričom odkladá refaktorovanie na neskôr, DevOps súvisiaci s IT blokuje release technickými prostriedkami. Nedostatok právomocí na zmenu situácie vedie zodpovedných zamestnancov k prejavom hyperzodpovednosti za to, na čo nemôžu vplývať, obzvlášť ak títo zamestnanci rozumejú a vidia chyby a ako ich opraviť — "Šťastie v nevedomosti", a ako následok k vyhoreniu a strate týchto zamestnancov.

Trh DevOps zdrojov

Poďme sa pozrieť na niekoľko pracovných ponúk na pozíciu DevOps od rôznych spoločností.

Sme pripravení sa s vami stretnúť, ak:

Ovladáte Zabbix a viete, čo je to Prometheus;

Iptables;

Aspiran BASH;

Profesor Ansible;

Guru Linux;

Viete používať debuggery a spoločnými silami s vývojármi nachádzať problémy aplikácií (php/java/python);

Routing vo vás nevyvoláva hysteriku;

Dávate značnú pozornosť zabezpečeniu systému;

Zálohujete "všetko a všetko", a tiež úspešne obnovujete toto "všetko a všetko";

Viete nastaviť systém tak, aby ste z minima dostali maximum;

Nastavujete replikácie pred spaním na Postgres a MySQL;

Nastavenie a úprava CI/CD je pre vás nevyhnutnosťou ako raňajky/obed/večera.

Máte skúsenosti s AWS;

Ste pripravení sa rozvíjať spolu s firmou;

Takže:

od 1 do 6 - systémový administrátor
7 - trošku sieťového administratívy, čo tiež patrí k sysadminovi strednej úrovne
8 - trošku zabezpečenia, čo je nevyhnutné pre sysadmina strednej úrovne
9-11 - Middle System Administrator
12 - V závislosti od stanovených úloh buď Middle System Administrator, alebo Build Engineer
13 - Virtualizácia - Middle System Administrator, alebo takzvaný CloudOps, rozšírené znalosti konkrétnych služieb hosting platformy, pre efektívne využívanie finančných prostriedkov a zníženie záťaže na údržbu

Zhrnujúc túto pozíciu, môžeme povedať, že chlapci sú dostatočne na úrovni Middle/Senior System Administrator.

Mimochodom, nemali by ste veľmi rozdeľovať administrátorov na Linux/Windows. Samozrejme, chápem, že služby a systémy týchto dvoch svetov sa líšia, ale základ je rovnaký a každý rešpektovaný administrátor pozná ako one, tak aj druhé, a aj keď nie, tak pre kompetentného admina nie je ťažké sa s tým oboznámiť.

Pozrime sa na inú pozíciu:

Skúsenosti s budovaním vysoko zaťažených systémov;

Vynikajúce znalosti operačného systému Linux, systémového softvéru a web stacku (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);

Skúsenosti s virtualizačnými systémami (KVM, VMWare, LXC/Docker);

Ovládanie skriptovacích jazykov;

Porozumenie princípom fungovania sietí a sieťových protokolov;

Porozumenie princípom budovania odolných systémov;

Samostatnosť a iniciatíva;

Rozoberáme:

1 - Senior System Administrator
2 - V závislosti od významu, ktorý vkladáme do tejto stack - Middle/Senior System Administrator
3 - Skúsenosti, ktoré môžu znamenať - "Klastre som nezvyšoval, ale vytváral a spravoval virtuálne stroje, mal som jeden Docker host, natiahnutý prístup k kontajnerom" - Middle System Administrator
4 — Junior System Administrator — áno, admin, ktorý nevie písať elementárne skripty automatizácie, bez ohľadu na jazyk, nie je admin — enikéy.
5 — Middle System Administrator
6 — Senior System Administrator

Súhrnne — Middle/Senior System Administrator

Ešte jedna:

Skúsenosť s devops;

Skúsenosti s jedným alebo viacerými produktmi na vytváranie CI/CD procesov. Gitlab CI bude výhodou;

Práca s kontajnermi a virtualizáciou; Ak ste používali docker – výborne, ak k8s – skvele!

Skúsenosť s prácou v agilnom tíme;

Znalosti akéhokoľvek programovacieho jazyka;

Pozrime sa:

1 — Hmm... Čo tým chalani myslia? =) Pravdepodobne sami nevedia, čo sa skrýva za týmto.
2 — Build Engineer
3 — Middle System Administrator
4 — Soft-skill, zatiaľ neuvažujme, hoci Agile je ďalšia vec, ktorá sa interpretuje, ako sa to hodí.
5 — Príliš široké — to môže byť skriptovací jazyk alebo kompilovaný. Zaujímavé, písal v škole v Pascale a Basic, budú im to vyhovovať? =)

Rád by som tiež poznamenal k bodu 3, aby sa posilnilo pochopenie, prečo tento bod pokrýva sysadmin. Kubernetes je len orchestrácia, nástroj, ktorý obalí priamu komunikáciu s ovládačmi sietí a hostiteľov virtualizácie/izolácie do niekoľkých príkazov a umožňuje abstraktnú komunikáciu s nimi, to je všetko. Na príklade vezmime 'build framework' Make, ktorý ja, mimochodom, považujem za framework. Áno, viem o móde dávať Make všade, kde treba a netreba — obaliť Maven do Make, vážne?
V podstate Make je len obal nad shellom, ktorý zjednodušuje konkrétne príkazy kompilácie, linkovania a prostredia pre kompiláciu, rovnako ako k8s.

Jedenkrát som robil pohovor s chlapcom, ktorý používal k8s vo svojej práci nad OpenStackom, a rozprával o tom, ako nasadzoval služby na ňom, avšak, keď som sa pýtal práve na OpenStack, ukázalo sa, že je administrátorovaný, rovnako ako je zapnutý systémovými administrátormi. Naozaj si myslíte, že človek, ktorý zdvihol OpenStack bez ohľadu na to, akú platformu za ním používa, nie je schopný používať k8s? =)
Tento uchádzač naozaj nie je DevOps, ale je rovnaký ako Systémový Administrátor a, aby som bol presnejší, Kubernetes Administrator.

Súhrnne opäť — Middle/Senior System Administrator to im bude stačiť.

Koľko zavesiť v gramoch

Rozdiel v ponúkaných mzdách pre uvedené pozície — 90k-200k
Teraz by som chcel vykonať parallel medzi peňažnými odmenami systémových administrátorov a DevOps inžiniermi.

V podstate, pre zjednodušenie môžeme rozdeliť úrovne podľa pracovných skúseností, hoci to nebude presné, pre účely článku to stačí.

Skúsenosti:

do 3 rokov — Junior
do 6 rokov — Middle
viac ako 6 rokov — Senior

Webová stránka na vyhľadávanie zamestnancov ponúka:
Systémoví administrátori:

Junior — 2 roky — 50k rub.
Middle — 5 rokov — 70k rub.
Senior — 11 rokov — 100k rub.

DevOps inžinieri:

Junior — 2 roky — 100k rub.
Middle — 3 roky — 160k rub.
Senior — 6 rokov — 220k rub.

Na skúsenosti DevOps'ov sa používala skúsenosť, ktorá sa aspoň čiastočne týkala SDLC.

Z vyššie uvedeného vyplýva, že v skutočnosti firmy nepotrebujú DevOps'ov, a že mohli ušetriť minimálne 50 percent z pôvodne plánovaných nákladov, ak by najali práve administrátora; navyše by mohli presnejšie určiť povinnosti hľadanej osoby a rýchlejšie uzavrieť potrebu. Netreba tiež zabúdať, že jasné rozdelenie zodpovednosti umožňuje znížiť požiadavky na personál a vytvoriť priaznivejšiu atmosféru v tíme v dôsledku absencie prekrytia. V drvivej väčšine ponúk sa objavujú utility a nálepky DevOps, ale nemajú v základe skutočné požiadavky na DevOps inžiniera, len dopyt po administrátorovi nástrojov.

Proces výučby DevOps inžinierov je tiež obmedzený na súbor špecifických prác, utilít, nedáva celkové pochopenie procesov a ich závislostí. Je to samozrejme dobré, keď dokáže človek pomocou Terraformu nahradiť AWS EKS, spolu s Fluentd sidecarom v tomto klastri a AWS ELK stackom pre systém logovania za 10 minút, pričom použije len jeden príkaz v konzole, ale ak nebude rozumieť samotnému princípu spracovania logov a na čo sú potrebné, a nebude vedieť, ako zhromažďovať metriky a sledovať degradáciu služby, tak to bude ten istý enikey, ktorý vie používať niektoré utility.

Dopyt však rodí ponuku, a vidíme extrémne prehriaty trh s pozíciou DevOps, kde požiadavky nezodpovedajú reálnej úlohe, a len umožňujú systémovým administrátorom zarábať viac.

Kto teda sú? DevOps'ovia alebo chamtiví systémoví administrátori? =)

Ako ďalej žiť?

Zamestnávateľom - presnejšie formulovať požiadavky a hľadať práve tých, ktorých potrebujete, a nie sa rozptyľovať nálepkami. Pokiaľ neviete, čomu sa DevOps venujú, nie sú vám v takom prípade potrební.

Zamestnancom - Učiť sa. Neustále zdokonaľovať svoje znalosti, pozerať sa na celkový obraz procesov a sledovať cestu k stanovenému cieľu. Môžete sa stať kýmkoľvek, ak sa len posnažíte.

Zdroj: habr.com