So'nggi paytlarda bunday reklamalar Internetni to'ldirdi. Yoqimli maoshga qaramay, ichkarida yovvoyi bid'at yozilganidan xijolat bo'lish mumkin emas. Avvaliga "DevOps" va "muhandis" ni qandaydir tarzda bir so'z bilan birlashtirish mumkin deb taxmin qilinadi, keyin esa tasodifiy talablar ro'yxati mavjud bo'lib, ularning ba'zilari tizim bo'shligidan aniq ko'chiriladi.
Ushbu postda men hayotning ushbu nuqtasiga qanday etib kelganimiz, DevOps aslida nima va u bilan nima qilish kerakligi haqida bir oz gaplashmoqchiman.
Bunday bo'sh ish o'rinlarini har tomonlama qoralash mumkin, ammo haqiqat qolmoqda: ularning ko'plari bor va hozirda bozor shunday ishlaydi. Biz devops konferentsiyasini o'tkazdik va ochiq e'lon qildik: " - DevOps muhandislari uchun emas." Bu ko'pchilik uchun g'alati va yovvoyi tuyuladi: nima uchun butunlay tijorat tadbirini o'tkazayotgan odamlar bozorga qarshi chiqadilar. Endi biz hamma narsani tushuntiramiz.
Madaniyat va jarayonlar haqida
Keling, DevOps muhandislik intizomi emasligidan boshlaylik. Hammasi tarixan o'rnatilgan rollarni taqsimlash mahsulot sifati uchun ishlamasligi bilan boshlandi. Dasturchilar faqat dasturlashsa, lekin sinov haqida hech narsa eshitishni istamasalar, dasturiy ta'minot xatolar bilan to'la. Agar administratorlar dasturiy ta'minot qanday va nima uchun yozilganiga ahamiyat bermasa, qo'llab-quvvatlash do'zaxga aylanadi.
Masalan, tizim ma'muri va xizmatni boshqarishga SRE yondashuvi o'rtasidagi farqni tavsiflash . Ichida qiziqarli tadqiqotlar olib borildi — aniqki, eng yaxshi ishlab chiquvchilar qandaydir tarzda ishlab chiqarishga yangi o'zgarishlarni soatiga bir martadan tezroq kiritishga muvaffaq bo'lishadi. Ular 10% dan ko'p bo'lmagan qo'llari bilan sinovdan o'tkazadilar (buni ko'rish mumkin ). Ular buni qanday qilishadi? Hisobot sarlavhalaridan birida "Excel yoki o'ling" deyiladi. Sinov kontekstida ushbu statistikani batafsil muhokama qilish uchun siz Baruch Sadogurskiyning asosiy ma'lumotlariga murojaat qilishingiz mumkin. boshqa konferentsiyamizda, Heisenbug.
“O'rtoqlar o'rtasida kelishuv bo'lmasa,
Ular uchun ishlar yaxshi ketmaydi,
Va undan hech narsa chiqmaydi, faqat azob.
Bir paytlar Oqqush, Qisqichbaqa va Pike...”
Sizningcha, veb-dasturchilarning qaysi qismi ishlab chiqarishda ularning ilovalaridan foydalanish shartlarini haqiqatan ham tushunadi? Ulardan qanchasi adminlarga borib, ma'lumotlar bazasi ishdan chiqsa nima bo'lishini aniqlashga harakat qiladi? Ulardan qaysi biri testerlarning oldiga borib, testlarni to'g'ri yozishni o'rgatishlarini so'raydi? Shuningdek, qo'riqchilar, mahsulot menejerlari va boshqa bir qancha odamlar bor.
DevOps-ning umumiy g'oyasi rollar va bo'limlar o'rtasida hamkorlikni yaratishdir. Birinchidan, bunga qandaydir aqlli tarzda tuzilgan dasturiy ta'minot orqali emas, balki muloqot amaliyoti orqali erishiladi. DevOps madaniyat, amaliyot, metodologiya va jarayonlar haqida. Bu savollarga javob beradigan muhandislik mutaxassisligi yo'q.
Vicious circle
O'sha paytda "devops muhandislik" intizomi qayerdan paydo bo'lgan? Bizda versiya bor! DevOps g'oyalari juda yaxshi edi - ular o'zlarining muvaffaqiyatlari qurboni bo'lishdi. O'ziga xos muhitga ega bo'lgan ba'zi soyabon yollovchilar va odam savdogarlari bu mavzu atrofida aylana boshladilar.
Tasavvur qiling: kecha siz Ximkida shawarma tayyorlagan edingiz va bugun siz allaqachon katta odamsiz, katta ishga qabul qiluvchisiz. Nomzodlarni izlash va tanlashning butun jarayoni bor, hamma narsa oson emas, siz tushunishingiz kerak. Aytaylik, bo'lim boshlig'i aytadi: X bo'yicha mutaxassis toping. Biz "muhandis" so'zini X ga belgilaymiz va biz tugatdik. Linux kerakmi? Bu, albatta, Linux muhandisi, agar siz DevOps-ni xohlasangiz, DevOps muhandisi. Vakansiya nafaqat sarlavhadan iborat, balki ichkariga ba'zi matnlar kiritilishi kerak. Eng oson yo'li - bu sizning tasavvuringizga qarab Google'dan kalit so'zlar to'plamini kiritishdir. DevOps ikkita so'zdan iborat - "Dev" va "Ops", ya'ni ishlab chiquvchilar va ma'murlar bilan bog'liq kalit so'zlarni bitta qoziqqa yopishtirishimiz kerak. 42 dasturlash tillarini bilish va Kubernetes va Swarm-dan bir vaqtning o'zida 20 yil foydalanish bo'yicha bo'sh ish o'rinlari shunday paydo bo'ladi. Ishchi diagrammasi.
Ma'lum bir "devops" super qahramonning ma'nosiz va shafqatsiz qiyofasi odamlar ongida shunday ildiz otgan, u hammani Jenkinsga joylashtirishga sozlaydi va baxt keladi. Oh, hamma narsa juda oddiy bo'lsa edi. "Va shu bilan siz tizim ma'murlarini ovlashingiz mumkin", deb o'ylaydi HR, "bu moda so'z, kalit so'zlar bir xil, ular o'lja olishlari kerak".
Talab taklifni keltirib chiqaradi va bu axlat bo'sh ish o'rinlari aqldan ozgan tizim ma'murlari bilan to'ldirildi, ular tushunishdi: siz hamma narsani avvalgidek qilishingiz mumkin, lekin o'zingizni "devops" deb atash orqali bir necha baravar ko'p narsalarni olishingiz mumkin. Xuddi siz SSH orqali serverlarni birma-bir qo'lda sozlaganingizdek, siz ularni sozlashda davom etasiz, ammo endi bu devops amaliyotidir. Bu qisman klassik administratorlarning kam baholanishi va DevOps atrofidagi shov-shuv bilan bog'liq bo'lgan qandaydir murakkab hodisa, lekin umuman olganda, nima sodir bo'ldi.
Shunday qilib, bizda talab va taklif bor. O'zini o'zi oziqlantiradigan yomon doira. Biz bunga qarshi kurashamiz (shu jumladan DevOops konferentsiyasini yaratish orqali).
Albatta, o'zlarini "devops" deb o'zgartirgan tizim ma'murlaridan tashqari, boshqa ishtirokchilar ham bor - masalan, professional SRE yoki Infrastruktura-as-Code ishlab chiquvchilari.
Odamlar DevOps-da nima qilishadi (haqiqatan ham)
Shunday qilib, siz DevOps amaliyotlarini o'rganish va qo'llashda oldinga inmoqchisiz. Lekin buni qanday qilish kerak, qaysi tomonga qarash kerak? Shubhasiz, siz mashhur kalit so'zlarga ko'r-ko'rona tayanmasligingiz kerak.
Agar ish bo'lsa, uni kimdir qilish kerak. Bular "devops muhandislari" emasligini allaqachon bilib oldik, keyin kimlar? Buni lavozimlar bo'yicha emas, balki muayyan ish yo'nalishlari nuqtai nazaridan shakllantirish to'g'riroq ko'rinadi.
Birinchidan, siz DevOps-ning yuragiga - jarayonlar va madaniyatga murojaat qilishingiz mumkin. Madaniyat sekin va qiyin ish bo'lib, an'anaviy ravishda menejerlar mas'uliyati bo'lsa ham, dasturchilardan tortib ma'murlargacha hamma u yoki bu tarzda ishtirok etadi. Bir necha oy oldin Tim Lister :
“Madaniyat tashkilotning asosiy qadriyatlari bilan belgilanadi. Odatda odamlar buni sezmaydilar, lekin ko'p yillar davomida konsalting sohasida ishlaganimiz uchun biz buni payqashga o'rganib qolganmiz. Siz kompaniyaga kirasiz va bir necha daqiqadan so'ng nima bo'layotganini his qila boshlaysiz. Biz buni "lazzat" deb ataymiz. Ba'zan bu hid juda yaxshi. Ba'zida ko'ngil aynishi sabab bo'ladi. (...) Muayyan harakatlar ortidagi qadriyatlar va e'tiqodlar tushunilmaguncha, siz madaniyatni o'zgartira olmaysiz. Xulq-atvorni kuzatish oson, ammo e'tiqodlarni izlash qiyin. DevOps - bu narsalar qanchalik murakkablashib borayotganining ajoyib namunasidir.
Albatta, masalaning texnik tomoni ham bor. Agar sizning yangi kodingiz bir oy ichida sinovdan o'tkazilsa, lekin faqat bir yildan keyin chiqarilsa va uni tezlashtirish jismonan imkonsiz bo'lsa, siz yaxshi amaliyotlarga amal qilmasligingiz mumkin. Yaxshi amaliyotlar yaxshi vositalar bilan qo'llab-quvvatlanadi. Misol uchun, Infrastructure-as-Code g'oyasini yodda tutgan holda, siz AWS CloudFormation va Terraformdan tortib Chef-Ansible-Puppetgacha bo'lgan hamma narsadan foydalanishingiz mumkin. Bularning barchasini bilishingiz va qila olishingiz kerak va bu allaqachon muhandislik intizomi. Sababni oqibat bilan aralashtirmaslik muhim: avval siz SRE tamoyillari bo'yicha ishlaysiz va shundan keyingina ushbu tamoyillarni ba'zi bir aniq texnik echimlar shaklida amalga oshirasiz. Shu bilan birga, SRE juda keng qamrovli metodologiya bo'lib, u Jenkinsni qanday o'rnatishni aytmaydi, lekin taxminan beshta asosiy tamoyil:
- Rollar va bo'limlar o'rtasidagi aloqa yaxshilandi
- Xatolarni ishning ajralmas qismi sifatida qabul qilish
- Sekin-asta o'zgarishlar qilish
- Asboblar va boshqa avtomatlashtirish vositalaridan foydalanish
- O'lchash mumkin bo'lgan hamma narsani o'lchash
Bu faqat ba'zi bayonotlar to'plami emas, balki o'ziga xosdir . Masalan, xatolarni qabul qilish yo'lida siz xavflarni tushunishingiz, xizmatlarning mavjudligi va mavjud emasligini o'lchashingiz kerak bo'ladi.) va SLO (), o'limdan keyin yozishni o'rganing va ularni yozishni qo'rqinchli emas.
SRE intizomida asboblardan foydalanish muhim bo'lsa-da, muvaffaqiyatning faqat bir qismidir. Biz doimo texnik jihatdan rivojlanishimiz, dunyoda nima sodir bo'layotganini va uni bizning ishimizda qanday qo'llash mumkinligini ko'rib chiqishimiz kerak.
O'z navbatida, Cloud Native echimlari endi juda mashhur bo'ldi. Bugungi kunda Cloud Native Computing Foundation tomonidan ta'riflanganidek, Cloud Native texnologiyalari tashkilotlarga ommaviy, xususiy va gibrid bulutlar kabi bugungi dinamik muhitda kengaytiriladigan ilovalarni ishlab chiqish va ishga tushirish imkonini beradi. Misollar: konteynerlar, xizmat ko'rsatish tarmoqlari, mikroservislar, o'zgarmas infratuzilma va deklarativ API. Ushbu usullarning barchasi bo'shashmasdan bog'langan tizimlarni elastik, boshqariladigan va yuqori darajada kuzatish imkonini beradi. Yaxshi avtomatlashtirish muhandislarga tez-tez va oldindan aytib bo'ladigan natijalar bilan katta o'zgarishlar qilish imkonini beradi. Bularning barchasi Docker va Kubernetes kabi taniqli vositalar to'plami tomonidan qo'llab-quvvatlanadi.
Bu ancha murakkab va keng ta'rif hududning ham ancha murakkab ekanligi bilan bog'liq. Bir tomondan, ushbu tizimga yangi o'zgarishlarni juda sodda tarzda kiritish kerakligi ta'kidlanadi. Boshqa tomondan, dasturiy ta'minot bilan aniqlangan infratuzilmada erkin bog'langan xizmatlar yashaydigan va u erda uzluksiz CI/CD yordamida etkazib beriladigan konteynerlashtirilgan muhitni qanday yaratishni aniqlash va bularning barchasi atrofida DevOps amaliyotlarini yaratish - bularning barchasi ko'proq narsani talab qiladi. itni bittasi yeydi.
Bularning barchasi bilan nima qilish kerak
Har bir inson bu muammolarni o'z yo'lida hal qiladi: masalan, shafqatsiz doirani buzish uchun oddiy vakansiyalarni nashr qilishingiz mumkin. Siz DevOps va Cloud Native kabi so'zlar nimani anglatishini bilib olishingiz va ularni to'g'ri va maqsadga muvofiq ishlatishingiz mumkin. Siz DevOps-da rivojlanishingiz va o'zingizning misolingiz bilan to'g'ri yondashuvlarni namoyish qilishingiz mumkin.
Biz konferentsiya o'tkazyapmiz , bu biz gaplashgan narsalarni chuqurroq o'rganish imkonini beradi. Buning uchun bir nechta hisobot guruhlari mavjud:
- Jarayonlar va madaniyat;
- Sayt ishonchliligi muhandisligi;
- Cloud Native;
Qaerga borishni qanday tanlash mumkin? Bu erda nozik bir nuqta bor. Bir tomondan, DevOps o'zaro ta'sirga tegishli va biz sizni turli bloklardagi taqdimotlarda qatnashishingizni juda xohlaymiz. Boshqa tomondan, agar siz konferentsiyaga bitta aniq vazifaga e'tibor qaratish uchun kelgan rivojlanish menejeri bo'lsangiz, unda hech kim sizni cheklamaydi - bu jarayonlar va madaniyat haqida blok bo'lishi aniq. Shuni unutmangki, konferentsiyadan so'ng (mulohaza shaklini to'ldirganingizdan so'ng) sizda yozuvlar bo'ladi, shunda siz har doim kamroq ahamiyatli taqdimotlarni keyinroq ko'rishingiz mumkin.
Shubhasiz, konferentsiyaning o'zida siz bir vaqtning o'zida uchta yo'lga bora olmaysiz, shuning uchun biz dasturni shunday tashkil qilamizki, har bir vaqt oralig'ida har qanday did uchun mavzular mavjud.
Agar DevOps muhandisi bo'lsangiz, nima qilish kerakligini tushunish qoladi! Birinchidan, aslida nima qilayotganingizni aniqlashga harakat qiling. Odatda ular bu so'zni chaqirishni yaxshi ko'radilar:
- Infratuzilmada ishlaydigan dasturchilar. SRE va Cloud Native haqidagi hisobotlar guruhlari sizga eng mos keladi.
- Tizim ma'murlari. Bu erda hamma narsa murakkabroq. DevOops tizim boshqaruvi haqida emas. Yaxshiyamki, tizim boshqaruvi mavzusida Internetda juda ko'p ajoyib konferentsiyalar, kitoblar, maqolalar, videolar va boshqalar mavjud. Boshqa tomondan, agar siz madaniyat va jarayonlarni tushunish, bulutli texnologiyalar va Cloud Native bilan hayot tafsilotlarini o'rganish nuqtai nazaridan o'zingizni rivojlantirishga qiziqsangiz, biz sizni ko'rishdan xursand bo'lamiz! Buni o'ylab ko'ring: siz ma'muriyat bilan shug'ullanyapsiz, keyin nima qilasiz? To'satdan o'zingizni noxush vaziyatga tushib qolmaslik uchun hozir o'rganishingiz kerak.
Yana bir variant bor: siz davom etasiz va o'zingizni shunday deb da'vo qilishda davom etasiz ayniqsa DevOps muhandisi va boshqa hech narsa, bu nimani anglatadi. Keyin biz sizni xafa qilishimiz kerak, DevOops DevOps muhandislari uchun konferentsiya emas!
dan siljitish Myunxenda
DevOops 2020 Moskva 29-30 aprel kunlari Moskvada bo'lib o'tadi, chiptalar allaqachon mavjud .
Shu bilan bir qatorda, mumkin 8 fevralgacha. E'tibor bering, arizani to'ldirishda siz hisobotingizdan ko'proq foyda ko'radigan maqsadli auditoriyani tanlashingiz kerak (ro'yxat ichida hayratlanarli narsa bor).
Manba: www.habr.com