DevOps မက်ထရစ်များ - တွက်ချက်မှုများအတွက် ဒေတာရယူရမည့်နေရာ

ရိုးရိုးသားသားပြောရလျှင် အိုင်ဗန်သည် စောင့်ကြည့်ရေးဌာနမှ လုပ်ဖော်ကိုင်ဖက်များ၏ အချည်းအနှီးကြိုးစားအားထုတ်မှုကို မကြာခဏ ရယ်မောလေ့ရှိသည်။ ၎င်းတို့သည် ကုမ္ပဏီ၏စီမံခန့်ခွဲမှုမှ ချမှတ်ထားသော တိုင်းတာမှုများကို အကောင်အထည်ဖော်ရန် ကြီးမားသော ကြိုးပမ်းအားထုတ်မှုများ ပြုလုပ်ခဲ့သည်။ သူတို့ အရမ်းအလုပ်များနေတာကြောင့် တခြားလူကို ဘာမှ မလုပ်စေချင်ဘူး။

သို့သော် စီမံခန့်ခွဲမှုအတွက် မလုံလောက်ပါ - ၎င်းတို့သည် ယခင်က လုပ်ဆောင်ခဲ့သည့်အရာများကို မသုံးတော့ဘဲ အလွန်လျင်မြန်စွာ တိုင်းတာမှုအသစ်များ ပိုများလာသည်။

မကြာသေးမီက၊ လူတိုင်းသည် လုပ်ငန်းအင်္ဂါရပ်များကို ပေးဆောင်ရမည့်အချိန်ဖြစ်သည့် LeadTime အကြောင်း ပြောဆိုလာကြသည်။ မက်ထရစ်သည် အလုပ်တစ်ခုလုပ်ဆောင်ရန် ရက်ပေါင်း 200 အရူးနံပါတ်တစ်ခုကို ပြသခဲ့သည်။ လူတိုင်းက အိုးးးးးးးးးးးးးးးးးးးးးးးးး။

အချိန်အတန်ကြာပြီးနောက်၊ ဆူညံသံ တဖြည်းဖြည်း ပျောက်ကွယ်သွားပြီး စီမံခန့်ခွဲသူသည် အခြားသော မက်ထရစ်တစ်ခုကို ဖန်တီးရန် အမိန့်တစ်ခု ရရှိခဲ့သည်။

မက်ထရစ်အသစ်သည် အမှောင်ထောင့်တွင် တိတ်တဆိတ်သေဆုံးသွားသကဲ့သို့ Ivan အတွက် လုံးဝရှင်းရှင်းလင်းလင်းပင်။

အမှန်မှာ၊ အိုင်ဗန်သည် နံပါတ်ကိုသိခြင်းသည် မည်သူကိုမျှ လုံးဝမပြောပြဟု တွေးခဲ့သည်။ ရက် 200 သို့မဟုတ် 2 ရက် - နံပါတ်ဖြင့်အကြောင်းပြချက်ကိုဆုံးဖြတ်ရန်နှင့်ကောင်းသည်ဖြစ်စေ၊ ဆိုးသည်ဖြစ်စေနားလည်ရန်မဖြစ်နိုင်သောကြောင့်ကွာခြားမှုမရှိပါ။

ဤသည်မှာ မက်ထရစ်များ၏ ပုံမှန်ထောင်ချောက်တစ်ခုဖြစ်သည်- မက်ထရစ်အသစ်သည် ဖြစ်တည်မှု၏အနှစ်သာရကို ပြောပြပြီး လျှို့ဝှက်လျှို့ဝှက်ချက်အချို့ကို ရှင်းပြလိမ့်မည်ဟု ထင်ရသည်။ လူတိုင်းက ဒီအတွက် အရမ်းမျှော်လင့်ထားပေမယ့် အကြောင်းတစ်ခုခုကြောင့် ဘာမှမဖြစ်ပါဘူး။ အဘယ်ကြောင့်ဆိုသော် လျှို့ဝှက်ချက်ကို မက်ထရစ်များတွင် မတွေ့သင့်သောကြောင့်ဖြစ်သည်။

