На дадзены момант гэта ці не самая дарагая пазіцыя на рынку. Мітусня вакол "DevOps" інжынераў пераўзыходзіць усе мажлівыя межы, а тым горш з Senior DevOps інжынерамі.
Я працую кіраўніком аддзела інтэграцыі і аўтаматызацыі, адгадайце ангельскую расшыфроўку – DevOps Manager. Ці адлюстроўвае менавіта ангельская расшыфроўка нашу паўсядзённую дзейнасць - ці наўрад, а вось рускі варыянт у дадзеным выпадку больш дакладны. Па родзе маёй дзейнасці, натуральна, што мне, неабходна гутарыць будучых чальцоў маёй каманды і, за мінулы год, праз мяне мінула чалавек 50, а яшчэ гэтулькі жа зрэзалася на праскрыне з маімі супрацоўнікамі.
Мы ўсё яшчэ знаходзімся ў пошуку калег, бо за лэйблам DevOps хаваецца вельмі вялікая праслойка рознага роду інжынераў.
Усё напісанае ніжэй з'яўляецца маім асабістым меркаваннем, вы не абавязаны згаджацца з ім, аднак дапускаю, што ўнясе адценне ў ваша стаўленне да тэмы. Нягледзячы на рызыку патрапіць у няласку, я публікую сваё меркаванне, паколькі лічу што яму ёсць месца быць.
Кампаніі па-рознаму разумеюць хто такія DevOps інжынеры і дзеля хуткага найму рэсурсу вешаюць гэты лэйбл усім. Сітуацыя досыць дзіўная, паколькі кампаніі гатовы плаціць нерэальныя ўзнагароды гэтым людзям, атрымліваючы за іх, у большасці выпадкаў, адміна-тулзіста.
Дык хто ж такія DevOps інжынеры?
Давайце пачнем з гісторыі з'яўлення – Development Operations з'явіўся як яшчэ адзін крок да аптымізацыі ўзаемадзеяння ў малых камандах для павышэння хуткасці вытворчасці прадукта, як чаканае следства. Ідэя складалася ў тым, каб узмацніць каманду распрацоўкі ведамі аб працэдурах і падыходах у кіраванні прадуктовым асяроддзем. Іншымі словамі, распрацоўшчык павінен разумець і ведаць як яго прадукт працуе ў тых ці іншых умовах, павінен разумець як дэплоіць яго прадукт, якія характарыстыкі асяроддзя падкруціць, каб павысіць прадукцыйнасць. Так, на працягу некаторага часу, з'явіліся распрацоўшчыкі з DevOps падыходам. DevOps распрацоўшчыкі пісалі скрыпты зборкі і ўпакоўкі для спрашчэння сваёй дзейнасці і працаздольнасці прадуктыўнага асяроддзя. Аднак, складанасць архітэктуры рашэнняў і ўзаемны ўплыў кампанентаў інфраструктуры з цягам часу пачало пагаршаць працоўныя паказчыкі асяроддзяў, з кожнай ітэрацыяй патрабаваліся ўсё глыбейшыя разуменні тых ці іншых кампанентаў, зніжаючы прадуктыўнасць самога распрацоўніка з-за дадатковых выдаткаў на разуменне кампанентаў і цюнінгу сістэм пад пэўную задачу. . Уласны кошт распрацоўніка расла, кошт прадукта разам з ім, рэзка падскочылі патрабаванні да новых распрацоўнікаў у камандзе, бо ім неабходна было таксама пакрываць абавязкі "зоркі" распрацоўкі і, натуральна, "зоркі" станавіліся ўсё менш даступныя. Таксама варта адзначыць, што, на маю вопыту, мала каму з распрацоўшчыкаў цікавая спецыфіка апрацоўкі пакетаў ядром аперацыйнай сістэмы, правілы маршрутызацыі пакетаў, аспекты бяспекі хаста. Лагічным крокам было прыцягнуць адміністратара, які менавіта з гэтым знакам і ўскласці падобнага фармату абавязкі менавіта на яго, што, дзякуючы яго досведу, дазволіла дасягнуць тых жа паказчыкаў меншым коштам у параўнанні з коштам «зоркі» распрацоўкі. Такіх адміністратараў змяшчалі ў каманду і асноўнай яго задачай было кіраванне тэставымі і прадуктыўнымі асяроддзямі, на правілах канкрэтна ўзятай каманды, з рэсурсамі вылучанымі менавіта гэтай камандзе. Так, уласна, і з'явіліся DevOps ва ўяўленні большасці.
Часткова ці цалкам, з часам, дадзеныя сістэмныя адміністратары пачалі разумець патрэбы менавіта гэтай канкрэтнай каманды ў галіне распрацоўкі, як спрасціць жыццё распрацоўшчыкам і тэсціроўшчыкам, як выкаціць абнаўленне і не застацца начаваць у пятніцу ў офісе, выпраўляючы памылкі дэплою. Час ішоў, зараз "зоркамі" станавіліся сістэмныя адміністратары, якія разумеюць чаго жадаюць распрацоўнікі. З мэтай мінімізацыі імпакта пачалі падцягвацца ўтыліты кіравання, усё ўспомнілі старыя і надзейныя метады ізаляцыі ўзроўня АС, якія дазвалялі мінімізаваць патрабаванні па бяспецы, кіраванню сеткавай часткі, ды і канфігурацыі хаста ў цэлым і, як следства зменшыць патрабаванні да новых "зорак".
З'явілася выдатная рэч docker. Чаму цудоўная? Ды толькі таму, што стварэнне ізаляцыі ў chroot або jail, роўна як OpenVZ, патрабавала нетрывіяльных ведаў АС, у контру ўтыліце якая дазваляе элементарна стварыць ізаляванае асяроддзе прыкладання на нейкім хасце з усім неабходным усярэдзіне і перадаць стырно кіравання распрацоўцы ізноў, а сістэмнаму адміністратару кіраваць толькі толькі адным хастом, забяспечваючы яго бяспеку і высокую даступнасць - лагічнае спрашчэнне. Але прагрэс не стаіць на месцы і сістэмы зноў становяцца ўсё складаней і складаней, кампанентаў усё больш і больш, адзін хост ужо не задавальняе патрэбам сістэмы і неабходна будаваць кластары, мы зноў вяртаемся да сістэмных адміністратараў, якія здольныя пабудаваць дадзеныя сістэмы.
Цыкл за цыклам, з'яўляюцца розныя сістэмы якія спрашчаюць распрацоўку і/ці адміністраванне, з'яўляюцца сістэмы аркестрацыі, якія, роўна датуль, пакуль не патрабуецца адысці ад стандартнага працэсу, простыя ў выкарыстанні. Мікрасэрвісная архітэктура таксама з'явілася з мэтай спрашчэння ўсяго апісанага вышэй – менш узаемасувязяў, прасцей ва ўпраўленні. У сваім досведзе я не заспеў цалкам мікрасэрвісную архітэктуру, я б сказаў 50 на 50 - 50 адсоткаў мікрасэрвісаў, чорныя скрынкі, прыйшло на ўваход, выйшла апрацаванае, іншыя 50 - разадраны маналіт, сэрвісы няздольныя працаваць асобна ад іншых кампанентаў. Усё гэта зноў наклала абмежаванні на ўзровень ведаў як распрацоўшчыкаў, так адміністратараў.
Падобныя «арэлі» узроўню экспертных ведаў таго ці іншага рэсурсу працягваюцца і дагэтуль. Але мы крыху адцягнуліся, ёсць нямала момантаў якія варта асвятліць.
Build Engineer/Release Engineer
Вельмі вузкаспецыялізаваныя інжынеры, якія з'явіліся як сродак стандартызацыі працэсаў зборкі ПЗ і яго рэлізаў. У працэсе ўвядзення павальнага Agile здавалася б яны перасталі быць запатрабаваны, аднак гэта далёка не так. Гэтая спецыялізацыя з'явілася як сродак стандартызацыі менавіта зборкі і пастаўкі ПЗ у прамысловых маштабах, г.зн. выкарыстоўваючы стандартныя тэхнікі для ўсіх прадуктаў кампаніі. Са з'яўленнем DevOps распрацоўнікаў часткова страцілі функцыі, паколькі менавіта распрацоўнікі сталі падрыхтоўваць прадукт да пастаўкі, а улічваючы зменлівую інфраструктуру і падыход у максімальна хуткай пастаўцы без аглядкі на якасць з часам ператварыліся менавіта ў стопар змен, паколькі прытрымліванне стандартам якасці непазбежна запавольвае пастаўкі. Так, паступова, частка функцыяналу Build/Release інжынераў перавандравала на плечы сістэмных адміністратараў.
Ops'ы такія розныя
Мы рухаемся далей і зноў наяўнасць вялікага кола абавязкаў і недахоп кваліфікаваных кадраў штурхае нас на жорсткую спецыялізацыю, як грыбы пасля дажджу, з'яўляюцца розныя Operations:
- TechOps - сістэмныя адміністратары энікеі aka HelpDesk Engineer
- LiveOps — сістэмныя адміністратары, якія пераважна адказваюць за прадуктыўныя асяроддзі
- CloudOps - сістэмныя адміністратары якія спецыялізуюцца на публічных «аблоках» Azure, AWS, GCP, etc.
- PlatOps/InfraOps/SysOps - сістэмныя адміністратары інфраструктуры.
- NetOps - сеткавыя адміністратары
- SecOps – сістэмныя адміністратары якія спецыялізуюцца на інфармацыйнай бяспецы – PCI compliance, CIS compliance, patching, etc.
DevOps – (у тэорыі) персона, не па чутках якая разумее ўсе працэсы цыклу распрацоўкі – распрацоўку, тэставанне, якая разумее архітэктуру прадукта, здольная ацаніць рызыкі бяспекі, знаёмая з падыходамі і сродкамі аўтаматызацыі, хоць бы на высокім узроўні, апроч гэтага якая разумее таксама прад і пост- рэлізную падтрымку прадукта. Персона здольная выступаць адвакатам як Operations, так і Development, што дазваляе выбудаваць спрыяльнае супрацоўніцтва паміж гэтымі двума слупамі. Якая разумее працэсы планавання прац камандамі і кіраванні чаканнямі замоўца.
Для выканання падобнага роду прац і абавязкаў дадзеная персона павінна мець сродкі кіравання не толькі працэсамі распрацоўкі, тэставанні, але і кіраванні інфраструктурай прадукта, а таксама планаванні рэсурсаў. DevOps у дадзеным разуменні не можа знаходзіцца ні ў IT, ні ў R&D, ні нават у PMO, ён павінен мець уплыў ва ўсіх гэтых абласцях – тэхнічны дырэктар кампаніі, Chief Technical Officier.
Ці так гэта ў вашай кампаніі? - Сумняваюся. У большасці выпадкаў гэта ці IT, ці R&D.
Недахоп сродкаў і магчымасці ўплыву хаця б на адзін з гэтых трох напрамкаў дзейнасці зробіць зрушэнне вагі праблем у бок дзе гэтыя змены прасцей прымяніць, як напрыклад прымяненне тэхнічных абмежаванняў на рэлізы ў сувязі з «брудным» кодам па дадзеных сістэм статычнага аналізатара. Гэта значыць калі PMO усталёўвае цвёрды тэрмін на выпуск функцыяналу, R&D не можа выдаць якасны вынік у гэтыя тэрміны і выдае яго як можа, пакінуўшы рэфактарынг на потым, DevOps які адносіцца да IT, тэхнічнымі сродкамі блакуе рэліз. Недахоп паўнамоцтваў на змену сітуацыі, у выпадку з адказнымі супрацоўнікамі вядзе да праявы гіперадказнасці за тое, на што яны не могуць паўплываць, тым больш калі гэтыя супрацоўнікі разумеюць і бачаць памылкі, і як іх выправіць - "Шчасце ў няведанні", і як следства да выгаранні і страты гэтых супрацоўнікаў.
Рынак DevOps рэсурсаў
Давайце разгледзім некалькі вакансій на пазіцыю DevOps ад розных кампаній.
Мы гатовы з Вамі сустрэнецца, калі Вы:
- Валодаеце Zabbix і ведаеце, што такое Prometheus;
- Iptables;
- Аспірант BASH;
- Прафесар Ansible;
- Гуру Linux;
- Умееце карыстацца дэбагам і сумесна з распрацоўшчыкамі знаходзіць праблемы прыкладанняў (php/java/python);
- Роўтынг не выклікае ў Вас істэрык;
- Надаеце значную ўвагу бяспецы сістэмы;
- Бекапіце "ўсё і ўся", а таксама паспяхова аднаўляеце гэта "ўсё і ўся";
- Умееце наладзіць сістэму так, каб выціснуць з мінімуму - максімум;
- Наладжваеце рэплікацыі перад сном на Postgres і MySQL;
- Настройка і карэкціроўка CI/CD для Вас – гэта неабходнасць як сняданак/абед/вячэру.
- Маеце досвед працы з AWS;
- Гатовы развівацца разам з кампаніяй;
Такім чынам:
- з 1 па 6 - сістэмны адміністратар
- 7 - трохі сеткавага адміністравання, што таксама ўкладваецца ў сісадміна, узроўня Middle
- 8 - трохі бяспекі, што абавязкова для сісадміна ўзроўню Middle
- 9-11 - Middle System Administrator
- 12 - У залежнасці ад пастаўленых задач альбо Middle System Administrator, альбо Build Engineer
- 13 — Віртуалізацыя — Middle System Administrator, альбо так званы CloudOps, пашыраныя веды менавіта сэрвісаў канкрэтнай хостынг пляцоўкі, для эфектыўнага выкарыстання грашовых сродкаў і зніжэння нагрузкі на абслугоўванне
Рэзюмуючы па дадзенай вакансіі можна сказаць, што рабятам дастаткова Middle / Senior System Administrator.
Дарэчы, не варта моцна падзяляць адмінаў на Linux/Windows. Я вядома разумею, што сэрвісы і сістэмы гэтых двух міроў адрозніваюцца, але аснова ва ўсіх адна і любы які паважае сябе адмін знакам як з адным, так і з іншым, і нават калі не знакам, то для пісьменнага адміна не складзе працы азнаёміцца з гэтым.
Разгледзім іншую вакансію:
- Вопыт пабудовы высоканагружаных сістэм;
- Выдатныя веды АС Linuх, агульнасістэмнага ПЗ і вэб-стэка (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Вопыт працы з сістэмамі віртуалізацыі (KVM, VMWare, LXC / Docker);
- Валоданне скрыптовымі мовамі;
- Разуменне прынцыпаў працы сетак сеткавых пратаколаў;
- Разуменне прынцыпаў пабудовы абароненай ад збояў сістэм;
- Самастойнасць і ініцыятыўнасць;
Разбіраны:
- 1 – Senior System Administrator
- 2 - У залежнасці ад сэнсу ўкладанага ў гэты стэк - Middle / Senior System Administrator
- 3 – Вопыт працы, у тым ліку, можа азначаць – «Кластар не падымаў, але ствараў і кіраваў віртуалкамі, быў адзін Docker хост, доступ да кантэйнераў націл» – Middle System Administrator
- 4 - Junior System Administrator - так, адмін не ўмелы пісаць элементарныя скрыпты аўтаматызацыі, па-за залежнасцю ад мовы, не адмін - энікей.
- 5 – Middle System Administrator
- 6 – Senior System Administrator
Рэзюмуючы — Middle/Senior System Administrator
Яшчэ адна:
- Вопыт працы devops;
- Досвед у выкарыстанні аднаго або некалькіх прадуктаў для фармавання CI/CD працэсаў. Gitlab CI будзе перавагай;
- Праца з кантэйнерамі і віртуалізацыяй; Калі выкарыстоўвалі docker - добра, а калі k8s - выдатна!
- Вопыт працы ў agile-камандзе;
- Веданне любой мовы праграмавання;
Паглядзім:
- 1 — Хм… Што хлопцы маюць на ўвазе? =) Хутчэй за ўсё яны самі не ведаюць што за гэтым хаваецца
- 2 – Build Engineer
- 3 – Middle System Administrator
- 4 — Софт-скіл, разглядаць пакуль не будзем, хоць Agile яшчэ адна рэч, якую інтэрпрэтуюць так, як зручна.
- 5 - Занадта вялізна - гэта можа быць скрыптовая мова, або кампіляваная. Цікава, а пісаў у школе на Pascal і Basic іх задаволіць? =)
Хацелася б таксама пакінуць рэмарку адносна 3 пункта, каб умацаваць разуменне, чаму гэты пункт пакрываецца сісадмінам. Kubernetes усяго толькі аркестрацыя, тулза якая абарочвае прамыя каманды драйверам сеткі і хастам віртуалізацыі/ізаляцыі ў пару каманд і дазваляе зрабіць зносіны з імі абстрактным, вось і ўсё. Для прыкладу возьмем 'build framework' Make, якога фрэймворкам я, дарэчы, не лічу. Так, я ведаю пра моду штурхаць Make куды заўгодна, дзе трэба і не трэба абгарнуць Maven у Make напрыклад, сур'ёзна?
У сутнасці Make проста абгортка над shell, якая спрашчае менавіта каманды кампіляцыі, лінкоўкі, асяроддзі кампіляцыі, гэтак жа як і k8s.
Аднойчы, я гутарыў хлопца, які выкарыстаў k8s у сваёй працы па-над OpenStack, і ён распавядаў як разгортваў сэрвісы на ім, аднак, калі я спытаў менавіта пра OpenStack, апынулася, што ён адмініструецца, роўна як і ўздымаецца сістэмнымі адміністратарамі. Вы праўда думаеце, што чалавек які падняў OpenStack па-за залежнасцю ад таго якую платформу ён выкарыстоўвае ззаду яго не здольны выкарыстаць k8s?=)
Дадзены суіскальнік на самой справе не DevOps, а такі ж Сістэмны Адміністратар і, каб быць дакладней, Kubernetes Administrator.
Рэзюмуем у чарговы раз – Middle / Senior System Administrator ім будзе дастаткова.
Колькі вешаць у грамах
Роскід прапанаваных заробкаў для названых вакансій — 90к-200к
Цяпер хацелася б правесці паралель паміж грашовымі ўзнагародамі Сістэмных Адміністратараў і DevOps Engineers.
У прынцыпе, для спрашчэння можна грэйды па досведзе працы раскідаць, хоць гэта і не будзе дакладным, для мэт артыкула хопіць.
досвед:
- да 3-х гадоў - Junior
- да 6-ці гадоў - Middle
- больш за 6 - Senior
Сайт пошуку супрацоўнікаў прапануе:
System Adminsitrators:
- Junior - 2 гады - 50к руб.
- Middle - 5 гадоў - 70к руб.
- Senior - 11 гадоў - 100к руб.
DevOps Engineers:
- Junior - 2 гады - 100к руб.
- Middle - 3 гады - 160к руб.
- Senior - 6 гадоў - 220к руб.
Па стажы «DevOps»'аў выкарыстоўваўся стаж, хоць неяк які закранае SDLC.
З вышэйазначанага вынікае, што насамрэч кампаніям не патрэбныя DevOps'ы, а таксама што яны маглі зэканоміць не менш за 50 працэнтаў ад першапачаткова запланаваных затрат, наняўшы менавіта Адміністратара, больш за тое, яны маглі б больш дакладна вызначыць абавязкі шуканага чалавека і хутчэй закрыць патрэбнасць. Не варта таксама забываць, што выразны падзел адказнасці дазваляе зменшыць патрабаванні да персанала, а таксама стварыць больш спрыяльную атмасферу ў калектыве, з прычыны адсутнасці скрыжаванняў. У пераважнай большасці вакансіі мільгаюць утылітамі і DevOps лэйбламі, аднак не мелыя ў аснове сапраўды патрабаванні да DevOps Engineer, толькі запыты на тулзавага адміністратара.
Працэс навучання DevOps інжынераў таксама абмежаваны толькі наборам спецыфічных прац, утыліт, не дае агульнага разумення працэсаў і іх залежнасцяў. Гэта вядома добра, калі чалавек можа выкарыстоўваючы Terraform задэплоіць AWS EKS, у звязку з Fluentd сайд-гнядым у гэтым кластары і AWS ELK стэкам для сістэмы лагавання за 10 хвілін, выкарыстоўваючы толькі адну каманду ў кансолі, але калі ён не будзе разумець сам прынцып апрацоўкі логаў і для чаго яны патрэбныя, не ведаць як збіраць метрыкі па іх і адсочваць дэградацыю сэрвісу, то гэта будзе ўсё той жа энікей, які ўмее выкарыстоўваць некаторыя ўтыліты.
Попыт, аднак, спараджае прапанову, і мы бачым вельмі перагрэты рынак пазіцыі DevOps, дзе патрабаванні не адпавядаюць рэальнай ролі, а толькі дазваляюць сістэмным адміністратарам зарабляць больш.
Дык хто ж яны? DevOps'ы ці прагныя сістэмныя адміністратары? =)
Як далей жыць?
Працадаўцам - дакладней фармуляваць патрабаванні і шукаць менавіта тых хто патрэбен, а не раскідвацца лэйбламі. Вы не ведаеце чым займаюцца DevOps - яны вам не патрэбныя ў такім выпадку.
Работнікам - Вучыцца. Пастаянна ўдасканальваць свае веды, глядзець на агульную карціну працэсаў і адсочваць шлях да пастаўленай мэты. Можна стаць кім захочаш, трэба толькі паспрабаваць.
Крыніца: habr.com