Rostini aytsam, Ivan monitoring bo'limidagi hamkasblarining behuda urinishlariga tez-tez kulib turardi. Ular kompaniya rahbariyati ularga erishishni buyurgan ko'rsatkichlarni amalga oshirish uchun katta kuch sarfladilar. Ular shunchalik band ediki, boshqa birovning hech narsa qilishini xohlamadilar.
Ammo menejment uchun bu etarli emas edi - ular doimiy ravishda ko'proq va ko'proq yangi ko'rsatkichlarga buyurtma berishdi, juda tez oldin qilingan narsalardan foydalanishni to'xtatdilar.
So'nggi paytlarda hamma LeadTime - biznes xususiyatlarini etkazib berish vaqti haqida gapirmoqda. Ko'rsatkich aqldan ozgan raqamni ko'rsatdi - bitta vazifani bajarish uchun 200 kun. Qanday qilib hamma ooh va aahed va qo'llarini osmonga ko'tardi!
Biroz vaqt o'tgach, shovqin asta-sekin so'ndi va rahbariyat boshqa ko'rsatkichni yaratish buyrug'ini oldi.
Ivanga yangi o'lchov qorong'i burchakda jimgina o'lishi aniq edi.
Darhaqiqat, Ivan raqamni bilish hech kimga hech narsa demaydi, deb o'yladi. 200 kun yoki 2 kun - farq yo'q, chunki raqam bo'yicha sababni aniqlash va uning yaxshi yoki yomon ekanligini tushunish mumkin emas.
Bu o'lchovlarning odatiy tuzog'i: yangi ko'rsatkich mavjudlikning mohiyatini aytib beradi va qandaydir sirni tushuntiradi. Hamma bunga juda ko'p umid qiladi, lekin negadir hech narsa sodir bo'lmaydi. Ha, chunki sirni o'lchovlarda topmaslik kerak!
Ivan uchun bu o'tgan bosqich edi. U buni tushundi o'lchovlar uchun va barcha sirlarni izlash kerak , ya'ni. bu ko'rsatkich shakllanganligidir.
Onlayn do'kon uchun ta'sir ob'ekti uning pul olib keladigan mijozlari bo'ladi, DevOps uchun esa quvur liniyasi yordamida tarqatishlarni yaratadigan va tarqatadigan jamoalar bo'ladi.
Bir kuni, zaldagi qulay stulga o'tirib, Ivan ta'sir ob'ekti jamoalar ekanligini hisobga olib, DevOps ko'rsatkichlarini qanday ko'rishni xohlayotgani haqida yaxshilab o'ylab ko'rishga qaror qildi.
DevOps ko'rsatkichlarining maqsadi
Har bir inson yetkazib berish vaqtini qisqartirishni xohlayotgani aniq. 200 kun, albatta, yaxshi emas.
Lekin qanday qilib, bu savol?
Kompaniyada yuzlab jamoalar ishlaydi va har kuni minglab distribyutorlar DevOps quvuridan o'tadi. Haqiqiy etkazib berish vaqti tarqatish sifatida paydo bo'ladi. Har bir jamoaning o'z vaqti va o'ziga xos xususiyatlari bo'ladi. Qanday qilib bu chalkashliklar orasidan biror narsani topish mumkin?
Javob o'z-o'zidan paydo bo'ldi - biz muammoli jamoalarni topishimiz va ular bilan nima sodir bo'layotganini va nima uchun bu juda uzoq davom etayotganini aniqlashimiz kerak va "yaxshi" jamoalardan hamma narsani tezda qanday qilishni o'rganishimiz kerak. Buning uchun siz DevOps stendlarining har birida jamoalar o'tkazgan vaqtni o'lchashingiz kerak:
βTizimning maqsadi jamoalarni tribunalardan o'tgan vaqtga qarab tanlash bo'ladi, ya'ni. Natijada, biz raqam emas, balki tanlangan vaqt bilan buyruqlar ro'yxatini olishimiz kerak.
Agar biz stendda jami qancha vaqt sarflangani va tribunalar orasidagi tanaffusga qancha vaqt sarflanganini aniqlasak, biz jamoalarni topib, ularga qo'ng'iroq qilib, sabablarini batafsilroq tushunib, ularni yo'q qilishimiz mumkinΒ», - deb o'yladi Ivan.
DevOps uchun yetkazib berish vaqtini qanday hisoblash mumkin
Uni hisoblash uchun DevOps jarayoni va uning mohiyatini o'rganish kerak edi.
Kompaniya cheklangan miqdordagi tizimlardan foydalanadi va ma'lumotni faqat ulardan va boshqa hech qanday joyda olish mumkin emas.
Kompaniyadagi barcha vazifalar Jirada ro'yxatga olingan. Vazifa qabul qilinganda, u uchun filial yaratildi va amalga oshirilgandan so'ng, BitBucket va Pull Requestga majburiyat berildi. PR (Pull Request) qabul qilinganda, tarqatish avtomatik ravishda yaratildi va Nexus omborida saqlanadi.
Keyinchalik, tarqatish, avtomatik va qo'lda sinovning to'g'riligini tekshirish uchun Jenkins yordamida bir nechta stendlarda tarqatildi:
Ivan stendlarda vaqtni hisoblash uchun qaysi tizimlardan qanday ma'lumotlarni olish mumkinligini aytib berdi:
- Nexus'dan - Tarqatishni yaratish vaqti va buyruq kodini o'z ichiga olgan jildning nomi
- Jenkins'dan - Har bir ishning boshlanish vaqti, davomiyligi va natijasi, stend nomi (ish parametrlarida), bosqichlar (ish bosqichlari), Nexus-da tarqatish uchun havola.
- Ivan Jira va BitBucketni quvur liniyasiga kiritmaslikka qaror qildi, chunki... ular tayyor tarqatishni stendlarda tarqatish bilan emas, balki rivojlanish bosqichi bilan ko'proq bog'liq edi.
Mavjud ma'lumotlarga asoslanib, quyidagi diagramma tuzildi:
Distribyutsiyalarni yaratish uchun qancha vaqt ketishini va ularning har biriga qancha vaqt sarflanishini bilib, siz butun DevOps quvur liniyasidan (to'liq tsikl) o'tishning umumiy xarajatlarini osongina hisoblashingiz mumkin.
Mana DevOps ko'rsatkichlari Ivan bilan yakunlandi:
- Yaratilgan tarqatishlar soni
- Stendga "kelgan" va stenddan "o'tgan" tarqatish ulushi
- Stendda sarflangan vaqt (stend aylanishi)
- To'liq tsikl (barcha stendlar uchun umumiy vaqt)
- Ish muddati
- Stendlar orasidagi ishlamay qolish vaqti
- Xuddi shu stendda ishga tushirish o'rtasidagi ish vaqti
Bir tomondan, ko'rsatkichlar DevOps quvur liniyasini vaqt jihatidan juda yaxshi tavsifladi, boshqa tomondan, ular juda oddiy deb hisoblandi.
Yaxshi bajarilgan ishdan mamnun bo'lgan Ivan taqdimot qildi va uni rahbariyatga taqdim etish uchun ketdi.
U g'amgin va qo'llarini pastga tushirgancha qaytib keldi.
"Bu fiasko, uka", - kulib qo'ydi istehzoli hamkasbi ...
Batafsil maqolada o'qing "".
Manba: www.habr.com