အိုင်ဗန်အတွက်၊ ဤသည်မှာ လွန်မြောက်သော အဆင့်ဖြစ်သည်။ အဲဒါကို သူနားလည်တယ်။ မက်ထရစ်များသည် သာမန်သစ်သားပေတံတစ်ခုမျှသာဖြစ်သည်။ တိုင်းတာခြင်းအတွက်၊ လျှို့ဝှက်ချက်အားလုံးကို ရှာဖွေရမည်။ သြဇာလွှမ်းမိုးမှု၏အရာဝတ္ထု, i.e. ဒါက မက်ထရစ်ကို ဖွဲ့ထားတာ။

အွန်လိုင်းစတိုးတစ်ခုအတွက်၊ သြဇာလွှမ်းမိုးမှု၏အရာဝတ္တုသည် ၎င်း၏ဖောက်သည်များဖြစ်ပြီး DevOps အတွက်၊ ၎င်းသည် ပိုက်လိုင်းကိုအသုံးပြု၍ ဖြန့်ဖြူးမှုများကို ဖန်တီးကာ ဖြန့်ချိသည့်အဖွဲ့များဖြစ်လိမ့်မည်။

တစ်နေ့တွင် ခန်းမအတွင်းရှိ သက်တောင့်သက်သာရှိသော ကုလားထိုင်တစ်လုံး၌ ထိုင်ရင်း အိုင်ဗန်သည် ဩဇာလွှမ်းမိုးမှု၏အရာမှာ အသင်းအဖွဲ့များဖြစ်သည်ဟူသောအချက်ကို ထည့်သွင်းစဉ်းစားကာ DevOps မက်ထရစ်များကို သူမည်ကဲ့သို့မြင်လိုကြောင်း အသေအချာစဉ်းစားရန် ဆုံးဖြတ်ခဲ့သည်။

DevOps Metrics ၏ရည်ရွယ်ချက်

ပို့ဆောင်ချိန်ကို လူတိုင်း လျှော့ချလိုသည်မှာ ရှင်းပါသည်။ ရက်ပေါင်း 200 ကတော့ အဆင်မပြေပါဘူး။

ဒါပေမယ့် အဲဒါက ဘယ်လိုမေးခွန်းလဲ။

ကုမ္ပဏီသည် ရာနှင့်ချီသော အဖွဲ့များကို ခန့်အပ်ထားပြီး ဖြန့်ဖြူးမှု ထောင်ပေါင်းများစွာသည် DevOps ပိုက်လိုင်းကို နေ့စဉ် ဖြတ်သန်းနေပါသည်။ အမှန်တကယ် ပေးပို့သည့်အချိန်သည် ဖြန့်ဖြူးမှုတစ်ခုအဖြစ် ပေါ်လာမည်ဖြစ်သည်။ အဖွဲ့တစ်ဖွဲ့စီတွင် ၎င်း၏ကိုယ်ပိုင်အချိန်နှင့် ၎င်း၏ကိုယ်ပိုင်လက္ခဏာများ ရှိမည်ဖြစ်သည်။ ဤအရှုပ်အထွေးကြားတွင် မည်ကဲ့သို့ ရှာတွေ့နိုင်သနည်း။

အဖြေသည် သဘာဝအတိုင်း ပေါ်ထွက်သည် - ကျွန်ုပ်တို့သည် ပြဿနာအဖွဲ့များကို ရှာဖွေပြီး ၎င်းတို့တွင် ဘာဖြစ်နေသနည်း၊ အဘယ်ကြောင့် ဤမျှကြာနေရသည်ကို အဖြေရှာရန် လိုအပ်ပြီး အရာအားလုံးကို လျင်မြန်စွာ လုပ်ဆောင်နိုင်ပုံကို "ကောင်း" အဖွဲ့များမှ သင်ယူပါ။ ၎င်းကိုလုပ်ဆောင်ရန်၊ DevOps ရပ်တည်မှုတစ်ခုစီတွင် အသင်းများအသုံးပြုသည့်အချိန်ကို တိုင်းတာရန် လိုအပ်သည်-

