Men yaqinda Logrocon tomonidan o'tkazilgan DevOpsForum 2019 ko'rgazmasida qatnashdim. Ushbu anjumanda ishtirokchilar biznes va rivojlanish hamda axborot texnologiyalari xizmati mutaxassislari oʻrtasida samarali hamkorlik qilish uchun yechimlar va yangi vositalarni topishga harakat qilishdi.
Konferentsiya muvaffaqiyatli o'tdi: haqiqatan ham juda ko'p foydali ma'ruzalar, qiziqarli taqdimot formatlari va ma'ruzachilar bilan ko'plab muloqotlar bo'ldi. Va ayniqsa, hech kim menga hech narsa sotmoqchi bo'lmagani juda muhim, bu so'nggi paytlarda katta konferentsiyalarda ma'ruzachilar aybdor edi.
Raiffeisenbank nutqlaridan parcha, Alfastrakhovanie, Mango Telecom kompaniyasining avtomatlashtirishni joriy etish tajribasi va kesish ostidagi boshqa tafsilotlar.
Mening ismim Yana, men tester bo'lib ishlayman, avtomatlashtirish, shuningdek DevOps bilan shug'ullanaman va konferentsiyalar va uchrashuvlarga borishni yaxshi ko'raman. Oxirgi ikki yil davomida men Oleg Buninning konferentsiyalarida (HighLoad++, TeamLead Conf), Jug tadbirlarida (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscowda bo'ldim.
Men birinchi navbatda konferentsiya dasturiga e'tibor qarataman. Men ma'ruza nima haqida bo'lishiga kamroq qarayman va ko'proq ma'ruzachiga qarayman. Hisobot juda texnologik va qiziqarli bo'lib chiqsa ham, hisobotdagi eng yaxshi tajribalardan ba'zilarini kompaniyangizda qo'llashingiz mumkinligi haqiqat emas. Va keyin sizga karnay kerak.
Raiffeisenbankdagi quvur oxirida yorug'lik
Odatda, men o'zimni qiziqtiradigan chetdagi ma'ruzachilarni qidiraman. DevOpsForum 2019 da Raiffeisenbank spikeri Mixail Bizan meni qiziqtirdi. O'z nutqi davomida u o'z jamoalarini asta-sekin DevOps-ga qanday qilib bog'lashayotgani, ularga nima uchun kerakligi va DevOps-ni o'zgartirish g'oyasini biznesga qanday sotish haqida gapirdi. Xo'sh, umuman olganda, men quvur liniyasining oxirida yorug'likni qanday ko'rish haqida gapirdim.
Mixail Bizhan, Raiffeisenbank avtomatlashtirish direktori
Endi ularning kompaniyasida "DevOps" yo'q. Ya'ni, u ishlaydi, lekin hamma jamoalarda emas. DevOps-ni amalga oshirishda ular aniq muhandislar nuqtai nazaridan ham, mahsulotga bo'lgan ehtiyoj va ushbu mahsulot qurilgan platformaning etukligi nuqtai nazaridan jamoalarning tayyorligiga tayanadilar. Misha DevOps nima uchun kerakligini biznesga qanday tushuntirish kerakligini aytdi.
Bank segmentida o'sishning bir nechta omillari mavjud: xizmatlar narxi va mijozlar bazasini kengaytirish. Xizmatlar narxini oshirish juda yaxshi haydovchi emas, lekin mijozlar bazasini ko'paytirish aksincha. Agar raqobatchilar ob'ektiv ravishda ajoyib mahsulotni chiqarsa, barcha mijozlar u erga boradilar, keyin vaqt o'tishi bilan bozor tekislanadi. Shuning uchun bozorga yangi mahsulotlarni joriy etish va ularni joriy etish tezligi banklarning asosiy e’tiborini tortadi. DevOps aynan shu maqsadda va korxonalar buni tushunishadi.
Keyingi muhim eslatma: DevOps har doim ham bozorga chiqish vaqtini kamaytirmaydi. DevOps yolg'iz ishlay olmaydi, bu ishlab chiqarishdan ishlab chiqarishgacha (koddan mijozga) mahsulotni yaratish va bozorga olib chiqish jarayonining bir qismidir. Ammo koddan oldingi hamma narsa DevOps bilan bevosita bog'liq emas. Ya'ni, marketologlar bozorni yillar davomida o'rganishi va butun umrini raqobatchilar bilan quvib o'tishlari mumkin. Mijozga nima kerakligini tezda tushunish va u yoki bu xususiyatni amalga oshirishni rejalashtirish kerak - ko'pincha DevOps ishlashi va kompaniya o'z maqsadiga erishish uchun bu etarli emas. Shuning uchun, birinchi navbatda, Raiffeisenbank DevOps-dan qanday foydalanishni o'rganish kerakligi haqida biznes bilan rozi bo'ldi. Avtomatlashtirish uchun avtomatlashtirish yangi mijozlar uchun kurashda ko'p yordam bermaydi.
Umuman olganda, Misha DevOpsni amalga oshirish kerak deb hisoblaydi, ammo oqilona. Va biz transformatsiya boshida jamoaning unumdorligi pasayib ketishiga, u kamroq pul topishiga, lekin keyin oqlanishiga tayyor bo'lishimiz kerak.
Mango Telecomda testlarni avtomatlashtirish
Tester sifatida men uchun yana bir qiziqarli hisobot Mango Telecom kompaniyasidan Egor Maslov tomonidan taqdim etildi. Taqdimot “SCRUM jamoasida to‘liq sinov siklini avtomatlashtirish” deb nomlangan. Egorning fikricha, DevOps SCRUM uchun maxsus yaratilgan, biroq ayni paytda DevOps-ni SCRUM jamoasiga kiritish juda muammoli. Buning sababi, SCRUM jamoasi har doim bir joyda ishlayotgani, innovatsiyalar bilan chalg'itishga va jarayonni qayta tiklashga vaqt yo'q. Muammo shundaki, SCRUM jamoadagi kichik guruhlarni (sinov guruhi, ishlab chiqish guruhi va boshqalar) ajratishni o'z ichiga olmaydi. Bundan tashqari, mavjud jarayonni avtomatlashtirish uchun hujjatlar kerak bo'ladi va SCRUM-da ko'pincha hujjatlar to'liq yo'q - "mahsulot qandaydir yozishdan muhimroqdir".
SCRUM-ga o'tgandan so'ng, testerlar xususiyatlarni qanday sinab ko'rish haqida ishlab chiquvchilar bilan maslahatlasha boshladilar. Asta-sekin, funksionallik hajmi oshdi, hech qanday hujjat yo'q edi va ular testlar bilan qamrab olinmagan funksionallikdagi ko'plab xatolarni aniqlay boshladilar va umuman, uni kim va qachon sinovdan o'tkazgani noma'lum edi. Bir so'z bilan aytganda - chalkashlik va chalkashlik. Biz sinovlarni avtomatlashtirishga o'tishga qaror qildik. Ammo o'shanda ham to'liq muvaffaqiyatsizlik yuz berdi. Ular autsorsing bo'yicha avtomatlashtirish bo'yicha mutaxassislarni yollashdi, ular ichki sinovchilarga noma'lum stekga yozdilar. Avtotestlar uchun ramka, albatta, ishladi, lekin autsorserlar ketganidan keyin u ikki hafta davom etdi. Keyingi ikkinchi raqamli avtotestni joriy etishga urinish edi. Bu hamma narsani kompaniya ichida, o'zingiz (to'g'ri vektor: ichki tajribani oshirish), SCRUM doirasida qurish va bu jarayonda hujjatlarni yaratish kerakligidan boshlandi. Avtomatlashtirish uchun stek mahsulot stekiga teng bo'lishi kerak (bu erda men uni qo'shyapman, JavaScript loyihangizni boshqa hech narsa bilan sinab ko'rmang). Sprint oxirida ular avtotestning butun jamoa bilan qanday ishlashini namoyish qilishdi (foydali). Shunday qilib, barcha jamoa a'zolarini avtomatlashtirish jarayoniga jalb qilish, shuningdek, avtotestlarga bo'lgan ishonch va ushbu avtotestdan albatta foydalanish imkoniyati oshdi (va doimiy nosozliklar tufayli bir oy ichida izoh berilmaydi).
Aytgancha, DevOpsForum 2019 da ochiq mikrofon bor edi - uzoq vaqtdan beri ma'lum bo'lgan va mening fikrimcha, nutqlarning foydali formati. Siz shu tarzda aylanib yurasiz, hisobotlarni tinglaysiz va keyin konferentsiyada ma'lum bir mavzu yoki muammoni muhokama qilish, muammoni hal qilishda tegishli tajriba almashish arziydi deb qaror qilasiz.
Tashkilotchilar qisqacha hisobotlar oqimini tayyorlaganliklarini ham payqadim. Har bir hisobot 10 daqiqadan ortiq davom etmaydi, undan keyin savollar beriladi. Shunday qilib, siz bir vaqtning o'zida ko'plab mavzularni qamrab olishingiz va sizni qiziqtirgan ma'ruzachilarga savollar berishingiz mumkin.
Taqdimotlar orasida men konferentsiya hamkorlarining stendlarini aylanib chiqdim va ko'p narsalarni o'g'irladim/yutdim. Oh, men tarqatmani yaxshi ko'raman!
Davra suhbati va DevOps muammolari Alfastrakhovanie-dagi rivojlanish direktori bilan
Men uchun DevOpsForum 2019 tortining muzlashi DevOps mutaxassislari ishtirokidagi bir soatlik yalpi majlis bo‘ldi. Seansning to'rtta ishtirokchisi DevOps-ga turli tomonlardan qarashga taklif qilindi: Anton Isanin (Alfastrakhovanie, ishlab chiqish bo'yicha direktor), Nailya Zamashkina (Fintech Lab, operatsion direktor), Oleg Egorkin (Rostelecom, Agile murabbiyi) va Anton Martyanov (mustaqil ekspert, DevOps-ga qaradi. biznes nuqtai nazaridan).
Mutaxassislar odamlarga yaqinroq o'tirishdi va keyin voqealar sodir bo'la boshladi: butun bir soat davomida tinglovchilar ishtirokchilari o'z savollarini berishdi va ekspertlar repni olishdi. Ba'zida haqiqiy bahslar bo'lib o'tdi. Savollar juda xilma-xil edi, masalan: DevOps muhandislari umuman kerakmi, nega ularni tizim ma'murlari sifatida o'qitib bo'lmaydi, DevOps hammaga taklif qilinishi kerakmi, uning qiymati nimada va hokazo.
Keyin men Anton Isanin bilan shaxsan gaplashdim. Biz DevOps madaniyatini har bir uyga olib kirish zarurligini muhokama qildik va DevOps transformatsiyasining qorong'u tomonini ochib berdik.
Tasavvur qilaylik, hamma yig'ilib, DevOps mahsulotga ham, biznes va jamoaga ham kerak degan qarorga keldi. Keling, uni amalga oshirishga boraylik. Hammasi amalga oshdi. Biz nafas chiqardik. DevOps bizni mijozga yaqinlashtirdi, endi biz uning barcha istaklarini tezda bajara olamiz. Natijada, bizda qat'iy qoidalar va talablarga ega bo'lgan katta Operatsiya bo'limi mavjud va u doimo mahsulotdagi kamchiliklarni topadi va ko'plab so'rovlarni yaratadi. Bundan tashqari, mijoz kutilmaganda tugmachani yashil emas, sariq rangga bo'yashni xohlasa ham, barcha kamchiliklarga "shoshilinch" maqomi beriladi. Loyiha o'sib bormoqda, relizlar soni ko'paymoqda va shunga mos ravishda mijozlar tomonidan yangi funksiyalarning kamchiliklari va tushunmovchiliklari soni ortib bormoqda. Ops xatolar haqida xabar berish uchun yana 10 kishini yollaydi va rivojlanish ularni yopish uchun yana 15 kishini yollaydi. Va yangi xususiyatlarni joriy etish o'rniga, jamoa cheksiz SD-lar bilan ishlaydi, foydalanuvchiga funksionallikni tushuntiradi va bir vaqtning o'zida qo'llab-quvvatlaydi. Natijada, Operatsiyalar ham, ishlanmalar ham ishlamoqda, ammo mijoz va biznes baxtsiz: yangi xususiyatlar qotib qoladi. Ma'lum bo'lishicha, DevOps mavjud bo'lib tuyuladi, lekin u mavjud emasga o'xshaydi.
DevOps-ni amalga oshirish zarurligiga kelsak, Anton bu biznesning miqyosiga bevosita bog'liqligini aniq ta'kidladi. Agar yiliga bitta mijozga xizmat ko'rsatish kompaniyaga milliard daromad keltirsa, DevOps kerak emas (agar siz ushbu mijozga muntazam ravishda yangi o'zgarishlar kiritishingiz shart bo'lmasa). Hamma narsa shokolad bilan qoplangan. Ammo agar biznes rivojlansa va ko'proq mijozlar paydo bo'lsa, unda siz rioya qilishingiz kerak. Qoidaga ko'ra, dastlab kompaniyada ajoyib Ops yo'q. Avval biz mahsulotni kesib tashladik va shundan keyingina mahsulot ishlashi uchun biz serverlarni kuzatib borishimiz va ta'minotni kuzatishimiz kerakligini tushunamiz. O'shanda Ops paydo bo'ladi. Shuni tushunish kerakki, Ops alohida bo'linma sifatida rivojlanish uchun bir qator to'siqlarni qo'yishni boshlaydi va barcha etkazib berishlar to'xtab qoladi. Ya'ni, bu holda, DevOps madaniyati allaqachon dolzarbdir, ammo biz uning qorong'u tomonlarini unutmasligimiz kerak.
Manba: www.habr.com