Қазіргі уақытта бұл нарықтағы ең қымбат позиция дерлік. «DevOps» инженерлерінің айналасындағы әбігер барлық елестететін шектен тыс және DevOps аға инженерлерімен одан да нашар.
Мен интеграция және автоматтандыру бөлімінің басшысы болып жұмыс істеймін, ағылшын тіліндегі декодтауды болжаймын - DevOps Manager. Ағылшын тіліндегі транскрипт біздің күнделікті әрекеттерімізді көрсететіні екіталай, бірақ бұл жағдайда орысша нұсқасы дәлірек. Менің қызметімнің сипатына байланысты менің командамның болашақ мүшелерінен сұхбат алу қажет болуы заңды және соңғы бір жыл ішінде мен арқылы 50-ге жуық адам өтті және менің қызметкерлеріммен алдын ала экранда дәл осындай санды үзіп тастады.
Біз әлі де әріптестер іздейміз, өйткені DevOps белгісінің артында әртүрлі инженерлердің өте үлкен қабаты жасырынып жатыр.
Төменде жазылғанның бәрі менің жеке пікірім, онымен келісу қажет емес, бірақ бұл тақырыпқа деген көзқарасыңызға біраз бояу қосатынын мойындаймын. Көңілден шығып қалу қаупіне қарамастан, мен өз пікірімді жариялаймын, өйткені мен оның орны бар деп есептеймін.
Компаниялар DevOps инженерлерінің кім екенін әртүрлі түсінеді және ресурсты тез жалдау үшін олар бұл белгіні барлығына іліп қояды. Жағдай өте таңқаларлық, өйткені компаниялар бұл адамдарға шынайы емес сыйақы төлеуге дайын, көп жағдайда олар үшін құрал әкімшісін алады.
Сонымен, DevOps инженерлері кімдер?
Оның пайда болу тарихынан бастайық - Әзірлеу операциялары күтілетін нәтиже ретінде өнімді өндіру жылдамдығын арттыру үшін шағын топтардағы өзара әрекеттесуді оңтайландыруға бағытталған тағы бір қадам ретінде пайда болды. Идея өнім ортасын басқарудағы процедуралар мен тәсілдер туралы білімі бар әзірлеушілер тобын нығайту болды. Басқаша айтқанда, әзірлеуші өз өнімінің белгілі бір жағдайларда қалай жұмыс істейтінін түсінуі және білуі керек, оның өнімін қалай орналастыру керектігін, өнімділікті жақсарту үшін қоршаған ортаның қандай сипаттамаларын реттеуге болатынын түсінуі керек. Осылайша, біраз уақыт бойы DevOps әдісі бар әзірлеушілер пайда болды. DevOps әзірлеушілері олардың әрекеттерін және өндірістік ортаның өнімділігін жеңілдету үшін құрастыру және орау сценарийлерін жазды. Дегенмен, шешім архитектурасының күрделілігі және инфрақұрылым құрамдастарының өзара әсері уақыт өте келе орталардың өнімділігін нашарлатты; әрбір итерациямен белгілі бір құрамдас бөліктерді тереңірек түсіну қажет болды, бұл қосымша мүмкіндіктерге байланысты әзірлеушінің өнімділігін төмендетеді. Белгілі бір тапсырма үшін компоненттерді және баптау жүйелерін түсіну шығындары. . Әзірлеушінің өзіндік құны өсті, онымен бірге өнімнің құны, командадағы жаңа әзірлеушілерге қойылатын талаптар күрт өсті, өйткені олар дамудың «жұлдызының» міндеттерін өтеуі керек болды және, әрине, «жұлдыздар» аз болды. және қол жетімділігі аз. Сондай-ақ, менің тәжірибем бойынша, операциялық жүйе ядросы арқылы пакеттерді өңдеу ерекшеліктері, пакеттерді маршруттау ережелері және хосттың қауіпсіздік аспектілері аз ғана әзірлеушілерді қызықтыратынын атап өткен жөн. Логикалық қадам осымен таныс әкімшіні тарту және оған ұқсас міндеттер жүктеу болды, бұл оның тәжірибесінің арқасында «жұлдызды» әзірлеу құнымен салыстырғанда бірдей көрсеткіштерге төмен бағамен қол жеткізуге мүмкіндік берді. Мұндай әкімшілер командаға орналастырылды және оның негізгі міндеті осы командаға бөлінген ресурстармен нақты команданың ережелеріне сәйкес сынақ және өндірістік орталарды басқару болды. Шын мәнінде, DevOps көпшіліктің санасында осылай пайда болды.
Уақыт өте келе бұл жүйелік әкімшілер осы команданың даму саласындағы қажеттіліктерін, әзірлеушілер мен тестерлер үшін өмірді қалай жеңілдетуге болатынын, жаңартуды қалай шығару керектігін және жұмада түнде қалудың қажеті жоқ екенін түсіне бастады. кеңсе, орналастыру қателерін түзету. Уақыт өтті, енді «жұлдыздар» әзірлеушілердің не қалайтынын түсінетін жүйелік әкімшілер болды. Әсерді азайту үшін басқару утилиталары пайда бола бастады; барлығы ОС деңгейін оқшаулаудың ескі және сенімді әдістерін еске түсірді, бұл қауіпсіздікке, желі бөлігін басқаруға және хост конфигурациясына қойылатын талаптарды азайтуға мүмкіндік берді. тұтас және нәтижесінде жаңа «жұлдыздарға» қойылатын талаптарды азайтады.
«Тамаша» нәрсе пайда болды - докер. Неге керемет? Иә, тек chroot немесе түрмеде оқшаулауды жасау, сондай-ақ OpenVZ үшін ОЖ туралы тривиальды емес білімді қажет ететіндіктен, утилита сізге белгілі бір хостта ішіндегі және қолмен қажеттінің бәрі бар оқшауланған қолданбалы ортаны құруға мүмкіндік береді. қайтадан даму тізгінін басып, жүйе әкімшісі оның қауіпсіздігі мен жоғары қолжетімділігін қамтамасыз ете отырып, тек бір ғана хостпен басқара алады - логикалық оңайлату. Бірақ прогресс бір орында тұрған жоқ және жүйелер қайтадан күрделене түсуде, құрамдас бөліктер көбейіп келеді, бір хост жүйенің қажеттіліктерін қанағаттандырмайды және кластерлерді құру қажет, біз қайтадан жүйелік әкімшілерге ораламыз. бұл жүйелерді құра алады.
Цикл артынан цикл, әзірлеуді және/немесе басқаруды жеңілдететін әртүрлі жүйелер пайда болады, стандартты процестен ауытқу қажет болғанша пайдалану оңай болатын оркестрлік жүйелер пайда болады. Микросервис архитектурасы да жоғарыда сипатталғанның барлығын жеңілдету мақсатында пайда болды - қарым-қатынастар аз, басқару оңай. Мен өз тәжірибемде толық микросервис архитектурасын таппадым, микросервистердің 50-ден 50 - 50 пайызын айтар едім, қара жәшіктер кірді, өңделеді, қалған 50-і жыртылған монолит, қызметтер басқалардан бөлек жұмыс істей алмайды. құрамдас бөліктер. Мұның бәрі әзірлеушілердің де, әкімшілердің де білім деңгейіне тағы да шектеулер қойды.
Белгілі бір ресурс бойынша сараптамалық білім деңгейіндегі ұқсас «тербеліс» бүгінгі күнге дейін жалғасуда. Бірақ біз сәл шегініс жасаймыз, ерекше атап өтуге болатын көптеген тұстар бар.
Құрылыс инженері/шығару инженері
Бағдарламалық жасақтаманы құру процестері мен шығарылымдарын стандарттау құралы ретінде пайда болған өте жоғары мамандандырылған инженерлер. Кең таралған Agile-ді енгізу барысында олар сұранысқа ие болмай қалған сияқты, бірақ бұл олай емес. Бұл мамандандыру өнеркәсіптік ауқымда бағдарламалық қамтамасыз етуді құрастыруды және жеткізуді стандарттау құралы ретінде пайда болды, т.б. компанияның барлық өнімдері үшін стандартты әдістерді қолдану. DevOps-тың пайда болуымен әзірлеушілер өз функцияларын ішінара жоғалтты, өйткені әзірлеушілер өнімді жеткізуге дайындай бастады және өзгеретін инфрақұрылым мен сапаны ескермей, мүмкіндігінше тез жеткізу тәсілін ескере отырып, олар уақыт өте келе өзгерістерді тоқтатады, өйткені сапа стандарттарын сақтау жеткізуді сөзсіз баяулатады. Осылайша, бірте-бірте құру/шығару инженерлерінің функционалдық бөлігі жүйелік әкімшілер иығына көшті.
Оптар өте әртүрлі
Біз қайта-қайта үлкен жауапкершіліктің болуы және білікті кадрлардың жетіспеушілігі бізді қатаң мамандандыруға итермелейді, жаңбырдан кейінгі саңырауқұлақтар сияқты, әртүрлі операциялар пайда болады:
- TechOps - enikey жүйелік әкімшілері, яғни HelpDesk инженері
- LiveOps - негізінен өндірістік орталарға жауапты жүйелік әкімшілер
- CloudOps – Azure, AWS, GCP және т.б. жалпыға қолжетімді бұлттарға маманданған жүйелік әкімшілер.
- PlatOps/InfraOps/SysOps - инфрақұрылымдық жүйе әкімшілері.
- NetOps - желі әкімшілері
- SecOps - ақпараттық қауіпсіздікке маманданған жүйелік әкімшілер - PCI сәйкестігі, CIS сәйкестігі, патчинг және т.б.
DevOps (теориялық тұрғыдан) – әзірлеу, тестілеу циклінің барлық процестерін өз көзімен түсінетін, өнім архитектурасын түсінетін, қауіпсіздік тәуекелдерін бағалай алатын, тәсілдер мен автоматтандыру құралдарын, кем дегенде жоғары деңгейде білетін адам. деңгейі, бұған қоса, өңдеуге дейінгі және кейінгі өңдеуді де түсінеді. Операциялар мен дамудың адвокаты ретінде әрекет ете алатын адам, бұл осы екі тірек арасындағы қолайлы ынтымақтастыққа мүмкіндік береді. Топтардың жұмысын жоспарлау және тұтынушылардың күтулерін басқару процестерін түсінеді.
Мұндай жұмыс пен жауапкершілікті орындау үшін бұл адам әзірлеу және сынау процестерін ғана емес, сонымен қатар өнім инфрақұрылымын басқаруды, сондай-ақ ресурстарды жоспарлауды басқару құралдары болуы керек. Бұл түсініктегі DevOps IT-да, ҒЗТКЖ-да, тіпті PMO-да орналаса алмайды; ол барлық осы салаларға әсер етуі керек - компанияның техникалық директоры, бас техникалық директоры.
Сіздің компанияңызда бұл рас па? - Мен күмәнданамын. Көп жағдайда бұл IT немесе R&D.
Қаражаттың жетіспеушілігі және қызметтің осы үш бағытының кем дегенде біреуіне әсер ету мүмкіндігі проблемалардың салмағын осы өзгерістерді қолдану оңайырақ жаққа қарай жылжытады, мысалы, статикалық деректерге сәйкес «лас» кодқа байланысты шығарылымдарға техникалық шектеулерді қолдану. анализатор жүйелері. Яғни, PMO функционалдылықты шығарудың қатаң мерзімін белгілегенде, ҒЗТКЖ осы мерзімдерде жоғары сапалы нәтиже бере алмайды және оны мүмкіндігінше шығарады, рефакторингті кейінге қалдырады, АТ-ға қатысты DevOps техникалық құралдармен шығаруды блоктайды. . Жауапты қызметкерлер жағдайында жағдайды өзгертуге өкілеттіктің болмауы, олар әсер ете алмайтын нәрсеге гипер-жауапкершіліктің көрінісіне әкеледі, әсіресе егер бұл қызметкерлер қателерді түсінсе және көрсе және оларды қалай түзетуге болады - «Бақыт - надандық», және нәтижесінде осы қызметкерлердің күйіп қалуы және жоғалуы.
DevOps ресурстар нарығы
Әртүрлі компаниялардың DevOps лауазымдарына арналған бірнеше бос жұмыс орындарын қарастырайық.
Біз сізбен кездесуге дайынбыз, егер сіз:
- Сізде Zabbix бар және Прометейдің не екенін білесіз;
- Iptables;
- BASH PhD студенті;
- Professor Ansible;
- Linux гуру;
- Түзетуді қалай пайдалану керектігін білу және әзірлеушілермен бірге қолданба мәселелерін табу (php/java/python);
- Маршрутизация сізді истерикаға әкелмейді;
- Жүйе қауіпсіздігіне айтарлықтай көңіл бөлу;
- «Барлығының және барлығының» сақтық көшірмесін жасаңыз, сонымен қатар осы «бәрін және бәрін» сәтті қалпына келтіріңіз;
- Сіз жүйені минимумнан максимум алатындай етіп конфигурациялауды білесіз;
- Postgres және MySQL жүйелерінде ұйықтар алдында репликацияны орнату;
- CI/CD орнату және реттеу сізге таңғы ас/түскі ас/кешкі ас сияқты қажет.
- AWS тәжірибесі бар;
- Компаниямен бірге дамуға дайын;
Мәселен:
- 1-ден 6-ға дейін – жүйелік әкімші
- 7 - жүйе әкімшісіне сәйкес келетін шағын желі әкімшілігі, Орта деңгей
- 8 - орта деңгейдегі жүйелік әкімші үшін міндетті болып табылатын кішкене қауіпсіздік
- 9-11 – Орташа жүйе әкімшісі
- 12 — Тағайындалған тапсырмаларға байланысты, орта жүйе әкімшісі немесе құрылыс инженері
- 13 - Виртуализация - Орталық жүйе әкімшісі немесе CloudOps деп аталатын, қаражатты тиімді пайдалану және техникалық қызмет көрсету жүктемесін азайту үшін белгілі бір хостинг сайтының қызметтері туралы кеңейтілген білім.
Осы бос орынды қорытындылай келе, жігіттер үшін орта/аға жүйелік әкімші жеткілікті деп айта аламыз.
Айтпақшы, Linux/Windows жүйесінде әкімшілерді қатты бөлуге болмайды. Әрине, мен түсінемін, бұл екі дүниенің қызметтері мен жүйелері әртүрлі, бірақ бәрінің негізі бір және өзін құрметтейтін кез келген админ екеуін де, екіншісін де жақсы біледі, тіпті ол таныс болмаса да, солай болады. құзырлы әкімшіге онымен танысу қиын емес.
Тағы бір бос орынды қарастырайық:
- Жоғары жүктеме жүйелерін құру тәжірибесі;
- Linux ОЖ, жалпы жүйелік бағдарламалық қамтамасыз ету және веб стек (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK) бойынша тамаша білім;
- Виртуализация жүйелерімен жұмыс тәжірибесі (KVM, VMWare, LXC/Docker);
- Сценарий тілдерін білу;
- Желілік хаттамалық желілердің жұмыс істеу принциптерін түсіну;
- Ақауларға төзімді жүйелерді құру принциптерін түсіну;
- Тәуелсіздік және бастамашылық;
Қарап көрейік:
- 1 – Аға жүйелік әкімші
- 2 - Осы стекке қойылған мағынаға байланысты - Орта/Аға Жүйе Әкімшісі
- 3 - Жұмыс тәжірибесі, соның ішінде мынаны білдіруі мүмкін: «Кластер виртуалды машиналарды көтермеді, бірақ құрды және басқарды, бір Docker хосты болды, контейнерлерге қол жеткізу мүмкін болмады» - Орташа жүйе әкімшісі
- 4 - Junior System Administrator - иә, әкімші емес, тілге қарамастан негізгі автоматтандыру сценарийлерін жазуды білмейтін әкімші - enikey.
- 5 - Орташа жүйелік әкімші
- 6 – Аға жүйелік әкімші
Қорытындылау үшін - Орта/Аға Жүйе Әкімшісі
Тағы бір:
- тәжірибесін дамытады;
- CI/CD процестерін жасау үшін бір немесе бірнеше өнімді пайдалану тәжірибесі. Gitlab CI артықшылығы болады;
- Контейнерлермен және виртуализациямен жұмыс істеу; Егер сіз докерді пайдалансаңыз, жақсы, бірақ k8s пайдалансаңыз, тамаша!
- Шапшаң командада жұмыс істеу тәжірибесі;
- Кез келген бағдарламалау тілін білу;
Қарайық:
- 1 - Мм... Жігіттер не айтып тұр? =) Оның артында не жасырылғанын олардың өздері білмейтін шығар
- 2 - құрылыс инженері
- 3 - Орташа жүйелік әкімші
- 4 - Жұмсақ шеберлік, біз оны әзірше қарастырмаймыз, бірақ Agile - бұл ыңғайлы түрде түсіндірілетін басқа нәрсе.
- 5 - Тым егжей-тегжейлі - бұл сценарий тілі немесе құрастырылған тіл болуы мүмкін. Қызық, мектепте Паскаль мен Бейсик тілінде жазу оларға жараса ма? =)
Сондай-ақ, бұл тармақты жүйелік әкімші неліктен қарастыратынын түсіну үшін 3-тармаққа қатысты ескерту қалдырғым келеді. Kubernetes - бұл жай ғана оркестр, желі драйверлері мен виртуализация/оқшаулау хосттарына тікелей командаларды бірнеше пәрменге орап, олармен дерексіз байланыс орнатуға мүмкіндік беретін құрал. Мысалы, «құрастыру шеңберін» алайық, айтпақшы, мен рамка деп санамаймын. Иә, мен Make-ті кез келген жерде, қажет және қажет емес жерде итеру сәні туралы білемін - Мавенді Макеге орау, мысалы, шындап?
Негізінде, Make - бұл k8s сияқты компиляция, байланыстыру және компиляция ортасының пәрмендерін жеңілдететін қабықтың үстінен орауыш.
Бірде мен OpenStack үстіндегі жұмысында k8-ді пайдаланған жігітпен сұхбаттасқанмын, ол онда қызметтерді қалай орналастырғаны туралы айтты, бірақ мен OpenStack туралы сұрағанымда, ол жүйе арқылы басқарылатыны және көтерілгені белгілі болды. әкімшілер. Сіз шынымен OpenStack орнатқан адам, оның артында қандай платформаны пайдаланатынына қарамастан, k8s пайдалана алмайды деп ойлайсыз ба? =)
Бұл өтініш беруші іс жүзінде DevOps емес, жүйелік әкімші және дәлірек айтқанда, Kubernetes әкімшісі.
Тағы бір рет қорытындылайық - олар үшін орта/аға жүйелік әкімші жеткілікті болады.
Граммен қанша салмақ
Көрсетілген бос орындарға ұсынылатын жалақы ауқымы 90-200 мың теңгені құрайды
Енді мен жүйелік әкімшілер мен DevOps инженерлерінің ақшалай сыйақылары арасында параллель жүргізгім келеді.
Негізінде, заттарды жеңілдету үшін сіз жұмыс тәжірибесіне негізделген бағаларды шашырата аласыз, бірақ бұл дәл емес, бірақ мақаланың мақсаттары үшін бұл жеткілікті болады.
Тәжірибе:
- 3 жасқа дейін – кіші
- 6 жасқа дейін – орта
- 6-дан жоғары – аға
Қызметкерлерді іздеу сайты мыналарды ұсынады:
Жүйе әкімшілері:
- Кіші - 2 жас - 50 мың руб.
- Орташа - 5 жыл - 70 мың руб.
- Үлкен - 11 жас - 100 мың руб.
DevOps инженерлері:
- Кіші - 2 жас - 100 мың руб.
- Орташа - 3 жыл - 160 мың руб.
- Үлкен - 6 жас - 220 мың руб.
«DevOps» тәжірибесіне сәйкес, кем дегенде SDLC-ге әсер еткен тәжірибе қолданылды.
Жоғарыда айтылғандардан, іс жүзінде компанияларға DevOps қажет емес, сонымен қатар олар Әкімшіні жалдау арқылы бастапқы жоспарланған шығындардың кем дегенде 50 пайызын үнемдей алатындығы шығады; сонымен қатар олар іздеген адамның жауапкершілігін нақтырақ анықтай алады. және қажеттілікті тезірек толтырыңыз. Міндеттердің нақты бөлінуі персоналға қойылатын талаптарды азайтуға, сондай-ақ бір-бірін қайталаудың болмауына байланысты ұжымда қолайлы жағдай жасауға мүмкіндік беретінін де ұмытпаған жөн. Бос жұмыс орындарының басым көпшілігі утилиталар мен DevOps белгілеріне толы, бірақ олар DevOps инженеріне қойылатын нақты талаптарға негізделмеген, тек құрал әкімшісіне арналған сұраулар.
DevOps инженерлерін оқыту процесі де тек нақты жұмыстардың, утилиталардың жиынтығымен шектеледі және процестер мен олардың тәуелділіктері туралы жалпы түсінік бермейді. Адам AWS EKS жүйесін Terraform көмегімен осы кластердегі Fluentd бүйірлік көлігімен және тіркеу жүйесіне арналған AWS ELK стекімен бірге 10 минут ішінде консольдегі бір ғана пәрменді қолдана алатын болса, әрине жақсы, бірақ егер ол түсінбесе журналдардың өзін өңдеу принципі және олар не үшін қажет, егер сіз олардағы көрсеткіштерді қалай жинауды және қызметтің нашарлауын қадағалайтыныңызды білмесеңіз, онда ол кейбір утилиталарды қалай пайдалану керектігін білетін бірдей enikey болады.
Алайда сұраныс ұсынысты тудырады және біз DevOps позициясы үшін өте қызып кеткен нарықты көреміз, мұнда талаптар нақты рөлге сәйкес келмейді, бірақ тек жүйелік әкімшілерге көбірек табыс табуға мүмкіндік береді.
Сонда олар кімдер? DevOps немесе ашкөз жүйелік әкімшілер? =)
Қалай өмір сүруді жалғастыру керек?
Жұмыс берушілер талаптарды дәлірек тұжырымдап, жапсырмаларды тастамай, дәл керектілерді іздеуі керек. Сіз DevOps не істейтінін білмейсіз - бұл жағдайда сізге қажет емес.
Жұмысшылар - үйрен. Біліміңізді үнемі жетілдіріңіз, процестердің жалпы көрінісін қараңыз және мақсатыңызға жету жолын қадағалаңыз. Сіз өзіңіз қалаған адам бола аласыз, тек тырысу керек.
Ақпарат көзі: www.habr.com