“စနစ်ရဲ့ ရည်ရွယ်ချက်က သူတို့ အမှတ်ပေးဇယားကို ကျော်ဖြတ်တဲ့ အချိန်ပေါ်မူတည်ပြီး အသင်းတွေကို ရွေးချယ်ဖို့ ဖြစ်တယ်။ ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် ရွေးချယ်ထားသောအချိန်နှင့်အတူ နံပါတ်တစ်ခုမဟုတ်ဘဲ ညွှန်ကြားချက်များစာရင်းကို ရယူသင့်သည်။

စုစုပေါင်း ရပ်တည်မှုမှာ အချိန်ဘယ်လောက်ကုန်ပြီး မတ်တပ်ရပ်တဲ့ကြားက အချိန်ဘယ်လောက်ကုန်သွားတယ်ဆိုတာ သိရင်၊ အသင်းတွေကို ရှာတွေ့နိုင်တယ်၊ သူတို့ကို ဖုန်းဆက်ပြီး အကြောင်းပြချက်တွေကို အသေးစိတ်နားလည်ပြီး သူတို့ကို ဖယ်ရှားပစ်နိုင်တယ်" ဟု အိုင်ဗန်က တွေးသည်။

DevOps အတွက် ပို့ဆောင်ချိန်ကို တွက်ချက်နည်း

၎င်းကိုတွက်ချက်ရန်အတွက် DevOps လုပ်ငန်းစဉ်နှင့် ၎င်း၏အနှစ်သာရကို စေ့စေ့စပ်စပ်လေ့လာရန် လိုအပ်သည်။

ကုမ္ပဏီသည် အကန့်အသတ်ရှိသော စနစ်များကို အသုံးပြုထားပြီး သတင်းအချက်အလက်များကို ၎င်းတို့ထံမှသာ ရရှိနိုင်ပြီး အခြားနေရာများတွင်သာ ရရှိနိုင်သည်။

ကုမ္ပဏီရှိ အလုပ်အားလုံးကို Jira တွင် မှတ်ပုံတင်ထားသည်။ လုပ်ဆောင်စရာတစ်ခုကို လုပ်ဆောင်သောအခါ၊ ၎င်းအတွက် ဌာနခွဲတစ်ခုကို ဖန်တီးပြီး အကောင်အထည်ဖော်ပြီးနောက် BitBucket နှင့် Pull Request သို့ ကတိကဝတ်တစ်ခု ပြုလုပ်ခဲ့သည်။ PR (Pull Request) ကို လက်ခံလိုက်သောအခါ၊ ဖြန့်ဖြူးမှုတစ်ခုကို Nexus repository တွင် အလိုအလျောက်ဖန်တီးပြီး သိမ်းဆည်းခဲ့သည်။

ထို့နောက်၊ ဖြန့်ချိမှု၊ အလိုအလျောက်နှင့် လူကိုယ်တိုင်စမ်းသပ်ခြင်း၏ မှန်ကန်မှုကို စစ်ဆေးရန် Jenkins ကို အသုံးပြု၍ အရောင်းအ၀ယ်အများအပြားတွင် ဖြန့်ဖြူးမှုကို စတင်ခဲ့သည်။

Ivan သည် မည်သည့်စနစ်မှ မည်သည့်အချက်အလက်ကို ယူဆောင်နိုင်သည်ဆိုသည်ကို ဖော်ပြခဲ့သည်မှာ အချိန်ကို တွက်ချက်နိုင်သည် ။

