Biz bir vaqtlar bitta ob'ektdagi mijozga elektron hujjat aylanish tizimini yetkazib bergan edik. Va keyin boshqa ob'ektga. Va yana bir. Va to'rtinchi va beshinchisi. Biz shunchalik hayajonlanib ketdikki, biz 10 ta taqsimlangan ob'ektga yetdik. Bu juda kuchli bo'lib chiqdi... ayniqsa, biz o'zgarishlarni yetkazib berishga kelganimizda. Ishlab chiqarish pallasiga etkazib berishning bir qismi sifatida sinov tizimining 5 ta stsenariysi oxir-oqibatda 10 soat va 6-7 xodimni talab qildi. Bunday xarajatlar bizni imkon qadar kamdan-kam hollarda etkazib berishga majbur qildi. Uch yillik faoliyatdan so'ng, biz bunga dosh berolmadik va loyihani bir chimdim DevOps bilan bezashga qaror qildik.
Endi barcha sinovlar 3 soat ichida amalga oshiriladi va unda 3 kishi ishtirok etadi: muhandis va ikkita sinovchi. Yaxshilanishlar raqamlarda aniq ifodalangan va ko'p sevgan TTM ning qisqarishiga olib keladi. Bizning tajribamizga ko'ra, DevOps-dan foyda ko'radigan mijozlar hatto bu haqda biladiganlarga qaraganda ko'proq. Shuning uchun, DevOps-ni odamlarga yaqinlashtirish uchun biz oddiy konstruktorni ishlab chiqdik, biz ushbu postda batafsilroq gaplashamiz.
Endi sizga batafsilroq aytib beraylik. Bitta energetika korxonasi 10 ta yirik ob’ektda texnik hujjat aylanishi tizimini joriy etmoqda. Bunday miqyosdagi loyihalarni DevOpssiz boshqarish oson emas, chunki qo'l mehnatining katta qismi ishni sezilarli darajada kechiktiradi va sifatni pasaytiradi - barcha qo'l ishlari xatolar bilan to'la. Boshqa tomondan, faqat bitta o'rnatish mavjud bo'lgan loyihalar mavjud, ammo hamma narsa avtomatik ravishda, doimiy va muvaffaqiyatsiz ishlashi kerak - masalan, yirik monolit tashkilotlarda bir xil hujjat aylanish tizimlari. Aks holda, kimdir sozlamalarni qo'lda qiladi, joylashtirish bo'yicha ko'rsatmalarni unutadi - va natijada ishlab chiqarishda sozlamalar yo'qoladi va hamma narsa buziladi.
Odatda biz mijoz bilan shartnoma asosida ishlaymiz va bu holda bizning manfaatlarimiz biroz farq qiladi. Buyurtmachi loyihaga qat'iy byudjet va texnik xususiyatlar doirasida qaraydi. Texnik spetsifikatsiyalarga kiritilmagan turli DevOps amaliyotlarining afzalliklarini unga tushuntirish qiyin bo'lishi mumkin. Agar u qo'shimcha biznes qiymatiga ega bo'lgan tezkor nashrlarga yoki avtomatlashtirish quvurini qurishga qiziqsa-chi?
Afsuski, oldindan tasdiqlangan xarajat bilan ishlaganda, bu qiziqish har doim ham topilmaydi. Bizning amaliyotimizda vijdonsiz va beparvo pudratchining rivojlanishini tanlashga majbur bo'lgan holat mavjud edi. Bu dahshatli edi: zamonaviy manba kodlari yo'q edi, bir xil tizimning kod bazasi turli xil o'rnatishlarda boshqacha edi, hujjatlar qisman yo'q edi va qisman dahshatli sifatga ega edi. Albatta, mijozning manba kodi, yig'ish, relizlar va boshqalar ustidan nazorati yo'q edi.
Hozircha DevOps haqida hamma ham bilmaydi, lekin biz uning afzalliklari, real resurslarni tejash haqida gapirishimiz bilanoq, barcha mijozlarning ko'zlari yonib ketadi. Shunday qilib, DevOps-ni o'z ichiga olgan so'rovlar soni vaqt o'tishi bilan ortib bormoqda. Bu erda mijozlar bilan bir xil tilda gaplashish uchun biz biznes muammolari va DevOps amaliyotlarini tezda bog'lashimiz kerak, bu esa mos rivojlanish quvurini yaratishga yordam beradi.
Shunday qilib, bizda bir tomondan bir qator muammolar bor, boshqa tomondan DevOps bilimlari, amaliyotlari va vositalari mavjud. Nima uchun tajribani hamma bilan baham ko'rmaysiz?
DevOps konstruktorini yaratish
Agile o'z manifestiga ega. ITIL o'z metodologiyasiga ega. DevOps unchalik omadli emas - u hali shablon va standartlarga ega emas. Garchi kompaniyalarning etukligini ularning rivojlanishi va operatsion amaliyotini baholash asosida aniqlash.
Yaxshiyamki, 2014 yilda taniqli Gartner kompaniyasi va asosiy DevOps amaliyotlari va ular o'rtasidagi munosabatlarni tahlil qildi. Shunga asoslanib, men infografikani chiqardim:
Biz buni o'zimizga asos qilib oldik . To'rt sohaning har birida asboblar to'plami mavjud - biz ularni ma'lumotlar bazasiga to'pladik, eng ommaboplarini aniqladik, integratsiya nuqtalarini va mos optimallashtirish mexanizmlarini aniqladik. Hammasi bo'lib chiqdi 36 ta amaliyot va 115 ta vosita, ularning to'rtdan bir qismi ochiq manba yoki bepul dasturiy ta'minotdir. Keyinchalik, biz har bir sohada nimaga erishganimiz va misol sifatida, biz postni boshlagan texnik hujjat aylanishini yaratish loyihasida bu qanday amalga oshirilganligi haqida gapiramiz.
Jarayonlar
Mashhur EDMS loyihasida texnik hujjatlarni boshqarish tizimi 10 ta ob'ektning har birida bir xil sxema bo'yicha joylashtirilgan. O'rnatish 4 ta serverni o'z ichiga oladi: ma'lumotlar bazasi serveri, dastur serveri, to'liq matnli indeksatsiya va kontentni boshqarish. O'rnatishda ular bitta tugun ichida ishlaydi va ob'ektlardagi ma'lumotlar markazida joylashgan. Barcha ob'ektlar infratuzilmada bir oz farq qiladi, ammo bu global o'zaro ta'sirga xalaqit bermaydi.
Birinchidan, DevOps amaliyotiga ko'ra, biz infratuzilmani mahalliy darajada avtomatlashtirdik, keyin biz etkazib berishni sinov pallasiga, keyin esa mijozning mahsulotiga keltirdik. Har bir jarayon bosqichma-bosqich ishlab chiqilgan. Atrof-muhit sozlamalari manba kodlari tizimida avtomatik yangilash uchun tarqatish to'plami tuzilganligini hisobga olgan holda o'rnatiladi. Konfiguratsiya o'zgargan taqdirda, muhandislar shunchaki versiyani boshqarish tizimiga tegishli o'zgartirishlarni kiritishlari kerak - va keyin avtomatik yangilanish muammosiz amalga oshiriladi.
Ushbu yondashuv tufayli test jarayoni ancha soddalashtirildi. Ilgari loyihada stendlarni qo‘lda yangilashdan boshqa hech narsa qilmagan sinovchilar bor edi. Endi ular faqat kelishadi, hamma narsa ishlayotganini ko'rishadi va foydaliroq ishlarni qilishadi. Har bir yangilanish avtomatik ravishda sinovdan o'tkaziladi - sirt darajasidan biznes stsenariylarini avtomatlashtirishgacha. Natijalar TestRail-da alohida hisobotlar sifatida joylashtiriladi.
Madaniyat
Uzluksiz tajriba sinov dizayni misolida eng yaxshi tushuntiriladi. Hali mavjud bo'lmagan tizimni sinovdan o'tkazish ijodiy ishdir. Sinov rejasini yozishda siz qanday qilib to'g'ri test qilishni va qaysi filiallarga amal qilishni tushunishingiz kerak. Shuningdek, cheklarning maqbul sonini aniqlash uchun vaqt va byudjet o'rtasidagi muvozanatni toping. Kerakli testlarni aniq tanlash, foydalanuvchi tizim bilan qanday munosabatda bo'lishi haqida o'ylash, atrof-muhit va mumkin bo'lgan tashqi omillarni hisobga olish muhimdir. Doimiy tajribasiz qilish mumkin emas.
Endi o'zaro munosabatlar madaniyati haqida. Ilgari ikkita qarama-qarshi tomon bor edi - muhandislar va ishlab chiquvchilar. Ishlab chiquvchilar shunday dedilar: “Uning qanday ishga tushirilishi bizga qiziq emas. Siz muhandissiz, siz aqllisiz, u nosozliklarsiz ishlashiga ishonch hosil qiling". Muhandislar javob berishdi: “Siz ishlab chiquvchilar juda ehtiyotsizsiz. Ehtiyot bo‘laylik, relizlaringizni kamroq o‘ynaymiz. Chunki siz bizga har safar sizib chiqadigan kodni berganingizda, qanday qilib o'zaro aloqada bo'lish bizga tushunarsiz bo'ladi.". Bu DevOps nuqtai nazaridan boshqacha tuzilgan madaniy o'zaro ta'sir muammosi. Bu erda muhandislar ham, ishlab chiquvchilar ham doimiy o'zgaruvchan, ammo ayni paytda ishonchli dasturiy ta'minotga qaratilgan yagona jamoaning bir qismidir.
Bitta jamoada mutaxassislar bir-biriga yordam berishga qaror qilishadi. Avvalgidek? Misol uchun, taxminan 50 sahifadan iborat qalin joylashtirish ko'rsatmalari tayyorlanayotgan edi.Muhandis uni o'qib chiqdi, hech narsani tushunmadi, la'natladi va ertalab soat uchda ishlab chiquvchidan izoh berishni so'radi. Ishlab chiquvchi izoh berdi va la'natladi - oxirida hech kim xursand bo'lmadi. Bundan tashqari, tabiiyki, ba'zi xatolar bor edi, chunki siz ko'rsatmalarda hamma narsani eslay olmaysiz. Va endi muhandis ishlab chiquvchi bilan birgalikda amaliy dasturiy ta'minot infratuzilmasini avtomatlashtirilgan tarzda joylashtirish uchun skript yozmoqda. Va ular bir-birlari bilan deyarli bir tilda gaplashadilar.
odamlar
Jamoaning kattaligi yangilanish doirasiga qarab belgilanadi. Jamoa yetkazib berishni shakllantirish jarayonida jalb qilinadi, unga umumiy loyiha jamoasidan qiziquvchilar kiradi. Keyin har bir bosqich uchun mas'ul bo'lganlar bilan yangilash rejasi yoziladi va jamoa uning borishi haqida hisobot beradi. Jamoaning barcha a'zolari bir-birini almashtiradilar. Jamoaning bir qismi sifatida bizda zaxira ishlab chiquvchi ham bor, lekin u deyarli hech qachon ulanishi shart emas.
texnologiya
Texnologik diagrammada bir nechta fikrlar ta'kidlangan, ammo ularning ostida bir nechta texnologiyalar mavjud - ularning tavsiflari bilan butun kitobni nashr etishingiz mumkin. Shunday qilib, biz eng qiziqarlilarini ajratib ko'rsatamiz.
Kod sifatida infratuzilma
Endi, ehtimol, bu kontseptsiya hech kimni hayratda qoldirmaydi, lekin ilgari infratuzilmalarning tavsiflari ko'p narsani orzu qilgan edi. , sinov muhitlari noyob edi, ularni qadrlashdi va qadrlashdi, chang zarralari ulardan puflandi.
Bugungi kunda hech kim tajriba qilishdan qo'rqmaydi. Virtual mashinalarning asosiy tasvirlari mavjud, muhitlarni joylashtirish uchun tayyor stsenariylar mavjud. Barcha shablonlar va skriptlar versiyalarni boshqarish tizimida saqlanadi va zudlik bilan yangilanadi. Ilgari, paketni stendga etkazish kerak bo'lganda, konfiguratsiya bo'shlig'i paydo bo'ldi. Endi siz faqat manba kodiga qator qo'shishingiz kerak.
Hujjatlashtirish uchun infratuzilma skriptlari va quvurlariga qo'shimcha ravishda Hujjatlar kod sifatida yondashuvi ham qo'llaniladi. Buning yordamida loyihaga yangi odamlarni ulash, ularni, masalan, test rejasida tasvirlangan funktsiyalar asosida tizim bilan tanishtirish, shuningdek, test holatlarini qayta ishlatish oson.
Doimiy yetkazib berish va monitoring
DevOps haqida, biz uzluksiz yetkazib berish va monitoringni amalga oshirish uchun vositalarni qanday tanlaganimiz haqida gaplashdik. Ko'pincha hech narsani qayta yozishning hojati yo'q - avval yozilgan skriptlardan foydalanish, komponentlar o'rtasida integratsiyani to'g'ri qurish va umumiy boshqaruv konsolini yaratish kifoya. Va barcha jarayonlar bitta tugma yoki jadval yordamida ishga tushirilishi mumkin.
Ingliz tilida “Continuous Delivery” va “Continuous Deployment” tushunchalari mavjud. Ikkalasini ham "doimiy yetkazib berish" deb tarjima qilish mumkin, lekin aslida ular orasida ozgina farq bor. Bizning loyihamizda taqsimlangan energiya kompaniyasining texnik hujjat aylanishi uchun, aksincha, etkazib berish qo'llaniladi - ishlab chiqarish uchun o'rnatish buyruq bo'yicha sodir bo'lganda. Joylashtirishda o'rnatish avtomatik ravishda amalga oshiriladi. Ushbu loyihada Uzluksiz yetkazib berish odatda aylandi DevOps ning markaziy qismi.
Umuman olganda, ma'lum parametrlarni to'plash orqali siz DevOps amaliyotlari nima uchun foydali ekanligini aniq tushunishingiz mumkin. Va buni raqamlarni juda yaxshi ko'radigan rahbariyatga etkazing. Ishga tushirishlarning umumiy soni, skript bosqichlarining bajarilish vaqti, muvaffaqiyatli ishga tushirishlar ulushi - bularning barchasi to'g'ridan-to'g'ri bozorga chiqish uchun har bir kishining sevimli vaqtiga, ya'ni versiyani boshqarish tizimiga kirishdan tortib to versiyani chiqarishgacha bo'lgan vaqtga bevosita ta'sir qiladi. ishlab chiqarish muhiti. Kerakli vositalarni amalga oshirish bilan muhandislar qimmatli ko'rsatkichlarni pochta orqali olishadi va loyiha menejeri ularni asboblar panelida ko'radi. Shu tarzda siz yangi vositalarning afzalliklarini darhol baholashingiz mumkin. Siz DevOps dizayneri yordamida ularni infratuzilmangizda sinab ko'rishingiz mumkin.
Bizning kimga kerak bo'ladi ?
Keling, da'vo qilmaylik: boshidan u biz uchun foydali bo'ldi. Yuqorida aytib o'tganimizdek, siz mijoz bilan bir xil tilda gaplashishingiz kerak va DevOps dizayneri yordamida biz tezda bunday suhbat uchun asosni chizishimiz mumkin. Biznes mutaxassislari o'zlari uchun nima kerakligini baholay oladilar va shu bilan tezroq rivojlanadilar. Biz dizaynerni iloji boricha batafsilroq qilishga harakat qildik, har qanday foydalanuvchi nimani tanlayotganini tushunishi uchun bir nechta tavsiflarni qo'shdik.
Dizaynerning formati kompaniyaning qurilish jarayonlari va avtomatlashtirishdagi mavjud ishlanmalarini hisobga olishga imkon beradi. Agar siz faqat mavjud jarayonlar bilan yaxshi integratsiyalashgan va bo'shliqlarni to'ldirishingiz mumkin bo'lgan echimlarni tanlasangiz, hamma narsani buzib tashlash va uni qayta tiklashning hojati yo'q.
Ehtimol, sizning rivojlanishingiz allaqachon yuqori darajaga ko'tarilgan va bizning vositamiz juda "kapitan" bo'lib tuyuladi. Ammo biz buni o'zimiz uchun foydali deb bilamiz va ba'zi o'quvchilarga foydali bo'lishiga umid qilamiz. Sizga eslatamiz dizaynerga - agar biror narsa bo'lsa, siz diagrammani dastlabki ma'lumotlarni kiritgandan so'ng darhol olasiz. Biz sizning fikr-mulohazalaringiz va qo'shimchalaringiz uchun minnatdor bo'lamiz.
Manba: www.habr.com