V současnosti je to snad nejdražší pozice na trhu. Hlava kolem inženýrů „DevOps“ převyšuje všechny myslitelné meze, a pro seniorní DevOps inženýry to platí dvojnásobně.
Pracuji jako vedoucí oddělení integrace a automatizace, uhádnete anglickou zkratku – DevOps Manager. Odráží přesně anglická zkratka naši každodenní činnost? O tom pochybuji, ale ruská varianta je v tomto případě přesnější. Ve své práci je samozřejmě potřeba pohovírat si s budoucími členy mého týmu a za uplynulý rok jsem prošel skrze 50 lidí, a ještě tolik bylo vyloučeno při preskrínu s mými zaměstnanci.
Stále jsme na hledání kolegů, protože za značkou DevOps se skrývá velmi široká vrstva různých inženýrů.
Vše, co je napsáno níže, je můj osobní názor, nemusíte s ním souhlasit, avšak připouštím, že to může přinést odstín do vašeho názoru na téma. I přes riziko, že se dostanu do nemilosti, zveřejňuji svůj názor, neboť si myslím, že má místo být.
Společnosti mají různé názory na to, kdo jsou DevOps inženýři, a pro rychlé najímání zdrojů připevňují tuto značku všem. Situace je dost podivná, protože společnosti jsou ochotny platit nereálné odměny těmto lidem, přičemž většinou dostávají administrátora-nástrojaře.
Kdo tedy jsou DevOps inženýři?
Pojďme začít s historií vzniku – Development Operations se objevil jako další krok k optimalizaci spolupráce v malých týmech za účelem zvýšení rychlosti výroby produktu, což bylo očekávaným důsledkem. Myšlenka spočívala v posílení týmu vývojářů znalostmi o postupech a přístupech v řízení produktového prostředí. Jinými slovy, vývojář by měl rozumět a vědět, jak jeho produkt funguje v různých podmínkách, měl by chápat, jak nasadit svůj produkt, jaké charakteristiky prostředí upravit, aby se zvýšil výkon. V průběhu času se tak objevili vývojáři s přístupem DevOps. DevOps vývojáři psali skripty pro sestavení a balení, aby usnadnili svou činnost a funkčnost produktivního prostředí. Nicméně složitost architektury řešení a vzájemný vliv komponent infrastruktury v průběhu času začaly zhoršovat pracovní ukazatele prostředí, každá iterace vyžadovala stále hlubší porozumění různým komponentům, což snižovalo produktivitu samotného vývojáře kvůli dodatečným nákladům na pochopení komponent a ladění systémů pro konkrétní úkol. Vlastní náklady vývojáře rostly, náklady na produkt šly ruku v ruce s nimi, a nároky na nové vývojáře v týmu prudce vzrostly, protože museli také pokrýt povinnosti 'hvězdy' vývoje, a přirozeně, 'hvězdy' se stávaly stále méně dostupnými. Také stojí za zmínku, že ze své zkušenosti vím, že málokoho z vývojářů zajímá specifika zpracování paketů jádrem operačního systému, pravidla směrování paketů, aspekty bezpečnosti hostitele. Logickým krokem bylo přizvat administrátora, který se s tímto obeznámen a přenést podobné povinnosti právě na něj, což díky jeho zkušenostem umožnilo dosáhnout stejných výsledků s menšími náklady než náklady na 'hvězdu' vývoje. Takoví administrátoři byli začleněni do týmu a jejich hlavním úkolem bylo řízení testovacích a produktivních prostředí podle pravidel konkrétního týmu, s prostředky vyčleněnými právě tomuto týmu. Tak se vlastně objevili DevOps v představách většiny.
Částečně nebo zcela, postupem času, začali tito systémoví administrátoři chápat potřeby konkrétního týmu vývoje, jak usnadnit život vývojářům a testerům, jak nasadit aktualizaci a nezůstávat v kanceláři v pátek v noci, abychom opravovali chyby při nasazení. Čas plynul a nyní se "hvězdami" stali systémoví administrátoři, kteří rozuměli tomu, co vývojáři chtějí. S cílem minimalizovat dopad se začaly objevovat nástroje pro správu, všichni si vzpomněli na staré a spolehlivé metody izolace na úrovni OS, které minimalizovaly požadavky na bezpečnost, správu síťové části a celkovou konfiguraci hostitele a tím snížily požadavky na nové "hvězdy."
Objevila se "úžasná" věc — docker. Proč úžasná? Jen proto, že vytvoření izolace v chroot nebo jail, stejně jako OpenVZ, vyžadovalo netriviální znalosti OS, a protinástroj, který nám umožňuje jednoduše vytvořit izolované prostředí aplikace na nějakém hostiteli se vším potřebným uvnitř a předat otěže vývoje zpět, zatímco systémový administrátor spravuje pouze jeden hostitel, zajišťující jeho bezpečnost a vysokou dostupnost — logické zjednodušení. Ale pokrok nestojí na místě a systémy se opět stávají stále složitějšími, komponentů je čím dál víc, jeden hostitel již nesplňuje potřeby 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.
Cyklicky se objevují různé systémy usnadňující vývoj a/nebo administraci, objevují se orchestrace, které, dokud není potřeba odklonit se od standardního procesu, jsou snadno použitelné. Mikroservisní architektura se také objevila s cílem zjednodušit vše výše popsané — méně vzájemných vazeb, snadnější správa. Ve svém zkušenosti jsem plně nezažil mikroservisní architekturu, řekl bych, že je to 50 na 50 — 50 procent mikroservisů, černé krabice, co přišlo na vstup, vyšlo zpracované, ostatních 50 — roztrhaný monolit, služby neschopné pracovat samostatně od ostatních komponent. To všechno opět uložilo omezení na úroveň znalostí jak vývojářů, tak administrátorů.
Podobné "houpačky" odborných znalostí určitého zdroje trvají až do dnešního dne. Ale trochu jsme se odklonili, je tu řada věcí, které stojí za to osvětlit.
Build Engineer/Release Engineer
Velmi specializovaní inženýři, kteří se objevili jako prostředek standardizace procesů sestavování softwaru a jeho uvolnění. V době masivního zavádění Agile by se mohlo zdát, že přestali být žádaní, ale to není pravda. Tato specializace vznikla jako prostředek standardizace právě sestavování a dodávky softwaru ve velkém měřítku, tedy využíváním standardních technik pro všechny produkty společnosti. Se vznikem DevOps vývojáři částečně ztratili funkce, protože to byli právě vývojáři, kteří připravovali produkt k dodání, a vzhledem k měnící se infrastruktuře a přístupu co nejrychlejší dodávce bez ohledu na kvalitu se časem stali vlastně brzdou změn, protože dodržování standardů kvality nevyhnutelně zpomaluje dodávky. Takže postupně část funkcionality Build/Release inženýrů přešla na systémové administrátory.
Opsové, tak různí
Postupujeme dále a opět přítomnost širokého spektra povinností a nedostatek kvalifikovaných pracovníků nás nutí k přísné specializaci, jako houby po dešti, objevují se různé Operations:
- TechOps — systémoví administrátoři e-mailových systémů aka HelpDesk Engineer
- LiveOps — systémoví administrátoři, převážně odpovědní za produkční prostředí
- CloudOps — systémoví administrátoři specializující se na veřejné "cloudy" Azure, AWS, GCP, atd.
- PlatOps/InfraOps/SysOps — systémoví administrátoři infrastruktury.
- NetOps — síťoví administrátoři
- SecOps — systémoví administrátoři specializující se na informační bezpečnost — PCI compliance, CIS compliance, patching, atd.
DevOps je (v teorii) osoba, která do detailu rozumí všem procesům vývojového cyklu — vývoji, testování, rozumí architektuře produktu, dokáže vyhodnotit bezpečnostní rizika, obeznámená s přístupy a nástroji automatizace alespoň na základní úrovni, mimo to také rozumí podpoře produktu před a po vydání. Je to osoba schopná působit jako advokát nejen pro Operations, ale i pro Development, což umožňuje navázání příznivé spolupráce mezi těmito dvěma pilíři. Rozumí procesům plánování práce týmy a řízení očekávání zákazníka.
Aby taková osoba mohla vykonávat tyto typy práce a povinností, musí mít nástroje pro řízení nejen procesů vývoje a testování, ale i správy produktové infrastruktury a plánování zdrojů. DevOps v tomto smyslu nemůže být umístěn ani v IT, ani v R&D, ani dokonce v PMO, musí mít vliv ve všech těchto oblastech — technický ředitel společnosti, Chief Technical Officer.
Je to tak ve vaší společnosti? — Pochybuji. V většině případů je to buď IT, nebo R&D.
Nedostatek prostředků a možnosti vlivu alespoň na jednu z těchto tří oblastí činnosti povede k posunu problémů směrem, kde je snazší tyto změny aplikovat, například zavedením technických omezení na vydání v důsledku "špinavého" kódu podle údajů ze statického analyzátoru. To znamená, že když PMO stanovuje přísný termín na uvolnění funkčnosti, R&D nemůže vyprodukovat kvalitní výsledek v těchto termínech a dodává to, jak může, odkládajíc refaktoring na později, DevOps patřící do IT technickými prostředky blokuje vydání. Nedostatek pravomocí k změně situace, u zodpovědných zaměstnanců vede k projevu hyperodpovědnosti za to, na co nemohou mít vliv, tím spíše, pokud ti zaměstnanci rozumí a vidí chyby, a jak je opravit — "Štěstí v nevědomosti", a tím ke vyhoření a ztrátě těchto zaměstnanců.
Trh DevOps zdrojů
Podívejme se na několik pracovních nabídek na pozici DevOps od různých společností.
Jsme připraveni se s vámi setkat, pokud:
- Ovládáte Zabbix a víte, co je to Prometheus;
- Iptables;
- Aspirant BASH;
- Profesor Ansible;
- Guru Linux;
- Umíte používat debug a společně s vývojáři nacházet problémy aplikací (php/java/python);
- Routing u vás nevyvolává hysterii;
- Věnujete značnou pozornost bezpečnosti systému;
- Zálohujete "vše a všechno" a úspěšně to "vše a všechno" obnovujete;
- Umíte nastavit systém tak, abyste ze minimum dostali maximum;
- Nastavujete replikace před spaním na Postgres a MySQL;
- Nastavení a úprava CI/CD je pro vás nezbytností jako snídaně/oběd/večeře.
- Máte zkušenosti s AWS;
- Jste ochotni se rozvíjet spolu s firmou;
Takže:
- od 1 do 6 — systémový administrátor
- 7 — trochu síťového administrativy, což také spadá do sysadmina na úrovni Middle
- 8 — trochu bezpečnosti, což je nezbytné pro sysadmina na úrovni Middle
- 9-11 — Middle System Administrator
- 12 — V závislosti na stanovených úkolech buď Middle System Administrator, nebo Build Engineer
- 13 — Virtualizace — Middle System Administrator, nebo takzvaný CloudOps, rozšířené znalosti konkrétních služeb hosting platformy, pro efektivní využívání finančních prostředků a snížení zátěže na údržbu.
Shrnuto k této nabídce lze říci, že kluci stačí na pozici Middle/Senior System Administrator.
Mimochodem, neměli bychom příliš rozdělovat administrátory na Linux/Windows. Chápeme, že služby a systémy obou světů se liší, ale základ je u všech stejný a každý seriózní administrátor zná jak jedno, tak i druhé, a i když s tím není obeznámen, pro schopného administrátora nebude problém se s tím seznámit.
Pojďme se podívat na jinou pracovní pozici:
- Zkušenosti s budováním vysoce zatížených systémů;
- Výborné znalosti OS Linux, obecného softwaru a webového stacku (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Zkušenosti s virtualizačními systémy (KVM, VMWare, LXC/Docker);
- Ovládání skriptovacích jazyků;
- Porozumění principům fungování síťových protokolů;
- Porozumění principům budování systémů odolných proti výpadkům;
- Samostatnost a iniciativnost;
Rozebíráme:
- 1 — Senior System Administrator
- 2 — V závislosti na smyslu vloženém do tohoto stacku — Middle/Senior System Administrator
- 3 — Zkušenosti, které mohou znamenat — "Klastr jsem nezvedal, ale vytvářel a spravoval virtuálky, měl jsem jeden Docker host, přístup k kontejnerům jsem měl." — Middle System Administrator
- 4 — Junior System Administrator — ano, administrátor, který neumí psát elementární skripty automatizace, bez ohledu na jazyk, není administrátor — helpdesk.
- 5 — Middle System Administrator
- 6 — Senior System Administrator
Shrnuto — Middle/Senior System Administrator
Další bod:
- Zkušenosti s devops;
- Zkušenosti s používáním jednoho nebo několika produktů pro vytváření CI/CD procesů. Gitlab CI bude výhodou;
- Práce s kontejnery a virtualizací; Pokud jste používali docker – skvělé, a pokud k8s – ještě lepší!
- Zkušenosti s prací v agile týmu;
- Znalost jakéhokoli programovacího jazyka;
Podíváme se:
- 1 — Hmm… Co tím kluci myslí? =) Pravděpodobně sami nevědí, co se za tím skrývá.
- 2 — Build Engineer
- 3 — Middle System Administrator
- 4 — Soft skills, zatím nezvažujeme, i když Agile je další věc, kterou interpretují tak, jak se to hodí.
- 5 — Příliš vágně — to může být skriptovací jazyk, nebo kompilovaný. Zajímalo by mě, jestli by je zajímalo, že jsem ve škole psal na Pascal a Basic? =)
Chtěl bych také uvést poznámku k bodu 3, abych posílil pochopení, proč je tento bod pokryt administrátorem. Kubernetes je jen orchestrátor, nástroj, který obaluje přímé příkazy sítovým ovladačům a hostitelům virtualizace/izolace do pár příkazů a umožňuje s nimi komunikaci abstraktním způsobem, to je vše. Pro příklad vezměme 'build framework' Make, který, mimochodem, za framework nepovažuji. Ano, vím o módě dávat Make kamkoli, kde to je potřeba a kde ne — obalit Maven do Make například, vážně?
V podstatě je Make jen obálka nad shellem, která zjednodušuje právě příkazy kompilace, linkování, prostředí kompilace, stejně jako k8s.
Jednou jsem pohovoroval kluka, který používal k8s ve své práci nad OpenStackem, a on vyprávěl, jak nasazoval služby na něm, avšak když jsem se ho ptal na OpenStack, vyšlo najevo, že je spravován a nastavován systémovými administrátory. Opravdu si myslíte, že člověk, který zprovoznil OpenStack bez ohledu na to, jakou platformu má za sebou, není schopen používat k8s?=)
Tento uchazeč ve skutečnosti není DevOps, ale stejný Systémový Administrátor a, abych byl přesnější, Kubernetes Administrator.
Shrňme znovu — Middle/Senior System Administrator bude pro ně dostatečný.
Kolik visí v gramech
Rozptyl nabízených platů pro uvedené pozice — 90k-200k
Nyní bych chtěl udělat paralelu mezi finančními odměnami systémových administrátorů a DevOps inženýrů.
V zásadě je možné si rozdělit úrovně podle zkušeností, ačkoliv to nebude přesné, pro účely článku to stačí.
Zkušenost:
- do 3 let — Junior
- do 6 let — Middle
- více než 6 let — Senior
Web pro hledání zaměstnanců nabízí:
Systémoví administrátoři:
- Junior — 2 roky — 50k Kč.
- Middle — 5 let — 70k Kč.
- Senior — 11 let — 100k Kč.
DevOps inženýři:
- Junior — 2 roky — 100k Kč.
- Middle — 3 roky — 160k Kč.
- Senior — 6 let — 220k Kč.
Pro zkušenosti DevOps inženýrů byl použit jakýkoliv relevantní časový údaj týkající se SDLC.
Z výše uvedeného vyplývá, že vlastně společnosti nepotřebují DevOps inženýry a mohly by ušetřit alespoň 50 procent původně plánovaných nákladů najmutím administrátora. Navíc by mohly přesněji definovat povinnosti požadovaného člověka a rychleji uzavřít potřebu. Také bychom neměli zapomínat, že jasné rozdělení odpovědnosti umožňuje snížit nároky na personál a také vytvořit příznivější atmosféru v týmu, kvůli nepřekrývání. Ve většině nabídek práce je spousta nástrojů a DevOps štítků, které však nemají na základě skutečné nároky na DevOps inženýra, pouze poptávku po administrátorovi nástrojů.
Proces školení DevOps inženýrů je také omezen pouze na soubor specifických úkolů a nástrojů, nedává celkové pochopení procesů a jejich závislostí. To je samozřejmě dobré, když člověk dokáže nasadit AWS EKS pomocí Terraformu, ve spojení s Fluentd side-car v tomto clusteru a AWS ELK stackem pro systém logování za 10 minut, využívající pouze jeden příkaz v konzoli, ale pokud nebude chápat samotný princip zpracování logů a k čemu jsou potřeba, nebude vědět, jak shromažďovat metriky a sledovat degradaci služby, bude to stále stejný enikey, schopný používat některé nástroje.
Poptávka však vytváří nabídku a vidíme extrémně přehřátý trh pozic DevOps, kde požadavky neodpovídají skutečné roli a jen umožňují systémovým administrátorům vydělávat více.
Kdo tedy jsou? DevOps inženýři nebo lakomí systémoví administrátoři? =)
Jak dál žít?
Zaměstnavatelé – lépe formulovat požadavky a hledat přesně ty, které jsou potřeba, a ne plýtvat názvy. Pokud nevíte, co dělají DevOps, nejsou vám tedy potřeba.
Zaměstnancům – Učit se. Neustále zlepšovat své znalosti, dívat se na celkový obraz procesů a sledovat cestu k určenému cíli. Můžete se stát kýmkoli, koho chcete, stačí se jen snažit.
Zdroj: habr.com
