Kompaniyamiz SRE jamoasini ishga tushirish jarayonida. Men bu hikoyaga rivojlanish tomondan keldim. Bu jarayonda men boshqa ishlab chiquvchilar bilan baham ko'rmoqchi bo'lgan fikrlar va tushunchalar bilan chiqdim. Ushbu mulohaza maqolasida men nima sodir bo'layotgani, qanday sodir bo'layotgani va har kim u bilan qanday yashashni davom ettirishi haqida gapiraman.
Ichki tadbirimizdagi chiqishlar asosida yozilgan turkum maqolalar davomi :
2. Infratuzilma kod sifatida. (Siz bu yerdasiz)
3. C# modellari yordamida Typescript shartnomalarini yaratish. (Jarayonda...)
4. Raft konsensus algoritmiga kirish. (Jarayonda...)
...
Biz g'oyalarni amalga oshirgan holda SRE jamoasini yaratishga qaror qildik . Ular o'zlarining ishlab chiquvchilari orasidan dasturchilarni yollashdi va ularni bir necha oyga o'qitishga yuborishdi.
Jamoa quyidagi o'quv vazifalarini oldi:
- Ko'pincha Microsoft Azure-da kod ko'rinishida joylashgan infratuzilmamizni tasvirlab bering (Terraform va uning atrofidagi narsalar).
- Ishlab chiquvchilarga infratuzilma bilan ishlashni o'rgating.
- Ishlab chiquvchilarni vazifaga tayyorlang.
Infratuzilma tushunchasini kod sifatida kiritamiz
Dunyoning odatiy modelida (klassik boshqaruv) infratuzilma haqidagi bilimlar ikki joyda joylashgan:
- Yoki mutaxassislarning boshlarida bilim shaklida.
- Yoki bu ma'lumot ba'zi yozuv mashinkalarida, ularning ba'zilari mutaxassislarga ma'lum. Ammo autsayder (agar butun jamoamiz to'satdan vafot etsa) nima va qanday ishlashini aniqlay olishi haqiqat emas. Mashinada juda ko'p ma'lumotlar bo'lishi mumkin: aksessuarlar, cronjobs, qo'rqitish (qarang. ) disk va nima sodir bo'lishining cheksiz ro'yxati. Haqiqatan ham nima bo'layotganini tushunish qiyin.
Ikkala holatda ham biz o'zimizni qaram bo'lib qolamiz:
- yoki o'limga duchor bo'lgan, kasallikka duchor bo'lgan, sevib qolgan, kayfiyatning o'zgarishi va oddiygina ishdan bo'shatilgan odamdan;
- yoki jismoniy ishlaydigan mashinadan, u ham tushadi, o'g'irlanadi va kutilmagan hodisalar va noqulayliklar keltiradi.
O'z-o'zidan ma'lumki, ideal holda hamma narsa inson tomonidan o'qiladigan, saqlanishi mumkin bo'lgan, yaxshi yozilgan kodga tarjima qilinishi kerak.
Shunday qilib, kod sifatida infratuzilma (Incfastructure as Code - IaC) kod ko'rinishidagi barcha mavjud infratuzilmaning tavsifi, shuningdek, u bilan ishlash va undan real infratuzilmani amalga oshirish uchun tegishli vositalardir.
Nima uchun hamma narsani kodga tarjima qilish kerak?Odamlar mashina emas. Ular hamma narsani eslay olmaydilar. Inson va mashinaning reaktsiyasi boshqacha. Avtomatlashtirilgan har qanday narsa inson tomonidan amalga oshirilgan har qanday narsadan tezroq. Eng muhimi, haqiqatning yagona manbai.
Yangi SRE muhandislari qayerdan keladi?Shunday qilib, biz yangi SRE muhandislarini yollashga qaror qildik, ammo ularni qaerdan olish kerak? To'g'ri javoblar bilan kitob () bizga aytadi: ishlab chiquvchilardan. Axir, ular kod bilan ishlaydi va siz ideal holatga erishasiz.
Biz ularni kompaniyamizdan tashqaridagi kadrlar bozorida uzoq vaqt qidirdik. Lekin tan olishimiz kerakki, biz so'rovlarimizga mos keladiganini topa olmadik. Men o'z xalqim orasida izlashga majbur bo'ldim.
Muammolar Infratuzilma kod sifatida
Endi infratuzilmani kodga qattiq kodlash misollarini ko'rib chiqamiz. Kod yaxshi yozilgan, yuqori sifatli, sharhlar va chekinishlar bilan.
Terraforma dan namuna kodi.
Ansible'dan namuna kodi.
Janoblar, agar bu juda oddiy bo'lsa! Biz haqiqiy dunyodamiz va u har doim sizni ajablantirishga, kutilmagan hodisalar va muammolarni taqdim etishga tayyor. Bu erda ham ularsiz qilolmayman.
1. Birinchi muammo shundaki, ko'p hollarda IaC qandaydir dsl hisoblanadi.
Va DSL, o'z navbatida, strukturaning tavsifi. Aniqroq qilib aytadigan bo'lsak, sizda nima bo'lishi kerak: Json, Yaml, o'z dsl bilan kelgan ba'zi yirik kompaniyalarning modifikatsiyalari (HCL terraformda ishlatiladi).
Muammo shundaki, u osonlikcha bunday tanish narsalarni o'z ichiga olmaydi:
- o'zgaruvchilar;
- shartlar;
- biror joyda izohlar yo'q, masalan, Jsonda, sukut bo'yicha ular taqdim etilmaydi;
- funktsiyalari;
- va men hatto sinflar, meros va boshqa narsalar kabi yuqori darajadagi narsalar haqida gapirmayapman.
2. Bunday kodning ikkinchi muammosi shundaki, u ko'pincha heterojen muhitdir. Odatda siz C# bilan o'tirib ishlaysiz, ya'ni. bitta til, bitta stek, bitta ekotizim bilan. Va bu erda sizda juda ko'p turli xil texnologiyalar mavjud.
Python bilan bash Json kiritilgan jarayonni ishga tushirganda, bu juda real holat. Siz uni tahlil qilasiz, keyin boshqa generator yana 30 ta fayl ishlab chiqaradi. Bularning barchasi uchun kirish o'zgaruvchilari Azure Key Vault'dan olinadi, ular Go'da yozilgan drone.io uchun plagin orqali birlashtiriladi va bu o'zgaruvchilar jsonnet shablon mexanizmidan yaratish natijasida yaratilgan yaml orqali o'tadi. Sizda shunday xilma-xil muhit mavjud bo'lganda, aniq tavsiflangan kodga ega bo'lish juda qiyin.
Bitta vazifa doirasidagi an'anaviy rivojlanish bir til bilan birga keladi. Bu erda biz juda ko'p tillar bilan ishlaymiz.
3. Uchinchi muammo - sozlash. Biz uchun hamma narsani qiladigan muharrirlarni (Ms Visual Studio, Jetbrains Rider) sovutishga odatlanganmiz. Va biz ahmoq bo'lsak ham, ular bizni noto'g'ri deb aytishadi. Bu normal va tabiiy ko'rinadi.
Ammo yaqin joyda VSCode mavjud bo'lib, unda qandaydir tarzda o'rnatilgan, qo'llab-quvvatlanadigan yoki qo'llab-quvvatlanmaydigan ba'zi plaginlar mavjud. Yangi versiyalar chiqdi va qo'llab-quvvatlanmadi. Funktsiyani amalga oshirishga oddiy o'tish (hatto u mavjud bo'lsa ham) murakkab va ahamiyatsiz muammoga aylanadi. O'zgaruvchining oddiy nomini o'zgartirish - o'nlab fayllar loyihasida takrorlash. Agar u sizga kerak bo'lgan narsalarni joylashtirsa, siz omadli bo'lasiz. Albatta, bu erda va u erda orqa yorug'lik bor, avtomatik to'ldirish bor, qaerdadir formatlash mavjud (garchi bu men uchun Windows-da terraformda ishlamasa ham).
Ushbu yozish paytida 0.12 versiyasini qo'llab-quvvatlash uchun hali chiqarilmagan, garchi u 3 oy davomida chiqarilgan bo'lsa ham.
Unutish vaqti keldi...
- Nosozliklarni tuzatish.
- Refaktoring vositasi.
- Avtomatik yakunlash.
- Kompilyatsiya paytida xatolarni aniqlash.
Bu kulgili, lekin bu ham rivojlanish vaqtini oshiradi va muqarrar ravishda yuzaga keladigan xatolar sonini oshiradi.
Eng yomoni shundaki, biz qanday qilib loyihalashtirish, fayllarni papkalarga ajratish, parchalash, kodni saqlash, o'qish va hokazolar haqida emas, balki bu buyruqni qanday qilib to'g'ri yozishim haqida o'ylashga majburmiz, chunki men uni qandaydir tarzda noto'g'ri yozganman. .
Yangi boshlovchi sifatida siz terraformalarni o'rganishga harakat qilyapsiz va IDE sizga umuman yordam bermayapti. Hujjatlar bo'lsa, ichkariga kiring va qarang. Ammo agar siz yangi dasturlash tiliga kirayotgan bo'lsangiz, IDE sizga bunday tur borligini aytadi, lekin bunday narsa yo'q. Hech bo'lmaganda int yoki string darajasida. Bu ko'pincha foydalidir.
Sinovlar haqida nima deyish mumkin?
Siz so'raysiz: "Testlar haqida nima deyish mumkin, janob dasturchilar?" Jiddiy yigitlar hamma narsani ishlab chiqarishda sinab ko'rishadi va bu juda qiyin. Veb-saytdagi terraform moduli uchun birlik testiga misol .
Ularda yaxshi hujjatlar bor. Menga Microsoft har doim hujjatlashtirish va o'qitishga bo'lgan yondashuvi uchun yoqdi. Ammo bu mukammal kod emasligini tushunish uchun siz Bob amaki bo'lishingiz shart emas. O'ngdagi tasdiqlashga e'tibor bering.
Birlik testidagi muammo shundaki, siz va men Json chiqishining to'g'riligini tekshirishimiz mumkin. Menga 5 ta parametr tashladim va 2000 ta chiziqli Json oyoq kiyimi berildi. Men bu erda nima bo'layotganini tahlil qila olaman, test natijasini tasdiqlay olaman ...
Go'da Jsonni tahlil qilish qiyin. Go'da yozishingiz kerak, chunki Go'da terraform siz yozayotgan tilda test qilish uchun yaxshi amaliyotdir. Kodning tashkil etilishi juda zaif. Shu bilan birga, bu sinov uchun eng yaxshi kutubxona.
Microsoft o'zi o'z modullarini yozadi va ularni shu tarzda sinab ko'radi. Albatta, bu ochiq manba. Siz haqingizda gapirayotgan hamma narsa kelib tuzatishingiz mumkin. Men o'tirib, bir hafta ichida hamma narsani tuzatishim mumkin, ochiq kodli VS kod plaginlari, terraformlar, chavandoz uchun plagin qilishim mumkin. Ehtimol, bir nechta analizatorlar yozing, linterlarni qo'shing, sinov uchun kutubxonaga hissa qo'shing. Men hamma narsani qila olaman. Lekin bu men qilishim kerak bo'lgan narsa emas.
Eng yaxshi amaliyotlar Infratuzilma kod sifatida
Keling, davom etaylik. Agar IaCda testlar bo'lmasa, IDE va sozlash yomon bo'lsa, unda hech bo'lmaganda eng yaxshi amaliyotlar bo'lishi kerak. Men hozirgina Google Analytics-ga bordim va ikkita qidiruv so'rovini solishtirdim: Terraformning eng yaxshi amaliyotlari va C# eng yaxshi amaliyotlari.
Biz nimani ko'ramiz? Shafqatsiz statistika bizning foydamizga emas. Materiallar miqdori bir xil. C# ni ishlab chiqishda biz shunchaki materiallar bilan to'lib-toshganmiz, bizda eng yaxshi amaliyotlar mavjud, mutaxassislar tomonidan yozilgan kitoblar, shuningdek, ushbu kitoblarni tanqid qiluvchi boshqa mutaxassislar tomonidan yozilgan kitoblar mavjud. Rasmiy hujjatlar, maqolalar, o'quv kurslari dengizi va endi ochiq manbalarni ishlab chiqish.
IaC so'roviga kelsak: bu erda siz yuqori yuklanish yoki HashiConf hisobotlaridan, rasmiy hujjatlardan va Github'dagi ko'plab muammolardan ma'lumotlarni asta-sekin yig'ishga harakat qilyapsiz. Umuman olganda, ushbu modullarni qanday tarqatish kerak, ular bilan nima qilish kerak? Bu haqiqiy muammoga o'xshaydi... Jamiyat bor, janoblar, u erda har qanday savol uchun Github-da sizga 10 ta sharh beriladi. Lekin bu aniq emas.
Afsuski, hozirgi vaqtda mutaxassislar endigina paydo bo'la boshladilar. Hozircha ularning soni juda oz. Jamiyatning o‘zi esa ibtidoiy darajada osilib turibdi.
Bularning barchasi qayerga ketmoqda va nima qilish kerak
Siz hamma narsani tashlab, C# ga, chavandoz dunyosiga qaytishingiz mumkin. Lekin yoq. Agar yechim topa olmasangiz, nega buni qilish bilan bezovta qilasiz? Quyida men sub'ektiv xulosalarimni keltiraman. Izohlarda men bilan bahslashishingiz mumkin, bu qiziqarli bo'ladi.
Shaxsan men bir nechta narsalarga pul tikaman:
- Bu sohada rivojlanish juda tez sodir bo'lmoqda. Mana DevOps uchun so'rovlar jadvali.
Mavzu shov-shuv bo'lishi mumkin, ammo bu sohaning o'sib borayotganining o'zi umid uyg'otadi.Agar biror narsa juda tez o'ssa, unda nima qilish kerakligini va nima qilmaslik kerakligini aytadigan aqlli odamlar paydo bo'ladi. Mashhurlikning oshishi, ehtimol, kimdir vscode uchun jsonnet plaginini nihoyat qo'shishga ulgurishiga olib keladi, bu sizga ctrl+shift+f orqali qidirish o'rniga, funksiyani amalga oshirishga o'tish imkonini beradi. Narsalar rivojlanishi bilan ko'proq materiallar paydo bo'ladi. Google'dan SRE haqidagi kitobning chiqarilishi bunga yorqin misoldir.
- An'anaviy rivojlanishda biz bu erda muvaffaqiyatli qo'llashimiz mumkin bo'lgan ishlab chiqilgan texnika va amaliyotlar mavjud. Ha, sinovlar va turli xil muhit, asboblar etarli emas, ammo foydali va foydali bo'lishi mumkin bo'lgan juda ko'p amaliyotlar to'plangan.
Arzimas misol: juft dasturlash orqali hamkorlik. Buni aniqlashga ko'p yordam beradi. Yaqin atrofda biror narsani tushunishga harakat qilayotgan qo'shningiz bo'lsa, birgalikda yaxshiroq tushunasiz.
Refaktoring qanday amalga oshirilishini tushunish, hatto bunday vaziyatda ham uni amalga oshirishga yordam beradi. Ya'ni, siz bir vaqtning o'zida hamma narsani o'zgartira olmaysiz, lekin nomni o'zgartiring, keyin joyni o'zgartiring, keyin siz ba'zi bir qismini ajratib ko'rsatishingiz mumkin, oh, lekin bu erda sharhlar etarli emas.
xulosa
Mening mulohazalarim pessimistik bo'lib tuyulishiga qaramay, men kelajakka umid bilan qarayman va hamma narsa biz (va siz) uchun yaxshi bo'lishini chin dildan umid qilaman.
Keyingi maqolaning ikkinchi qismi tayyorlanmoqda. Unda men o‘quv jarayonimizni yaxshilash va infratuzilma bilan ishlash uchun agile rivojlanish amaliyotlaridan qanday foydalanishga harakat qilganimiz haqida gapirib beraman.
Manba: www.habr.com