Endi DevOps mavzusi shov-shuvli. Uzluksiz integratsiya va yetkazib berish quvuri hamma uni amalga oshirmoqda. Ammo ko'pchilik CI/CD quvurining turli bosqichlarida axborot tizimlarining ishonchliligini ta'minlashga har doim ham tegishli e'tibor qaratmaydi. Ushbu maqolada men dasturiy ta'minot sifatini tekshirishni avtomatlashtirish va uni "o'z-o'zini davolash" uchun mumkin bo'lgan stsenariylarni amalga oshirish bo'yicha tajribam haqida gapirmoqchiman.
Men kompaniyaning IT xizmatlarini boshqarish bo'limida muhandis bo'lib ishlayman . Mening asosiy mutaxassisligim turli xil ilovalarning ishlashi va mavjudligi monitoringi tizimlarini joriy qilishdir. Men tez-tez bozorning turli segmentlaridagi IT mijozlari bilan ularning IT xizmatlari sifatini monitoring qilish bilan bog'liq dolzarb masalalar bo'yicha muloqot qilaman. Asosiy maqsad - chiqarish sikli vaqtini minimallashtirish va relizlar chastotasini oshirish. Bu, albatta, yaxshi: ko'proq relizlar - ko'proq yangi xususiyatlar - ko'proq qoniqarli foydalanuvchilar - ko'proq foyda. Lekin, aslida, hamma vaqt ham yaxshi natija beravermaydi. Juda yuqori joylashtirish stavkalari bilan, bizning nashrlarimiz sifati haqida darhol savol tug'iladi. To'liq avtomatlashtirilgan quvur liniyasi bo'lsa ham, eng katta qiyinchiliklardan biri xizmatlarni sinovdan ishlab chiqarishga o'tkazishdir, bu ilovalarning ishlash muddati va foydalanuvchi tajribasiga ta'sir qilmaydi.
Mijozlar bilan ko'plab suhbatlar natijalariga ko'ra, shuni aytishim mumkinki, ishlab chiqarish sifatini nazorat qilish, dasturning ishonchliligi muammosi va uning "o'z-o'zini davolash" imkoniyati (masalan, barqaror versiyaga qaytish) CIning turli bosqichlarida. /CD quvur liniyasi eng qiziqarli va dolzarb mavzulardan biridir.
Yaqinda men o'zim mijozlar tomonida ishladim - onlayn-banking dasturlarini qo'llab-quvvatlash xizmatida. Ilovamiz arxitekturasi ko'plab o'z-o'zidan yozilgan mikroservislardan foydalangan. Eng achinarlisi shundaki, barcha ishlab chiquvchilar rivojlanishning yuqori sur'atlariga bardosh bera olmadilar, ba'zi mikroservislarning sifati yomonlashdi, bu esa ular va ularning yaratuvchilari uchun kulgili taxalluslarni keltirib chiqardi. Ushbu mahsulotlar qanday materiallardan tayyorlanganligi haqida hikoyalar bor edi.
"Muammoni shakllantirish"
Chiqarishlarning yuqori chastotasi va ko'p sonli mikroservislar sinov bosqichida ham, foydalanish bosqichida ham dasturning ishlashini tushunishni qiyinlashtiradi. O'zgarishlar doimiy ravishda sodir bo'ladi va yaxshi monitoring vositalarisiz ularni nazorat qilish juda qiyin. Ko'pincha, ertalab tunda chiqarilgandan so'ng, ishlab chiquvchilar kukunli bochkada o'tirishadi va hech narsa buzilmasligini kutishadi, garchi barcha tekshiruvlar sinov bosqichida muvaffaqiyatli bo'lgan.
Yana bir nuqta bor. Sinov bosqichida dasturiy ta'minotning funksionalligi tekshiriladi: dasturning asosiy funktsiyalarini amalga oshirish va xatolarning yo'qligi. Samaradorlikni sifat jihatidan baholash yo yo'q yoki dastur va integratsiya qatlamining barcha jihatlarini hisobga olmaydi. Ba'zi ko'rsatkichlar umuman tekshirilmasligi mumkin. Natijada, ishlab chiqarish muhitida buzilish sodir bo'lganda, texnik yordam bo'limi bu haqda faqat haqiqiy foydalanuvchilar shikoyat qila boshlaganda bilib oladi. Men past sifatli dasturiy ta'minotning oxirgi foydalanuvchilarga ta'sirini minimallashtirishni xohlayman.
Yechimlardan biri CI/CD quvurining turli bosqichlarida dasturiy ta'minot sifatini tekshirish jarayonlarini amalga oshirish va favqulodda vaziyatlarda tizimni tiklash uchun turli stsenariylarni qo'shishdir. Bizda DevOps borligini ham eslaymiz. Korxonalar yangi mahsulotni iloji boricha tezroq olishni kutmoqdalar. Shuning uchun bizning barcha tekshiruvlarimiz va skriptlarimiz avtomatlashtirilgan bo'lishi kerak.
Vazifa ikki qismga bo'lingan:
- sinov bosqichida yig'ilishlar sifatini nazorat qilish (past sifatli yig'ilishlarni ushlash jarayonini avtomatlashtirish uchun);
- ishlab chiqarish muhitida dasturiy ta'minot sifatini nazorat qilish (muammolarni avtomatik aniqlash mexanizmlari va ularni o'z-o'zini davolashning mumkin bo'lgan stsenariylari).
Ko'rsatkichlarni kuzatish va yig'ish uchun vosita
Belgilangan maqsadlarga erishish uchun muammolarni aniqlay oladigan va ularni CI/CD quvurining turli bosqichlarida avtomatlashtirish tizimlariga o'tkaza oladigan monitoring tizimi talab qilinadi. Agar ushbu tizim turli jamoalar uchun foydali ko'rsatkichlarni taqdim etsa, bu ham ijobiy narsa bo'ladi: ishlab chiqish, test qilish, ishlatish. Va agar u biznes uchun ham bo'lsa, bu juda ajoyib.
Ko'rsatkichlarni to'plash uchun siz turli xil tizimlar to'plamidan foydalanishingiz mumkin (Prometey, ELK Stack, Zabbix va boshqalar), ammo mening fikrimcha, APM sinfidagi echimlar ushbu vazifalar uchun eng mos keladi (), bu sizning hayotingizni sezilarli darajada soddalashtirishi mumkin.
Qo'llab-quvvatlash xizmatidagi ishimning bir qismi sifatida men Dynatrace'dan APM sinfi yechimidan foydalangan holda shunga o'xshash loyihani amalga oshirishni boshladim. Endi, integratorda ishlaganim sababli, men monitoring tizimlari bozorini yaxshi bilaman. Mening sub'ektiv fikrim: Dynatrace bunday muammolarni hal qilish uchun eng mos keladi.
Dynatrace har bir foydalanuvchi operatsiyasining gorizontal ko'rinishini kodni bajarish darajasigacha granüler darajada taqdim etadi. Siz turli xil axborot xizmatlari o'rtasidagi o'zaro ta'sirning butun zanjirini kuzatishingiz mumkin: veb va mobil ilovalarning oldingi darajalaridan, dastur serverlarining orqa qismidan, integratsiya avtobusidan ma'lumotlar bazasiga ma'lum bir qo'ng'iroqgacha.
. Tizim komponentlari orasidagi barcha bog'liqliklarni avtomatik ravishda qurish
. Xizmat ko'rsatish yo'lini avtomatik aniqlash va qurish
Shuningdek, biz turli xil avtomatlashtirish vositalari bilan integratsiya qilishimiz kerakligini eslaymiz. Bu erda yechim turli ko'rsatkichlar va hodisalarni yuborish va qabul qilish imkonini beruvchi qulay APIga ega.
Keyinchalik, Dynatrace tizimi yordamida ushbu muammolarni qanday hal qilish haqida batafsilroq ko'rib chiqamiz.
Vazifa 1. Sinov bosqichida yig'ilishlar sifatini nazorat qilishni avtomatlashtirish
Birinchi qiyinchilik dasturni yetkazib berish jarayonida muammolarni imkon qadar tezroq topishdir. Faqat "yaxshi" kod tuzilmalari ishlab chiqarishga yetishi kerak. Buning uchun sinov bosqichida sizning quvur liniyasi xizmatlaringiz sifatini tekshirish uchun qo'shimcha monitorlarni o'z ichiga olishi kerak.
Keling, buni qanday amalga oshirish va bu jarayonni avtomatlashtirishni bosqichma-bosqich ko'rib chiqaylik:
Rasmda dasturiy ta'minot sifatini tekshirishning avtomatlashtirilgan bosqichlari ko'rsatilgan:
- monitoring tizimini joylashtirish (agentlarni o'rnatish);
- dasturiy ta'minot sifatini baholash uchun hodisalarni aniqlash (ko'rsatkichlar va chegara qiymatlari) va ularni monitoring tizimiga o'tkazish;
- yuk va ishlash testlarini yaratish;
- monitoring tizimida ishlash va mavjudligi ma'lumotlarini yig'ish;
- dasturiy ta'minot sifatini baholash hodisalari asosida test ma'lumotlarini monitoring tizimidan CI/CD tizimiga o'tkazish. Yig'malarni avtomatik tahlil qilish.
Qadam 1. Monitoring tizimini joylashtirish
Avval siz agentlarni sinov muhitingizga o'rnatishingiz kerak. Shu bilan birga, Dynatrace yechimi yoqimli xususiyatga ega - u OT nusxasida (Windows, Linux, AIX) o'rnatilgan universal agent OneAgentdan foydalanadi, sizning xizmatlaringizni avtomatik ravishda aniqlaydi va ular bo'yicha monitoring ma'lumotlarini yig'ishni boshlaydi. Har bir jarayon uchun alohida agentni sozlashingiz shart emas. Vaziyat bulutli va konteyner platformalari uchun ham xuddi shunday bo'ladi. Shu bilan birga, siz agentni o'rnatish jarayonini ham avtomatlashtirishingiz mumkin. Dynatrace "infratuzilmani kod sifatida" tushunchasiga juda mos keladi (): Barcha mashhur platformalar uchun tayyor skriptlar va ko'rsatmalar mavjud. Siz agentni xizmatingiz konfiguratsiyasiga joylashtirasiz va uni o'rnatganingizdan so'ng siz darhol ishlayotgan agent bilan yangi xizmatni olasiz.
2-qadam: dasturiy ta'minot sifati hodisalarini aniqlang
Endi siz xizmatlar va biznes operatsiyalari ro'yxati haqida qaror qabul qilishingiz kerak. Sizning xizmatingiz uchun juda muhim bo'lgan foydalanuvchi operatsiyalarini hisobga olish muhimdir. Bu erda men biznes va tizim tahlilchilari bilan maslahatlashishni tavsiya qilaman.
Keyinchalik, har bir daraja uchun ko'rib chiqishga qaysi ko'rsatkichlarni kiritishni xohlayotganingizni aniqlashingiz kerak. Misol uchun, bu bajarilish vaqti (o'rtacha, median, foizlar va boshqalarga bo'lingan), xatolar (mantiqiy, xizmat ko'rsatish, infratuzilma va boshqalar) va turli infratuzilma ko'rsatkichlari (xotira yig'indisi, axlat yig'uvchi, iplar soni va boshqalar) bo'lishi mumkin.
DevOps jamoasi tomonidan avtomatlashtirish va foydalanish qulayligi uchun "Kod sifatida monitoring" tushunchasi paydo bo'ladi. Bu bilan men shuni nazarda tutyapmanki, ishlab chiquvchi/sinovchi dasturiy ta'minot sifatini ta'minlash ko'rsatkichlarini belgilaydigan oddiy JSON faylini yozishi mumkin.
Keling, bunday JSON fayliga misolni ko'rib chiqaylik. Dynatrace API ob'ektlari kalit/qiymat juftlari sifatida ishlatiladi (API tavsifini bu yerda topishingiz mumkin ).
{
"timeseries": [
{
"timeseriesId": "service.ResponseTime",
"aggregation": "avg",
"tags": "Frontend",
"severe": 250000,
"warning": 1000000
},
{
"timeseriesId": "service.ResponseTime ",
"aggregation": "avg",
"tags": "Backend",
"severe": 4000000,
"warning": 8000000
},
{
"timeseriesId": "docker.Container.Cpu",
"aggregation": "avg",
"severe": 50,
"warning": 70
}
]
}Fayl vaqt seriyalarining ta'riflari to'plamidir:
- timeseriesId - tekshirilayotgan ko'rsatkich, masalan, Javob berish vaqti, Xatolar soni, ishlatilgan xotira va boshqalar;
- yig'ish - ko'rsatkichlarni yig'ish darajasi, bizning holatlarimizda o'rtacha, lekin siz o'zingizga kerak bo'lgan istalganidan foydalanishingiz mumkin (o'rtacha, min, maksimal, yig'indi, hisob, foiz);
- teglar - monitoring tizimidagi ob'ekt yorlig'i yoki ma'lum bir ob'ekt identifikatorini belgilashingiz mumkin;
- jiddiy va ogohlantirish - bu ko'rsatkichlar bizning ko'rsatkichlarimizning chegara qiymatlarini tartibga soladi; agar sinov qiymati jiddiy chegaradan oshib ketgan bo'lsa, unda bizning qurilishimiz muvaffaqiyatsiz deb belgilanadi.
Quyidagi rasmda bunday chegaralardan foydalanish misoli ko'rsatilgan.
3-qadam: yuk yaratish
Xizmatimizning sifat darajasini aniqlaganimizdan so'ng, biz sinov yukini yaratishimiz kerak. Jmeter, Selenium, Neotys, Gatling va boshqalar kabi o'zingizga qulay bo'lgan har qanday sinov vositalaridan foydalanishingiz mumkin.
Dynatrace monitoring tizimi testlaringizdan turli metamaʼlumotlarni olish va qaysi testlar qaysi relizlar sikli va qaysi xizmatga tegishli ekanligini aniqlash imkonini beradi. HTTP test so'rovlariga qo'shimcha sarlavhalar qo'shish tavsiya etiladi.
Quyidagi rasmda X-Dynatrace-Test qo'shimcha sarlavhasidan foydalanib, ushbu test savatga element qo'shish jarayonini sinab ko'rish bilan bog'liqligini ko'rsatadigan misol ko'rsatilgan.
Har bir yuklash testini o'tkazganingizda, CI/CD serveridan Event API yordamida Dynatrace-ga qo'shimcha kontekstli ma'lumotlarni yuborasiz. Shu tarzda, tizim turli testlarni farqlay oladi.
. Monitoring tizimida yukni sinovdan o'tkazish boshlanishi haqidagi voqea
4-5-qadam. Ishlash ma'lumotlarini to'plang va ma'lumotlarni CI/CD tizimiga o'tkazing
Yaratilgan test bilan birgalikda xizmat sifati ko'rsatkichlarini tekshirish bo'yicha ma'lumotlarni to'plash zarurligi to'g'risidagi voqea monitoring tizimiga uzatiladi. Shuningdek, u bizning asosiy ko'rsatkichlarni belgilaydigan JSON faylimizni ham belgilaydi.
Monitoring tizimiga jo'natish uchun CI/CD serverida yaratilgan dasturiy ta'minot sifatini tekshirish zarurligi haqidagi voqea
Bizning misolimizda sifatni tekshirish hodisasi deyiladi perfSigDynatraceReport (Ishlash_imzosi) - bu tayyor T-Systems Multimedia Solutions kompaniyasining yigitlari tomonidan ishlab chiqilgan Jenkins bilan integratsiya uchun. Har bir sinovni ishga tushirish hodisasi xizmat, tuzilish raqami va sinov vaqti haqida ma'lumotni o'z ichiga oladi. Plagin qurish vaqtida ishlash qiymatlarini to'playdi, ularni baholaydi va natijani oldingi tuzilmalar va ishlamaydigan talablar bilan taqqoslaydi.
Qurilish sifatini tekshirish boshlanishi haqidagi monitoring tizimidagi voqea.
Sinov tugagandan so'ng, dasturiy ta'minot sifatini baholash uchun barcha ko'rsatkichlar doimiy integratsiya tizimiga o'tkaziladi, masalan, natijalar bo'yicha hisobot ishlab chiqaradigan Jenkins.
CI/CD serveridagi yig'ilishlar bo'yicha statistik ma'lumotlarning natijasi.
Har bir alohida tuzilish uchun biz butun test davomida o'rnatgan har bir ko'rsatkich bo'yicha statistikani ko'ramiz. Shuningdek, biz ma'lum chegara qiymatlarida (ogohlantirish va jiddiy chegaralar) buzilishlar mavjudligini ko'ramiz. Umumiy ko'rsatkichlarga asoslanib, butun tuzilish barqaror, beqaror yoki muvaffaqiyatsiz deb belgilangan. Bundan tashqari, qulaylik uchun hisobotga joriy tuzilishni oldingi bilan taqqoslaydigan ko'rsatkichlarni qo'shishingiz mumkin.
CI/CD serverida yig'ilishlar bo'yicha batafsil statistikani ko'ring.
Ikki yig'ilishni batafsil taqqoslash
Agar kerak bo'lsa, siz Dynatrace interfeysiga o'tishingiz mumkin va u erda siz har bir tuzilmangiz uchun statistikani batafsilroq ko'rishingiz va ularni bir-biri bilan taqqoslashingiz mumkin.
Dynatrace-da qurilish statistikasini taqqoslash.
topilmalar
Natijada, biz uzluksiz integratsiya quvurida avtomatlashtirilgan "xizmat sifatida monitoring" xizmatini olamiz. Ishlab chiquvchi yoki tester faqat JSON faylida ko'rsatkichlar ro'yxatini belgilashi kerak va qolgan hamma narsa avtomatik ravishda sodir bo'ladi. Biz nashrlarning shaffof sifati nazoratini olamiz: unumdorlik, resurslar iste'moli yoki arxitektura regresslari haqidagi barcha bildirishnomalar.
Vazifa 2. Ishlab chiqarish muhitida dasturiy ta'minot sifatini nazorat qilishni avtomatlashtirish
Shunday qilib, biz Pipeline'dagi sinov bosqichida monitoring jarayonini qanday avtomatlashtirish masalasini hal qildik. Shunday qilib, biz ishlab chiqarish muhitiga etib boradigan past sifatli yig'ilishlar foizini minimallashtiramiz.
Ammo yomon dasturiy ta'minot sotilsa yoki biror narsa buzilib qolsa, nima qilish kerak. Utopiya uchun biz mexanizmlar muammolarni avtomatik ravishda aniqlashini va iloji bo'lsa, tizimning o'zi, hech bo'lmaganda tunda o'z faoliyatini tiklashini xohladik.
Buning uchun biz oldingi bo'limga o'xshab, ishlab chiqarish muhitida dasturiy ta'minot sifatini avtomatik tekshirishni ta'minlashimiz va ularni tizimning o'zini o'zi tiklash stsenariylariga asoslanishimiz kerak.
Kod sifatida avtomatik tuzatish
Aksariyat kompaniyalarda turli xil keng tarqalgan muammolar haqida to'plangan bilim bazasi va ularni tuzatish bo'yicha harakatlar ro'yxati mavjud, masalan, jarayonlarni qayta boshlash, resurslarni tozalash, versiyalarni qaytarish, noto'g'ri konfiguratsiya o'zgarishlarini tiklash, komponentlar sonini ko'paytirish yoki kamaytirish. klaster, ko'k yoki yashil konturni almashtirish va boshqalar.
Ushbu foydalanish holatlari men gaplashadigan ko'plab jamoalar tomonidan yillar davomida ma'lum bo'lgan bo'lsa-da, ularni avtomatlashtirish haqida o'ylamagan yoki sarmoya kiritganlar kam.
Agar siz bu haqda o'ylayotgan bo'lsangiz, o'z-o'zini davolash dasturining ishlashi uchun jarayonlarni amalga oshirishda ortiqcha murakkab narsa yo'q, siz ma'murlaringizning allaqachon ma'lum bo'lgan ish stsenariylarini kod skriptlari ko'rinishida taqdim etishingiz kerak ("kod sifatida avtomatik tuzatish" tushunchasi) , siz har bir aniq holat uchun oldindan yozgansiz. Avtomatik ta'mirlash skriptlari muammoning asosiy sababini bartaraf etishga qaratilgan bo'lishi kerak. Hodisaga javob berish uchun to'g'ri harakatlarni o'zingiz aniqlaysiz.
Monitoring tizimingizdagi har qanday ko'rsatkich skriptni ishga tushirish uchun tetik rolini o'ynashi mumkin, asosiysi, bu ko'rsatkichlar hamma narsa yomon ekanligini aniq aniqlaydi, chunki siz samarali muhitda noto'g'ri pozitivlarni olishni xohlamaysiz.
Siz har qanday tizim yoki tizimlar to'plamidan foydalanishingiz mumkin: Prometheus, ELK Stack, Zabbix va boshqalar. Lekin men APM yechimiga asoslangan ba'zi misollar keltiraman (Dynatrace yana misol bo'ladi), bu ham hayotingizni osonlashtirishga yordam beradi.
Birinchidan, dastur ishlashi nuqtai nazaridan ishlash bilan bog'liq hamma narsa mavjud. Yechim turli darajadagi yuzlab ko'rsatkichlarni taqdim etadi, ulardan siz tetikleyici sifatida foydalanishingiz mumkin:
- foydalanuvchi darajasi (brauzerlar, mobil ilovalar, IoT qurilmalari, foydalanuvchi xatti-harakati, konversiya va boshqalar);
- xizmat ko'rsatish va operatsiyalar darajasi (ishlash, mavjudlik, xatolar va boshqalar);
- dastur infratuzilmasi darajasi (host OS ko'rsatkichlari, JMX, MQ, web-server va boshqalar);
- platforma darajasi (virtualizatsiya, bulut, konteyner va boshqalar).
Dynatrace-da darajalarni kuzatish.
Ikkinchidan, yuqorida aytib o'tganimdek, Dynatrace ochiq APIga ega, bu uni turli uchinchi tomon tizimlari bilan integratsiya qilishni juda osonlashtiradi. Masalan, nazorat parametrlari oshib ketganda avtomatlashtirish tizimiga xabarnoma yuborish.
Quyida Ansible bilan ishlashga misol keltirilgan.
Quyida men qanday avtomatlashtirishni amalga oshirish mumkinligi haqida bir nechta misollar keltiraman. Bu holatlarning faqat bir qismi; sizning muhitingizdagi ularning ro'yxati faqat sizning tasavvuringiz va monitoring vositalarining imkoniyatlari bilan cheklanishi mumkin.
1. Yomon tarqatish - versiyani qaytarish
Agar biz hamma narsani sinov muhitida juda yaxshi sinab ko'rsak ham, yangi nashr sizning ilovangizni ishlab chiqarish muhitida o'ldirishi mumkin. Xuddi shu inson omili bekor qilinmagan.
Quyidagi rasmda biz xizmatdagi operatsiyalarni bajarish vaqtida keskin sakrash mavjudligini ko'ramiz. Ushbu sakrashning boshlanishi dasturga joylashtirish vaqtiga to'g'ri keladi. Biz ushbu ma'lumotlarning barchasini voqea sifatida avtomatlashtirish tizimiga uzatamiz. Agar biz o'rnatgan vaqtdan keyin xizmatning ishlashi normal holatga qaytmasa, u holda versiyani eskisiga qaytaradigan skript avtomatik ravishda chaqiriladi.
Joylashtirishdan keyin operatsiyalar samaradorligining pasayishi.
2. Resursni 100% yuklash - marshrutlash uchun tugun qo'shing
Quyidagi misolda, monitoring tizimi komponentlardan biri 100% protsessor yukini boshdan kechirayotganini aniqlaydi.
CPU yuki 100%
Ushbu hodisa uchun bir nechta turli stsenariylar mavjud. Masalan, monitoring tizimi resurslarning etishmasligi xizmat yukining ortishi bilan bog'liqligini qo'shimcha ravishda tekshiradi. Agar shunday bo'lsa, u holda marshrutga avtomatik ravishda tugun qo'shadigan va shu bilan butun tizimning funksionalligini tiklaydigan skript bajariladi.
Hodisadan keyin masshtablash
3. Qattiq diskda bo'sh joy etishmasligi - diskni tozalash
O'ylaymanki, ko'p odamlar allaqachon bu jarayonlarni avtomatlashtirishgan. APM-dan foydalanib, siz disk quyi tizimidagi bo'sh joyni ham kuzatishingiz mumkin. Agar bo'sh joy bo'lmasa yoki disk sekin ishlayotgan bo'lsa, biz uni tozalash yoki bo'sh joy qo'shish uchun skriptni chaqiramiz.
Disk yuki 100%
4. Past foydalanuvchi faolligi yoki past konvertatsiya - ko'k va yashil novdalar o'rtasida almashish
Men tez-tez iste'molchilarni ishlab chiqarish muhitida ilovalar uchun ikkita halqa (ko'k-yashil joylashtirish) ishlatayotganini ko'raman. Bu sizga yangi nashrlarni etkazib berishda filiallar o'rtasida tezda almashish imkonini beradi. Ko'pincha, joylashtirishdan so'ng, darhol sezilmaydigan keskin o'zgarishlar yuz berishi mumkin. Bunday holda, ishlash va mavjudlikning pasayishi kuzatilmasligi mumkin. Bunday o'zgarishlarga tezda javob berish uchun foydalanuvchi xatti-harakatlarini aks ettiruvchi turli ko'rsatkichlardan foydalanish yaxshiroqdir (sessiyalar soni va foydalanuvchi harakatlari, konvertatsiya, chiqish tezligi). Quyidagi rasmda konvertatsiya tezligi pasayganda, dasturiy ta'minot tarmoqlari o'rtasida almashinish sodir bo'ladigan misol ko'rsatilgan.
Dasturiy ta'minot tarmoqlari o'rtasida almashinishdan keyin konversiya darajasi pasayadi.
Avtomatik muammolarni aniqlash mexanizmlari
Nihoyat, men sizga Dynatrace-ni nima uchun ko'proq yoqtirishimga yana bir misol keltiraman.
Sinov muhitida yig'ilishlar sifatini tekshirishni avtomatlashtirish haqidagi hikoyamning qismida biz barcha chegara qiymatlarini qo'lda aniqladik. Bu sinov muhiti uchun odatiy holdir, sinovchining o'zi yukga qarab har bir sinovdan oldin ko'rsatkichlarni aniqlaydi. Ishlab chiqarish muhitida muammolar turli xil asosiy mexanizmlarni hisobga olgan holda avtomatik ravishda aniqlanishi maqsadga muvofiqdir.
Dynatrace qiziqarli o'rnatilgan sun'iy intellekt vositalariga ega bo'lib, ular anomal ko'rsatkichlarni aniqlash (tayanchlash) va barcha komponentlar o'rtasidagi o'zaro ta'sir xaritasini yaratish, hodisalarni bir-biri bilan taqqoslash va korrelyatsiya qilish mexanizmlariga asoslanib, xizmatingiz ishlashidagi anomaliyalarni aniqlaydi va batafsil ma'lumot beradi. har bir muammo va asosiy sabab haqida ma'lumot.
Komponentlar o'rtasidagi bog'liqlikni avtomatik ravishda tahlil qilish orqali Dynatrace nafaqat muammoli xizmatning asosiy sabab ekanligini, balki uning boshqa xizmatlarga bog'liqligini ham aniqlaydi. Quyidagi misolda Dynatrace tranzaksiyani amalga oshirish davomida har bir xizmatning sog'lig'ini avtomatik ravishda kuzatib boradi va baholaydi va Golang xizmatini asosiy sabab sifatida aniqlaydi.
Muvaffaqiyatsizlikning asosiy sababini aniqlashga misol.
Quyidagi rasmda hodisa boshidanoq arizangiz bilan bog'liq muammolarni kuzatish jarayoni ko'rsatilgan.
Barcha komponentlar va ulardagi hodisalarni ko'rsatish bilan paydo bo'lgan muammoni vizualizatsiya qilish
Monitoring tizimi yuzaga kelgan muammo bilan bog'liq voqealarning to'liq xronologiyasini to'pladi. Vaqt jadvali ostidagi oynada biz komponentlarning har biridagi barcha asosiy voqealarni ko'ramiz. Ushbu hodisalarga asoslanib, siz kod skriptlari shaklida avtomatik tuzatish uchun protseduralarni o'rnatishingiz mumkin.
Bundan tashqari, men sizga monitoring tizimini Service Desk yoki xato kuzatuvchisi bilan birlashtirishni maslahat beraman. Muammo yuzaga kelganda, ishlab chiquvchilar uni ishlab chiqarish muhitida kod darajasida tahlil qilish uchun tezda to'liq ma'lumot oladi.
xulosa
Natijada, biz Pipeline-da o'rnatilgan avtomatlashtirilgan dasturiy ta'minot sifatini tekshiradigan CI/CD quvur liniyasiga ega bo'ldik. Biz past sifatli yig'ilishlar sonini minimallashtiramiz, umuman tizimning ishonchliligini oshiramiz va agar tizimimiz hali ham muvaffaqiyatsiz bo'lsa, biz uni qayta tiklash mexanizmlarini ishga tushiramiz.
Bu, albatta, dasturiy ta'minot sifati monitoringini avtomatlashtirish uchun kuch sarflashga arziydi; bu har doim ham tez jarayon emas, lekin vaqt o'tishi bilan u o'z mevasini beradi. Ishlab chiqarish muhitidagi yangi hodisani hal qilgandan so'ng, yomon tuzilish ishlab chiqarishga tushmasligi uchun sinov muhitida tekshiruvlar uchun qaysi monitorlarni qo'shish kerakligini darhol o'ylab ko'rishingizni tavsiya qilaman, shuningdek, ushbu muammolarni avtomatik ravishda tuzatish uchun skript yaratish.
Umid qilamanki, mening misollarim sizning harakatlaringizda sizga yordam beradi. Men o'z-o'zini davolash tizimlarini amalga oshirish uchun ishlatiladigan o'lchovlar misollaringizni ko'rishga qiziqaman.
Manba: www.habr.com