MSA sifatni boshqarish CI eshigi orqali chiqarish

1. CIga sifat nazorati tizimini o'rnatish sababi

Men hozirda DevOps muhandisi sifatida bir MSA maslahat xizmatida ishtirok etmoqdaman. Maslahat deganda odatda xizmat chegaralari yoki domen ajratish kabi dizayn bilan bog'liq narsalar ko'z oldimizga keladi, ammo men tutgan soha sifat nazorati tizimida edi. Ushbu maqola o'sha ish haqidagi yozuvdir.

Sifat nazorati deganda kod uslubi, statik tahlil, test qamrovi, tasvir zaiflik skanerlash kabi narsalar ko'z oldingizga keladi. Ushbu narsalar o'z-o'zidan yangilik emas. Aslida qiyin bo'lgan narsa esa "buni qayerda, qanchalik kuchli majburiyat bilan amalga oshirish kerak" edi. MSAda bu savol kutilgandek ancha jiddiy.

Xizmatlarni kichik qismlarga bo'lish, tarqatish birliklarini ham shuncha ko'paytiradi. Kecha bitta bo'lgan tarqatish o‘n yoki yigirma bo‘lakka bo‘linadi va har bir xizmat o‘z dasturiy siklida ishlaydi. Bunday holatda sifat elementini "ilojini qilsak yaxshi bo'ladi" darajasidagi tavsiya qilib qolsak, xizmatlar soni ortishi bilan aniqlanmagan joylarni tutib olishadi. Haqiqatan ham birinchi marta qo'shilganimda aynan shunday holatda edim.

Shuning uchun sifatni boshqarish joyini yana qayta ko'rib chiqdik. Xulosa CI edi.

CI har bir o'zgarish doimo bir marta o'tib ketadigan yo'ldir. Ushbu yo'lda sifat standartlarini eshik sifatida o'rnatganimizda, kim ish qilmasin, qaysi xizmat bo'lmasin, barchasi bir xil standartsiz o'tadi. Odamlarning halolligi emas, balki pipeline standartni ushlab turadigan holatga keladi. Sifatni "saqlash yaxshi"dan "o'ta olmasangiz keyingisi emas" ga o'zgartirish mumkin bo'lgan, eng tabiiy joy shunda edi.

Quyida o'sha nuqtai nazardan sifat elementlarini CI ichida qanday bog'lashingiz haqida gapiraman.

2. Agent kodlash va sifat

Eshik dizayniga kirishdan oldin bir dastlabki shart bor. Hozirgi vaqtda kod yozish usuli tezda o'zgarib bormoqda. Dasturlashning sezilarli qismi AI agentlari bilan amalga oshirilmoqda. Men ushbu o'zgarishni sifat nuqtai nazaridan tahdid emas, imkoniyat qilib ko'rdim.

Test kodi misol sifatida. Avval testni yetarli darajada yozish o'z-o'zidan xarajat bo'lar edi. Qamrovni 80% gacha oshirish uchun chegaraviy shartlar va istisnolarni insonning qo'li bilan yaratish kerak bo'lar edi va bu vaqtni behuda sarflashdan ko'ra asosiy yo'lni bir muammo sifatida yondashish edi. Eng ko'p kechiktirilgan ish esa test edi.

Agentlarni qo'shganda bu nuqta o'zgaradi. Chegara shartlari yoki istisno oqimlarini o'z ichiga olgan testlarni tezda chiqarish mumkin bo'ladi va takrorlanuvchi va zerikarli bo'lgan ishlar hajmi ko'proq ushlab turiladi. Bir vaqt ichida qamrovni yuqoriroq va zichroq olish imkoniyati oshdi. Vositalar yaxshilangani sayin sifatning maqsad chizig'i ham birga ko'tarilishi mumkin.

Shuni aytish kerakki, bu erda bir shart bor. Agent tomonidan yaratilgan kod yoki test bo'ladimi, bularning haqiqatan ham ma'noli tasdiqlanishiga kimdir doimiy ravishda baho berishi kerak. Agar bu bahoni odamlarga topshirib qo'ysak, ishlab chiqarish tezligi oshadi, lekin tasdiq tezligi bu ortda qoladi. Yaratuvchi hajmi oshgan, lekin filtrlovchi qo'l o'zgarmaydi.

