V tuto chvíli jde o téměř nejdražší pozici na trhu. Povyk kolem inženýrů „DevOps“ překračuje všechny představitelné meze a ještě horší je u starších inženýrů DevOps.
Pracuji jako vedoucí oddělení integrace a automatizace, hádejte anglické dekódování - DevOps Manager. Je nepravděpodobné, že by anglický přepis odrážel naše každodenní aktivity, ale ruská verze je v tomto případě přesnější. Vzhledem k povaze mé činnosti je přirozené, že potřebuji zpovídat budoucí členy svého týmu a za poslední rok mnou prošlo asi 50 lidí a stejný počet byl odříznut na prescreenu s mými zaměstnanci.
Stále hledáme kolegy, protože za označením DevOps se skrývá velmi velká vrstva různých druhů inženýrů.
Vše napsané níže je můj osobní názor, nemusíte s ním souhlasit, ale uznávám, že to trochu přibarví váš postoj k tématu. I přes riziko, že upadnu v nemilost, zveřejňuji svůj názor, protože věřím, že má své místo.
Společnosti různě chápou, kdo jsou inženýři DevOps, a v zájmu rychlého najmutí zdroje navěsí toto označení na každého. Situace je poměrně zvláštní, protože firmy jsou připraveny těmto lidem vyplácet nereálné odměny a ve většině případů za ně dostávají správce nástrojů.
Kdo jsou tedy inženýři DevOps?
Začněme historií jeho vzhledu – Vývojové operace se objevily jako další krok k optimalizaci interakce v malých týmech ke zvýšení rychlosti výroby produktu, jako očekávaný důsledek. Smyslem bylo posílit vývojový tým o znalosti postupů a přístupů při řízení produktového prostředí. Jinými slovy, vývojář musí rozumět a vědět, jak jeho produkt funguje za určitých podmínek, musí rozumět tomu, jak svůj produkt nasadit, jaké vlastnosti prostředí lze upravit pro zlepšení výkonu. Nějakou dobu se tedy objevili vývojáři s přístupem DevOps. Vývojáři DevOps napsali skripty sestavení a balení, aby zjednodušili jejich činnosti a výkon produkčního prostředí. Složitost architektury řešení a vzájemné ovlivňování infrastrukturních komponent však postupem času začaly zhoršovat výkon prostředí, s každou iterací bylo vyžadováno stále hlubší porozumění určitým komponentám, což snižovalo produktivitu vývojáře kvůli dalšímu náklady na pochopení komponent a systémů ladění pro konkrétní úkol. Vlastní náklady vývojáře rostly, náklady na produkt spolu s nimi, požadavky na nové vývojáře v týmu prudce vyskočily, protože také potřebovali pokrýt odpovědnost vývojové „hvězdy“ a přirozeně se „hvězd“ zmenšilo. a méně dostupné. Za zmínku také stojí, že podle mých zkušeností se jen málo vývojářů zajímá o specifika zpracování paketů jádrem operačního systému, pravidla pro směrování paketů a bezpečnostní aspekty hostitele. Logickým krokem bylo přilákat administrátora, který se v tom vyzná a přidělit mu podobné povinnosti, což díky jeho zkušenostem umožnilo dosáhnout stejných ukazatelů s nižšími náklady ve srovnání s náklady „hvězdného“ vývoje. Tito správci byli umístěni do týmu a jeho hlavním úkolem bylo řídit testovací a produkční prostředí podle pravidel konkrétního týmu se zdroji přidělenými právě tomuto týmu. Takto se ve skutečnosti DevOps objevil v myslích většiny.
Částečně nebo úplně postupem času tito správci systému začali chápat potřeby tohoto konkrétního týmu v oblasti vývoje, jak usnadnit život vývojářům a testerům, jak nasadit aktualizaci a nemuset zůstávat přes noc v pátek v kancelář, oprava chyb při nasazení. Čas plynul a nyní byli „hvězdami“ správci systému, kteří chápali, co vývojáři chtějí. Aby byl dopad minimalizován, začaly se objevovat nástroje pro správu, všichni si pamatovali staré a spolehlivé metody izolace úrovně OS, které umožňovaly minimalizovat požadavky na zabezpečení, správu síťové části a konfiguraci hostitele jako celé a v důsledku toho snížit požadavky na nové „hvězdy“.
Objevila se "úžasná" věc - docker. Proč úžasné? Ano, pouze proto, že vytvoření izolace v chrootu nebo ve vězení, stejně jako OpenVZ, vyžadovalo netriviální znalost OS, na rozdíl od toho vám utilita umožňuje jednoduše vytvořit izolované aplikační prostředí na určitém hostiteli se vším potřebným uvnitř a v ruce opět nad otěží vývoje a správce systému může spravovat pouze jeden hostitel, což zajišťuje jeho bezpečnost a vysokou dostupnost - logické zjednodušení. Pokrok ale nestojí a systémy jsou opět čím dál složitější, komponent je stále více, jeden hostitel již nevyhovuje potřebám systému a je nutné budovat clustery, opět se vracíme k systémovým administrátorům, kteří jsou schopni tyto systémy postavit.
Cyklus po cyklu se objevují různé systémy, které zjednodušují vývoj a/nebo administraci, objevují se orchestrační systémy, které, dokud se nepotřebujete odchýlit od standardního procesu, jsou snadno použitelné. Objevila se také architektura mikroservisů s cílem zjednodušit vše výše popsané – méně vztahů, snadnější správa. Z mé zkušenosti jsem nenašel úplně mikroservisní architekturu, řekl bych 50 až 50 - 50 procent mikroslužeb, černé skříňky, přišly, vyšly zpracované, dalších 50 je roztrhaný monolit, služby neschopné fungovat odděleně od ostatních komponenty. To vše opět uvalilo omezení na úroveň znalostí jak vývojářů, tak administrátorů.
Podobné „výkyvy“ v úrovni odborných znalostí konkrétního zdroje přetrvávají dodnes. Ale to jsme trochu odbočili, existuje mnoho bodů, které stojí za to zdůraznit.
Stavební inženýr/Inženýr uvolnění
Velmi vysoce specializovaní inženýři, kteří se objevili jako prostředek standardizace procesů a verzí tvorby softwaru. V procesu zavádění rozšířených Agile by se zdálo, že přestaly být žádané, ale zdaleka tomu tak není. Tato specializace se objevila jako prostředek standardizace montáže a dodávky softwaru v průmyslovém měřítku, tzn. pomocí standardních technik pro všechny produkty společnosti. S příchodem DevOps vývojáři částečně ztratili své funkce, protože to byli vývojáři, kteří začali připravovat produkt k dodání, a vzhledem k měnící se infrastruktuře a přístupu k co nejrychlejšímu dodání bez ohledu na kvalitu se postupem času změnili v brzdou změn, protože dodržování standardů kvality nevyhnutelně zpomaluje dodávky. Postupně se tedy část funkčnosti Build/Release inženýrů přesunula na ramena systémových administrátorů.
Ops jsou tak odlišné
Jdeme dál a opět přítomnost velkého spektra povinností a nedostatek kvalifikovaného personálu nás tlačí k přísné specializaci, jako houby po dešti se objevují různé Operace:
- TechOps – správci systému enikey aka HelpDesk Engineer
- LiveOps – správci systému primárně zodpovědní za produkční prostředí
- CloudOps - systémoví administrátoři se specializací na veřejné cloudy Azure, AWS, GCP atd.
- PlatOps/InfraOps/SysOps - správci infrastrukturního systému.
- NetOps – správci sítí
- SecOps - systémoví administrátoři specializující se na informační bezpečnost - PCI compliance, CIS compliance, patching atd.
DevOps je (teoreticky) člověk, který z první ruky rozumí všem procesům vývojového cyklu – vývoj, testování, rozumí architektuře produktu, je schopen posoudit bezpečnostní rizika, zná přístupy a automatizační nástroje, alespoň na vysoké úrovni úroveň, kromě toho také rozumí před- a post-processing podporu vydání produktu. Osoba schopná působit jako obhájce provozu i rozvoje, což umožňuje příznivou spolupráci mezi těmito dvěma pilíři. Rozumí procesům plánování práce týmů a řízení očekávání zákazníků.
Aby tato osoba mohla vykonávat tento druh práce a povinností, musí mít prostředky k řízení nejen vývojových a testovacích procesů, ale také správy produktové infrastruktury a také plánování zdrojů. DevOps v tomto chápání nemůže být umístěn ani v IT, ani ve výzkumu a vývoji, dokonce ani v PMO, musí mít vliv ve všech těchto oblastech – technický ředitel společnosti, Chief Technical Officer.
Platí to ve vaší společnosti? - Pochybuji. Ve většině případů se jedná buď o IT, nebo o výzkum a vývoj.
Nedostatek finančních prostředků a schopnost ovlivnit alespoň jednu z těchto tří oblastí činnosti přesune váhu problémů tam, kde je snazší tyto změny aplikovat, jako je aplikace technických omezení na vydání v souvislosti se „špinavým“ kódem podle statických analyzátorové systémy. To znamená, že když PMO stanoví přísný termín pro vydání funkčnosti, R&D nemůže v těchto termínech vytvořit vysoce kvalitní výsledek a vytvoří jej co nejlépe, refaktoring nechává na později, DevOps související s IT blokuje vydání pomocí technických prostředků . Nedostatek pravomoci změnit situaci u odpovědných zaměstnanců vede k projevu hyperzodpovědnosti za to, co nemohou ovlivnit, zvláště pokud tito zaměstnanci chápou a vidí chyby a jak je napravit - „Blaženost je nevědomost“, a v důsledku toho k vyhoření a ztrátě těchto zaměstnanců.
Trh zdrojů DevOps
Podívejme se na několik volných pozic pro pozice DevOps od různých společností.
Jsme připraveni se s vámi setkat, pokud:
- Vlastníte Zabbix a víte, co je Prometheus;
- iptables;
- BASH PhD student;
- profesor Ansible;
- Linuxový guru;
- Vědět, jak používat ladění a hledat problémy aplikací společně s vývojáři (php/java/python);
- Směrování vás nezpůsobí hysterii;
- Věnujte velkou pozornost zabezpečení systému;
- Zálohujte „cokoli a všechno“ a také úspěšně obnovte toto „cokoli a všechno“;
- Víte, jak nakonfigurovat systém tak, abyste z minima vytěžili maximum;
- Před spaním nastavte replikaci na Postgres a MySQL;
- Nastavení a nastavení CI/CD je pro vás stejně nezbytné jako snídaně/oběd/večeře.
- Máte zkušenosti s AWS;
- Připraveno k rozvoji se společností;
Takže:
- od 1 do 6 - správce systému
- 7 - malá správa sítě, která se hodí i do správce systému, střední úroveň
- 8 - malé zabezpečení, které je povinné pro správce systému střední úrovně
- 9-11 – Správce středního systému
- 12 — V závislosti na přiřazených úlohách buď Middle System Administrator nebo Build Engineer
- 13 - Virtualizace - Middle System Administrator neboli tzv. CloudOps, pokročilá znalost služeb konkrétního hostingového webu, pro efektivní využití finančních prostředků a snížení zátěže na údržbu
Shrneme-li toto volné místo, můžeme říci, že střední/seniorní systémový administrátor klukům stačí.
Mimochodem, neměli byste silně rozdělovat administrátory na Linuxu/Windows. Samozřejmě chápu, že služby a systémy těchto dvou světů jsou různé, ale základ pro všechny je stejný a každý seberespektující admin zná jeden i druhý, a i když nezná, bude pro kompetentního administrátora nebude obtížné se v něm vyznat.
Podívejme se na další volné místo:
- Zkušenosti s budováním vysokozatížených systémů;
- Výborná znalost OS Linux, obecný systémový software a web stack (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Zkušenosti s virtualizačními systémy (KVM, VMWare, LXC/Docker);
- znalost skriptovacích jazyků;
- Pochopení principů fungování sítí síťových protokolů;
- Pochopení principů budování systémů odolných vůči poruchám;
- Nezávislost a iniciativa;
Pojďme se podívat:
- 1 – Senior System Administrator
- 2 - V závislosti na významu vloženém do tohoto zásobníku - Střední/Senior System Administrator
- 3 - Pracovní zkušenosti, včetně, mohou znamenat - "Cluster nezvedl, ale vytvořil a spravoval virtuální stroje, byl tam jeden hostitel Docker, přístup ke kontejnerům nebyl k dispozici" - Správce středního systému
- 4 - Junior System Administrator - ano, admin, který neumí psát základní automatizační skripty bez ohledu na jazyk, ne admin - enikey.
- 5 - Správce středního systému
- 6 – Senior System Administrator
Abych to shrnul - Střední/Senior System Administrator
Ještě jeden:
- Devops zkušenosti;
- Zkušenosti s používáním jednoho nebo více produktů k vytváření procesů CI/CD. Gitlab CI bude výhodou;
- Práce s kontejnery a virtualizace; Pokud jste použili docker, dobře, ale pokud jste použili k8, skvělé!
- Zkušenosti s prací v agilním týmu;
- znalost jakéhokoli programovacího jazyka;
Uvidíme:
- 1 - Hmm... Co tím kluci myslí? =) S největší pravděpodobností sami nevědí, co se za tím skrývá
- 2 - Stavební inženýr
- 3 - Správce středního systému
- 4 - Měkká dovednost, o ní zatím nebudeme uvažovat, ačkoli Agile je další věc, která se interpretuje způsobem, který je pohodlný.
- 5 - Příliš mnohomluvný - může to být skriptovací jazyk nebo kompilovaný jazyk. Zajímalo by mě, jestli jim ve škole bude vyhovovat psaní v Pascalu a Basicu? =)
Rád bych také zanechal poznámku k bodu 3, abych lépe pochopil, proč se tímto bodem zabývá správce systému. Kubernetes je jen orchestrace, nástroj, který zabaluje přímé příkazy síťovým ovladačům a hostitelům virtualizace/izolace do několika příkazů a umožňuje vám s nimi abstraktně komunikovat, to je vše. Vezměme si například 'build framework' Make, což mimochodem nepovažuji za rámec. Ano, vím o módě strkat Make kamkoli, kde je to nutné a nepotřebné – obalit Mavena například v Make vážně?
Make je v podstatě jen obal nad shellem, který zjednodušuje příkazy prostředí kompilace, propojení a kompilace, stejně jako k8s.
Jednou jsem dělal rozhovor s člověkem, který používal k8s ve své práci na OpenStacku, a mluvil o tom, jak na něm nasazoval služby, ale když jsem se zeptal na OpenStack, ukázalo se, že byl spravován a také vyvíjen systémem správci. Opravdu si myslíš, že člověk, který si nainstaloval OpenStack, bez ohledu na to, jakou platformu za sebou používá, není schopen používat k8s? =)
Tento žadatel ve skutečnosti není DevOps, ale správce systému a přesněji správce Kubernetes.
Shrňme si to ještě jednou – postačí jim Middle/Senior System Administrator.
Kolik vážit v gramech
Rozsah navrhovaných mezd na uvedená volná místa je 90-200 tisíc
Nyní bych rád uvedl paralelu mezi peněžními odměnami systémových administrátorů a DevOps Engineers.
V zásadě můžete pro zjednodušení rozptýlit známky na základě pracovních zkušeností, i když to nebude přesné, ale pro účely článku to bude stačit.
Zkušenost:
- do 3 let – Junior
- do 6 let – střední
- více než 6 – senior
Stránka pro vyhledávání zaměstnanců nabízí:
Správci systému:
- Junior - 2 roky - 50 XNUMX rub.
- Střední - 5 let - 70 XNUMX rub.
- Senior - 11 let - 100 XNUMX rub.
Inženýři DevOps:
- Junior - 2 roky - 100 XNUMX rub.
- Střední - 3 roky - 160 XNUMX rub.
- Senior - 6 let - 220 XNUMX rub.
Podle zkušeností „DevOps“ byly použity zkušenosti, které alespoň nějak ovlivnily SDLC.
Z výše uvedeného vyplývá, že společnosti ve skutečnosti DevOps nepotřebují a také že by najmutím Administrátora mohly ušetřit minimálně 50 procent původně plánovaných nákladů, navíc by mohly jasněji definovat zodpovědnosti osoby, kterou hledají. a rychleji vyplňte potřebu. Neměli bychom zapomínat ani na to, že jasné rozdělení odpovědností nám díky absenci přesahů umožňuje snížit nároky na personál a vytvořit příznivější atmosféru v týmu. Drtivá většina volných míst je plná utilit a DevOps štítků, ale nevycházejí ze skutečných požadavků na DevOps Engineera, pouze z požadavků na správce nástroje.
Proces školení inženýrů DevOps je také omezen pouze na sadu konkrétních prací, utilit a neposkytuje obecné pochopení procesů a jejich závislostí. Určitě je dobré, když člověk může nasadit AWS EKS pomocí Terraformu, ve spojení s postranním vozíkem Fluentd v tomto clusteru a zásobníkem AWS ELK pro logovací systém za 10 minut pomocí jediného příkazu v konzole, ale pokud nerozumí princip samotného zpracování logů a k čemu jsou potřeba, pokud nevíte, jak na nich sbírat metriky a sledovat degradaci služby, tak to bude pořád ten samý enikey, který ví, jak používat nějaké utility.
Poptávka však vytváří nabídku a na pozici DevOps vidíme extrémně přehřátý trh, kde požadavky neodpovídají skutečné roli, ale umožňují pouze správcům systému vydělat více.
tak kdo to jsou? DevOps nebo chamtiví správci systému? =)
Jak dál žít?
Zaměstnavatelé by měli přesněji formulovat požadavky a hledat přesně ty, kteří jsou potřeba, a ne házet nálepkami. Nevíte, co DevOps dělají – v takovém případě je nepotřebujete.
Dělníci - Učte se. Neustále zdokonalujte své znalosti, dívejte se na celkový obraz procesů a sledujte cestu ke svému cíli. Můžete se stát kýmkoli chcete, jen to musíte zkusit.
Zdroj: www.habr.com