Momentálne je to takmer najdrahšia pozícia na trhu. Rozruch okolo inžinierov „DevOps“ presahuje všetky predstaviteľné hranice a ešte horšie je to v prípade starších inžinierov DevOps.
Pracujem ako vedúci oddelenia integrácie a automatizácie, hádajte anglické dekódovanie - DevOps Manager. Je nepravdepodobné, že by anglický prepis odrážal naše každodenné aktivity, ale ruská verzia je v tomto prípade presnejšia. Vzhľadom na charakter mojej činnosti je prirodzené, že potrebujem robiť rozhovory s budúcimi členmi svojho tímu a za posledný rok mnou prešlo asi 50 ľudí a rovnaký počet bol odrezaný na prescreene 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 druhov inžinierov.
Všetko, čo je napísané nižšie, je môj osobný názor, nemusíte s ním súhlasiť, ale pripúšťam, že to trochu prifarbí váš postoj k téme. Napriek riziku, že upadnem do nemilosti, zverejňujem svoj názor, pretože verím, že má miesto.
Spoločnosti majú rôzne chápanie toho, kto sú inžinieri DevOps, a v záujme rýchleho najatia zdroja zavesia toto označenie na každého. Situácia je dosť zvláštna, keďže firmy sú pripravené vyplácať týmto ľuďom neskutočné odmeny, pričom za nich vo väčšine prípadov dostanú správcu nástrojov.
Kto sú teda inžinieri DevOps?
Začnime históriou jeho vzhľadu – Vývojové operácie sa objavili 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 o znalosti postupov a prístupov pri riadení produktového prostredia. Inými slovami, vývojár musí rozumieť a vedieť, ako jeho produkt funguje v určitých podmienkach, musí rozumieť tomu, ako svoj produkt nasadiť, aké vlastnosti prostredia je možné upraviť, aby sa zlepšil výkon. Takže nejaký čas sa objavili vývojári s prístupom DevOps. Vývojári DevOps napísali skripty na zostavovanie a balenie, aby zjednodušili ich činnosti a výkon produkčného prostredia. Zložitosť architektúry riešenia a vzájomné ovplyvňovanie komponentov infraštruktúry však postupom času začali zhoršovať výkon prostredí, s každou iteráciou bolo potrebné čoraz hlbšie pochopenie určitých komponentov, čím sa znižovala produktivita vývojára v dôsledku dodatočných náklady na pochopenie komponentov a ladiacich systémov pre konkrétnu úlohu. Vlastné náklady vývojára rástli, náklady na produkt spolu s nimi, požiadavky na nových vývojárov v tíme prudko vyskočili, pretože potrebovali pokryť aj povinnosti vývojovej „hviezdy“ a „hviezd“ sa prirodzene zmenšovalo. a menej dostupné. Za zmienku tiež stojí, že podľa mojich skúseností sa len málo vývojárov zaujíma o špecifiká spracovania paketov jadrom operačného systému, pravidlá smerovania paketov a bezpečnostné aspekty hostiteľa. Logickým krokom bolo prilákať správcu, ktorý sa v tom vyzná a prideliť mu podobné povinnosti, čo vďaka jeho skúsenostiam umožnilo dosiahnuť rovnaké ukazovatele pri nižších nákladoch v porovnaní s nákladmi na „hviezdičkový“ vývoj. Takíto správcovia boli umiestnení do tímu a jeho hlavnou úlohou bolo riadiť testovacie a produkčné prostredia podľa pravidiel konkrétneho tímu so zdrojmi pridelenými práve tomuto tímu. Takto sa v skutočnosti DevOps objavil v mysliach väčšiny.
Čiastočne alebo úplne postupom času títo správcovia systému začali chápať potreby tohto konkrétneho tímu v oblasti vývoja, ako uľahčiť život vývojárom a testerom, ako zaviesť aktualizáciu a nezostať v piatok cez noc v kancelária, oprava chýb nasadenia. Čas plynul a teraz boli „hviezdami“ správcovia systému, ktorí pochopili, čo vývojári chcú. Aby sa minimalizoval dopad, začali prichádzať nástroje na správu, každý si pamätal staré a spoľahlivé metódy izolácie úrovne OS, ktoré umožňovali minimalizovať požiadavky na bezpečnosť, správu sieťovej časti a konfiguráciu hostiteľa ako a v dôsledku toho znížiť požiadavky na nové „hviezdy“.
Objavila sa „úžasná“ vec – docker. Prečo úžasné? Áno, len preto, že vytvorenie izolácie v chroote alebo jail, ako aj OpenVZ, si vyžadovalo netriviálne znalosti OS, na rozdiel od toho vám pomôcka umožňuje jednoducho vytvoriť izolované aplikačné prostredie na určitom hostiteľovi so všetkým potrebným vo vnútri a v ruke. opäť nad oprasami vývoja a správca systému môže spravovať len s jedným hostiteľom, čím je zaistená jeho bezpečnosť a vysoká dostupnosť – logické zjednodušenie. Pokrok však nestojí a systémy sú opäť čoraz zložitejšie, komponentov je stále viac, jeden hostiteľ už nevyhovuje potrebám systému a je potrebné budovať klastre, opäť sa vraciame k systémovým administrátorom, ktorí sú schopný vybudovať tieto systémy.
Cyklus po cykle sa objavujú rôzne systémy, ktoré zjednodušujú vývoj a/alebo administráciu, objavujú sa orchestračné systémy, ktoré, kým sa nepotrebujete odchýliť od štandardného procesu, sa ľahko používajú. Objavila sa aj architektúra mikroservisov s cieľom zjednodušiť všetko vyššie popísané – menej vzťahov, jednoduchšie spravovanie. Z mojej skúsenosti som nenašiel úplne mikroservisnú architektúru, povedal by som, že 50 až 50 - 50 percent mikroslužieb, čiernych skriniek, prišlo, vyšlo spracovaných, ďalších 50 je roztrhnutý monolit, služby neschopné fungovať oddelene od ostatných komponentov. To všetko opäť uvalilo obmedzenia na úroveň znalostí vývojárov aj administrátorov.
Podobné „výkyvy“ v úrovni odborných znalostí konkrétneho zdroja pretrvávajú dodnes. Ale to sme trochu odbočili, existuje veľa bodov, ktoré stojí za to zdôrazniť.
Stavebný inžinier/uvoľňovací inžinier
Veľmi vysoko špecializovaní inžinieri, ktorí sa objavili ako prostriedok štandardizácie procesov tvorby softvéru a vydaní. V procese zavádzania rozšíreného Agile by sa zdalo, že prestali byť žiadané, ale zďaleka to tak nie je. Táto špecializácia sa objavila ako prostriedok štandardizácie montáže a dodávky softvéru v priemyselnom meradle, t.j. pomocou štandardných techník pre všetky produkty spoločnosti. S príchodom DevOps vývojári čiastočne stratili svoje funkcie, pretože to boli vývojári, ktorí začali pripravovať produkt na dodávku a vzhľadom na meniacu sa infraštruktúru a prístup k čo najrýchlejšiemu dodaniu bez ohľadu na kvalitu sa časom zmenili na brzdou zmien, pretože dodržiavanie noriem kvality nevyhnutne spomaľuje dodávky. Postupne sa tak časť funkcionality Build/Release inžinierov presunula na plecia systémových administrátorov.
Ops sú také odlišné
Ideme ďalej a opäť prítomnosť veľkého rozsahu povinností a nedostatok kvalifikovaného personálu nás tlačí k prísnej špecializácii, ako huby po daždi vznikajú rôzne prevádzky:
- TechOps - správcovia systému enikey alias HelpDesk Engineer
- LiveOps – správcovia systému, ktorí sú primárne zodpovední za produkčné prostredia
- CloudOps - správcovia systému špecializujúci sa na verejné cloudy Azure, AWS, GCP atď.
- PlatOps/InfraOps/SysOps - správcovia systémov infraštruktúry.
- NetOps – správcovia siete
- SecOps – správcovia systémov so špecializáciou na informačnú bezpečnosť – súlad s PCI, súlad s CIS, záplatovanie atď.
DevOps je (teoreticky) človek, ktorý z prvej ruky rozumie všetkým procesom vývojového cyklu - vývoj, testovanie, rozumie architektúre produktu, je schopný posúdiť bezpečnostné riziká, pozná prístupy a automatizačné nástroje, minimálne na vysokej úrovni. úrovni okrem toho rozumie aj podpora pred a po spracovaní. Osoba schopná pôsobiť ako obhajca prevádzky aj rozvoja, čo umožňuje priaznivú spoluprácu medzi týmito dvoma piliermi. Rozumie procesom plánovania práce tímov a riadenia očakávaní zákazníkov.
Na vykonávanie tohto druhu práce a zodpovedností musí mať táto osoba prostriedky na riadenie nielen procesov vývoja a testovania, ale aj riadenia infraštruktúry produktu, ako aj plánovania zdrojov. DevOps v tomto chápaní nemôže byť umiestnený ani v IT, ani vo výskume a vývoji, dokonca ani v PMO; musí mať vplyv vo všetkých týchto oblastiach - technický riaditeľ spoločnosti, technický riaditeľ.
Platí to vo vašej spoločnosti? - Pochybujem. Vo väčšine prípadov ide buď o IT alebo výskum a vývoj.
Nedostatok financií a schopnosť ovplyvniť aspoň jednu z týchto troch oblastí činnosti presunie váhu problémov tam, kde sa tieto zmeny ľahšie uplatňujú, ako je napríklad uplatňovanie technických obmedzení na uvoľnenie v súvislosti so „špinavým“ kódom podľa statických analyzátorové systémy. To znamená, že keď PMO stanoví prísny termín na uvoľnenie funkčnosti, R&D nemôže v rámci týchto termínov vyprodukovať kvalitný výsledok a vyprodukuje ho čo najlepšie, pričom refaktoring nechá na neskôr, DevOps súvisiace s IT blokuje uvoľnenie technickými prostriedkami. . Nedostatok právomocí zmeniť situáciu u zodpovedných zamestnancov vedie k prejavom hyperzodpovednosti za to, čo nemôžu ovplyvniť, najmä ak títo zamestnanci chápu a vidia chyby a ako ich napraviť - „Blaženosť v nevedomosti“ a v dôsledku toho k vyhoreniu a strate týchto zamestnancov.
Trh zdrojov DevOps
Pozrime sa na niekoľko voľných pozícií na pozície DevOps od rôznych spoločností.
Sme pripravení sa s vami stretnúť, ak:
- Vlastníte Zabbix a viete, čo je Prometheus;
- iptables;
- doktorand BASH;
- profesor Ansible;
- Linuxový guru;
- Vedieť, ako používať ladenie a nájsť problémy s aplikáciami spolu s vývojármi (php/java/python);
- Smerovanie vás neurobí hysterickým;
- Venujte veľkú pozornosť bezpečnosti systému;
- Zálohujte „všetko a všetko“ a tiež úspešne obnovte toto „všetko a všetko“;
- Viete, ako nakonfigurovať systém tak, aby ste z minima vyťažili maximum;
- Nastavte replikáciu pred spaním na Postgres a MySQL;
- Nastavenie a nastavenie CI/CD je pre vás rovnako potrebné ako raňajky/obed/večera.
- Máte skúsenosti s AWS;
- Pripravený na rozvoj so spoločnosťou;
Takže:
- od 1 do 6 - správca systému
- 7 - malá správa siete, ktorá sa hodí aj do správcu systému, stredná úroveň
- 8 - malá bezpečnosť, ktorá je povinná pre správcu systému strednej úrovne
- 9-11 – Správca stredného systému
- 12 — V závislosti od priradených úloh buď správca stredného systému alebo staviteľ
- 13 - Virtualizácia - Middle System Administrator, alebo takzvaný CloudOps, pokročilá znalosť služieb konkrétneho hostingového webu, pre efektívne využitie financií a zníženie záťaže na údržbu
Keď zhrnieme túto voľnú pozíciu, môžeme povedať, že stredný/vyšší správca systému chlapom stačí.
Mimochodom, nemali by ste silne rozdeľovať správcov v systéme Linux/Windows. Samozrejme chápem, že služby a systémy týchto dvoch svetov sú odlišné, ale základ pre všetkých je rovnaký a každý sebaúctyhodný admin pozná jeden aj druhý, a aj keď nepozná, bude pre kompetentného administrátora nebude ťažké sa v ňom vyznať.
Pozrime sa na ďalšie voľné miesto:
- Skúsenosti s budovaním systémov s vysokým zaťažením;
- Výborná znalosť OS Linux, všeobecný systémový softvér a webový zásobník (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Skúsenosti s virtualizačnými systémami (KVM, VMWare, LXC/Docker);
- znalosť skriptovacích jazykov;
- Pochopenie princípov fungovania sietí sieťových protokolov;
- Pochopenie princípov budovania systémov odolných voči poruchám;
- Nezávislosť a iniciatíva;
Poďme sa pozrieť na:
- 1 – Senior System Administrator
- 2 - V závislosti od významu vloženého do tohto zásobníka - Stredný/Senior System Administrator
- 3 - Pracovné skúsenosti, vrátane, môžu znamenať - "Klaster nevytvoril, ale vytvoril a spravoval virtuálne stroje, bol tam jeden hostiteľ Docker, prístup ku kontajnerom nebol k dispozícii" - Správca stredného systému
- 4 - Junior System Administrator - áno, admin, ktorý nevie písať základné automatizačné skripty bez ohľadu na jazyk, nie admin - enikey.
- 5 - Správca stredného systému
- 6 – Senior System Administrator
Aby som to zhrnul - stredný/vyšší správca systému
Ďalší:
- Devops skúsenosti;
- Skúsenosti s používaním jedného alebo viacerých produktov na vytváranie procesov CI/CD. Gitlab CI bude výhodou;
- Práca s kontajnermi a virtualizácia; Ak ste použili docker, dobré, ale ak ste použili k8, skvelé!
- Skúsenosti s prácou v agilnom tíme;
- znalosť akéhokoľvek programovacieho jazyka;
Pozrime sa:
- 1 - Hmm... Čo tým chlapci myslia? =) S najväčšou pravdepodobnosťou sami nevedia, čo sa za tým skrýva
- 2 - Stavebný inžinier
- 3 - Správca stredného systému
- 4 - Mäkká zručnosť, o nej zatiaľ nebudeme uvažovať, hoci agilnosť je ďalšia vec, ktorá sa interpretuje spôsobom, ktorý je pohodlný.
- 5 - Príliš podrobný - môže to byť skriptovací jazyk alebo kompilovaný jazyk. Zaujímalo by ma, či im bude vyhovovať písanie v jazyku Pascal a Basic v škole? =)
Chcel by som tiež zanechať poznámku k bodu 3, aby som lepšie pochopil, prečo sa týmto bodom zaoberá správca systému. Kubernetes je len orchestrácia, nástroj, ktorý zabalí priame príkazy sieťovým ovládačom a hostiteľom virtualizácie/izolácie do niekoľkých príkazov a umožní vám s nimi abstraktne komunikovať, to je všetko. Vezmime si napríklad „build framework“ Make, ktorý mimochodom nepovažujem za rámec. Áno, viem o móde strkať Make kamkoľvek, kde je to potrebné a nie potrebné – obaliť Mavena v Make napríklad vážne?
Make je v podstate len obal nad shellom, ktorý zjednodušuje príkazy prostredia kompilácie, prepojenia a kompilácie, rovnako ako k8s.
Raz som robil rozhovor s chlapíkom, ktorý používal k8s vo svojej práci na OpenStacku, a hovoril o tom, ako na ňom nasadil služby, keď som sa však spýtal na OpenStack, ukázalo sa, že bol spravovaný a tiež vytvorený systémom. správcovia. Naozaj si myslíš, že človek, ktorý si nainštaloval OpenStack, bez ohľadu na to, akú platformu používa za sebou, nie je schopný používať k8s? =)
Tento žiadateľ v skutočnosti nie je DevOps, ale správca systému a presnejšie správca Kubernetes.
Zhrňme si to ešte raz – postačí im Middle/Senior System Administrator.
Koľko vážiť v gramoch
Rozsah navrhovaných miezd na uvedené voľné pracovné miesta je 90-200-tisíc
Teraz by som chcel uviesť paralelu medzi peňažnými odmenami systémových administrátorov a DevOps Engineers.
V zásade, aby ste veci zjednodušili, môžete známky rozhádzať na základe pracovných skúseností, aj keď to nebude presné, ale na účely článku to bude stačiť.
Skúsenosť:
- do 3 rokov – Junior
- do 6 rokov – Stred
- viac ako 6 – Senior
Stránka na vyhľadávanie zamestnancov ponúka:
Správcovia systému:
- Junior - 2 roky - 50 XNUMX rub.
- Stredná - 5 rokov - 70 XNUMX rub.
- Senior - 11 rokov - 100 XNUMX rub.
Inžinieri DevOps:
- Junior - 2 roky - 100 XNUMX rub.
- Stredná - 3 roky - 160 XNUMX rub.
- Senior - 6 rokov - 220 XNUMX rub.
Podľa skúseností „DevOps“ boli použité skúsenosti, ktoré aspoň nejako ovplyvnili SDLC.
Z vyššie uvedeného vyplýva, že spoločnosti v skutočnosti DevOps nepotrebujú, a tiež, že by najatím administrátora mohli ušetriť minimálne 50 percent pôvodne plánovaných nákladov, navyše by mohli jasnejšie definovať zodpovednosť osoby, ktorú hľadajú. a rýchlejšie naplniť potrebu. Netreba zabúdať ani na to, že jasné rozdelenie zodpovedností nám vďaka absencii presahov umožňuje znižovať nároky na personál, ako aj vytvárať priaznivejšiu atmosféru v tíme. Prevažná väčšina voľných pracovných miest je plná utilít a štítkov DevOps, ale nie sú založené na skutočných požiadavkách na DevOps Engineer, ale iba na požiadavkách na správcu nástroja.
Proces školenia inžinierov DevOps je tiež obmedzený len na súbor konkrétnych prác, pomôcok a neposkytuje všeobecné pochopenie procesov a ich závislostí. Určite je dobré, keď človek dokáže nasadiť AWS EKS pomocou Terraformu, v spojení s postranným vozíkom Fluentd v tomto klastri a zásobníkom AWS ELK pre logovací systém za 10 minút pomocou jediného príkazu v konzole, ale ak nerozumie princíp samotného spracovania logov a na čo sú potrebné, ak na nich neviete zbierať metriky a sledovať degradáciu služby, tak to bude stále ten istý enikey, ktorý vie použiť nejaké utility.
Dopyt však vytvára ponuku a na pozícii DevOps vidíme extrémne prehriaty trh, kde požiadavky nezodpovedajú skutočnej úlohe, ale umožňujú iba administrátorom systému zarobiť viac.
Kto sú teda? DevOps alebo chamtiví správcovia systému? =)
Ako ďalej žiť?
Zamestnávatelia by mali presnejšie formulovať požiadavky a hľadať presne tých, ktorí sú potrební, a nie rozhadzovať nálepky. Neviete, čo robia DevOps – v takom prípade ich nepotrebujete.
Pracovníci – učte sa. Neustále zdokonaľujte svoje znalosti, pozerajte sa na celkový obraz procesov a sledujte cestu k svojmu cieľu. Môžete sa stať kým chcete, len to musíte skúsiť.
Zdroj: hab.com