Shuning uchun "agent yordamida tezroq, ko'proq ish qilinadi" va "CI eshigi bilan standartni doimiy ravishda majburlaydi" juftlikda bormoqda. Yaratish tezligi oshganda, natijani qabul qiladimi yoki yo'qmi, mexanik baholashning qiymati aksincha oshadi. Ushbu maqolaning qolgan qismi shunday eshigini qanday yaratganimiz haqidagi ma'lumotlardir.

3. CI sifat eshigi

Dizayn printsipi juda oddiy. Xatolarni oldinroq ushlasang, ularni ta'mirlash arzonroq, orqaga ketgan sarf esa qimmatroq. Ushbu haqiqatni pipeline tuzilishiga aniq ko'chirishning o'zi barcha narsadir.

Shuning uchun sifat darvozasi bitta katta tekshirish sifatida emas, balki javobgarlikni turli to'rt bosqichga bo'lib chiqdi.

Erta to'xtatish → Asosiy chiziq tasdiqlanishi → Amaliy nomzodni tekshirish → O'sish baholash

Har bir bosqichda o’tishning ma'nosi boshqacha. Erta to'xtatishni o'tishga erishganingizdan so'ng, yig'ish ochiladi, asosiy chiziq tasdiqlangandan so'ng, rasmiy sifat asosiy chiziq sifatida ro'yxatga olinadi va amaliy nomzodni tekshirishdan o'tganingizda, faqat shunda o'sish baholashiga taqdim etilishingiz mumkin.

Bu yerda bir narsani aniq belgilab oldik. Har qanday shox strategiyasi mavjud bo'lsa ham, sifat nazoratining mezonlari bir xilda bo'ladi. Strategiya bosqichlar va vaziyatga qarab o'zgarishi mumkin, lekin darvoza talab qiladigan sifat darajasi strategiyaga qarab o'zgaradigan bo'lsa, bu mezon deb atalishi mumkin emas.

Ushbu loyiha qurilish (SI) bosqichida nashr nazorati muhim deb hisoblangan, shuning uchun GitFlow asosida olib boriladi va operatsion (SM) bosqichda avtomatlashtirish etarlicha yetuk bo'lsa, Trunk-based ga o'tish yo'lini ham chizdik. Shuning uchun darvozani umumiy model sifatida belgilab qo'ydik va faqat bajarish joylarini shox strategiyasiga mos ravishda xaritaladik. Strategiyani almashtirsangiz ham, tekshirish mazmuni bir xil bo'lib qoladi.

Shaxsan men, MSA ni monorepo orqali boshqaradigan muhitda, oxirida Trunk-based bu yaxshiroq mos keladi deb o'ylayman. Monorepo da bir nechta xizmat bir xotirani bo'lishadi, bu erda GitFlow kabi release·develop·feature shoxlari uzun joylar bilan bo'linsa, xizmatlar soniga qarab integratsiya nuqtalari ko'payadi. To'qnashuv va birlashish xarajatlari ham shunday ortadi. Trunk-based esa qisqa muddatli ish olib boradi va tez-tez trunk ga qo'shiladi, shuning uchun o'zgarishlar uzoqlarga ketib, bir vaqtning o'zida to'qnashuvga tushish holati kamayadi.

Bu yerda keyinchalik aytadigan tanlangan CI ga qo'shilsa, juda yaxshi kombinatsiya bo'ladi. Xotira ko'p xizmatlarga ega bo'lsa ham, o'zgarishlar ta'sir doirasini tanlab tekshiradi, shuning uchun tez-tez integratsiya qilinadi va CI xarajatlari odatiy darajada saqlanadi. Integratsiya tsikli qisqa bo'lishidan kelib chiqadigan xavf sifat darvazasi yordamida qoplanadi. Shuning uchun ushbu loyiha SI uchun GitFlow bilan boshlanadi, lekin operatsiya barqaror bo'lgach, Trunk-based ga o'tish masalasini tavsiya qilish uchun tayyorladik.

[ Rasm 1. Shox strategiyasiga bog'liq bo'lmasdan ishlaydigan sifat darvozasi bosqichlari ]

