DevOps ta'rifi juda murakkab, shuning uchun biz har safar bu haqda muhokamani qaytadan boshlashimiz kerak. Faqat Habré-da ushbu mavzu bo'yicha minglab nashrlar mavjud. Ammo agar siz buni o'qiyotgan bo'lsangiz, DevOps nima ekanligini bilasiz. Chunki men emasman. Salom mening ismim Aleksandr Titov (@) va biz DevOps haqida gaplashamiz va men o'z tajribam bilan o'rtoqlashaman.
Men o'z hikoyamni qanday foydali qilish haqida uzoq vaqtdan beri o'yladim, shuning uchun bu erda juda ko'p savollar bo'ladi - men o'zimga va kompaniyamiz mijozlariga so'raganlarim. Ushbu savollarga javob berish orqali tushunish yaxshilanadi. Men sizga DevOps nima uchun mening nuqtai nazarimdan kerakligini, yana, mening nuqtai nazarimdan nima ekanligini va yana DevOpsga o'tayotganingizni mening nuqtai nazarimdan qanday tushunish kerakligini aytaman. Oxirgi nuqta savollar orqali bo'ladi. Ularga o'zingiz javob berib, kompaniyangiz DevOpsga o'tyaptimi yoki qandaydir muammolar bor-yo'qligini tushunishingiz mumkin.
Bir vaqtlar men qo'shilish va sotib olish to'lqinlarida yurgan edim. Birinchidan, men Qik deb nomlangan kichik startapda ishladim, keyin uni Skype deb nomlangan biroz kattaroq kompaniya sotib oldi, keyin esa Microsoft deb nomlangan biroz kattaroq kompaniya sotib oldi. O'sha paytda men DevOps g'oyasi turli o'lchamdagi kompaniyalarda qanday o'zgarganini ko'ra boshladim. Shundan so'ng men DevOps-ga bozor nuqtai nazaridan qarashga qiziqib qoldim va men hamkasblarim bilan Express 42 kompaniyasiga asos soldik. Mana 6 yildan beri biz bozor to'lqinlari bo'ylab harakatlanmoqdamiz.
Boshqa narsalar qatorida, men DevOps Moskva hamjamiyatining tashkilotchilaridan biri va DevOps-Days 2017 tashkilotchisiman, lekin men 2018 yilni tashkil qilmadim. Express 42 ko'plab kompaniyalar bilan ishlaydi. Biz u erda DevOps-ni o'stiramiz, bu qanday sodir bo'lishini kuzatamiz, xulosalar chiqaramiz, tahlil qilamiz, o'z xulosalarimizni hammaga aytamiz va odamlarni DevOps amaliyotiga o'rgatamiz. Umuman olganda, biz bu boradagi tajriba va tajribamizni oshirish uchun qo‘limizdan kelganini qilmoqdamiz.
Nima uchun DevOps
Hammani va har doim o'ylaydigan birinchi savol - nima uchun? Ko'pchilik DevOps bu shunchaki avtomatlashtirish yoki har bir kompaniyada mavjud bo'lgan shunga o'xshash narsa deb o'ylaydi.
— Bizda uzluksiz integratsiya bor edi - bu bizda allaqachon DevOps borligini anglatadi va bularning barchasi nima uchun kerak? Chet elda mazza qilishyapti, lekin ishlashimizga xalaqit berishyapti!
Jamiyat va metodologiyaning 9 yillik rivojlanishi davomida bu hali ham marketing porlashi emasligi aniq bo'ldi, ammo nima uchun bu kerakligi hali ham aniq emas. Har qanday vosita va jarayon singari, DevOps ham oxir-oqibat erishadigan aniq maqsadlarga ega.
Bularning barchasi dunyoning o'zgarib borayotgani bilan bog'liq. U korporativ yondashuvdan uzoqlashadi, kompaniyalar to'g'ridan-to'g'ri orzu sari harakat qilganda, bizning Sankt-Peterburg klassikimiz kuylaganidek, A nuqtadan B nuqtaga ma'lum strategiya bo'yicha, buning uchun qurilgan ma'lum bir tuzilma bilan.
Aslida, IT-dagi hamma narsa shu yondashuvga muvofiq qurilishi kerak. Bu erda IT faqat jarayonlarni avtomatlashtirish uchun ishlatiladi.
Avtomatlashtirish tez-tez o'zgarmaydi, chunki kompaniya yaxshi bosib o'tgan yo'ldan tushganida, nimani o'zgartirish kerak? U ishlaydi - unga tegmang. Endi dunyoda yondashuvlar o'zgarib bormoqda va Agile deb nomlangan yondashuv B so'nggi nuqta darhol ko'rinmasligini ko'rsatadi.
Kompaniya bozordan o'tib, mijoz bilan ishlaganda, u doimiy ravishda bozorni o'rganadi va yakuniy B nuqtasini o'zgartiradi. Bundan tashqari, kompaniya o'z yo'nalishini qanchalik tez-tez o'zgartirsa, oxir-oqibat shunchalik muvaffaqiyatli bo'ladi, chunki u ko'proq bozorni tanlaydi. bo'shliqlar.
Strategiya men yaqinda bilib olgan qiziqarli kompaniya tomonidan namoyish etilgan. One Box Shave - bu qutidagi ustara va soqol uchun aksessuarlarga obuna yetkazib berish xizmati. Ular turli mijozlar uchun o'zlarining "qutilarini" qanday sozlashni bilishadi. Bu ma'lum bir dasturiy ta'minot tomonidan amalga oshiriladi, keyin esa buyurtmani mahsulotni ishlab chiqaradigan Koreya zavodiga yuboradi.
Ushbu mahsulotni Unilever 1 milliard dollarga sotib olgan. Endi u Gillette bilan raqobatlashadi va Amerika bozorida iste'molchilarning katta qismini tortib oldi. One Box Shave deydi:
- 4 ta pichoqmi? Siz jiddiymisiz? Bu nima uchun kerak - bu soqol sifatini yaxshilamaydi. Maxsus tanlangan krem, xushbo'y hid va ikkita pichoqli yuqori sifatli ustara o'sha 4 ta Gillette pichoqlaridan ko'ra ko'proq muammolarni hal qiladi! Tez orada 10 ga yetamizmi?
Dunyo shunday o'zgaradi. Unileverning ta'kidlashicha, ular buni amalga oshirishga imkon beruvchi ajoyib IT tizimiga ega. Oxir-oqibat, bu kontseptsiyaga o'xshaydi Bozorga chiqish vaqti, bu haqda hech kim gapirmagan.
Vaqtdan bozorga chiqishning maqsadi biz qanchalik tez-tez joylashtirishimiz emas. Siz tez-tez joylashtirishingiz mumkin, ammo chiqarish davrlari uzoq bo'ladi. Agar uch oylik ozod qilish tsikllari bir-birining ustiga qo'yilsa, ularni bir haftaga almashtirsa, kompaniya haftada bir marta joylashtirganga o'xshaydi. Va g'oyadan yakuniy amalga oshirishgacha 3 oy davom etadi.
Bozorgacha bo'lgan vaqt - bu g'oyadan yakuniy amalga oshirishgacha bo'lgan vaqtni minimallashtirish.
Bunday holda, dasturiy ta'minot bozor bilan o'zaro ta'sir qiladi. One Box Shave veb-sayti mijoz bilan shunday munosabatda bo'ladi. Ularda sotuvchilar yo'q - faqat tashrif buyuruvchilar bosadigan va istaklarini qoldiradigan veb-sayt. Shunga ko'ra, yangi narsa doimiy ravishda saytda joylashtirilishi va istaklarga muvofiq yangilanishi kerak. Misol uchun, Janubiy Koreyada ular Rossiyadan farqli ravishda soqol olishadi va ular qarag'ay emas, balki, masalan, sabzi va vanilning hidini yaxshi ko'radilar.
Sayt tarkibini tezda o'zgartirish zarur bo'lganligi sababli, dasturiy ta'minotni ishlab chiqish juda o'zgaradi. Dasturiy ta'minot orqali biz mijoz nimani xohlashini aniqlashimiz kerak. Ilgari biz buni ba'zi aylanma yo'llar orqali, masalan, biznesni boshqarish orqali bilib oldik. Keyin biz uni loyihalashtirdik, IT tizimiga talablarni qo'ydik va hammasi zo'r edi. Endi hamma narsa boshqacha - dasturiy ta'minot jarayonda ishtirok etayotgan har bir kishi, shu jumladan muhandislar tomonidan ishlab chiqilgan, chunki texnik xususiyatlar orqali ular bozor qanday ishlashini o'rganadilar va biznes bilan o'z tushunchalarini baham ko'radilar.
Misol uchun, Qikda biz to'satdan odamlar serverga kontaktlar ro'yxatini yuklashni yoqtirishlarini bilib oldik va ular bizga ilovani taqdim etishdi. Dastlab biz bu haqda o'ylamagan edik. Klassik kompaniyada hamma bu xato deb qaror qilgan bo'lardi, chunki spetsifikatsiya bu ajoyib ishlashi kerakligi haqida aytilmagan va odatda tizzada qo'llaniladi, ular bu xususiyatni o'chirib qo'yishgan va: "Bu hech kimga kerak emas, Eng muhimi, asosiy funksiya ishlaydi." . Texnologiya kompaniyasi esa buni imkoniyat deb biladi va shunga muvofiq dasturiy ta'minotni o'zgartirishni boshlaydi.
1968 yilda uzoqni ko'rgan yigit Melvin Konvey quyidagi fikrni ishlab chiqdi.
Tizimni yaratuvchi tashkilot ushbu tashkilotning aloqa tuzilmasini takrorlaydigan dizayn bilan cheklanadi.
Batafsilroq aytganda, boshqa turdagi tizimlarni ishlab chiqarish uchun siz boshqa turdagi kompaniya ichida aloqa tuzilishiga ega bo'lishingiz kerak. Agar sizning aloqa tuzilmangiz yuqori darajadagi ierarxik bo'lsa, bu sizga juda yuqori vaqt ko'rsatkichini ta'minlaydigan tizimlarni yaratishga imkon bermaydi.
O'qing mumkin . Bu DevOps madaniyati yoki falsafasini tushunish uchun muhim, chunki DevOps-da tubdan o'zgargan yagona narsa - bu jamoalar o'rtasidagi aloqa tuzilishi.
Jarayon nuqtai nazaridan, DevOps-dan oldin barcha bosqichlar: tahlil, ishlab chiqish, sinov, operatsiya chiziqli edi.
DevOps holatida bu jarayonlarning barchasi bir vaqtning o'zida sodir bo'ladi.
Buni amalga oshirishning yagona yo'li - bozorga chiqish vaqti. Qadimgi jarayonda ishlagan odamlar uchun bu qandaydir kosmik va umuman shunday ko'rinadi.
Xo'sh, nima uchun sizga DevOps kerak?
Raqamli mahsulotlarni ishlab chiqish uchun. Agar sizning kompaniyangiz raqamli mahsulotga ega bo'lmasa, DevOps kerak emas - bu juda muhim.
DevOps dasturiy ta'minotni ketma-ket ishlab chiqarish tezligi cheklovlarini yengib chiqadi. Unda barcha jarayonlar bir vaqtning o'zida sodir bo'ladi.
Qiyinchilik kuchayadi. DevOps evangelistlari sizga dasturiy ta'minotni chiqarishni osonlashtirishini aytishganda, bu bema'nilik.
DevOps bilan ishlar yanada murakkablashadi.
Avito stendidagi konferentsiyada siz Docker konteynerini joylashtirish qanday ekanligini ko'rishingiz mumkin edi - bu haqiqiy bo'lmagan vazifa. Qiyinchilik juda qiyin bo'ladi, siz bir vaqtning o'zida ko'plab to'plarni o'ynashingiz kerak.
DevOps kompaniyadagi jarayon va tashkilotni butunlay o'zgartiradi — aniqrog‘i, DevOps emas, balki raqamli mahsulot o‘zgaradi. DevOps-ga kelish uchun siz hali ham bu jarayonni butunlay o'zgartirishingiz kerak.
Mutaxassis uchun savollar
Senda nima bor? Kompaniyada ishlayotgan va mutaxassis sifatida rivojlanayotganingizda o'zingizga savol berishingiz mumkin bo'lgan savollar.
Raqamli mahsulotni yaratish strategiyangiz bormi? Agar mavjud bo'lsa, bu allaqachon yaxshi. Bu sizning kompaniyangiz DevOps tomon harakat qilayotganini anglatadi.
Sizning kompaniyangiz allaqachon raqamli mahsulotni yaratyaptimi? Bu shuni anglatadiki, siz yana bir darajaga ko'tarilishingiz va narsalarni yanada qiziqarli qilishingiz mumkin - yana DevOps nuqtai nazaridan. Men faqat shu nuqtai nazardan gapiryapman.
Sizning kompaniyangiz raqamli mahsulotlar bozorida yetakchilardan birimi? Spotify, Yandex, Uber hozirda texnologik taraqqiyot cho'qqisida turgan kompaniyalardir.
O'zingizga ushbu savollarni bering va agar barcha javoblar yo'q bo'lsa, unda bu kompaniyada DevOps bilan shug'ullanmasligingiz kerak. Agar DevOps mavzusi siz uchun haqiqatan ham qiziq bo'lsa, ehtimol ... boshqa kompaniyaga o'tish kerakmi? Agar sizning kompaniyangiz DevOps-ga kirmoqchi bo'lsa, lekin siz barcha savollarga "Yo'q" deb javob bergan bo'lsangiz, u hech qachon o'zgarmas go'zal karkidonga o'xshaydi.
tashkilot
Aytganimdek, Konvey qonuniga ko'ra, kompaniyaning tashkil etilishi o'zgaradi. Tashkiliy nuqtai nazardan DevOps-ning kompaniya ichiga kirib borishiga nima xalaqit berishidan boshlayman.
"Quduqlar" muammosi
Inglizcha "Silo" so'zi bu erda rus tiliga "yaxshi" deb tarjima qilingan. Bu muammoning mohiyati shundaki jamoalar o'rtasida ma'lumot almashish yo'q. Har bir jamoa navigatsiya qilish uchun umumiy xarita yaratmasdan, o'z tajribasini chuqur o'rganadi.
Qaysidir ma'noda bu menga Moskvaga endigina kelgan va metro xaritasida qanday harakat qilishni hali bilmagan odamni eslatadi. Muskovitlar odatda o'z hududlarini juda yaxshi bilishadi va Moskva bo'ylab ular metro xaritasi yordamida harakat qilishlari mumkin. Moskvaga birinchi marta kelganingizda, sizda bunday mahorat yo'q va siz shunchaki yo'naltirilgansiz.
DevOps ushbu yo'nalishni yo'qotish momentidan o'tishni va barcha bo'limlar umumiy o'zaro ta'sir xaritasini yaratish uchun birgalikda ishlashni taklif qiladi.
Bunga ikki omil to'sqinlik qiladi.
Korporativ boshqaruv tizimining oqibati. U alohida ierarxik "quduqlarda" qurilgan. Masalan, ushbu tizimni qo'llab-quvvatlaydigan kompaniyalarda ma'lum KPI mavjud. Boshqa tomondan, o'z tajribalari chegarasidan tashqariga chiqish va butun tizimni boshqarish qiyin bo'lgan odamning miyasi to'sqinlik qiladi. Bu shunchaki noqulay. Tasavvur qiling-a, siz Bangkok aeroportidasiz - siz tezda yo'l topa olmaysiz. DevOps-da harakat qilish ham qiyin va shuning uchun odamlar u erga borish uchun qo'llanma topishingiz kerakligini aytishadi.
Ammo eng muhimi, DevOps ruhi bilan sug'orilgan, Fauler va boshqa bir qancha kitoblarni o'qigan muhandis uchun "quduqlar" muammosi shundan iboratki, "quduqlar" sizga "ravshan" narsalarni qilishga ruxsat bermaydi. Biz DevOps Moscowdan keyin tez-tez birga bo'lamiz, bir-birimiz bilan gaplashamiz va odamlar shikoyat qiladilar:
— Biz shunchaki CI-ni ishga tushirmoqchi edik, ammo ma'lum bo'lishicha, menejmentga bunga ehtiyoj yo'q edi.
Bu aniq, chunki sodir bo'ladi CI и Uzluksiz yetkazib berish jarayoni ko'plab imtihonlar chegarasida. Shunchaki tashkiliy darajadagi "quduqlar" muammosini yengmasdan turib, nima qilsangiz ham, qanchalik qayg'uli bo'lishingizdan qat'i nazar, oldinga siljiy olmaysiz.
Kompaniyadagi jarayonning har bir ishtirokchisi: backend va frontend ishlab chiquvchilari, test, DBA, operatsiya, tarmoq, o'z yo'nalishi bo'yicha qazishadi va menejerdan boshqa hech kimning umumiy xaritasi yo'q, u qandaydir tarzda ularni kuzatib boradi va ularni "bo'lish" yordamida boshqaradi. va zabt et” usuli.
Odamlar ba'zi yulduzlar yoki bayroqlar uchun kurashmoqda, har kim o'z tajribasini qazmoqda.
Natijada, bularning barchasini bir-biriga ulash va umumiy quvur qurish vazifasi tug'ilganda va yulduzlar va bayroqlar uchun kurashishning hojati qolmaganida, savol tug'iladi - baribir nima qilish kerak? Biz qandaydir tarzda kelishuvga erishishimiz kerak, lekin buni maktabda hech kim bizga o'rgatmagan. Bizni maktabdan beri o'rgatishdi: sakkizinchi sinf - voy! - ettinchi sinf bilan solishtirganda! Bu yerda ham xuddi shunday.
Sizning kompaniyangizda ham shundaymi?
Buni tekshirish uchun o'zingizga quyidagi savollarni berishingiz mumkin.
Jamoalar umumiy vositalardan foydalanadimi va o'sha umumiy vositalarni o'zgartirishga hissa qo'shadimi?
Jamoalar qanchalik tez-tez qayta tashkil etiladi - bir jamoaning ba'zi mutaxassislari boshqa jamoaga o'tadi? DevOps muhitida bu odatiy holga aylanadi, chunki ba'zida odam boshqa mutaxassislik sohasi nima qilayotganini tushunolmaydi. U boshqa bo'limga o'tadi, o'zi uchun yo'nalish va ushbu bo'lim bilan o'zaro aloqalar xaritasini yaratish uchun u erda ikki hafta ishlaydi.
O'zgarishlar qo'mitasini tuzib, narsalarni o'zgartirish mumkinmi? Yoki buning uchun eng yuqori boshqaruv va yo'nalishning kuchli qo'li kerakmi? Men yaqinda Facebookda bir kam taniqli bank qanday qilib buyurtmalar orqali vositalarni amalga oshirayotganini yozdim: biz buyurtma yozamiz, uni bir yil davomida bajaramiz va nima bo'lishini ko'ramiz. Bu, albatta, uzoq va qayg'uli.
Menejerlar uchun kompaniya yutuqlarini hisobga olmasdan shaxsiy yutuqlarni olish qanchalik muhim?
Agar siz ushbu savollarga o'zingiz javob bersangiz, kompaniyangizda bunday muammo bor yoki yo'qligi aniqroq bo'ladi.
Infratuzilma kod sifatida
Ushbu muammoni hal qilgandan so'ng, DevOps-da oldinga siljish qiyin bo'lgan birinchi muhim amaliyot kod sifatida infratuzilma.
Ko'pincha infratuzilma kod sifatida quyidagicha qabul qilinadi:
— Keling, hamma narsani bash-da avtomatlashtiraylik, administratorlar qo'lda ishlamasligi uchun o'zimizni skriptlar bilan yopamiz!
Ammo bu unday emas.
Kod sifatida infratuzilma siz ishlayotgan AT tizimini uning holatini doimiy ravishda tushunish uchun kod shaklida tasvirlashingizni anglatadi.
Boshqa jamoalar bilan birgalikda siz hamma tushuna oladigan va navigatsiya va navigatsiya qila oladigan kod ko'rinishida xarita yaratasiz. Bu nimada qilinganligi muhim emas - Chef, Ansible, Salt yoki Kubernetes-da YAML fayllaridan foydalanish - farq yo'q.
Anjumanda 2GIS hamkasbi alohida tizimlarning tuzilishini tavsiflovchi Kubernetes uchun o'zlarining ichki narsalarini qanday yasaganliklarini aytib berdi. 500 ta tizimni tavsiflash uchun ularga ushbu tavsifni yaratuvchi alohida vosita kerak edi. Ushbu tavsif mavjud bo'lganda, har bir kishi bir-biri bilan tekshirishi, o'zgarishlarni kuzatishi, uni qanday o'zgartirishi va yaxshilashi mumkin, nima etishmayotgan.
Qabul qilaman, individual bash skriptlari odatda bu tushunchani ta'minlamaydi. Men ishlagan kompaniyalardan birida hatto "faqat yozish" skriptining nomi ham bor edi - skript yozilganda, lekin endi uni o'qish mumkin emas. Menimcha, bu sizga ham tanish.
Infratuzilma kod kabi infratuzilmaning joriy holatini tavsiflovchi kod. Ko'pgina mahsulot, infratuzilma va xizmat ko'rsatish guruhlari ushbu kod ustida birgalikda ishlaydi va eng muhimi, ularning barchasi ushbu kod qanday ishlashini tushunishlari kerak.
Kod eng yaxshi kod amaliyotlariga muvofiq saqlanadi: birgalikda ishlab chiqish, kodni ko'rib chiqish, XP-dasturlash, test qilish, tortish so'rovlari, kod infratuzilmalari uchun CI - bularning barchasi mos keladi va foydalanish mumkin.
Kod barcha muhandislar uchun umumiy tilga aylanadi.
Koddagi infratuzilmani o'zgartirish ko'p vaqtni talab qilmaydi. Ha, infratuzilma kodida texnik qarz ham bo'lishi mumkin. Odatda jamoalar spagetti kodi kabi yozadigan skriptlar yoki hatto Ansible ko'rinishida "infratuzilmani kod sifatida" amalga oshirishni boshlaganidan bir yarim yil o'tgach duch kelishadi va ular aralashga bash skriptlarini ham tashlaydilar!
Muhim: Agar siz hali bu narsani sinab ko'rmagan bo'lsangiz, buni eslang Ansible bash emas! Hujjatlarni diqqat bilan o'qing, ular bu haqda yozganlarini o'rganing.
Infratuzilma kod sifatida infratuzilma kodini alohida qatlamlarga ajratishdir.
Bizning kompaniyamizda biz 3 ta asosiy qatlamni ajratamiz, ular juda aniq va sodda, ammo ularning soni ko'proq bo'lishi mumkin. Siz infratuzilma kodingizni ko'rib chiqishingiz va sizda bunday holat bor yoki yo'qligini aytishingiz mumkin. Agar qatlamlar ta'kidlanmagan bo'lsa, unda siz biroz vaqt olishingiz va biroz refaktor qilishingiz kerak.
asosiy qatlam - OS, zaxira nusxalari va boshqa past darajadagi narsalar shunday sozlangan, masalan, Kubernetes asosiy darajada qanday joylashtirilgan.
Xizmat darajasi - bular siz ishlab chiquvchiga taqdim etadigan xizmatlar: xizmat sifatida ro'yxatga olish, xizmat sifatida monitoring, xizmat sifatida ma'lumotlar bazasi, xizmat sifatida balanslashtiruvchi, xizmat sifatida navbat, xizmat sifatida uzluksiz yetkazib berish - alohida jamoalar tomonidan taqdim etiladigan xizmatlar to'plami rivojlanishini ta’minlay oladi. Bularning barchasi konfiguratsiyani boshqarish tizimidagi alohida modullarda tasvirlanishi kerak.
Ilovalar amalga oshiriladigan qatlam va oldingi ikki qatlam ustida qanday ochilishini tasvirlaydi.
Nazorat savollari
Sizning kompaniyangiz umumiy infratuzilma omboriga egami? Siz infratuzilmangizdagi texnik qarzlarni boshqarasizmi? Infratuzilma omborida rivojlanish amaliyotlaridan foydalanasizmi? Sizning infratuzilmangiz qatlamlarga bo'linganmi? Base-service-APP diagrammasini tekshirishingiz mumkin. O'zgarish qilish qanchalik qiyin?
Agar siz o'zgartirishlar kiritish uchun bir yarim kun kerak bo'lganini boshdan kechirgan bo'lsangiz, bu sizning texnik qarzingiz borligini va u bilan ishlashingiz kerakligini anglatadi. Siz hozirgina infratuzilma kodingizdagi texnik qarzga duch keldingiz. Ba'zi CCTL-ni o'zgartirish uchun siz infratuzilma kodining yarmini qayta yozishingiz kerak bo'lgan ko'plab voqealarni eslayman, chunki ijodkorlik va hamma narsani avtomatlashtirish istagi hamma joyda hamma narsani korroziyaga olib keldi, barcha tutqichlar olib tashlangan va refaktor qilish zarur.
Uzluksiz yetkazib berish
Keling, debetni kredit bilan taqqoslaylik. Avval infratuzilmaning tavsifi keladi, bu juda oddiy bo'lishi mumkin. Siz hamma narsani batafsil tasvirlab berishingiz shart emas, lekin u bilan ishlashingiz uchun ba'zi bir asosiy tavsif talab qilinadi. Aks holda, keyingi uzluksiz etkazib berish bilan nima qilish kerakligi aniq emas. Ushbu amaliyotlarning barchasi siz DevOps-ga kelganingizda bir vaqtning o'zida paydo bo'ladi, ammo bu sizda nima borligini va uni qanday boshqarishni tushunishdan boshlanadi. Bu infratuzilmaning kod sifatidagi amaliyotidir.
Sizda borligi va uni qanday boshqarish kerakligi ayon bo'lgach, ishlab chiquvchi kodini imkon qadar tezroq ishlab chiqarishga qanday yuborishni aniqlay boshlaysiz. Men ishlab chiquvchi bilan birga aytmoqchiman - biz "quduqlar" muammosi haqida eslaymiz, ya'ni buni alohida odamlar emas, balki jamoa o'ylab topadi.
Biz bilan bo'lganimizda Vanya Evtuxovich birinchi kitobni ko'rgan Jez Humble va mualliflar guruhlari "Doimiy yetkazib berish", 2009 yilda chiqarilgan, biz uning sarlavhasini rus tiliga qanday tarjima qilish haqida uzoq vaqt o'yladik. Ular buni “Doimiy yetkazib berish” deb tarjima qilmoqchi bo‘lishdi, lekin afsuski, “Doimiy yetkazib berish” deb tarjima qilindi. Nazarimda, bizning nomimizda ruscha nimadir bor, bosim bilan.
Doimiy etkazib berish vositalari
Mahsulot omboridagi kod har doim ishlab chiqarishga yuklab olinishi mumkin. U befarq bo'lmasligi mumkin, lekin u doimo bunga tayyor. Shunga ko'ra, siz doimo dum suyagi ostida qandaydir tashvish hissini tushuntirish qiyin bo'lgan kodni yozasiz. Ko'pincha infratuzilma kodini chiqarganingizda paydo bo'ladi. Bu qandaydir tashvish hissi mavjud bo'lishi kerak - bu kodni biroz boshqacha yozishga imkon beruvchi miya jarayonlarini ishga tushiradi. Bu ishlab chiqish ichidagi qoidalarda qayd etilishi kerak.
Doimiy ravishda yetkazib berish uchun sizga infratuzilma platformasida ishlaydigan artefakt formati kerak. Agar siz infratuzilma platformasi bo'ylab turli formatdagi "hayot chiqindilarini" tashlasangiz, u birlashtiriladi, uni saqlash qiyin va texnik qarz muammosi paydo bo'ladi. Artifakt formatini moslashtirish kerak - bu ham jamoaviy vazifa: barchamiz yig'ilib, miyamizni shitirlashimiz va ushbu formatni o'ylab topishimiz kerak.
Artefakt doimiy ravishda takomillashtiriladi va etkazib berish quvuri orqali harakatlanayotganda ishlab chiqarish muhitiga mos ravishda o'zgaradi. Artefakt quvur bo'ylab harakatlanayotganda, u doimo o'zi uchun noqulay bo'lgan ba'zi narsalarga duch keladi, ular siz ishlab chiqarishga qo'ygan artefakt duch keladigan narsaga o'xshaydi. Agar klassik ishlab chiqishda buni ishlab chiqarishni amalga oshiradigan tizim ma'muri amalga oshirsa, DevOps jarayonida bu har doim sodir bo'ladi: bu erda ular uni ba'zi testlar bilan sinab ko'rishdi, bu erda uni Kubernetes klasteriga tashlashdi, bu ko'proq yoki kamroq o'xshash. ishlab chiqarishga, keyin birdan ular yuk sinovini boshladilar.
Bu biroz Pac-Man o'yinini eslatadi - artefakt qandaydir hikoyadan o'tadi. Shu bilan birga, kod haqiqatan ham hikoyadan o'tadimi yoki yo'qmi va u qandaydir tarzda ishlab chiqarishingiz bilan bog'liqmi yoki yo'qligini nazorat qilish muhimdir. Ishlab chiqarishdagi hikoyalarni Uzluksiz yetkazib berish jarayoniga tortish mumkin: biror narsa tushib qolganda shunday bo'lgan, endi ushbu stsenariyni tizim ichida dasturlashtiramiz. Har safar kod ushbu stsenariydan o'tadi va keyingi safar bu muammoga duch kelmaysiz. Siz bu haqda mijozingizga kelganidan ancha oldin bilib olasiz.
Turli xil joylashtirish strategiyalari. Misol uchun, siz kodni turli mijozlarda turlicha sinab ko'rish, kod qanday ishlashi haqida ma'lumot olish va 100 million foydalanuvchiga tarqatilganidan ancha oldinroq bo'lish uchun AB testi yoki kanareykalarni joylashtirishdan foydalanasiz.
"Izchil ravishda yetkazib berish" shunday ko'rinadi.
Etkazib berish jarayoni Dev, CI, Test, PreProd, Prod alohida muhit emas, bu sizning artefaktingiz o'tadigan o'tga chidamli summaga ega bosqichlar yoki stantsiyalar.
Agar sizda asosiy xizmat ilovasi sifatida tavsiflangan infratuzilma kodingiz bo'lsa, u yordam beradi barcha skriptlarni unutmang, va ularni ushbu artefakt uchun kod sifatida yozing, artefaktni targ'ib qilish va ketayotganda uni o'zgartiring.
O'z-o'zini tekshirish uchun savollar
95% hollarda xususiyat tavsifidan ishlab chiqarishga qadar vaqt bir haftadan kammi? Quvurning har bir bosqichida artefaktning sifati yaxshilanadimi? Uning boshidan o'tgan hikoya bormi? Turli tarqatish strategiyalaridan foydalanasizmi?
Agar barcha javoblar ha bo'lsa, demak siz juda zo'rsiz! Javoblaringizni sharhlarda yozing - men xursand bo'laman).
qayta aloqa
Bu eng qiyin amaliyotdir. DevOpsConf konferentsiyasida Infobip kompaniyasining hamkasbi bu haqda gapirar ekan, o'z so'zlarida biroz chalkashdi, chunki bu haqiqatan ham hamma narsani kuzatishingiz kerakligi haqida juda murakkab amaliyot!
Misol uchun, uzoq vaqt oldin, men Qikda ishlaganimda va biz hamma narsani kuzatishimiz kerakligini angladik. Biz buni qildik va hozirda Zabbixda 150 000 ta mahsulotimiz bor, ular doimiy ravishda nazorat qilinadi. Bu qo'rqinchli edi, texnik direktor barmog'ini chakkasiga burdi:
- Bolalar, nega noaniq narsa bilan serverni zo'rlayapsiz?
Ammo keyin bu haqiqatan ham juda ajoyib strategiya ekanligini ko'rsatadigan voqea sodir bo'ldi.
Xizmatlardan biri doimiy ravishda ishdan chiqa boshladi. Dastlab, u qulab tushmadi, bu qiziq, u erda kod qo'shilmagan, chunki u deyarli hech qanday biznes funksiyasiga ega bo'lmagan asosiy broker edi - u shunchaki alohida xizmatlar o'rtasida xabarlar yubordi. Xizmat 4 oy davomida o'zgarmadi va to'satdan "Segmentatsiya xatosi" xatosi bilan ishlamay boshladi.
Biz hayratda qoldik, Zabbix-da jadvallarimizni ochdik va ma'lum bo'ldiki, bir yarim hafta oldin ushbu broker foydalanadigan API xizmatidagi so'rovlar harakati sezilarli darajada o'zgargan. Keyinchalik ma'lum turdagi xabarlarni yuborish chastotasi o'zgarganini ko'rdik. Keyinchalik bular android mijozlari ekanligini bilib oldik. Biz so'radik:
- Bolalar, bir yarim hafta oldin sizga nima bo'ldi?
Bunga javoban biz ular foydalanuvchi interfeysini qanday qayta ishlab chiqqani haqida qiziqarli voqeani eshitdik. Hech kim darhol HTTP kutubxonasini o'zgartirganligini aytishi dargumon. Android mijozlari uchun bu hammomdagi sovunni almashtirishga o'xshaydi - ular shunchaki eslamaydilar. Natijada, 40 daqiqalik suhbatdan so'ng, ular HTTP kutubxonasini o'zgartirganligini va uning standart vaqtlari o'zgarganligini bilib oldik. Bu API serveridagi trafik harakatining o'zgarishiga olib keldi, bu esa broker ichida poygaga sabab bo'lgan vaziyatga olib keldi va u ishdan chiqa boshladi.
Chuqur kuzatuvsiz buni ochish umuman mumkin emas. Agar tashkilotda hali ham "quduqlar" muammosi mavjud bo'lsa, hamma bir-biriga pul tashlaganida, bu yillar davomida yashashi mumkin. Siz shunchaki serverni qayta ishga tushirasiz, chunki muammoni hal qilishning iloji yo'q. Sizda mavjud bo'lgan barcha hodisalarni kuzatganingizda, kuzatib borganingizda, kuzatib borganingizda va monitoringni test sifatida ishlatganingizda - kod yozing va uni qanday kuzatishni darhol ko'rsating, shuningdek kod shaklida (bizda allaqachon kod sifatida infratuzilma mavjud), hamma narsa aniq bo'ladi. kaftida. Hatto bunday murakkab muammolar ham osongina kuzatilishi mumkin.
Ishlab chiqarishda emas, etkazib berish jarayonining har bir bosqichida artefakt bilan nima sodir bo'lishi haqida barcha ma'lumotlarni to'plang.
Monitoringni CI-ga yuklang va ba'zi asosiy narsalar u erda allaqachon ko'rinadi. Keyinchalik siz ularni Test, PredProd va yuk testlarida ko'rasiz. Barcha bosqichlarda ma'lumot to'plang, nafaqat o'lchovlar, statistika, balki jurnallar: dastur qanday paydo bo'lganligi, anomaliyalar - hamma narsani to'plang.
Aks holda, buni aniqlash qiyin bo'ladi. Men DevOps yanada murakkab ekanligini aytdim. Ushbu murakkablikni engish uchun siz oddiy tahlillarga ega bo'lishingiz kerak.
O'z-o'zini nazorat qilish uchun savollar
Sizning monitoringingiz va ro'yxatga olish siz uchun ishlab chiqish vositasimi? Kod yozayotganda, ishlab chiquvchilaringiz, jumladan, siz uni qanday kuzatish haqida o'ylaysizmi?
Mijozlardan muammolar haqida eshitasizmi? Mijozni kuzatish va ro'yxatga olishdan yaxshiroq tushunasizmi? Siz tizimni monitoring va jurnalga yozishdan yaxshiroq tushunasizmi? Tizimdagi tendentsiya o'sib borayotganini ko'rganingiz va yana 3 hafta ichida hamma narsa o'lishini tushunganingiz uchun tizimni o'zgartirasizmi?
Ushbu uchta komponentga ega bo'lganingizdan so'ng, kompaniyangizda qanday infratuzilma platformasi borligi haqida o'ylashingiz mumkin.
Infratuzilma platformasi
Gap shundaki, bu har bir kompaniyada mavjud bo'lgan turli xil vositalar to'plamidir.
Infratuzilma platformasining mohiyati shundaki, barcha jamoalar ushbu vositalardan foydalanadilar va ularni birgalikda ishlab chiqadilar.
Infratuzilma platformasining alohida qismlarini ishlab chiqish uchun mas'ul bo'lgan alohida guruhlar mavjudligi aniq. Shu bilan birga, har bir muhandis infratuzilma platformasining rivojlanishi, ishlashi va targ'iboti uchun javobgardir. Ichki darajada u umumiy vositaga aylanadi.
Barcha jamoalar infratuzilma platformasini ishlab chiqadilar va unga o'zlarining IDE kabi ehtiyotkorlik bilan munosabatda bo'lishadi. IDE-da siz hamma narsani chiroyli va tez qilish uchun turli xil plaginlarni o'rnatasiz va tezkor tugmalarni sozlaysiz. Sublime, Atom yoki Visual Studio Code-ni ochganingizda, kod xatolari paydo bo'ladi va siz umuman ishlashning iloji yo'qligini tushunasiz, darhol xafa bo'lasiz va IDE-ni tuzatishga yugurasiz.
Infratuzilma platformangizga xuddi shunday munosabatda bo'ling. Agar biror narsa noto'g'ri ekanligini tushunsangiz, uni o'zingiz tuzata olmasangiz, so'rov qoldiring. Agar oddiy narsa bo'lsa, uni o'zingiz tahrirlang, tortish so'rovini yuboring, bolalar buni ko'rib chiqadilar va qo'shadilar. Bu ishlab chiquvchining boshidagi muhandislik vositalariga nisbatan biroz boshqacha yondashuv.
Infratuzilma platformasi sifatni doimiy ravishda yaxshilash bilan artefaktni ishlab chiqishdan mijozga o'tkazishni ta'minlaydi. IP ishlab chiqarishda kod bilan sodir bo'ladigan voqealar to'plami bilan dasturlashtirilgan. Rivojlanish yillari davomida bunday hikoyalar juda ko'p, ulardan ba'zilari noyob va faqat sizga tegishli - ularni Google orqali qidirish mumkin emas.
Shu nuqtada, infratuzilma platformasi sizning raqobat ustunligingizga aylanadi, chunki uning ichiga raqobatchining asbobida bo'lmagan narsa o'rnatilgan. Sizning IP qanchalik chuqurroq bo'lsa, bozorga chiqish vaqti bo'yicha raqobatdosh ustunligingiz shunchalik katta bo'ladi. Bu yerda paydo bo'ladi sotuvchini qulflash muammosi: Siz boshqa birovning platformasini qabul qilishingiz mumkin, lekin birovning tajribasidan foydalanib, bu sizga qanchalik tegishli ekanligini tushunolmaysiz. Ha, har bir kompaniya Amazon kabi platformani qura olmaydi. Bu kompaniyaning tajribasi bozordagi mavqeiga mos keladigan qiyin yo'nalishdir va u erda sotuvchi qulfidan foydalana olmaysiz. Bu haqda o'ylash ham muhimdir.
Sxema
Bu DevOps kompaniyasida barcha amaliyot va jarayonlarni sozlashda sizga yordam beradigan infratuzilma platformasining asosiy diagrammasi.
Keling, u nimadan iboratligini ko'rib chiqaylik.
Resurslarni orkestrlash tizimi, bu protsessor, xotira, diskni ilovalar va boshqa xizmatlar bilan ta'minlaydi. Buning ustiga - past darajadagi xizmatlar: monitoring, logging, CI/CD Engine, artefaktni saqlash, tizim kodi sifatida infratuzilma.
Yuqori darajadagi xizmatlar: xizmat sifatida ma'lumotlar bazasi, xizmat sifatida navbatlar, xizmat sifatida yuk balansi, xizmat sifatida tasvir hajmini o'zgartirish, xizmat sifatida Big Data zavodi. Buning ustiga - mijozingizga doimiy ravishda o'zgartiriladigan kodni etkazib beradigan quvur liniyasi.
Sizning dasturiy ta'minotingiz mijoz uchun qanday ishlashi haqida ma'lumot olasiz, uni o'zgartirasiz, ushbu kodni yana taqdim etasiz, ma'lumot olasiz - va shuning uchun siz doimo infratuzilma platformasini va dasturiy ta'minotingizni rivojlantirasiz.
Diagrammada etkazib berish quvur liniyasi ko'p bosqichlardan iborat. Ammo bu misol sifatida keltirilgan sxematik diagramma - uni birma-bir takrorlashning hojati yo'q. Bosqichlar xizmatlar bilan xuddi xizmatlar kabi o'zaro ta'sir qiladi - platformaning har bir g'ishtining o'ziga xos tarixi bor: resurslar qanday taqsimlanadi, dastur qanday ishga tushiriladi, resurslar bilan ishlaydi, nazorat qilinadi va o'zgaradi.
Platformaning har bir qismida hikoya borligini tushunish muhimdir va o'zingizdan bu g'isht qanday hikoyani olib yurganini so'rang, ehtimol uni tashlab yuborish va uchinchi tomon xizmati bilan almashtirish kerak. Misol uchun, g'isht o'rniga Okmetrni o'rnatish mumkinmi? Ehtimol, yigitlar bu tajribani bizdan ko'ra ko'proq rivojlantirgandir. Ammo, ehtimol, yo'q - ehtimol bizda noyob tajriba bor, biz Prometeyni o'rnatishimiz va uni yanada rivojlantirishimiz kerak.
Platformani yaratish
Bu murakkab aloqa jarayoni. Asosiy amaliyotlarga ega bo'lganingizda, siz talablar va standartlarni ishlab chiqadigan turli muhandislar va mutaxassislar o'rtasida muloqotni boshlaysiz va ularni doimiy ravishda turli xil vositalar va yondashuvlarga o'zgartirasiz. Bu erda DevOps-da mavjud bo'lgan madaniyat muhim ahamiyatga ega.
Madaniyat bilan hamma narsa juda oddiy - bu hamkorlik va muloqot haqida, ya'ni bir-biri bilan umumiy sohada ishlash istagi, bitta asbobni birgalikda ishlatish istagi. Bu erda raketa ilmi yo'q - hamma narsa juda oddiy, banal. Misol uchun, hammamiz kiraverishda yashaymiz va uni toza tutamiz - mana shunday madaniyat darajasi.
Senda nima bor?
Shunga qaramay, o'zingizga savol berishingiz mumkin.
Infratuzilma platformasi ajratilganmi? Uning rivojlanishi uchun kim javobgar? Infratuzilma platformangizning raqobatbardosh afzalliklarini tushunasizmi?
Siz doimo o'zingizga bu savollarni berishingiz kerak. Agar biror narsa uchinchi tomon xizmatlariga o'tkazilishi mumkin bo'lsa, uni o'tkazish kerak; agar uchinchi tomon xizmati sizning harakatingizni bloklashni boshlasa, unda siz o'zingiz ichida tizim yaratishingiz kerak.
Shunday qilib, DevOps...
... bu murakkab tizim, unda quyidagilar bo'lishi kerak:
- Raqamli mahsulot.
- Ushbu raqamli mahsulotni ishlab chiqadigan biznes modullari.
- Kod yozadigan mahsulot guruhlari.
- Uzluksiz yetkazib berish amaliyoti.
- Platformalar xizmat sifatida.
- Infratuzilma xizmat sifatida.
- Infratuzilma kod sifatida.
- DevOps-ga o'rnatilgan ishonchlilikni saqlash uchun alohida amaliyotlar.
- Bularning barchasini tasvirlaydigan fikr-mulohaza amaliyoti.
Siz ushbu diagrammadan foydalanishingiz mumkin, unda kompaniyangizda mavjud bo'lgan narsalarni ta'kidlashingiz mumkin: u ishlab chiqilganmi yoki hali ham ishlab chiqilishi kerak.
Bir necha hafta ichida tugaydi . RIT++ ning bir qismi sifatida. Konferentsiyaga keling, u erda siz uzluksiz yetkazib berish, kod sifatida infratuzilma va DevOps transformatsiyasi haqida ko'plab ajoyib hisobotlarni topasiz. , oxirgi narx muddati - 20-may
Manba: www.habr.com