Ayni paytda bu bozordagi deyarli eng qimmat pozitsiya. "DevOps" muhandislari atrofidagi shov-shuv barcha tasavvur qilinadigan chegaralardan tashqarida va DevOps katta muhandislari bilan bundan ham yomoni.
Men integratsiya va avtomatlashtirish bo'limi boshlig'i bo'lib ishlayman, inglizcha dekodlashni taxmin qilaman - DevOps menejeri. Ingliz tilidagi transkript bizning kundalik faoliyatimizni aks ettirishi dargumon, ammo bu holda ruscha versiyasi aniqroq. Faoliyatim xususiyatiga koβra, jamoamning boβlajak aβzolaridan intervyu olishim kerakligi tabiiy va oβtgan bir yil ichida mendan 50 ga yaqin odam oβtdi va xuddi shunday raqam xodimlarim bilan oldindan koβrishda uzilib qoldi.
Biz hali ham hamkasblarni izlayapmiz, chunki DevOps yorlig'i ortida turli xil muhandislarning juda katta qatlami yashiringan.
Quyida yozilganlarning hammasi mening shaxsiy fikrim, bunga qo'shilishingiz shart emas, lekin tan olamanki, mavzuga munosabatingizga qandaydir rang qo'shadi. E'tibordan chetda qolish xavfiga qaramay, men o'z fikrimni e'lon qilaman, chunki uning o'rni borligiga ishonaman.
Kompaniyalar DevOps muhandislari kimligini turlicha tushunishadi va resursni tezda yollash uchun ular bu yorliqni hammaga osib qo'yishadi. Vaziyat juda g'alati, chunki kompaniyalar bu odamlarga haqiqiy bo'lmagan haq to'lashga tayyor, aksariyat hollarda ular uchun vosita ma'murini oladi.
Xo'sh, DevOps muhandislari kimlar?
Keling, uning paydo bo'lish tarixidan boshlaylik - Rivojlanish operatsiyalari kutilgan natija sifatida mahsulot ishlab chiqarish tezligini oshirish uchun kichik guruhlardagi o'zaro ta'sirni optimallashtirishga qaratilgan yana bir qadam sifatida paydo bo'ldi. G'oya ishlab chiqish guruhini mahsulot muhitini boshqarishda protseduralar va yondashuvlar bilimi bilan mustahkamlash edi. Boshqacha qilib aytganda, ishlab chiquvchi o'z mahsulotining ma'lum sharoitlarda qanday ishlashini tushunishi va bilishi kerak, o'z mahsulotini qanday joylashtirishni, ish faoliyatini yaxshilash uchun atrof-muhitning qanday xususiyatlarini sozlash mumkinligini tushunishi kerak. Shunday qilib, bir muncha vaqt DevOps yondashuviga ega ishlab chiquvchilar paydo bo'ldi. DevOps ishlab chiquvchilari o'z faoliyatini va ishlab chiqarish muhitining ishlashini soddalashtirish uchun qurish va qadoqlash skriptlarini yozdilar. Biroq, yechim arxitekturasining murakkabligi va infratuzilma tarkibiy qismlarining o'zaro ta'siri vaqt o'tishi bilan muhitning ish faoliyatini yomonlashtira boshladi; har bir iteratsiya bilan ba'zi tarkibiy qismlarni tobora chuqurroq tushunish talab qilinmoqda, bu esa qo'shimchalar tufayli ishlab chiquvchining unumdorligini pasaytiradi. Muayyan vazifa uchun komponentlar va sozlash tizimlarini tushunish xarajatlari. . Ishlab chiquvchining o'z narxi o'sdi, u bilan birga mahsulot tannarxi, jamoadagi yangi ishlab chiquvchilarga qo'yiladigan talablar keskin oshdi, chunki ular rivojlanish "yulduzi" ning mas'uliyatini qoplashlari kerak edi va tabiiyki, "yulduzlar" kamroq bo'ldi. va kamroq mavjud. Shuni ham ta'kidlash kerakki, mening tajribamga ko'ra, kam sonli ishlab chiquvchilar operatsion tizim yadrosi tomonidan paketlarni qayta ishlashning o'ziga xos xususiyatlari, paketlarni marshrutlash qoidalari va xost xavfsizligi jihatlari bilan qiziqishadi. Mantiqiy qadam bu bilan tanish bo'lgan ma'murni jalb qilish va unga o'xshash mas'uliyatni yuklash edi, bu uning tajribasi tufayli bir xil ko'rsatkichlarga "yulduzli" rivojlanish narxiga nisbatan arzonroq narxda erishish imkonini berdi. Bunday ma'murlar jamoaga joylashtirildi va uning asosiy vazifasi sinov va ishlab chiqarish muhitini, ma'lum bir jamoa qoidalariga muvofiq, ushbu jamoaga ajratilgan resurslar bilan boshqarish edi. Aslida DevOps ko'pchilikning ongida shunday paydo bo'ldi.
Qisman yoki to'liq, vaqt o'tishi bilan, ushbu tizim ma'murlari ushbu jamoaning rivojlanish sohasidagi ehtiyojlarini, ishlab chiquvchilar va testerlar hayotini qanday osonlashtirishni, yangilanishni qanday chiqarishni va juma kuni kechada qolmasligini tushuna boshladilar. ofis, joylashtirish xatolarini tuzatish. Vaqt o'tdi va endi "yulduzlar" ishlab chiquvchilar nimani xohlashlarini tushunadigan tizim ma'murlari edi. Ta'sirni minimallashtirish uchun boshqaruv yordamchi dasturlari paydo bo'la boshladi; hamma OS darajasini izolyatsiya qilishning eski va ishonchli usullarini esladi, bu esa xavfsizlik, tarmoq qismini boshqarish va xost konfiguratsiyasiga qo'yiladigan talablarni minimallashtirishga imkon berdi. butun va natijada yangi "yulduzlar" uchun talablarni kamaytiradi.
"Ajoyib" narsa paydo bo'ldi - doker. Nega ajoyib? Ha, faqat chroot yoki qamoqxonada izolyatsiyani yaratish, shuningdek, OpenVZ OS haqida ahamiyatsiz bo'lmagan bilimlarni talab qilganligi sababli, undan farqli o'laroq, yordamchi dastur sizga ichki va qo'lda kerak bo'lgan barcha narsalar bilan ma'lum bir xostda izolyatsiya qilingan dastur muhitini yaratishga imkon beradi. yana rivojlanish jilovi ustidan, va tizim ma'muri faqat bitta xost bilan boshqarishi mumkin, uning xavfsizligi va yuqori mavjudligini ta'minlash - mantiqiy soddalashtirish. Ammo taraqqiyot to'xtamaydi va tizimlar yana tobora murakkablashmoqda, ko'proq komponentlar mavjud, bitta xost tizim ehtiyojlarini qondirmaydi va klasterlarni qurish kerak, biz yana tizim ma'murlariga qaytamiz. bu tizimlarni yaratishga qodir.
Tsikldan keyin ishlab chiqish va / yoki boshqarishni soddalashtiradigan turli xil tizimlar paydo bo'ladi, orkestrlash tizimlari paydo bo'ladi, siz standart jarayondan chetga chiqmaguningizcha ulardan foydalanish oson. Mikroservis arxitekturasi ham yuqorida tavsiflangan hamma narsani soddalashtirish maqsadida paydo bo'ldi - kamroq munosabatlar, boshqarish osonroq. O'z tajribamga ko'ra, men to'liq mikroservis arxitekturasini topa olmadim, deyman, 50 dan 50 - 50 foizgacha mikroservislar, qora qutilar kirdi, chiqdi, qayta ishlandi, qolgan 50 tasi yirtilgan monolit, xizmatlar boshqalardan alohida ishlay olmaydi. komponentlar. Bularning barchasi ishlab chiquvchilar va ma'murlarning bilim darajasiga yana cheklovlar qo'ydi.
Muayyan resursning ekspert bilimlari darajasidagi shunga o'xshash "tebranishlar" bugungi kungacha davom etmoqda. Ammo biz biroz chetga chiqamiz, ta'kidlash kerak bo'lgan ko'plab fikrlar mavjud.
Qurilish muhandisi/reliz muhandisi
Dasturiy ta'minotni yaratish jarayonlari va nashrlarini standartlashtirish vositasi sifatida paydo bo'lgan juda yuqori ixtisoslashgan muhandislar. Keng tarqalgan Agile-ni joriy qilish jarayonida ular talabni to'xtatganga o'xshaydi, ammo bu unchalik uzoqdir. Ushbu ixtisoslashuv dasturiy ta'minotni sanoat miqyosida yig'ish va etkazib berishni standartlashtirish vositasi sifatida paydo bo'ldi, ya'ni. barcha kompaniya mahsulotlari uchun standart texnikadan foydalanish. DevOps-ning paydo bo'lishi bilan ishlab chiquvchilar o'z funktsiyalarini qisman yo'qotdilar, chunki aynan ishlab chiquvchilar mahsulotni yetkazib berishga tayyorlashni boshladilar va o'zgaruvchan infratuzilma va sifatni hisobga olmasdan iloji boricha tezroq etkazib berish yondashuvini hisobga olgan holda, vaqt o'tishi bilan ular o'z funksiyalarini yo'qotdilar. o'zgarishlarning to'xtatilishi, chunki sifat standartlariga rioya qilish muqarrar ravishda etkazib berishni sekinlashtiradi. Shunday qilib, asta-sekin Build/Release muhandislari funksiyalarining bir qismi tizim ma'murlari yelkasiga o'tdi.
Oplar juda boshqacha
Biz yana va yana katta mas'uliyatning mavjudligi va malakali kadrlarning etishmasligi bizni yomg'irdan keyingi qo'ziqorin kabi qat'iy ixtisoslashuvga undaydi, turli xil operatsiyalar paydo bo'ladi:
- TechOps - enikey tizim ma'murlari, aka HelpDesk Engineer
- LiveOps - asosan ishlab chiqarish muhiti uchun mas'ul bo'lgan tizim ma'murlari
- CloudOps - umumiy bulutli Azure, AWS, GCP va boshqalarga ixtisoslashgan tizim ma'murlari.
- PlatOps/InfraOps/SysOps - infratuzilma tizimi ma'murlari.
- NetOps - tarmoq ma'murlari
- SecOps - axborot xavfsizligiga ixtisoslashgan tizim ma'murlari - PCI muvofiqligi, MDH muvofiqligi, tuzatishlar va boshqalar.
DevOps (nazariy jihatdan) rivojlanish tsiklining barcha jarayonlarini - ishlab chiqish, sinovdan o'tkazish, mahsulot arxitekturasini tushunadigan, xavfsizlik xavflarini baholay oladigan, yondashuvlar va avtomatlashtirish vositalarini hech bo'lmaganda yuqori darajada biladigan shaxsdir. darajasi, bunga qo'shimcha ravishda, qayta ishlashdan oldingi va keyingi jarayonlarni ham tushunadi. Operatsiyalar va rivojlanish uchun advokat sifatida harakat qila oladigan shaxs, bu ikki ustun o'rtasida qulay hamkorlik qilish imkonini beradi. Jamoalar ishini rejalashtirish va mijozlar kutganlarini boshqarish jarayonlarini tushunadi.
Bunday ish va mas'uliyatni bajarish uchun bu shaxs nafaqat ishlab chiqish va sinov jarayonlarini, balki mahsulot infratuzilmasini boshqarishni, shuningdek resurslarni rejalashtirishni boshqarish vositalariga ega bo'lishi kerak. Ushbu tushunchadagi DevOps ITda ham, R&Dda ham, hatto PMOda ham joylasha olmaydi; u ushbu sohalarning barchasiga ta'sir qilishi kerak - kompaniyaning texnik direktori, bosh texnik direktori.
Sizning kompaniyangizda bu haqiqatmi? - Bunday deb o'ylamayman. Ko'pgina hollarda, bu IT yoki R&D.
Mablag'larning etishmasligi va faoliyatning ushbu uchta yo'nalishidan kamida bittasiga ta'sir o'tkazish qobiliyati muammolarning og'irligini ushbu o'zgarishlarni qo'llash osonroq bo'lgan joyga o'zgartiradi, masalan, statik kodga muvofiq "iflos" kod bilan bog'liq holda nashrlarga texnik cheklovlarni qo'llash. analizator tizimlari. Ya'ni, PMO funksionallikni chiqarish uchun qat'iy muddatni belgilab qo'yganda, AR-GE ushbu muddatlarda yuqori sifatli natijani keltira olmaydi va uni iloji boricha ishlab chiqaradi, refaktoringni keyinroqqa qoldiradi, IT bilan bog'liq DevOps nashrni texnik vositalar bilan bloklaydi. . Vaziyatni o'zgartirish uchun vakolatning yo'qligi, mas'ul xodimlarda, ular ta'sir qila olmaydigan narsalar uchun yuqori mas'uliyatning namoyon bo'lishiga olib keladi, ayniqsa bu xodimlar xatolarni tushunsa va ko'rsa va ularni qanday tuzatish kerak - "Jaholatdagi baxt" , va natijada bu xodimlarning charchashi va yo'qolishi.
DevOps resurslar bozori
Keling, turli kompaniyalarning DevOps lavozimlari uchun bir nechta bo'sh ish o'rinlarini ko'rib chiqaylik.
Biz siz bilan uchrashishga tayyormiz, agar siz:
- Siz Zabbixga egasiz va Prometey nima ekanligini bilasiz;
- Iptables;
- BASH PhD talabasi;
- Professor Ansible;
- Linux guru;
- Nosozliklarni tuzatishdan qanday foydalanishni bilish va dasturchilar bilan birgalikda dastur muammolarini topish (php/java/python);
- Marshrut sizni histerik qilmaydi;
- Tizim xavfsizligiga katta e'tibor bering;
- "Hamma narsani va hamma narsani" zaxiralang, shuningdek, ushbu "hamma narsani va hamma narsani" muvaffaqiyatli tiklang;
- Siz tizimni minimaldan maksimal foyda oladigan tarzda qanday sozlashni bilasiz;
- Postgres va MySQL-da yotishdan oldin replikatsiyani o'rnating;
- CI/CDni sozlash va sozlash siz uchun nonushta/tushlik/kechki ovqat kabi zarur.
- AWS bilan tajribaga ega bo'lish;
- Kompaniya bilan rivojlanishga tayyor;
Shunday qilib:
- 1 dan 6 gacha - tizim ma'muri
- 7 - kichik tarmoq ma'muriyati, bu tizim administratoriga ham mos keladi, O'rta daraja
- 8 - o'rta darajadagi tizim ma'muri uchun majburiy bo'lgan ozgina xavfsizlik
- 9-11 - O'rta tizim ma'muri
- 12 - Belgilangan vazifalarga qarab, o'rta tizim ma'muri yoki qurilish muhandisi
- 13 - Virtualizatsiya - O'rta tizim ma'muri yoki CloudOps deb ataladigan, mablag'lardan samarali foydalanish va texnik xizmat ko'rsatish yukini kamaytirish uchun ma'lum bir xosting saytining xizmatlari haqida ilg'or bilim.
Ushbu vakansiyani sarhisob qiladigan bo'lsak, shuni aytishimiz mumkinki, o'rta/katta tizim administratori yigitlar uchun etarli.
Aytgancha, siz Linux/Windows-da administratorlarni qattiq ajratmasligingiz kerak. Albatta, tushunaman, bu ikki dunyoning xizmatlari va tizimlari har xil, lekin hamma uchun asos bir va o'zini hurmat qiladigan har qanday admin birini ham, boshqasini ham yaxshi biladi va u tanish bo'lmasa ham, shunday bo'ladi. vakolatli administrator uchun u bilan tanishish qiyin emas.
Keling, boshqa vakansiyani ko'rib chiqaylik:
- Yuqori yuk tizimlarini qurish tajribasi;
- Linux OS, umumiy tizim dasturiy ta'minoti va veb-stek (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK) bo'yicha mukammal bilim;
- Virtualizatsiya tizimlari (KVM, VMWare, LXC/Docker) bilan ishlash tajribasi;
- Skript tillarini bilish;
- Tarmoq protokoli tarmoqlarining ishlash tamoyillarini tushunish;
- Nosozliklarga chidamli tizimlarni qurish tamoyillarini tushunish;
- Mustaqillik va tashabbuskorlik;
Keling, ko'rib chiqaylik:
- 1 β Katta tizim administratori
- 2 - Ushbu stekga kiritilgan ma'noga qarab - O'rta/Yuqori tizim ma'muri
- 3 - Ish tajribasi, shu jumladan, shuni anglatishi mumkin - "Klaster ko'tarmadi, lekin virtual mashinalarni yaratdi va boshqardi, bitta Docker xosti bor edi, konteynerlarga kirish imkoni yo'q edi" - O'rta tizim ma'muri
- 4 - Junior System Administrator - ha, qaysi tildan qat'i nazar, asosiy avtomatlashtirish skriptlarini yozishni bilmaydigan administrator - enikey.
- 5 - o'rta tizim administratori
- 6 β Katta tizim administratori
Xulosa qilish uchun - O'rta / Katta tizim ma'muri
Boshqasi:
- Devops tajribasi;
- CI/CD jarayonlarini yaratish uchun bir yoki bir nechta mahsulotlardan foydalanish tajribasi. Gitlab CI afzalligi bo'ladi;
- Konteynerlar va virtualizatsiya bilan ishlash; Agar siz docker-dan foydalansangiz, yaxshi, lekin agar siz k8-dan foydalansangiz, ajoyib!
- Agile jamoada ishlash tajribasi;
- Har qanday dasturlash tilini bilish;
Ko'raylikchi:
- 1 - Hmm... Yigitlar nima demoqchi? =) Ehtimol, ularning o'zlari uning orqasida nima yashiringanini bilishmaydi
- 2 - Qurilish muhandisi
- 3 - o'rta tizim administratori
- 4 - Yumshoq mahorat, biz buni hozircha ko'rib chiqmaymiz, garchi Agile - bu qulay tarzda talqin qilinadigan yana bir narsa.
- 5 - Juda batafsil - bu skript tili yoki tuzilgan til bo'lishi mumkin. Qiziq, maktabda Paskal va Basic tillarida yozish ularga mos keladimi? =)
Shuningdek, ushbu nuqta tizim ma'muri tomonidan nima uchun qamrab olinganligini tushunishni kuchaytirish uchun 3-bandga tegishli eslatma qo'ymoqchiman. Kubernetes - bu shunchaki orkestr, tarmoq drayverlari va virtualizatsiya/izolyatsiya xostlariga to'g'ridan-to'g'ri buyruqlarni bir nechta buyruqlar bilan o'rab oladigan va ular bilan mavhum aloqa qilish imkonini beruvchi vosita, hammasi. Misol uchun, "qurilish ramkasi" Make-ni olaylik, aytmoqchi, men ramka deb hisoblamayman. Ha, men Make-ni kerakli va kerak bo'lmagan joyda silkitish modasi haqida bilaman - Mavenni Make-ga o'rash, masalan, jiddiymi?
Aslini olganda, Make bu xuddi k8s kabi kompilyatsiya, bog'lash va kompilyatsiya muhiti buyruqlarini soddalashtiradigan qobiq ustidagi o'ram.
Bir marta, men OpenStack ustidagi ishida k8-dan foydalangan yigitdan intervyu oldim va u unga qanday xizmatlarni joylashtirgani haqida gapirdi, ammo men OpenStack haqida so'raganimda, u boshqariladigan va tizim tomonidan ko'tarilganligi ma'lum bo'ldi. ma'murlar. Sizningcha, OpenStack-ni o'rnatgan odam, uning orqasida qaysi platformadan foydalanishidan qat'i nazar, k8-dan foydalana olmaydi? =)
Ushbu arizachi aslida DevOps emas, balki tizim ma'muri va aniqrog'i Kubernetes ma'muri.
Keling, yana bir bor xulosa qilaylik - ular uchun o'rta/katta tizim ma'muri etarli bo'ladi.
Gramlarda qancha tortish kerak
Ko'rsatilgan bo'sh ish o'rinlari uchun taklif qilingan ish haqi oralig'i 90-200 ming
Endi men tizim ma'murlari va DevOps muhandislarining pul mukofotlari o'rtasida parallellikni keltirmoqchiman.
Aslida, narsalarni soddalashtirish uchun siz ish tajribasiga asoslangan baholarni tarqatishingiz mumkin, garchi bu aniq bo'lmasa-da, ammo maqolaning maqsadlari uchun bu etarli bo'ladi.
Tajriba:
- 3 yoshgacha - Junior
- 6 yoshgacha - o'rta
- 6 dan ortiq - Katta
Xodimlarni qidirish sayti quyidagilarni taklif qiladi:
Tizim ma'murlari:
- Yoshlar - 2 yosh - 50 ming rub.
- O'rta - 5 yil - 70 ming rub.
- Katta yoshli - 11 yil - 100 ming rub.
DevOps muhandislari:
- Yoshlar - 2 yosh - 100 ming rub.
- O'rta - 3 yil - 160 ming rub.
- Katta yoshli - 6 yil - 220 ming rub.
"DevOps" tajribasiga ko'ra, hech bo'lmaganda SDLC ga qandaydir tarzda ta'sir qilgan tajriba ishlatilgan.
Yuqoridagilardan kelib chiqadiki, aslida kompaniyalarga DevOps kerak emas, shuningdek, ular Administratorni yollash orqali dastlab rejalashtirilgan xarajatlarning kamida 50 foizini tejashlari mumkin; bundan tashqari, ular izlayotgan shaxsning mas'uliyatini aniqroq belgilashlari mumkin. va ehtiyojni tezroq to'ldirish. Shuni ham unutmasligimiz kerakki, vazifalarning aniq taqsimlanishi xodimlarga qo'yiladigan talablarni kamaytirishga, shuningdek, bir-biriga o'xshash holatlarning yo'qligi sababli jamoada yanada qulay muhit yaratishga imkon beradi. Bo'sh ish o'rinlarining katta qismi yordamchi dasturlar va DevOps yorliqlari bilan to'la, lekin ular DevOps muhandisi uchun haqiqiy talablarga asoslanmagan, faqat asbob ma'muriga so'rovlar.
DevOps muhandislarini o'qitish jarayoni, shuningdek, faqat muayyan ishlar, yordamchi dasturlar to'plami bilan cheklangan va jarayonlar va ularning bog'liqliklari haqida umumiy tushuncha bermaydi. Biror kishi AWS EKS-ni Terraform-dan foydalanib, ushbu klasterdagi Fluentd yorlig'i va ro'yxatga olish tizimi uchun AWS ELK stek bilan birgalikda konsolda faqat bitta buyruqni ishlatib, 10 daqiqada o'rnatishi juda yaxshi, lekin agar u buni tushunmasa jurnallarni qayta ishlash printsipi va ular nima uchun kerak, agar siz ular bo'yicha o'lchovlarni qanday yig'ishni va xizmatning yomonlashuvini kuzatishni bilmasangiz, u hali ham ba'zi yordamchi dasturlardan qanday foydalanishni biladigan o'sha enikey bo'lib qoladi.
Biroq, talab taklifni keltirib chiqaradi va biz DevOps pozitsiyasi uchun juda qizib ketgan bozorni ko'ramiz, bu erda talablar haqiqiy rolga mos kelmaydi, faqat tizim ma'murlariga ko'proq daromad olish imkonini beradi.
Xo'sh, ular kimlar? DevOps yoki ochko'z tizim ma'murlari? =)
Qanday qilib yashashni davom ettirish kerak?
Ish beruvchilar talablarni aniqroq shakllantirishlari va kerak bo'lganlarni izlashlari kerak va yorliqlarni tashlamasliklari kerak. Siz DevOps nima qilishini bilmaysiz - bu holda ular sizga kerak emas.
Ishchilar - o'rganing. Doimiy ravishda bilimingizni oshiring, jarayonlarning umumiy rasmini ko'rib chiqing va maqsadingizga yo'lni kuzatib boring. Siz xohlagan odamga aylanishingiz mumkin, shunchaki harakat qilishingiz kerak.
Manba: www.habr.com