Shunday qilib, bosqich va javobgarliklarni ajratib qo'yganimizdan so'ng, "Ushbu o'zgarish qaysi bosqichda nima o‘tishi kerak?" aniq bo'ldi. Bir nafar ko'rib chiquvchi hamma narsani boshida ushlab turadigan tuzilishdan, pipeline 1-daraja mudofaa bo'lib o'tishga o'tdi.

Darvaza o'rnatilganda haqiqatan ham to'qnashuvga sabab bo'lgan yana bir muammo paydo bo'ldi. Ko'p xizmat mavjud bo'lgan monorepo da har bir o'zgarishni tekshirmoqchi bo'lganimizda CI vaqti tezda nazoratdan chiqadi. Bitta qatorni tuzatish va 20 daqiqa kutish bilan hech kim darvozani yaxshi ko'rmaydi.

Shuning uchun tanlangan CI ni qo'lladik. O'zgargan modullarni qurish va bog'lanish grafigi bo'ylab ta'sirlanadigan xizmatlarni faqat test obyekti sifatida qo'shish usuli. Biroq, to'siqni maqsadsiz toraytirmadik. Umumiy kutubxona yoki voqea shartnomalari, infratuzilma o'zgarganda yoki chiqarish nomzodini tayyorlaganda doirasi toraytirmay, to'liq qayta ishlashni ta'minlaydigan istisnolarni belgilashimiz kerak bo'ldi. Tezlikni istab to'rtkocha o'lchadagan eng xavfli hol ni nazorat qilishda yo'qotish, bu erda "toraytirish, lekin xavfli o'zgarishlarni kengaytirishi kerak" degan belgi aniqlangan.

Biroq tanlangan CI dan vaqtni qisqartirishga muvaffaqiyat qozongan paytlar keladi. To'liq tasdiqlashdan o'tishi uchun vaqt yo'q paytlar. Ehtiyoji bor chaqiriqlar bo'ladi va demo yoki namoyish rejalariga moslashish paytlarida ham shunday bo'ladi. Bu erda iroda masalasi emas, shunchaki doimo mavjud bo'lgan haqiqiyotdir.

Shuning uchun sifat darvosasi tekshirish modullarini tanlash imkoniyatini ochish mumkin bo'ldi.

Statik tahlil, integratsiya testlari, qoplama tekshiruvi, zaiflik skanerlari kabi og'ir tasdiqlashlar pipeline parametrlarida namoyish etildi va sharoitga qarab ularning bir qismini o‘tkazib yuborish imkonini berdi. Qiyin vaziyatda darvoza butunlay to'siq qilib oshgani uchun, odamlarda nihoyat CI dan tashqariga chiqishning xavfli yo'lini izlashadi. Shunday narxda "bu safar nimani o'chirishga niyat qilyapsiz?" ni pipeline ichida ochiq baqirish yaxshi bo'ladi.

Albatta o‘chirish uchun xarajat keltiriladi. Qaysi tasdiqlashlar olib tashlanganligini qurilish yozuvlarida qoldiramiz, va qurilish muvaffaqiyatsiz yoki yagona test muvaffaqiyatsiz bo'lsa, ushbu asosiy to'siqlarni dastlabki imkoniyatlar ro'yxatidan chiqarib, qanday holatda ham o'chirib qo'ymaymiz. Imkoniyatlar tuzilishining maqsadi nazoratni ozod qilish emas, "tezlik bilan harakat qilish kerak bo'lgan vaziyatlar"ni darvoza dizayniga olib kelishdan iborat edi.

4. To'siq kuchi (Hard Block/ Soft Block / Warning)

Darvoza yaratishda eng ko'p o'ylaganim kutilmagan tarzda "nima to'silishi" emas, "nima to'silmasligi" edi.

Agar hamma narsa kuchli to'silsa, pipeline tezda yomon obro'ga ega bo'ladi. Format bir oz noto'g'ri bo'lsa, tarqatish to'xtatiladi, hamma darvozaning chetlarini aylanib o'tishni o'ylay boshlaydi. Shuning uchun to'siq kuchini uch bosqichga bo'ldik.

