DevOps so'nggi bir necha yil ichida juda mashhur mavzuga aylandi. Ko'pchilik unga qo'shilishni orzu qiladi, lekin amaliyot shuni ko'rsatadiki, ko'pincha faqat ish haqi darajasi tufayli.
Ba'zi odamlar DevOps-ni o'zlarining rezyumelarida ro'yxatga olishadi, garchi ular bu atamaning mohiyatini har doim ham bilishmasa yoki tushunmasa ham. Ba'zilar Ansible, GitLab, Jenkins, Terraform va shunga o'xshash narsalarni (ro'yxatni didingizga qarab davom ettirish mumkin) o'rgangach, siz darhol "devopsist" bo'lasiz deb o'ylashadi. Bu, albatta, to'g'ri emas.
So'nggi bir necha yil davomida men asosan turli kompaniyalarda DevOps-ni joriy qilish bilan shug'ullanganman. Bungacha u 20 yildan ortiq vaqt davomida tizim administratoridan tortib IT direktorigacha bo‘lgan lavozimlarda ishlagan. Hozirda Playgendary kompaniyasida DevOps yetakchi muhandisi.
DevOps kim
Maqola yozish g'oyasi yana bir savoldan keyin paydo bo'ldi: "DevOps kim?" Bu nima yoki kim ekanligi haqida hali ham aniq atama yo'q. Ba'zi javoblar allaqachon bu erda . Birinchidan, men undan asosiy fikrlarni ajratib ko'rsataman, keyin esa o'z kuzatishlarim va fikrlarim bilan o'rtoqlashaman.
DevOps yollanishi mumkin bo'lgan mutaxassis emas, kommunal xizmatlar to'plami emas va muhandislar bilan ishlab chiquvchilar bo'limi emas.
DevOps - bu falsafa va metodologiya.
Boshqacha qilib aytganda, bu ishlab chiquvchilarga tizim ma'murlari bilan faol aloqada bo'lishga yordam beradigan amaliyotlar to'plamidir. Ya'ni, ish jarayonlarini bir-biriga bog'lash va birlashtirish.
DevOps paydo bo'lishi bilan mutaxassislarning tuzilishi va rollari bir xil bo'lib qoldi (ishlab chiquvchilar bor, muhandislar bor), lekin o'zaro ta'sir qilish qoidalari o'zgardi. Bo'limlar orasidagi chegaralar xiralashgan.
DevOps maqsadlarini uchta nuqtada tasvirlash mumkin:
- Dasturiy ta'minot muntazam yangilanishi kerak.
- Dasturiy ta'minot tezda bajarilishi kerak.
- Dasturiy ta'minot qulay va qisqa vaqt ichida joylashtirilishi kerak.
DevOps uchun yagona vosita yo'q. Bir nechta mahsulotlarni sozlash, etkazib berish va o'rganish DevOps kompaniyada paydo bo'lgan degani emas. Ko'plab vositalar mavjud va ularning barchasi turli bosqichlarda qo'llaniladi, lekin bitta umumiy maqsadga xizmat qiladi.
Va bu DevOps vositalarining faqat bir qismi
Men 2 yildan ortiq vaqtdan beri DevOps muhandisi lavozimi uchun odamlar bilan suhbatlashyapman va bu atamaning mohiyatini aniq tushunish qanchalik muhimligini tushunib yetdim. Men baham ko'rmoqchi bo'lgan aniq tajribalar, kuzatishlar va fikrlarni to'pladim.
Intervyu tajribasidan men quyidagi rasmni ko'raman: DevOpsni ish unvoni deb hisoblaydigan mutaxassislar odatda hamkasblari bilan tushunmovchiliklarga duch kelishadi.
Ajoyib misol bor edi. Bir yigit intervyuga rezyumeida juda ko'p aqlli so'zlar bilan keldi. Oxirgi uchta ishida u 5-6 oylik tajribaga ega edi. Men ikkita startapni tark etdim, chunki ular "chiqishmadi". Ammo uchinchi kompaniya haqida u u erda uni hech kim tushunmasligini aytdi: ishlab chiquvchilar Windows-da kod yozadilar va direktor bu kodni oddiy Docker-ga "o'rashga" va CI/CD quvuriga o'rnatishga majbur qiladi. Yigit hozirgi ish joyi va hamkasblari haqida juda ko'p salbiy narsalarni aytdi - men shunchaki javob bermoqchi edim: "Shunday qilib, siz filni sotmaysiz."
Keyin men unga har bir nomzod uchun ro'yxatimda yuqori bo'lgan savolni berdim.
— Shaxsan siz uchun DevOps nimani anglatadi?
- Umuman yoki men buni qanday qabul qilaman?
Men uning shaxsiy fikri bilan qiziqdim. U atamaning nazariyasi va kelib chiqishini bilar edi, lekin ular bilan qat'iyan rozi bo'lmadi. U DevOpsni ish unvoni deb hisoblagan. Uning muammolarining ildizi shu yerda. Xuddi shu fikrga ega bo'lgan boshqa mutaxassislar kabi.
"DevOps sehri" haqida ko'p eshitgan ish beruvchilar kelib, ushbu "sehr" ni yaratadigan odamni topmoqchi. Va "DevOps - bu ish" toifasidagi abituriyentlar bu yondashuv bilan ular kutganlarni qondira olmasligini tushunishmaydi. Va umuman olganda, ular o'zlarining rezyumelarida DevOps-ni yozdilar, chunki bu trend va ular buning uchun juda ko'p pul to'laydilar.
DevOps metodologiyasi va falsafasi
Metodologiya nazariy va amaliy bo'lishi mumkin. Bizning holatda, bu ikkinchisi. Yuqorida aytib o'tganimdek, DevOps - bu belgilangan maqsadlarga erishish uchun ishlatiladigan amaliyotlar va strategiyalar to'plami. Va har bir holatda, kompaniyaning biznes jarayonlariga qarab, u sezilarli darajada farq qilishi mumkin. Bu uni yaxshiroq yoki yomonlashtirmaydi.
DevOps metodologiyasi faqat maqsadlarga erishish vositasidir.
Endi DevOps falsafasi nima haqida. Va bu, ehtimol, eng qiyin savol.
Qisqa va lo'nda javobni shakllantirish juda qiyin, chunki u hali rasmiylashtirilmagan. Va DevOps falsafasi tarafdorlari ko'proq amaliyot bilan shug'ullanishganligi sababli, falsafa qilish uchun vaqt yo'q. Biroq, bu juda muhim jarayon. Bundan tashqari, bu muhandislik faoliyati bilan bevosita bog'liq. Hatto ixtisoslashgan bilim sohasi ham mavjud - .
Mening universitetimda bunday fan yo'q edi, men 90-yillarda topilgan materiallardan foydalanib, hamma narsani o'zim o'rganishim kerak edi. Mavzu muhandislik ta'limi uchun ixtiyoriydir, shuning uchun javobning rasmiylashtirilmaganligi. Ammo DevOps bilan jiddiy shug'ullangan odamlar kompaniyaning barcha jarayonlarida ma'lum bir "ruh" yoki "ongsiz ravishda keng qamrovlilik" ni his qila boshlaydilar.
O'z tajribamdan foydalanib, men ushbu falsafaning ba'zi "postulatlarini" rasmiylashtirishga harakat qildim. Natija quyidagicha:
- DevOps - bu bilim yoki faoliyatning alohida sohasiga ajratilishi mumkin bo'lgan mustaqil narsa emas.
- Kompaniyaning barcha xodimlari o'z faoliyatini rejalashtirishda DevOps metodologiyasiga amal qilishlari kerak.
- DevOps kompaniya ichidagi barcha jarayonlarga ta'sir qiladi.
- DevOps o'z xizmatlarini rivojlantirish va mijozlarga maksimal qulaylikni ta'minlash uchun kompaniya ichidagi har qanday jarayonlar uchun vaqt xarajatlarini kamaytirish uchun mavjud.
- DevOps, zamonaviy tilda aytganda, kompaniyaning har bir xodimining vaqt xarajatlarini kamaytirish va atrofimizdagi IT-mahsulotlar sifatini yaxshilashga qaratilgan faol pozitsiyasidir.
O'ylaymanki, mening "postulatlarim" alohida muhokama mavzusi. Ammo endi qurish uchun nimadir bor.
DevOps nima qiladi
Bu erda asosiy so'z aloqadir. Ko'plab aloqalar mavjud, ularning tashabbuskori aynan o'sha DevOps muhandisi bo'lishi kerak. Nega bunday? Chunki bu falsafa va metodologiya, shundan keyingina muhandislik bilimi.
G'arb mehnat bozori haqida 100% ishonch bilan gapira olmayman. Ammo men Rossiyadagi DevOps bozori haqida juda ko'p narsani bilaman. Yuzlab intervyularga qo'shimcha ravishda, so'nggi bir yarim yil ichida men Rossiyaning yirik kompaniyalari va banklari uchun "DevOpsni amalga oshirish" xizmati uchun yuzlab texnik oldindan sotuvlarda ishtirok etdim.
Rossiyada DevOps hali juda yosh, ammo allaqachon trend bo'lgan mavzu. Bilishimcha, birgina Moskvada 2019 yilda bunday mutaxassislarning etishmasligi 1000 dan ortiq kishini tashkil etgan. Va ish beruvchilar uchun Kubernetes so'zi deyarli buqa uchun qizil lattaga o'xshaydi. Ushbu vosita tarafdorlari undan zarur bo'lmagan va iqtisodiy jihatdan foydali bo'lmagan joylarda ham foydalanishga tayyor. Ish beruvchi har doim ham qaysi hollarda foydalanish maqsadga muvofiqligini tushunmaydi va to'g'ri joylashtirish bilan Kubernetes klasterini saqlash odatiy klaster sxemasidan foydalangan holda dasturni joylashtirishdan 2-3 baravar qimmat turadi. Haqiqatan ham kerak bo'lgan joyda foydalaning.
DevOpsni amalga oshirish pul jihatidan qimmat. Va u o'z-o'zidan emas, balki boshqa sohalarda iqtisodiy foyda keltiradigan joyda oqlanadi.
DevOps muhandislari, aslida, kashshoflar - ular kompaniyada ushbu metodologiyani birinchi bo'lib joriy etishlari va jarayonlarni qurishlari kerak. Buning muvaffaqiyatli bo'lishi uchun mutaxassis barcha darajadagi xodimlar va hamkasblar bilan doimiy aloqada bo'lishi kerak. Odatda aytganimdek, kompaniyaning barcha xodimlari DevOpsni amalga oshirish jarayonida ishtirok etishlari kerak: tozalovchi ayoldan tortib bosh direktorgacha. Va bu old shart. Agar jamoaning eng kichik a'zosi DevOps nima ekanligini va nima uchun muayyan tashkiliy harakatlar amalga oshirilishini bilmasa va tushunmasa, muvaffaqiyatli amalga oshirish ishlamaydi.
Bundan tashqari, DevOps muhandisi vaqti-vaqti bilan ma'muriy resursdan foydalanishi kerak. Masalan, "atrof-muhitga qarshilik" ni engish uchun - jamoa DevOps vositalari va metodologiyasini qabul qilishga tayyor bo'lmaganda.
Ishlab chiquvchi faqat kod va testlarni yozishi kerak. Buning uchun unga loyiha infratuzilmasini o'rnatadigan va mahalliy darajada qo'llab-quvvatlaydigan o'ta kuchli noutbuk kerak emas. Masalan, front-end dasturchi o'z noutbukida dasturning barcha elementlarini, jumladan ma'lumotlar bazasini, S3 emulyatorini (minio) va hokazolarni saqlaydi. Ya'ni, u ushbu mahalliy infratuzilmani saqlashga ko'p vaqt sarflaydi va bunday yechimning barcha muammolari bilan yakka o'zi kurashadi. Oldin uchun kodni ishlab chiqish o'rniga. Bunday odamlar har qanday o'zgarishlarga juda chidamli bo'lishi mumkin.
Ammo shunday jamoalar borki, ular, aksincha, yangi vositalar va usullarni joriy etishdan mamnun va bu jarayonda faol ishtirok etadilar. Garchi bu holatda ham DevOps muhandisi va jamoa o'rtasidagi aloqa bekor qilinmagan.
DevOps kerak bo'lmaganda
DevOps kerak bo'lmagan holatlar mavjud. Bu haqiqat - buni tushunish va qabul qilish kerak.
Avvalo, bu har qanday kompaniyalarga (ayniqsa, kichik biznesga) taalluqlidir, chunki ularning foydasi mijozlarga axborot xizmatlarini ko'rsatadigan IT-mahsulotlarning mavjudligi yoki yo'qligiga bevosita bog'liq emas. Va bu erda biz kompaniyaning veb-sayti haqida gapirmayapmiz, xoh u statik "vizit kartasi" bo'lsin, xoh dinamik yangiliklar bloklari va boshqalar.
Mijozning qoniqishi va yana sizga qaytish istagi mijoz bilan o'zaro aloqa qilish uchun ushbu axborot xizmatlarining mavjudligi, ularning sifati va maqsadliligiga bog'liq bo'lsa, DevOps talab qilinadi.
Yorqin misol - taniqli banklardan biri. Kompaniyada an'anaviy mijozlar ofislari mavjud emas, hujjatlar aylanishi pochta yoki kurerlar orqali amalga oshiriladi va ko'plab xodimlar uydan ishlaydi. Kompaniya shunchaki bank bo'lishni to'xtatdi va mening fikrimcha, rivojlangan DevOps texnologiyalariga ega IT-kompaniyaga aylandi.
Boshqa ko'plab misollar va ma'ruzalarni tematik uchrashuvlar va konferentsiyalarning yozuvlarida topish mumkin. Men ularning ba'zilariga shaxsan tashrif buyurdim - bu ushbu yo'nalishda rivojlanmoqchi bo'lganlar uchun juda foydali tajriba. DevOps bo'yicha yaxshi ma'ruzalar va materiallarga ega YouTube kanallariga havolalar:
Endi biznesingizga qarang va bu haqda o'ylab ko'ring: Sizning kompaniyangiz va uning foydasi mijozlar bilan o'zaro aloqada bo'lish uchun IT mahsulotlariga qanchalik bog'liq?
Agar sizning kompaniyangiz kichik do'konda baliq sotsa va yagona IT mahsuloti ikkita 1C: Korxona konfiguratsiyasi (Buxgalteriya hisobi va UNF) bo'lsa, DevOps haqida gapirishning ma'nosi yo'q.
Agar siz yirik savdo va ishlab chiqarish korxonasida ishlasangiz (masalan, siz ov miltiqlarini ishlab chiqarsangiz), bu haqda o'ylashingiz kerak. Siz tashabbusni o'z qo'lingizga olishingiz va rahbariyatingizga DevOps-ni joriy etish istiqbollarini etkazishingiz mumkin. Xo'sh, va shu bilan birga, bu jarayonni boshqaring. Proaktiv pozitsiya DevOps falsafasining muhim tamoyillaridan biridir.
Yillik moliyaviy aylanmaning hajmi va hajmi sizning kompaniyangiz DevOps-ga muhtojligini aniqlashning asosiy mezoni emas.
Mijozlar bilan bevosita muloqot qilmaydigan yirik sanoat korxonasini tasavvur qilaylik. Masalan, ba'zi avtomobil ishlab chiqaruvchilar va avtomobil ishlab chiqaruvchi kompaniyalar. Men hozir ishonchim komil emas, lekin o'tmishdagi tajribamdan ko'ra, ko'p yillar davomida barcha mijozlar bilan muloqot elektron pochta va telefon orqali amalga oshirilgan.
Ularning mijozlari avtomobil sotuvchilari cheklangan ro'yxati. Va har biriga ishlab chiqaruvchidan mutaxassis tayinlanadi. Barcha ichki hujjat aylanishi SAP ERP orqali amalga oshiriladi. Ichki xodimlar asosan axborot tizimining mijozlari hisoblanadi. Ammo bu IS klaster tizimlarini boshqarishning klassik vositalari bilan boshqariladi. Bu DevOps amaliyotlaridan foydalanish imkoniyatini istisno qiladi.
Shunday qilib, xulosa: agar maqolaning boshidan metodologiyaning maqsadlarini eslasak, bunday korxonalar uchun DevOps-ni joriy qilish juda muhim narsa emas. Ammo bugungi kunda ular DevOps vositalaridan foydalanishlarini istisno qilmayman.
Boshqa tomondan, DevOps metodologiyasi, falsafasi, amaliyoti va vositalaridan foydalangan holda dasturiy ta'minotni ishlab chiqadigan ko'plab kichik kompaniyalar mavjud. Va ular DevOps-ni joriy qilish xarajatlari dasturiy ta'minot bozorida samarali raqobatlashish imkonini beruvchi xarajat ekanligiga ishonishadi. Bunday kompaniyalarning misollarini ko'rish mumkin .
DevOps kerak yoki yo'qligini tushunishning asosiy mezoni: IT-mahsulotlaringiz kompaniya va mijozlar uchun qanday ahamiyatga ega.
Agar kompaniyaning foyda keltiradigan asosiy mahsuloti dasturiy ta'minot bo'lsa, sizga DevOps kerak. Va agar siz boshqa mahsulotlardan foydalanib haqiqiy pul topsangiz, unchalik muhim emas. Bu, shuningdek, o'yinlar bilan onlayn do'konlar yoki mobil ilovalarni o'z ichiga oladi.
Har qanday o'yinlar moliyalashtirish tufayli mavjud: o'yinchilar tomonidan to'g'ridan-to'g'ri yoki bilvosita. Playgendary-da biz ularni yaratishda bevosita ishtirok etgan 200 dan ortiq odamlar bilan bepul mobil o'yinlarni ishlab chiqamiz. DevOps-dan qanday foydalanamiz?
Ha, yuqorida tavsiflanganidek, xuddi shunday. Men doimiy ravishda ishlab chiquvchilar va testerlar bilan muloqot qilaman va DevOps metodologiyasi va vositalari bo'yicha xodimlar uchun ichki treninglar o'tkazaman.
Endi biz Jenkins-dan Unity bilan barcha yig'ish quvurlarini bajarish va keyinchalik App Store va Play Marketga joylashtirish uchun CI/CD quvurlari vositasi sifatida faol foydalanmoqdamiz. Klassik asboblar to'plamidan ko'proq:
- Asana - loyihani boshqarish uchun. Jenkins bilan integratsiya sozlangan.
- Google Meet - video uchrashuvlar uchun.
- Slack - aloqa va turli ogohlantirishlar, shu jumladan Jenkins xabarnomalari uchun.
- Atlassian Confluence - hujjatlar va guruh ishlari uchun.
Bizning yaqin rejalarimizga SonarQube yordamida statik kod tahlilini joriy etish va Uzluksiz integratsiya bosqichida Selenium yordamida avtomatlashtirilgan UI testini o'tkazish kiradi.
Xulosa o'rniga
Men quyidagi fikr bilan yakunlamoqchiman: yuqori malakali DevOps muhandisi bo'lish uchun odamlar bilan jonli muloqot qilishni o'rganish juda muhimdir.
DevOps muhandisi jamoaviy o'yinchidir. Va boshqa hech narsa. Hamkasblar bilan muloqot qilish tashabbusi ba'zi holatlarning ta'siri ostida emas, balki undan chiqishi kerak. DevOps mutaxassisi jamoa uchun eng yaxshi yechimni ko'rishi va taklif qilishi kerak.
Va ha, har qanday yechimni amalga oshirish juda ko'p muhokamalarni talab qiladi va oxir-oqibat u butunlay o'zgarishi mumkin. Mustaqil rivojlanayotgan, o'z g'oyalarini taklif qiladigan va amalga oshirgan bunday shaxs jamoa uchun ham, ish beruvchi uchun ham qadr-qimmatini oshiradi. Bu, oxir-oqibat, uning oylik ish haqi miqdorida yoki qo'shimcha bonuslar shaklida aks etadi.
Manba: www.habr.com