• Nexus မှ - ဖြန့်ဝေဖန်တီးမှုအချိန်နှင့် အမိန့်ကုဒ်ပါရှိသော ဖိုင်တွဲ၏အမည်
• Jenkins မှ - အလုပ်တစ်ခုစီ၏ စတင်ချိန်၊ ကြာချိန်နှင့် ရလဒ်၊ ရပ်တည်မှုအမည် (အလုပ်ဘောင်များအတွင်း)၊ အဆင့်များ (အလုပ်အဆင့်များ)၊ Nexus တွင် ဖြန့်ဖြူးမှုသို့ ချိတ်ဆက်ပါ။
• Ivan သည် ပိုက်လိုင်းတွင် Jira နှင့် BitBucket တို့ကို မထည့်သွင်းရန် ဆုံးဖြတ်ထားသောကြောင့် ... ၎င်းတို့သည် ဖွံ့ဖြိုးတိုးတက်မှုအဆင့်နှင့် ပိုမိုဆက်စပ်နေပြီး အချောထည်ဖြန့်ချီခြင်းကို စင်များပေါ်တွင် လွှင့်တင်ခြင်းမပြုပါ။

ရရှိနိုင်သော အချက်အလက်များအပေါ် အခြေခံ၍ အောက်ပါ ပုံကြမ်းကို ရေးဆွဲခဲ့သည်-

ဖြန့်ဖြူးမှုများကို ဖန်တီးရန် အချိန်မည်မျှကြာပြီး ၎င်းတို့တစ်ခုစီအတွက် အချိန်မည်မျှသုံးစွဲသည်ကို သိရှိခြင်းဖြင့် DevOps ပိုက်လိုင်းတစ်ခုလုံး (သံသရာတစ်ခုလုံး) ဖြတ်သန်းသွားရမည့် စုစုပေါင်းကုန်ကျစရိတ်များကို အလွယ်တကူ တွက်ချက်နိုင်ပါသည်။

ဤသည်မှာ Ivan နှင့်အဆုံးသတ်ထားသော DevOps မက်ထရစ်များဖြစ်သည်။

• ဖြန့်ဝေမှုအရေအတွက်ကို ဖန်တီးခဲ့သည်။
• ရပ်တည်မှုသို့ "လာ" နှင့် "ကျော်" ဖြန့်ဖြူးမှုဝေစု
• မတ်တပ်ရပ်ချိန် (stand cycle)
• သံသရာအပြည့် (ရပ်အားလုံးအတွက် စုစုပေါင်းအချိန်)
• အလုပ်ကြာချိန်
• ရပ်နေချိန်
• တူညီသောရပ်တည်မှုတွင် အလုပ်စတင်ခြင်းကြားတွင် စက်ရပ်ချိန်

တစ်ဖက်တွင်၊ မက်ထရစ်များသည် အချိန်ကာလအရ DevOps ပိုက်လိုင်းကို ကောင်းမွန်စွာဖော်ပြပြီး အခြားတစ်ဖက်တွင်၊ ၎င်းတို့သည် အလွန်ရိုးရှင်းသည်ဟု ယူဆပါသည်။

အလုပ်ကို ကောင်းမွန်စွာ ပြီးမြောက်ခြင်းအတွက် ကျေနပ်အားရစွာဖြင့် အိုင်ဗန်သည် တင်ဆက်မှုတစ်ခုကို ပြုလုပ်ပြီး စီမံခန့်ခွဲရေးထံ တင်ပြသွားခဲ့သည်။

ညို့ညို့လက်နဲ့ ပြန်လာခဲ့တယ်။

“ဒါက အလိမ်အညာပါပဲ အစ်ကို” လို့ မထင်မှတ်ထားတဲ့ လုပ်ဖော်ကိုင်ဖက်က ပြုံးပြီး...

ဆောင်းပါးတွင် ဆက်လက်ဖတ်ရှုရန် "ရလဒ်တွေက အိုင်ဗန်ကို ဘယ်လောက်မြန်မြန်ဆန်ဆန် ကူညီပေးခဲ့လဲ။"။

source: www.habr.com