Qatlam	Ma'no	Vakil element
Hard Block	Istisno tasdiqlashsiz birlashtirish va ko'tarilish mumkin emas	Build muvaffaqiyatsizligi, unit test muvaffaqiyatsizligi, Critical/High zaiflik, majburiy tasdiqlashni qondirish emas
Soft Block	To'ldiruvchi rejani yozib qo'ysangiz, shartli tasdiqlash kerak	Qamrov yetarli emas, ishlashni qaytariq qilish, Medium zaiflik, noturg'un integratsiya testi
Warning	To'silmaydi, faqat tendentsiyani boshqaradi	Format, past og'irlik, hujjat yo'q, stil muammolari

Shunday qilib, bu bo'linish natijasida gate "mustaqil to'siq" emas, balki "xatar darajasiga mos ravishda javob beradigan tizim"ga aylandi. Noxush narsalarni o'tkazib yuborib, xavfli narsalarni aniq tutish usuli hisoblanadi.

Kuchni pasaytirganimiz sari chiqib ketish uchun ham joy ajraladi. Shuning uchun qo'shimcha qoidalarni ham kiritdik. Bir xil element ikki marta ketma-ket muvaffaqiyatsiz bo'lsa, Softni Hardga ko'tarish ustida o'ylaymiz va to'lov yoki hisob-kitob kabi asosiy biznes yo'lining muvaffaqiyatsizligi har qanday test qatlamiga qaramay, mustaqil ravishda Hard sifatida ko'rib chiqildi. Bir xil muvaffaqiyatsizlik bo'lsa ham, qayerdan kelganiga qarab og'irlik farq qiladi.

Natijada, "to'siq qilmaslik"ni belgilash va "hech qachon taslim bo'lmaydigan yo'l"ni belgilash bir to'plam hisoblanadi. Kuchni uchga bo'lish ham, shu ikki o'rtasidagi muvozanatni saqlash mexanizmi edi.

5. Statik tahlil va testlar

Gate'ning asosini qurgandan so'ng har bir gate haqiqatan nima tekshirishini to'ldirishimiz kerak edi.

Kod bazasi Kotlin bo'lganligi uchun, statik tahlil vositalarini qasddan ikkiga bo'ldik. Kotlin tiliga xos tahlil detekt tomonidan amalga oshiriladi, formatlash va linting esa ktlint tomonidan bajariladi, qoplama o'lchami esa alohida Kover tomonidan kuzatiladi.

Vositalarni ko'paytirish maqsad emas edi. Detekt Kotlinning xos iboralarini yoki ma'no asosidagi nuqsonlarni yaxshi aniqlaydi, ktlint esa stilni mexanik jihatdan izchil ravishda majburlaydi. Ular orasida qobiliyat farq qilishi mumkin. Ularni ajratganimizda, "bu buzilish qaysi vositadan topildi" aniqlash osonlashadi, gate'ning baholash mezonlarini o'rnatish ancha toza bo'ladi.

Testlar har bir qatlam bo'yicha turli paytlarda va mas'uliyatlarda o'tkazildi. Har bir testni har bir bosqichda o'tkazsak, xarajatni ko'tara olmaymiz. Tez va arzon tekshiruvlar oldinda, sekin va qimmat tekshiruvlar esa orqada joylashgan.

Test qatlamlari	Bajarish vaqti	Maqsad
Unit Test	PR / asos chizig'ini belgilash	Modul ichidagi mantiqiy to'g'rilik
Integration (Testcontainers)	PR markazi	Xizmat chegaralari·integratsiya qaytishining erta aniqlanishi
E2E tutun	Asosiy chiziqni tasdiqlash	Tarqatishdan oldin sayoz qaytish tekshiruvi
E2E kengaytirish	stage dan keyin	Tarqatma standart asosiy oqimni tekshirish

Qoplama mutlaq ball sifatida ko'rilmagan. Sinov notopilgan xavfli sohalarni aks ettiruvchi ko'rsatkich sifatida qaraldi. Asosiy chiziq jami 70%, asosiy domen va yangi kod esa 80% qilib belgilandi, ammo raqamning o'zidan ko'ra asosiy yo'lning tekshirilmagan holati katta xavf hisoblandi. Raqamlar bilan birga turib, o'tishga mo'ljallangan bo'sh sinovlar orttiroladi.

Shuning uchun bir operatsion standart belgiladik. Qoplama raqamini eshikning mutlaq kesimi sifatida olmaydi. Yangi kod qoplamasi qaytishni oldini olish bo'yicha oldindan ko'rsatkich sifatida nisbatan qattiq ko'riladi, ammo mavjud kodning past raqami bir vaqtning o'zida to'sib qo'ymasdan, asosiy yo'lni bosqichma-bosqich oshirish usuli bilan boshqarildi. Oldin aytilganidek, agentlardan foydalanish orqali bu maqsad chizig'ini amalda yuqoriroq belgilash mumkin deb hisobladim.

6. o'zgarmas artefakt

Sifatni qanday yaxshi tekshirsangiz ham, tekshirgan narsalar boshqacha bo'lsa, operatsiyada chiqariladigan bo'lsa, tasdiqlashning hammasi bekor bo'ladi. Kutilmagan darajada shu yerda qochish holatlari ko'p.

Shuning uchun operatsion ko'tarilish drebiltsiz amalga oshirilishi haqida prinsipni belgiladik. Stage-da tekshiruvdan o'tgan aniq natijalarni shu digest bilan retag qilib operatsiyaga ko'taramiz. Tekshirilgan kommit SHA va ko'tarilish maqsadidagi SHA farq qilsa, ko'tarilishni to'xtatamiz. "Operatsion maqsadda qayta qurish" kabi narsalarni yo'l xaritasidan ayirib tashladik.

Ahamiyatsiz ko'rinishi mumkin, lekin MSA-da bu prinsipning og'irligi boshqacha. Xizmatlar bo'yicha mustaqil tarqatishlar ko'paygan sari, "tekshirilgan o'sha bayt shunchaki operatsiyaga ko'tarilgan" kafolati nosozlik tahlili va qaytish ishonchliligini belgilaydi. Bu kafolat bo'lmasa, nosozlik yuzaga kelganda, "tekshirilgan va operatsion asl bir xilmi" deb shubhalanishga to'g'ri keladi.

[ Rasm 2. Qayta qurmasdan bir xil digest bilan ko'tarilish oqim ]

Xavfiyatni boshqarish ham xuddi shu joyga kiritildi. Trivy'ni CI runner ichida tasvirlarni skanerlashga o‘tkazdik va Critical hamda High xavfiyatlar, tasvir allaqachon registrda joylashgan bo‘lsa ham, ko‘tariladiganlardan chiqarib tashlandi. Natijalar SARIF formatida jamlandi va markazda trendlarni ko‘rdik. Xavfsizlik ham ' tavsiya' emas, balki o‘tish shartlaridan biri sifatida belgilandi.

7. AI kod ko‘rib chiqish

Sifat Gate'ni tartibga solayotgan paytlarimda, CI bosqichida AI kod ko‘rib chiqishni qo‘llab-quvvatlashini bilib oldim va to‘g‘ridan-to‘g‘ri qo‘shishga kirishdim.

PR joylashtirilganda, AI o‘zgarishlarni ko‘zdan kechirish orqali xato nomzodlar, qaytish xavfi, testlarni yo‘qotish, qoidalarni buzish mumkinligini birinchi marta ko‘rsatadi. Pipeline'ga ulab ishlatganda, rostini aytsam, harakatlari kutganimdan yaxshiroq edi.

Eng ta'sirchan tomoni - bu bir necha nuqtai nazardan cheklanmasidir. Inson ko‘rib chiqqanda ko‘zdan kechirish tartibini deyarli to‘liq kuzatib borib, ko‘plab nuqtalarni ko‘rsatdi. Bir PR joylashtirganda, odatda shunday tuziladi.

• O‘zgarish tahlili— Qanday faylning nimaga o‘zgarganini birinchi bo‘lib bir qator bilan qisqacha bayon qilish

• Potensial kamchiliklar·yaxshilanishlar— Hujjatlashtirishda noaniq joylar, yo‘q bo‘lsa tarqatishda xato bo‘lishi mumkin bo‘lgan sozlamalarga bog‘liqliklarni ko‘rsatish

• Xavfsizlik muammolari— API kaliti yoki ma'lumotnoma kabi sezgir ma'lumotlarning aralashib ketishini tekshirish

• Tuzilish·bog‘lanish darajasi— Meros aloqasi o‘zgarishi yoki boshqa modullar bilan bog‘lanish darajasining oshishi, uning ta'sir doirasini aniqlashni taklif qiladi

• Takrorlanish·optimizatsiya— O‘xshash mantiq takroriyligi yoki ishlatilmaydigan kodlarni qayta ko‘rib chiqish uchun nomzod sifatida belgilash

• Test taklif— o'zgarish ta'siriga nisbatan qamrov yetarlimi, deb so'rab, zarur holatlarni qo'shishni tavsiya qilaman

Hujjatga Marker qo'shish darajasidagi kichik PR ni yuborishda ham "bu o'zgarish boshqa kodga qanday ta'sir qiladi"gacha kuzatib bergan. Tahlilchining nuqtai nazaridan bu tekshirishning boshlanish nuqtasini bir qadam oldinga olib keladi. Qo'shimcha tafsilotlarga birinchi navbatda e'tibor qaratilgani uchun, odam o'z vaqtida muhim qarorlarga ko'proq diqqat qaratishi mumkin.

Ammo bu funksiya, oxir-oqibat, haqiqiy ishga kiritilmadi.

Sababi xavfsizlik edi. Boshqarilayotgan ma'lumotlarning sezgirligi yuqori bo'lgan muhitda kod va unga bog'liq ma'lumotlar tashqi tomonga o'tish yo'llarini sezgirlik bilan qarshi olish mumkin bo'lmadi va o'zgarishlarni tashqi AI xizmatlariga yuborish usuli joriy etilishi qiyin edi. Funktsiyaning yaxshi ishlashi va bu muhitga haqiqatan olib borilsa muammosi alohida edi.

Shuning uchun "tekshirilgan va samarasi tasdiqlangan, lekin xavfsizlik mezonlarini avval qondirmasdan ishga kiritilmaydi" degan cheklovda qoldik. Agar joriy etilsa, ma'lumotlarni tashqariga chiqarishga ruxsat bermaydigan maxfiy LLM asosida bo'lishi kerak va shunda ham AI doimo yordamchi bo'lib, oxirgi tasdiq odam tahlilchisi tomonidan beriladi degan printsipni saqlab qolmoqchimiz.

Texnik jihatdan mumkin bo'lgan va ushbu maydonga kiritiladigan narsalar o'rtasidagi masofani bir marta o'lchagandek bo'ldik, lekin o'sha masofani to'ldiradigan mezon qoldirib qo'yish ham o'z-o'zidan bir natija hisoblardim.

8. Xulosa qilib

Orqaga nazar tashlasak, ushbu ish aslo hayajonli vositalarni olish emas edi. Sifat ko'rsatkichlari har safar bir xil mezonlardan o'tishiga imkon bergan CI da o'z o'rnini topgan edi, bu asosiy nuqtasi edi.

Ish davomida eng ko'p his qilganlarimizni tizimga kiritganda quyidagicha bo'ladi.

• Sifat ko'rsatkichlarining aksariyati kod CI ga kelganida eng tabiiy va izchil ko'rinishga ega.

• Agent sifatida kod yozish jarayoni sifatga tahdid emas, balki imkoniyatdir. Yaxshi foydalanilsa, qamrov va tekshirish zichligini ko'proq oshirish mumkin.

• Geyt nima to'sishi kerakligi o'rniga, nima to'smasligi kerakligini birgalikda loyihalash kerak, shunda yomon ko'rinmaydi va omon qoladi.

• Tekshirilgan mahsulotlarni to'g'ridan-to'g'ri qo'yish immutable printsipi yo'qolsa, oldida barcha tekshiruvlar bir lahzada kuchsizlanadi.

• Texnik jihatdan mumkin bo'lgan va bu muhitga kiritiladigan narsalar turlicha. AI tekshiruvi kabi ta'sirga ega bo'lib, xavfsizlik sababli to'xtatilgan hollarda bu misoldir.

MSA maslahat berish xizmatida xizmatlarni loyiha qilish yoki tarqatish tizimi kabi ko‘zga o‘tar natijalar birinchi bo‘lib e'tibor qaratiladi. Ammo bu natijalar vaqt o‘tgan sari ma'lum sifatni saqlab qolishi uchun asosida yopqich bo‘lib turadigan narsa, har kuni tinchlik bilan ishlayotgan CI sifati darvozasi deb o‘ylayman.

Tim