DevOps မူများကို အခြေခံ၍ အသွင်ပြောင်းခြင်း Archetype ခုနစ်ခု

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

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

ဂျွန်ဝီလီ John သည် DevOps ၏ဖခင်တစ်ဦးဖြစ်သည်။ John သည် ကုမ္ပဏီအများအပြားတွင် ဆယ်စုနှစ်များစွာ အတွေ့အကြုံရှိသူဖြစ်သည်။ မကြာသေးမီက သူသည် ၎င်းတို့တစ်ဦးစီနှင့် သူ၏အလုပ်တွင် ပေါ်ထွက်လာသော သီးခြားပုံစံများကို သတိပြုမိလာသည်။ ဤပုံစံများကိုအသုံးပြု၍ John သည် ကုမ္ပဏီများအား DevOps အသွင်ပြောင်းခြင်းဆီသို့ စစ်မှန်သောလမ်းကြောင်းပေါ်တွင် လမ်းညွှန်ပေးသည်။ DevOops 2018 ကွန်ဖရင့်မှ သူ၏ဟောပြောချက်ကို ဘာသာပြန်ချက်တွင် ဤပုံစံများအကြောင်း ပိုမိုလေ့လာပါ။

စပီကာအကြောင်း-

အိုင်တီစီမံခန့်ခွဲမှုတွင် 35 နှစ်ကျော်၊ Canonical တွင် OpenCloud ၏ရှေ့ဆက်သူအား ဖန်တီးနိုင်ခဲ့ပြီး Dell နှင့် Docker သို့ ရောင်းချခဲ့သည့် နှစ်ခုအပါအဝင် startup 10 ခုတွင် အလုပ်လုပ်ခဲ့သည်။ သူသည် လက်ရှိတွင် SJ Technologies တွင် DevOps နှင့် Digital Practices ၏ ဒုတိယဥက္ကဌဖြစ်သည်။

အောက်ပါတို့သည် ယောဟန်၏ရှုထောင့်မှပြောပြသော ဇာတ်လမ်းဖြစ်သည်။

ကျွန်တော့်နာမည်က John Willis ဖြစ်ပြီး Twitter မှာ တွေ့တာ အကောင်းဆုံးပါ။ @botchagalupeGmail နှင့် GitHub တွင် တူညီသော အမည်ပြောင်ရှိသည်။ ဒီ link ကို ၎င်းတို့အတွက် ကျွန်ုပ်၏ အစီရင်ခံစာများနှင့် တင်ပြချက်များ၏ ဗီဒီယိုမှတ်တမ်းများကို သင်ရှာတွေ့နိုင်ပါသည်။

ကုမ္ပဏီကြီးတွေ အသီးသီးမှာ CIO တွေနဲ့ တွေ့ဆုံမှုတွေ အများကြီးရှိတယ်။ သူတို့သည် DevOps ကို နားမလည်ကြောင်း မကြာခဏ ညည်းညူကြပြီး ၎င်းတို့အား ရှင်းပြရန် ကြိုးစားသူတိုင်းသည် အခြားအရာတစ်ခုခုကို လုံးဝပြောနေကြပါသည်။ ဒါရိုက်တာများသည် ရှင်းပြထားသည့်အတိုင်း အရာအားလုံးကို လုပ်ဆောင်နေပုံရသော်လည်း DevOps သည် အလုပ်မလုပ်သည့် နောက်တစ်ခုဖြစ်သည်။ ဒါတွေက နှစ်တစ်ရာကျော် သက်တမ်းရှိတဲ့ ကုမ္ပဏီကြီးတွေပါ။ သူတို့နဲ့ စကားပြောအပြီးမှာ ပြဿနာတော်တော်များများကို နည်းပညာမြင့်ဖြေရှင်းနည်းတွေနဲ့မဟုတ်ဘဲ နည်းပညာနိမ့်ပါးတဲ့နည်းလမ်းတွေက အကောင်းဆုံးဖြေရှင်းနိုင်တယ်ဆိုတာကို နိဂုံးချုပ်လိုက်ရပါတယ်။ ဌာနအသီးသီးက လူတွေနဲ့ ရိုးရိုးရှင်းရှင်း စကားပြောဖို့ ရက်သတ္တပတ်တွေကြာခဲ့တယ်။ ဤပို့စ်တွင် ပထမဆုံးပုံတွင် သင်တွေ့မြင်ရသည့်အရာမှာ ကျွန်ုပ်၏ နောက်ဆုံးပရောဂျက်ဖြစ်သည်။ သုံးရက်လောက် အလုပ်ပြီးတဲ့ အခန်းက ဒီပုံပါပဲ။

DevOps ဆိုတာဘာလဲ။

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

ယခု ကျွန်ုပ်တို့တွင် ဒေတာများစွာ၊ ပညာရပ်ဆိုင်ရာ သုတေသနပြုမှု ငါးနှစ်နှင့် စက်မှုလုပ်ငန်းစကေးဖြင့် စမ်းသပ်ထားသော သီအိုရီများ အများအပြားရှိသည်။ ဤသုတေသနက ကျွန်ုပ်တို့အား အောက်ပါတို့ကို ပြောပြသည်- အချို့သော အပြုအမူပုံစံများကို အဖွဲ့အစည်းယဉ်ကျေးမှုတစ်ခုတွင် ပေါင်းစပ်ပါက၊ သင်သည် အဆ 2000 အရှိန်ကို ရရှိနိုင်သည်။ ဤအရှိန်သည် ရေရှည်တည်တံ့ခိုင်မြဲမှုတွင် အလားတူတိုးတက်မှုနှင့် ကိုက်ညီပါသည်။ ဤသည်မှာ DevOps သည် မည်သည့်ကုမ္ပဏီအတွက်မဆို ပေးဆောင်နိုင်သည့် အကျိုးကျေးဇူးများ၏ အရေအတွက်အတိုင်းအတာတစ်ခုဖြစ်သည်။ လွန်ခဲ့သောနှစ်အနည်းငယ်က၊ ကျွန်ုပ်သည် Fortune 5000 ကုမ္ပဏီ၏ CEO အား DevOps ကို တင်ပြခဲ့ပါသည်။ တင်ဆက်မှုကို ပြင်ဆင်နေချိန် ငါးမိနစ်အတွင်း ကျွန်ုပ်၏ နှစ်ပေါင်းများစွာ အတွေ့အကြုံကို အကျဉ်းချုပ်ပြောရသောကြောင့် အလွန်စိတ်လှုပ်ရှားမိပါသည်။

အဆုံးတွင် ကျွန်ုပ်သည် အောက်ပါတို့ကို ပေးခဲ့သည်။ DevOps ၏အဓိပ္ပါယ်: ဤသည်မှာ လူ့စွမ်းအားအရင်းအနှီးကို မြင့်မားသောအဖွဲ့အစည်းဆိုင်ရာ အရင်းအနှီးအဖြစ်သို့ အသွင်ပြောင်းစေသည့် အလေ့အကျင့်များနှင့် ပုံစံများဖြစ်သည်။ ဥပမာတစ်ခုအနေနှင့် တိုယိုတာသည် လွန်ခဲ့သည့် နှစ် 50 သို့မဟုတ် 60 အတွင်း လည်ပတ်ပုံဖြစ်သည်။

(ဤနေရာမှစ၍ ဤပုံများကို အကိုးအကားအဖြစ်မဟုတ်ဘဲ သရုပ်ဖော်ပုံအဖြစ် ပံ့ပိုးပေးထားပါသည်။ ၎င်းတို့၏ အကြောင်းအရာများသည် ကုမ္ပဏီအသစ်တစ်ခုစီအတွက် ကွဲပြားပါမည်။ သို့သော်၊ ပုံအား သီးခြားကြည့်ရှုနိုင်ပြီး ချဲ့နိုင်ပါသည်။ ဒီလင့်မှာ။)

ဤအလေ့အကျင့်များထဲမှ အအောင်မြင်ဆုံးတစ်ခုဖြစ်သည်။ တနျဖိုးစမ်းချောင်းမြေပုံဤအကြောင်းအရာနှင့် ပတ်သက်၍ စာအုပ်ကောင်းများစွာ ရှိပြီး အအောင်မြင်ဆုံး စာအုပ်များမှာ Karen Martin ဖြစ်သည်။ ဒါပေမယ့် လွန်ခဲ့တဲ့တစ်နှစ်အတွင်းမှာ ဒီချဉ်းကပ်မှုက နည်းပညာမြင့်လွန်းတယ်လို့ ကောက်ချက်ချခဲ့တယ်။ သေချာတာကတော့ အားသာချက်တွေ အများကြီးရှိပြီး ကျွန်တော် အကျယ်တဝင့် သုံးဖူးပါတယ်။ ဒါပေမယ့် CEO က ဘာကြောင့် သူတို့ရဲ့ကုမ္ပဏီက ချဉ်းကပ်မှုအသစ်ကို မကူးပြောင်းနိုင်တာလဲလို့ မေးတဲ့အခါ၊ value stream mapping အကြောင်းပြောဖို့ စောလွန်းပါတယ်။ အရင်ဖြေရမယ့် အခြေခံမေးခွန်းတွေ အများကြီးရှိပါသေးတယ်။

ကျွန်ုပ်၏လုပ်ဖော်ကိုင်ဖက်အများစုသည် ကုမ္ပဏီတစ်ခုအား ကုမ္ပဏီအား အချက်ငါးချက် လမ်းညွှန်ပေးရုံမျှဖြင့် အမှားလုပ်မိပြီး ခြောက်လအကြာတွင် ဖြစ်ပျက်ခဲ့သည်များကို ကြည့်ရှုရန် ပြန်လာမည်ဟု ကျွန်ုပ်ထင်ပါသည်။ value stream mapping ကဲ့သို့ ကောင်းမွန်သော မူဘောင်တစ်ခုပင်လျှင် မမြင်နိုင်သော အစက်အပြောက်များ ရှိသည်။ ကုမ္ပဏီအသီးသီး၏ ဒါရိုက်တာများနှင့် ရာနှင့်ချီသော အင်တာဗျူးပြီးနောက်၊ ပြဿနာကို ၎င်း၏အစိတ်အပိုင်းများအဖြစ်သို့ ခွဲထုတ်နိုင်စေမည့် တိကျသောပုံစံတစ်ခုကို ကျွန်ုပ်တီထွင်ခဲ့ပြီး၊ ယခု ကျွန်ုပ်တို့သည် ဤအစိတ်အပိုင်းတစ်ခုစီကို အလှည့်ကျ ဆွေးနွေးပါမည်။ နည်းပညာဆိုင်ရာ ဖြေရှင်းချက်များကို မအကောင်အထည်ဖော်မီ၊ ဤပုံစံကို ကျွန်ုပ်အသုံးပြုပြီး ရလဒ်အနေဖြင့် ကျွန်ုပ်၏နံရံများကို ပုံကြမ်းများဖြင့် ဖုံးအုပ်ထားသည်။ မကြာသေးမီက၊ ကျွန်တော်သည် အပြန်အလှန်ရန်ပုံငွေဖြင့် အလုပ်လုပ်ခဲ့ပြီး ထိုကဲ့သို့သော ပုံချပ်ပေါင်း 100-150 ဖြင့် အဆုံးသတ်ခဲ့သည်။

ယဉ်ကျေးမှု ဓလေ့စရိုက်များသည် နံနက်စာအတွက် ကောင်းမွန်သော နည်းလမ်းများကို စားသုံးကြသည်။

အဓိကအချက်မှာ ဤအရာဖြစ်သည်- အဖွဲ့အစည်း၏ယဉ်ကျေးမှုမကောင်းပါက Lean၊ Agile၊ SAFE သို့မဟုတ် DevOps သည် မည်သည့်ပမာဏကိုမျှ အထောက်အကူမပြုပါ။ ၎င်းသည် scuba ဂီယာမပါဘဲ ရေငုပ်ခြင်း သို့မဟုတ် X-ray မပါပဲ လုပ်ဆောင်ခြင်းကဲ့သို့ဖြစ်သည်။ တစ်နည်းဆိုရသော် Drucker နှင့် Deming ကို အဓိပ္ပါယ်ဖော်ရန် - မကောင်းတဲ့ အဖွဲ့အစည်း ယဉ်ကျေးမှု သည် မည်သည့် ကောင်းမွန်သော စနစ် ကိုမဆို မျိုချ မိသွားလိမ့်မည် ။

ဤအဓိကပြဿနာကိုဖြေရှင်းရန်၊ အောက်ပါအဆင့်များကိုလုပ်ဆောင်ရန်လိုအပ်သည်-

1. အလုပ်အားလုံးကို မြင်သာအောင် လုပ်ပါ- အလုပ်အားလုံးကို မြင်သာအောင် လုပ်ရမယ်။ အချို့သောစခရင်ပေါ်တွင် ပြသရမည့်သဘောမဟုတ်သော်လည်း ၎င်းကိုမြင်နိုင်စေသင့်သည့်သဘောမျိုးဖြစ်သည်။
2. စုပေါင်းလုပ်ငန်းစီမံခန့်ခွဲမှုစနစ်များ- စီမံခန့်ခွဲမှုစနစ်များကို စုစည်းရန် လိုအပ်ပါသည်။ "လူမျိုးစု" အသိပညာနှင့် အဖွဲ့အစည်းဆိုင်ရာ အသိပညာပြဿနာတွင်၊ 10 တွင် 9 မှုတွင်၊ လူတွေသည် ပိတ်ဆို့မှုများဖြစ်သည်။ စာအုပ်ထဲမှာ Phoenix စီမံကိန်း ပြဿနာမှာ ပရောဂျက်ကို သုံးနှစ်နှောင့်နှေးနေသည့် Brent တစ်ဦးတည်းသော ပြဿနာဖြစ်သည်။ ပြီးတော့ ကျွန်တော်က နေရာတိုင်းလိုလို "Brents" ထဲကို ပြေးသွားတယ်။ အဆိုပါ ပိတ်ဆို့မှုများကို ဖြေရှင်းရန် ကျွန်ုပ်တို့စာရင်းတွင် နောက်ထပ်အချက်နှစ်ချက်ကို အသုံးပြုပါသည်။
3. ကန့်သတ်မှုနည်းလမ်းသီအိုရီ- Theory of Constraints။
4. ပူးပေါင်းဆောင်ရွက်မှု ဟက်ကာများ- ပူးပေါင်းဟက်ကာများ။
5. Toyota Kata (Kata လေ့ကျင့်ခြင်း။): Toyota Kata အကြောင်း အများကြီး မပြောတော့ပါဘူး။ သင်စိတ်ဝင်စားပါက၎င်းသည်ကျွန်ုပ်၏ GitHub တွင်ရှိသည်။ presentation တွေရှိတယ်။ ဤအကြောင်းအရာအားလုံးနီးပါးတွင်
6. စျေးကွက်ဦးတည်သောအဖွဲ့အစည်း- စျေးကွက်ဦးတည်သောအဖွဲ့အစည်း။
7. Shift-left စာရင်းစစ်များ- သံသရာ၏အစောပိုင်းအဆင့်များတွင်စာရင်းစစ်။

ကျွန်တော်ဟာ အဖွဲ့အစည်းတစ်ခုနဲ့ စတင်အလုပ်လုပ်တာ အရမ်းရိုးရှင်းပါတယ်။ ကုမ္ပဏီကိုသွားပြီး ဝန်ထမ်းတွေနဲ့ စကားပြောပါ။ သင်တွေ့မြင်ရသည့်အတိုင်း၊ အဆင့်မြင့်နည်းပညာများပါ ၀ င်ခြင်းမရှိပါ။ သင်လိုအပ်သမျှသည် ရေးရန်သာဖြစ်သည်။ ကျွန်ုပ်သည် အခန်းတစ်ခန်းတွင် အဖွဲ့များစွာကို စုစည်းပြီး ကျွန်ုပ်၏ archetype ခုနစ်ခုနှင့်ပတ်သက်၍ ၎င်းတို့ပြောနေသည့်အရာကို ခွဲခြမ်းစိတ်ဖြာပါ။ ပြီးတော့ သူတို့ကို အမှတ်အသားပေးပြီးတော့ သူတို့ပြောသမျှကို ဘုတ်ပေါ်မှာ ချရေးခိုင်းတယ်။ ပုံမှန်အားဖြင့်၊ ဤအစည်းအဝေးမျိုးတွင် မှတ်စုယူသူ တစ်ဦးရှိကာ အကောင်းဆုံးမှာ ဆွေးနွေးမှု၏ 10% ကို ဖမ်းယူနိုင်မည်ဖြစ်သည်။ ကျွန်ုပ်၏နည်းလမ်းဖြင့်၊ ဤကိန်းဂဏန်းအား ၄၀% ဝန်းကျင်အထိ မြှင့်တင်နိုင်သည်။

(ဤပုံဥပမာကို သီးခြားကြည့်ရှုနိုင်ပါသည်။ link ကိုကြည့်ပါ။)

ကျွန်ုပ်၏ချဉ်းကပ်မှုသည် William Schneider (William Schneider၊ Reengineering Alternative) ချဉ်းကပ်မှုသည် မည်သည့်အဖွဲ့အစည်းကိုမဆို လေးထောင့်လေးခုအဖြစ် ခွဲထုတ်နိုင်သည်ဟူသော အယူအဆအပေါ် အခြေခံသည်။ ကျွန်တော့်အတွက်၊ ဤပုံကားချပ်သည် များသောအားဖြင့် အဖွဲ့အစည်းတစ်ခုအား ခွဲခြမ်းစိတ်ဖြာသည့်အခါ ဖြစ်ပေါ်လာသည့် အခြားသော ရာနှင့်ချီသော ပုံကြမ်းများနှင့် လုပ်ဆောင်ခြင်း၏ ရလဒ်ဖြစ်သည်။ ထိန်းချုပ်မှုအဆင့်မြင့်သော်လည်း အရည်အချင်းနိမ့်သော အဖွဲ့အစည်းတစ်ခုရှိသည်ဟု ယူဆကြပါစို့။ ဤသည်မှာ အလွန်မလိုလားအပ်သော အခြေအနေတစ်ခုဖြစ်သည်- လူတိုင်းက လိုင်းကိုတက်နေချိန်ဖြစ်သော်လည်း ဘာလုပ်ရမည်ကို မည်သူမျှ မသိပေ။

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

(ဤပုံဥပမာကို သီးခြားကြည့်ရှုနိုင်ပါသည်။ link ကိုကြည့်ပါ။)

တင်းကျပ်စွာသတ်မှတ်ထားသော လမ်းညွှန်ချက်များပါသော နည်းလမ်းများသည် အမှန်တရား၏အောင်မြင်မှုကို နောက်ဆုံးတွင် အဟန့်အတားဖြစ်စေသည်ဟု ကျွန်ုပ်ယုံကြည်ပါသည်။ အထူးသဖြင့် Value stream mapping တွင် အချက်အလက်တည်ဆောက်ပုံနှင့်ပတ်သက်သည့် စည်းမျဉ်းများစွာရှိသည်။ အခုပြောနေတဲ့ အလုပ်ရဲ့အစောပိုင်းအဆင့်မှာ ဒီစည်းမျဉ်းတွေက ဘယ်သူ့အတွက်မှ အသုံးမဝင်ပါဘူး။ ဝှိုက်ဘုတ်ပေါ်တွင် ကုမ္ပဏီ၏ ပကတိအခြေအနေမှန်ကို လက်ထဲတွင် အမှတ်အသားပါသော ပုဂ္ဂိုလ်က အခြေအနေကို နားလည်ရန် အကောင်းဆုံးနည်းလမ်းဖြစ်သည်။ ဒီလိုအချက်အလက်တွေက အမှုဆောင်တွေဆီကို မရောက်ဘူး။ ဤအချိန်တွင်၊ မြှားတစ်စင်းကို မှားယွင်းစွာဆွဲသည်ဟု ၎င်းတို့အား ကြားဖြတ်ပြောခြင်းသည် မိုက်မဲပါသည်။ ဤအဆင့်တွင်၊ ဥပမာအားဖြင့်၊ ရိုးရှင်းသောစည်းမျဉ်းများကို အသုံးပြုခြင်းသည် ပိုကောင်းသည်- အဆင့်များစွာရှိသော abstraction ကို အရောင်မတူညီသော အမှတ်အသားများကို အသုံးပြုခြင်းဖြင့် ရိုးရိုးရှင်းရှင်း ဖန်တီးနိုင်သည်။

ဒီမှာ နည်းပညာမြင့်တာမရှိဘူးလို့ ထပ်ပြောပါရစေ။ အရာဝတ္ထုများ မည်သို့အလုပ်လုပ်ပုံ၏ ရည်ရွယ်ချက်အမှန်ကို အနက်ရောင်အမှတ်အသားဖြင့် ပုံဖော်ထားသည်။ လူတွေက လက်ရှိအခြေအနေနဲ့ ပတ်သက်ပြီး သူတို့မကြိုက်တာတွေကို ညွှန်ပြဖို့ အနီရောင် အမှတ်အသားကို အသုံးပြုကြပါတယ်။ သူတို့ရေးတာက ငါမဟုတ်ဘူး၊ အစည်းအဝေးပြီးလို့ CIO ကိုသွားတဲ့အခါ ပြင်ရမယ့်အချက် ၁၀ ချက်စာရင်းကို မတင်ပြဘူး။ ကုမ္ပဏီကလူတွေပြောနေတာတွေနဲ့ လက်ရှိသက်သေပြထားတဲ့ပုံစံတွေကြား ချိတ်ဆက်မှုတွေကို ရှာဖွေဖို့ ကြိုးစားနေပါတယ်။ နောက်ဆုံးတွင်၊ ပြဿနာအတွက် ဖြစ်နိုင်ခြေရှိသော အဖြေများကို အပြာရောင် အမှတ်အသားဖြင့် အကြံပြုထားသည်။

(ဤပုံဥပမာကို သီးခြားကြည့်ရှုနိုင်ပါသည်။ link ကိုကြည့်ပါ။)

ဤချဉ်းကပ်မှု၏ ဥပမာကို အထက်တွင် ပြထားသည်။ ဒီနှစ်အစောပိုင်းက ဘဏ်တစ်ခုနဲ့ လုပ်ခဲ့တယ်။ ဒီဇိုင်းနှင့် လိုအပ်ချက်များကို ပြန်လည်သုံးသပ်ခြင်းများကို တက်ရောက်ခွင့်မပြုကြောင်း အဆိုပါရှိ လုံခြုံရေးဌာနက ယုံကြည်ခဲ့သည်။

(ဤပုံဥပမာကို သီးခြားကြည့်ရှုနိုင်ပါသည်။ link ကိုကြည့်ပါ။)

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

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

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

(ဤပုံဥပမာကို သီးခြားကြည့်ရှုနိုင်ပါသည်။ link ကိုကြည့်ပါ။)

ဒီဘဏ်မှာ ကျွန်တော့်ရဲ့ နောက်ဆုံးတွေ့ဆုံမှုကတော့ ရင်းနှီးမြှုပ်နှံမှုဆော့ဖ်ဝဲလ်နဲ့ ပတ်သက်ပြီး လုပ်ဆောင်နေတဲ့ အဖွဲ့ပါ။ အမှတ်အသားပါသော စာရွက်တစ်ရွက်ပေါ်တွင် ပုံများရေးခြင်းသည် whiteboard ထက် ပိုကောင်းသည်၊ smartboard ထက်တောင် ပိုကောင်းကြောင်း သူတို့နှင့်အတူ ရှာဖွေတွေ့ရှိခဲ့သည်။

သင်မြင်ရသော ဓာတ်ပုံများသည် ကျွန်ုပ်တို့ အစည်းအဝေးစတုတ္ထနေ့တွင် ဟိုတယ်အစည်းအဝေးခန်းမ၏ ပုံစံဖြစ်သည်။ ပုံစံများ သို့မဟုတ် archetypes ကိုရှာဖွေရန် ဤပုံများကို ကျွန်ုပ်တို့အသုံးပြုခဲ့သည်။

ဒါကြောင့် ဝန်ထမ်းတွေကို မေးခွန်းတွေမေးပြီး အဖြေတွေကို အရောင်သုံးရောင် (အနက်၊ အနီ၊ အပြာ) နဲ့ အမှတ်အသားတွေနဲ့ ရေးချပါတယ်။ archetypes အတွက် သူတို့ရဲ့အဖြေတွေကို ငါခွဲခြမ်းစိတ်ဖြာတယ်။ အခု archetype တစ်ခုချင်းစီကို အလှည့်ကျ ဆွေးနွေးကြည့်ရအောင်။

1. အလုပ်အားလုံးကို မြင်သာအောင်ပြုလုပ်ပါ- အလုပ်အား မြင်သာအောင်ပြုလုပ်ပါ။

ကျွန်တော်လုပ်ကိုင်နေသော ကုမ္ပဏီအများစုသည် အထောက်အထားမဲ့အလုပ်၏ ရာခိုင်နှုန်း အလွန်မြင့်မားသည်။ ဥပမာ၊ ဝန်ထမ်းတစ်ယောက်က တခြားတစ်ယောက်ဆီလာပြီး တစ်ခုခုလုပ်ခိုင်းတဲ့အခါမျိုးပေါ့။ အဖွဲ့အစည်းကြီးများတွင် အလုပ်၏ 60% ကို အစီအစဉ်ချ၍မရပါ။ အလုပ်၏ 40% အထိသည် လုံးဝအထောက်အထားမရှိပေ။ ဒါက Boeing သာဆိုရင်၊ ငါ သူတို့ရဲ့ လေယာဉ်ကို ဘယ်တော့မှ မပျံသန်းတော့ဘူး။ အလုပ်တစ်ဝက်သာ မှတ်တမ်းတင်ထားလျှင် မှန်ကန်သည်ဖြစ်စေ၊ အခြားနည်းလမ်းအားလုံးသည် အသုံးမဝင်ကြောင်း သက်သေပြနေပါသည်- မည်သည့်အရာကိုမှ အလိုအလျောက်လုပ်ဆောင်ရန် ကြိုးပမ်းရာတွင် အရေးမကြီးပါ၊ အဘယ်ကြောင့်ဆိုသော် သိထားသော 50% သည် အလုပ်၏ အချောမွေ့ဆုံးနှင့် အတိကျဆုံးဖြစ်နိုင်ပြီး၊ သိသာထင်ရှားသောရလဒ်များကို ထုတ်ပေးမည်မဟုတ်သည့် အလိုအလျောက်စနစ်ကြောင့်ဖြစ်ပြီး အဆိုးဆုံးမှာ စာရွက်စာတမ်းမရှိသောတစ်ဝက်တွင်သာဖြစ်သည်။ စာရွက်စာတမ်းမရှိဘဲ၊ ဟက်ကာများနှင့် လျှို့ဝှက်အလုပ်မျိုးစုံကို ရှာတွေ့ရန် သို့မဟုတ် အစောပိုင်းတွင် ကျွန်တော်ဖော်ပြခဲ့သော အလွန် "Brents" ပိတ်ဆို့မှုများကို ရှာဖွေရန် မဖြစ်နိုင်ပါ။ Dominica DeGrandis ၏ အံ့သြဖွယ်စာအုပ်တစ်အုပ်ရှိသည်။ အလုပ်ကို မြင်သာအောင် လုပ်ပါ။သူမက ထုတ်ပြတယ်။ မတူညီသော "အချိန်ပေါက်ကြားမှု" ငါးခု၊ (အချိန်သူခိုး)

• လုပ်ငန်းစဉ်တွင် အလုပ်များလွန်းခြင်း (WIP)
• အမည်မသိ မှီခိုမှု
• မစီစဉ်ထားသော အလုပ်
• ဦးစားပေး ပဋိပက္ခများ
• လျစ်လျူရှုထားသော အလုပ်

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

The Phoenix Project သည် သုံးနှစ်နောက်ကျသော ပရောဂျက်တစ်ခုအကြောင်း အံ့သြဖွယ်ဇာတ်လမ်းတစ်ပုဒ်ဖြစ်သည်။ ယင်းကြောင့် ထုတ်ပယ်ခံရသည့် ဇာတ်ကောင်များအနက်မှ တစ်ဦးသည် ဆိုကရေးတီးတစ်မျိုးအဖြစ် မိတ်ဆက်သည့် အခြားဇာတ်ကောင်နှင့် တွေ့ဆုံသည်။ သူဘာမှားသွားလဲ အတိအကျ အဖြေရှာဖို့ ကူညီပေးတယ်။ ကုမ္ပဏီတွင် Brent ဟုခေါ်သော sysadmin တစ်ခုတည်းရှိပြီး အလုပ်အားလုံးသည် တစ်နည်းမဟုတ်တစ်နည်းဖြင့် သူ့ထံဖြတ်သန်းသွားသည်ကို တွေ့ရှိရသည်။ အစည်းအဝေးတစ်ခုတွင် လက်အောက်ငယ်သားတစ်ဦးကို မေးသည်- နာရီဝက်အလုပ်တာဝန်သည် တစ်ပတ်လျှင် အဘယ်ကြောင့် ကြာသနည်း။ အဖြေသည် တန်းစီခြင်းသီအိုရီနှင့် Little's Law ၏ အလွန်ရိုးရှင်းသော ရှင်းလင်းချက်ဖြစ်ပြီး၊ 90% အသုံးချမှုတွင် အလုပ်ချိန်တိုင်း ကိုးနာရီကြာကြောင်း ဖော်ပြသည်။ အလုပ်တစ်ခုစီကို အခြားလူခုနစ်ဦးထံ ပေးပို့ရန် လိုအပ်သောကြောင့် ထိုအချိန်သည် ၆၃ နာရီ၊ ခုနစ်ကြိမ် ကိုးကြိမ် ဖြစ်လာသည်။ ကျွန်ုပ်၏အချက်မှာ Little's Law သို့မဟုတ် ရှုပ်ထွေးသော တန်းစီခြင်းသီအိုရီကို အသုံးပြုရန် အနည်းဆုံး ဒေတာရှိရန် လိုအပ်ပါသည်။

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

အလုပ်အား မြင်နိုင်သည့်အခါ၊ ဒေတာကို သေသေသပ်သပ် ခွဲခြားနိုင်သည် (ဓာတ်ပုံတွင် Dominika လုပ်ဆောင်နေသည်)၊ ပေါက်ကြားမှုငါးခုကို အသုံးချနိုင်ပြီး အလိုအလျောက်စနစ်ကို အကောင်အထည်ဖော်နိုင်သည်။

2. အလုပ်စီမံခန့်ခွဲမှုစနစ်များကို စုစည်းပါ- အလုပ်စီမံခန့်ခွဲမှု

ကျွန်တော်ပြောနေတဲ့ ပုံစံတွေက ပိရမစ်လိုပါပဲ။ ပထမတစ်ခုက မှန်မှန်ကန်ကန်လုပ်ရင် ဒုတိယတစ်ခုက superstructure တစ်မျိုးပါ။ အများစုမှာ startup များအတွက် အလုပ်မဖြစ်ပါ။ Fortune 5000 ကဲ့သို့သော ကုမ္ပဏီကြီးများအတွက် ၎င်းတို့အား မှတ်သားထားရန် လိုအပ်ပါသည်။ ကျွန်ုပ်လုပ်ကိုင်ခဲ့သော နောက်ဆုံးကုမ္ပဏီတွင် လက်မှတ်ရောင်းချသည့်စနစ် 10 ခုရှိသည်။ အဖွဲ့တစ်ဖွဲ့က Remedy ကိုသုံးတယ်၊ နောက်တစ်ခုက သူတို့ရဲ့ကိုယ်ပိုင်စနစ်ကို ရေးတယ်၊ တတိယတစ်ယောက်က Jira ကိုသုံးတယ်၊ တခြားသူတွေကလည်း အီးမေးလ်နဲ့လုပ်တယ်။ ကုမ္ပဏီတစ်ခုတွင် မတူညီသော ပိုက်လိုင်းပေါင်း 30 ရှိသောအခါ အလားတူပြဿနာမျိုး ဖြစ်ပေါ်လာသော်လည်း ထိုကိစ္စအားလုံးကို ဆွေးနွေးရန် ကျွန်ုပ်မှာ အချိန်မရှိပါ။

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

လက်မှတ်ရောင်းသည့်ပြဿနာကိုဖြေရှင်းရန်၊ တစ်ခုတည်းသော၊ အဓိကစနစ်တစ်ခုကို ရွေးချယ်ရန် လိုအပ်သည်။ Jira ကိုသုံးရင် Jira ကိုပဲသုံးပါ။ အခြားရွေးချယ်စရာရှိရင် အဲဒါကိုပဲ သုံးပါ။ အဓိကအချက်မှာ လက်မှတ်များကို ဖွံ့ဖြိုးတိုးတက်ရေး လုပ်ငန်းစဉ်တွင် နောက်ထပ်ခြေလှမ်းအဖြစ် ထည့်သွင်းစဉ်းစားရန်ဖြစ်သည်။ လုပ်ဆောင်ချက်တိုင်းတွင် ဖွံ့ဖြိုးတိုးတက်မှုလုပ်ငန်းအသွားအလာတစ်လျှောက် စီးဆင်းသွားမည့် လက်မှတ်တစ်ခုရှိသင့်သည်။ လက်မှတ်များကို ဇာတ်လမ်းဘုတ်ပေါ်တွင် တင်ပြီးနောက် ၎င်းတို့အတွက် တာဝန်ရှိပါသည်။

အခြေခံအဆောက်အအုံနှင့် လုပ်ငန်းဆောင်ရွက်မှုများအပါအဝင် ဌာနအားလုံးနှင့် သက်ဆိုင်ပါသည်။ သို့မှသာ ကျွန်ုပ်တို့သည် ပိုမိုယုံကြည်စိတ်ချရသော အခြေအနေတစ်ရပ်ကို ဖန်တီးနိုင်မည်ဖြစ်သည်။ ဤလုပ်ငန်းစဉ်ကိုဖွဲ့စည်းပြီးသည်နှင့်၊ လျှောက်လွှာတစ်ခုစီအတွက်မည်သူမှာတာဝန်ရှိသည်ကိုရုတ်တရက်ဆုံးဖြတ်ရန်လွယ်ကူလာသည်။ ဘာဖြစ်လို့လဲဆိုတော့ အခု ကျွန်တော်တို့ 50% မဟုတ်ဘဲ 98% က ဝန်ဆောင်မှုအသစ်တွေကို လက်ခံရရှိလို့ပါ။ ဤ core process အလုပ်လုပ်ပါက စနစ်တစ်ခုလုံးတွင် တိကျမှု တိုးလာပါသည်။

ပိုက်လိုင်းဝန်ဆောင်မှု

၎င်းသည် ကော်ပိုရေးရှင်းကြီးများနှင့်သာ သက်ဆိုင်ပါသည်။ သင်သည် နယ်ပယ်အသစ်တွင် ကုမ္ပဏီအသစ်ဖြစ်ပါက၊ သင်၏လက်စွပ်များကို လှန်ပြီး သင်၏ Travis CI သို့မဟုတ် CircleCI ဖြင့် ကပ်လိုက်ပါ။ Fortune 5000 ကုမ္ပဏီနဲ့ ပတ်သက်ရင် ကျွန်တော်အလုပ်လုပ်တဲ့ ဘဏ်မှာ ဖြစ်ပျက်ခဲ့တဲ့ အဖြစ်အပျက်က ဥပမာပါ။ Google သည် ၎င်းတို့ထံလာပြီး IBM စနစ်ဟောင်းများ၏ ပုံကြမ်းများကို ပြသခဲ့သည်။ Google ကောင်လေးတွေက "ဒီအတွက် အရင်းအမြစ်ကုဒ်က ဘယ်မှာလဲ" လို့ ရှုပ်ပွပြီး မေးပါတယ်။ အရင်းအမြစ်ကုဒ်၊ GUI ပင်မရှိခဲ့ပါ။ ဤသည်မှာ ကြီးမားသော အဖွဲ့အစည်းများနှင့် ကိုင်တွယ်ဖြေရှင်းရမည့် ဖြစ်ရပ်မှန်ဖြစ်သည်- ရှေးဟောင်း ပင်မဘောင်တစ်ခုရှိ အသက် ၄၀ အရွယ် ဘဏ်မှတ်တမ်းများ။ ကျွန်ုပ်၏ဖောက်သည်များထဲမှတစ်ဦးသည် KeyBank အပလီကေးရှင်းအတွက် Circuit Breaker ပုံစံများအပြင် Chaos Monkey ပါရှိသော Kubernetes ကွန်တိန်နာများကို အသုံးပြုပါသည်။ သို့သော် ဤကွန်တိန်နာများသည် နောက်ဆုံးတွင် COBOL အပလီကေးရှင်းသို့ ချိတ်ဆက်သည်။

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

3. Theory of Constraints- ကန့်သတ်မှုသီအိုရီ

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

ဤပုံချပ်ပေါ်တွင် ဤအရာပေါ်လာသောအခါ၊ ထိုလူများကို အမှတ်အသားဖြင့် အတိအကျ ဝိုင်းထားလိုက်သည်- ဥပမာအားဖြင့်၊ အစည်းအဝေးတိုင်းတွင် Lou သည် လူအချို့ ရှိနေသည်ကို တွေ့ရပါသည်။ ပြီးတော့ ဒါက ငါ့အတွက် ရှင်းပါတယ်၊ ဒါက ဒေသခံ Brent ပါ။ CIO က တီရှပ်တစ်ထည်နဲ့ ဖိနပ်နဲ့ IBM ဝတ်စုံဝတ်ထားတဲ့ ယောက်ျားတစ်ယောက်ကို ရွေးချယ်တဲ့အခါ တခြားကောင်လေးက သူတို့ မပြောဘူးတဲ့ ဒါရိုက်တာကို မကြားချင်တဲ့အရာတွေကို ဒါရိုက်တာကို ပြောပြနိုင်လို့ပဲ သူတို့က ရွေးလိုက်တာ။ သူတို့ကုမ္ပဏီမှာ Fred နဲ့ Lou လို့ ခေါ်တဲ့ တစ်စုံတစ်ယောက် က သူတို့ကုမ္ပဏီမှာ ပိတ်ဆို့မှုတွေ ရှိနေတယ်လို့ သူတို့ကို ပြောလိုက်တယ်။ ဤပိတ်ဆို့မှုကို လွတ်မြောက်ရန် လိုအပ်သည်။ သူတို့ရဲ့ အသိပညာကို သူတို့ဆီက တစ်နည်းမဟုတ်တစ်နည်း ထုတ်ယူရမယ်။

ဤပြဿနာမျိုးကိုဖြေရှင်းရန်၊ ဥပမာအားဖြင့်၊ ကျွန်ုပ်သည် Slack ကိုအသုံးပြုရန်အကြံပြုနိုင်သည်။ စမတ်ကျတဲ့ CEO တစ်ယောက်က "ဘာလို့လဲ" လို့ မေးလိမ့်မယ်။ DevOps အတိုင်ပင်ခံများသည် ထိုသို့သောကိစ္စများတွင် အများအားဖြင့် ဖြေကြသည်- "ဘာလို့လဲဆိုတော့ လူတိုင်းလုပ်နေကြတာ။" CEO က တကယ်ထက်မြက်ရင် "ဒါဆို ဘာပြောမလဲ" ပြီးတော့ အဲဒါ စကားဝိုင်းရဲ့ အဆုံး။ အဲဒါကို ကျွန်တော်က ပြန်ဖြေတယ်- ကုမ္ပဏီမှာ Fred၊ Lou၊ Susie နဲ့ Jane မှာ ပိတ်ဆို့မှုလေးခုရှိလို့။ ၎င်းတို့၏ အသိပညာကို အဖွဲ့အစည်းအဖြစ် သတ်မှတ်ရန်၊ ဦးစွာ Slack ကို မိတ်ဆက်ပေးရန် လိုအပ်ပါသည်။ သင့်ဝီကီအားလုံးသည် ၎င်းတို့ရှိနေသည်ကို မည်သူမျှမသိသောကြောင့် လုံးဝအဓိပ္ပာယ်မရှိပေ။ အကယ်၍ အင်ဂျင်နီယာအဖွဲ့တစ်ဖွဲ့သည် front-end နှင့် back-end development နှစ်ခုလုံးကို ကိုင်တွယ်ဖြေရှင်းနိုင်ပြီး၊ လူတိုင်းသည် front-end development team သို့မဟုတ် infrastructure team ကို မေးခွန်းများဖြင့် ဆက်သွယ်နိုင်ကြောင်း သိထားရန် လိုအပ်ပါက၊ Lou သို့မဟုတ် Fred သည် wiki သို့ ချိတ်ဆက်ရန် အချိန်ရှိပေမည်။ ထို့နောက် Slack တွင် တစ်စုံတစ်ဦးသည် အဘယ်ကြောင့် အဆင့် 5 အလုပ်မလုပ်သနည်းဟု မေးနိုင်သည်။ ထို့နောက် Lou သို့မဟုတ် Fred သည် wiki ရှိ ညွှန်ကြားချက်များကို ပြင်ပေးလိမ့်မည်။ ဒီလုပ်ငန်းစဉ်ကို အကောင်အထည်ဖော်ရင်၊ အများကြီးဖြစ်လာလိမ့်မယ်။

ဤအရာသည် ကျွန်ုပ်၏ အဓိကအချက်ဖြစ်သည်- နည်းပညာမြင့်ဖြေရှင်းနည်းများကို အကြံပြုခြင်းမပြုမီ၊ သင်သည် ပထမဦးစွာ အခြေခံအုတ်မြစ်ကို ချထားရန် လိုအပ်ပြီး ၎င်းကို ဖော်ပြထားသည့် နည်းပညာနိမ့်သော ဖြေရှင်းနည်းများဖြင့် ၎င်းကို လုပ်ဆောင်နိုင်ပါသည်။ ၎င်းတို့၏ ရည်ရွယ်ချက်ကို မရှင်းပြဘဲ အဆင့်မြင့်နည်းပညာဖြင့် စတင်ပါက၊ ၎င်းသည် များသောအားဖြင့် ကောင်းစွာ မပြီးဆုံးနိုင်ပါ။ ကျွန်ုပ်တို့၏ဖောက်သည်များထဲမှတစ်ဦးသည် အလွန်စျေးသက်သာပြီး ရိုးရှင်းသောဖြေရှင်းချက်ဖြစ်သော Azure ML ကိုအသုံးပြုသည်။ သူတို့ရဲ့မေးခွန်းတွေရဲ့ 30% လောက်ကို Self-Learning Machine ကိုယ်တိုင်က ဖြေပေးခဲ့ပါတယ်။ ဤအရာအား ဒေတာသိပ္ပံ၊ စာရင်းအင်းပညာ သို့မဟုတ် သင်္ချာဘာသာရပ်တွင် နောက်ခံမရှိသော အော်ပရေတာများက ရေးသားခဲ့ခြင်းဖြစ်သည်။ ဒါပြောနေတာ။ ထိုသို့သောအဖြေတစ်ခု၏ကုန်ကျစရိတ်သည်အနည်းငယ်မျှသာဖြစ်သည်။

4. ပူးပေါင်းဆောင်ရွက်ရေး ဟက်ခ်များ- ပူးပေါင်းဆောင်ရွက်မှု ဟက်ကာများ

စတုတ္ထပုံစံမှာ အထီးကျန်မှုကို တိုက်ဖျက်ရမည် ဖြစ်သည်။ ဒါကို လူအများစုက သိပြီးပြီ- အထီးကျန်ခြင်းက ရန်လိုမှုကို ဖြစ်စေတယ်။ ဌာနတိုင်းသည် ၎င်း၏ကြမ်းပြင်ပေါ်တွင်ရှိပြီး လူများသည် ဓာတ်လှေကားမှလွဲ၍ အချင်းချင်း မဆက်ဆံပါက၊ ၎င်းတို့ကြားတွင် ရန်လိုမှုများ ဖြစ်ပေါ်လာရန် အလွန်လွယ်ကူပါသည်။ ဒါပေမယ့် ဆန့်ကျင်ဘက်အနေနဲ့ လူတွေက တစ်ခန်းတည်းနေရင် ချက်ချင်း ပျောက်သွားတယ်။ တစ်စုံတစ်ယောက်သည် ယေဘုယျစွပ်စွဲချက်တစ်ခုကို ပြုလုပ်သောအခါ—ဥပမာ၊ ထိုသို့သော-ထိုကဲ့သို့သော အင်တာဖေ့စ်တစ်ခုသည် မည်သည့်အခါမျှ အလုပ်မလုပ်ကြောင်း—တည်ဆောက်ရန် လွယ်ကူသည်။ အင်တာဖေ့စ်ကိုရေးသားသော ပရိုဂရမ်မာများသည် တိကျသောမေးခွန်းများကို စတင်မေးမြန်းရန် လိုအပ်ပြီး ဥပမာအားဖြင့်၊ အသုံးပြုသူသည် ကိရိယာကို လွဲမှားစွာအသုံးပြုခဲ့ကြောင်း မကြာမီ ရှင်းရှင်းလင်းလင်းဖြစ်လာမည်ဖြစ်သည်။

အထီးကျန်မှုကို ကျော်လွှားရန် နည်းလမ်းများစွာရှိသည်။ တခါက သြစတြေးလျမှာ ဘဏ်တစ်ခုအတွက် အကြံဉာဏ်တောင်းခဲ့ပေမယ့် ကျွန်တော့်မှာ ကလေးနှစ်ယောက်နဲ့ ဇနီးတစ်ယောက်ရှိတာကြောင့် ငြင်းဆိုခဲ့ပါတယ်။ ကျွန်တော်လုပ်နိုင်တာ အကောင်းဆုံးကတော့ graphical storytelling ကို အကြံပေးတာပါ။ အလုပ်ဖြစ်တယ်ဆိုတာ သက်သေပြထားတဲ့ အရာတစ်ခုပါ။ နောက်ထပ်စိတ်ဝင်စားဖို့ကောင်းတဲ့နည်းလမ်းကတော့ ပိန်ကော်ဖီအစည်းအဝေးတွေပါ။ အဖွဲ့အစည်းကြီးတစ်ခုတွင်၊ ၎င်းသည် အသိပညာဖြန့်ဝေရန် နည်းလမ်းကောင်းတစ်ခုဖြစ်သည်။ သင်သည် အတွင်းပိုင်း DevOpsDays၊ ဟက်ကာသွန် စသည်တို့ကို ကိုင်ဆောင်နိုင်သည်။

5. Coaching Kata

အစမှာ ပြောခဲ့သလိုပဲ ဒီနေ့တော့ ဒီအကြောင်းကို မပြောတော့ပါဘူး။ စိတ်ဝင်စားရင် ကြည့်ရှုနိုင်ပါတယ်။ ကျွန်ုပ်၏တင်ပြချက်အချို့.

Mike Rother မှ ဤအကြောင်းအရာနှင့် ပတ်သက်၍ ကောင်းမွန်သော အစီရင်ခံစာတစ်ခုလည်း ရှိပါသည်။

6. Market Oriented: စျေးကွက်ကို ဦးတည်သော အဖွဲ့အစည်း

ဤနေရာတွင် မတူညီသောပြဿနာများရှိသည်။ ဥပမာအားဖြင့် "I" people, "T" people, and "E" people. "ငါ" ဆိုသည်မှာ တစ်ခုတည်းကိုသာ လုပ်ဆောင်သူများဖြစ်သည်။ ၎င်းတို့သည် သီးခြားဌာနဆိုင်ရာ အဖွဲ့အစည်းများတွင် ရှိတတ်သည်။ "T" ဆိုသည်မှာ တစ်ခုခုကို ကောင်းကောင်းတတ်မြောက်ပြီး အခြားအရာများစွာတွင် ထူးချွန်သူများဖြစ်သည်။ "အီး" သို့မဟုတ် "ဖြီး" သည်ပင် အရည်အချင်းများစွာရှိသူများဖြစ်သည်။

Conway ၏ ဥပဒေသည် ဤနေရာတွင် အကျုံးဝင်သည် (Conway ၏ဥပဒေ၎င်း၏ အရိုးရှင်းဆုံးပုံစံဖြင့် အောက်ပါအတိုင်း အကျဉ်းချုံးနိုင်သည်- အဖွဲ့သုံးဖွဲ့သည် compiler တစ်ခုတွင် အလုပ်လုပ်ပါက ရလဒ် compiler တွင် အပိုင်းသုံးပိုင်း ပါဝင်သည်။ ထို့ကြောင့်၊ အဖွဲ့အစည်းတစ်ခုတွင် သီးခြားခွဲထုတ်မှုအဆင့်မြင့်မားပါက၊ Kubernetes၊ Circuit Breaker၊ API တိုးချဲ့နိုင်မှုနှင့် အခြားခေတ်မီသောအရာများကိုပင် အဖွဲ့အစည်းကိုယ်တိုင်ကဲ့သို့ပင် ဖွဲ့စည်းတည်ဆောက်မည်ဖြစ်သည်။ Conway ၏ အဆိုအရ တင်းကြပ်စွာ နှင့် သင်တို့ ငယ်ရွယ်သူများ အားလုံးကို နှောင့်ယှက်ရန်။

ဤပြဿနာအတွက် ဖြေရှင်းနည်းကို အကြိမ်များစွာ ဖော်ပြခဲ့ပြီးဖြစ်သည်။ ဥပမာအားဖြင့်၊ Fernando Fernandez မှ ဖော်ပြထားသော အဖွဲ့အစည်းဆိုင်ရာ ပုံစံများ ရှိပါသည်။ ၎င်းတွင် သီးခြားခွဲထားခြင်းဖြင့် ကျွန်ုပ်ဖော်ပြခဲ့သော ပြဿနာရှိသော ဗိသုကာသည် လုပ်ဆောင်ချက်ကို ဦးတည်သည့် ဗိသုကာတစ်ခုဖြစ်သည်။ ဒုတိယအမျိုးအစားမှာ အဆိုးဆုံးဖြစ်ပြီး အခြားနှစ်ခု၏ ပေါင်းစပ်မှုဖြစ်သည့် မက်ထရစ်ဗိသုကာလက်ရာဖြစ်သည်။ တတိယအချက်မှာ startup အများစုတွင် ကျွန်ုပ်တို့တွေ့မြင်နေရသည့်အရာဖြစ်ပြီး ကုမ္ပဏီကြီးများသည်လည်း ဤအမျိုးအစားနှင့် ကိုက်ညီရန် ကြိုးစားကြသည်။ ဒါက စျေးကွက်ကို ဦးတည်တဲ့ အဖွဲ့အစည်းတစ်ခုပါ။ ဤတွင်၊ ဖောက်သည်တောင်းဆိုမှုများကို ဖြစ်နိုင်သမျှအမြန်ဆုံးတုံ့ပြန်မှုရရှိရန် အကောင်းဆုံးဖြစ်အောင်ပြုလုပ်ခြင်းသည် ဖြစ်ပေါ်ပါသည်။ ဒါကို တစ်ခါတရံ ပြားတဲ့အဖွဲ့အစည်းလို့ ခေါ်တယ်။

ဤဖွဲ့စည်းပုံမှာ မတူညီသော နည်းလမ်းများစွာဖြင့် ဖော်ပြထားသော အသုံးအနှုန်းကို နှစ်သက်ပါသည်။ build/run commands များAmazon မှာ သူတို့ခေါ်တယ်။ ပီဇာအဖွဲ့နှစ်ဖွဲ့ဤဖွဲ့စည်းပုံတွင်၊ "I"-type လူအားလုံးကို ဝန်ဆောင်မှုတစ်ခုတည်းတွင် အုပ်စုဖွဲ့ထားပြီး၊ ၎င်းတို့သည် "T" အမျိုးအစားလူများနှင့် တဖြည်းဖြည်း ပိုမိုနီးကပ်လာကာ ကောင်းစွာစီမံခန့်ခွဲပါက ၎င်းတို့သည် "E" ဖြစ်လာနိုင်သည်။ ဤနေရာတွင် ပထမအငြင်းပွားမှုမှာ ထိုသို့သောဖွဲ့စည်းပုံသည် မလိုအပ်တော့ပေ။ ကျွန်ုပ်တို့တွင် သီးခြားစမ်းသပ်မှုဌာနတစ်ခုရှိနိုင်လျှင် ဌာနတိုင်းတွင် စမ်းသပ်သူအား အဘယ်ကြောင့် လိုအပ်သနည်း။ ငါတုံ့ပြန်သည်- ဤကိစ္စတွင်အပိုကုန်ကျစရိတ်များသည်အနာဂတ်တွင် "E" အမျိုးအစားဖြစ်လာသောအဖွဲ့အစည်းတစ်ခုလုံး၏စျေးနှုန်းဖြစ်သည်။ ထိုသို့သောဖွဲ့စည်းပုံတွင်၊ စမ်းသပ်သူသည် ကွန်ရက်များ၊ ဗိသုကာပညာ၊ ဒီဇိုင်းစသည်ဖြင့် တဖြည်းဖြည်းလေ့လာသင်ယူသည်။ ရလဒ်အနေဖြင့် အဖွဲ့အစည်း၏အဖွဲ့ဝင်တိုင်းသည် အဖွဲ့အစည်းအတွင်းဖြစ်ပျက်သမျှကို အပြည့်အဝသိရှိနားလည်ပါသည်။ ဤအစီအစဥ်သည် စက်မှုလုပ်ငန်းတွင် မည်သို့အလုပ်လုပ်သည်ကို သိလိုပါက ဆက်ဖတ်ပါ။ Mike Rother၊ Toyota Kata.

7. Shift-left auditors- လည်ပတ်မှုအစောပိုင်းတွင် စာရင်းစစ်ခြင်း။ လုံခြုံရေးလိုက်နာမှုသည် မြင်သာသောအင်္ဂါရပ်တစ်ခုဖြစ်သည်။

မင်းရဲ့ လုပ်ဆောင်ချက်တွေက အနံ့စမ်းသပ်မှု မအောင်မြင်တဲ့အခါ၊ မင်းအတွက် အလုပ်လုပ်ပေးတဲ့လူတွေက မတုံးဘူး။ အထက်ဖော်ပြပါ ဥပမာတွင်ကဲ့သို့၊ ၎င်းတို့သည် နေရာတိုင်းတွင် သက်ရောက်မှုအသေးအဖွဲ/မရှိဟု သတ်မှတ်ပြီး သုံးနှစ်ကြာသွားကာ မည်သူမျှ သတိမထားမိပါက၊ စနစ်သည် အလုပ်မလုပ်ကြောင်း လူတိုင်း ကောင်းစွာသိပါသည်။ သို့မဟုတ် အခြားသော ဥပမာ- အပြောင်းအလဲ အကြံပေးဘုတ်အဖွဲ့၊ ဗုဒ္ဓဟူးနေ့တိုင်း အစီရင်ခံစာများ တင်သွင်းရမည်ဟု ဆိုရမည်။ သီအိုရီအရ၊ စနစ်တစ်ခုလုံး မည်သို့အလုပ်လုပ်သည်ကို သိသင့်သည် (အထူးသဖြင့် လစာကောင်းကောင်းမရသော) လူအုပ်စုတစ်စုရှိပါသည်။ ပြီးခဲ့သောငါးနှစ်အတွင်း၊ ကျွန်ုပ်တို့၏စနစ်များသည် မယုံနိုင်လောက်အောင် ရှုပ်ထွေးနေကြောင်း သင်သတိပြုမိပေမည်။ ပြီးတော့ လူငါးယောက် ခြောက်ယောက်က သူတို့အကောင်အထည်မဖော်တဲ့ အပြောင်းအလဲတစ်ခုအတွက် ဆုံးဖြတ်ချက်တစ်ခုချရမှာဖြစ်ပြီး သူတို့ဘာမှမသိတဲ့အကြောင်း၊

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

စာရင်းစစ်တွေကို မဖြုတ်ဘဲ ဖိတ်ရမယ်။ စမ်းသပ်မှုအားလုံးအောင်မြင်ပါက၊ မပြောင်းလဲနိုင်သော ထာဝရတည်မြဲနေမည့် မပြောင်းလဲနိုင်သော ဒွိကွန်တိန်နာများကို သင်ရေးသားထားကြောင်း ၎င်းတို့အား ပြောပြပါ။ သင့်တွင် ကုဒ်အဖြစ် ပိုက်လိုင်းတစ်ခုရှိကြောင်း ၎င်းတို့အား ပြောပြပြီး ၎င်းကို ဆိုလိုကြောင်း ရှင်းပြပါ။ ၎င်းတို့အား အောက်ပါ ပုံကြမ်းကို ပြပါ- အားနည်းချက် စမ်းသပ်မှုများအားလုံးကို ကျော်ဖြတ်သည့် ကွန်တိန်နာတစ်ခုတွင် မပြောင်းလဲနိုင်သော၊ ဖတ်ရန်-သီးသန့် binary တစ်ခု၊ ပြီးတော့ အဲဒါကို ဘယ်တော့မှ မထိရုံမကဘူး၊ ပိုက်လိုင်းကို ဖန်တီးတဲ့ စနစ်တောင်မှ ဒိုင်နမစ်နည်းနဲ့ ဖန်တီးထားတာမို့ ဘယ်တော့မှ မထိဘူး။ Blockchain တစ်မျိုးကိုဖန်တီးရန် Vault ကိုအသုံးပြုသော Capital One ကဲ့သို့ဖောက်သည်များရှိသည်။ စာရင်းစစ်စားဖိုမှူး "ချက်ပြုတ်နည်းများ" ကိုသင်ပြသရန်မလိုအပ်ပါ။ ထုတ်လုပ်မှုတွင် Jira လက်မှတ်တစ်ခုဖြစ်ပျက်ခဲ့သည်နှင့်၎င်းအတွက်မည်သူမှာတာဝန်ရှိသည်ကိုရှင်းလင်းစွာပြသသော blockchain တစ်ခုကိုသူတို့ကိုပြသပါ။

အတိုင်း အစီရင်ခံစာSonatype မှ 2018 ခုနှစ်တွင်ဖန်တီးခဲ့ပြီး 2017 ခုနှစ်တွင် OSS ဒေါင်းလုဒ်တောင်းဆိုမှု 87 ဘီလီယံရှိခဲ့သည်။

အားနည်းချက်များကြောင့် ဖြစ်ပေါ်လာသည့် ဆုံးရှုံးမှုများမှာ မတန်တဆဖြစ်သည်။ ထို့အပြင် အထက်ဖော်ပြပါ ကိန်းဂဏန်းများတွင် အခွင့်အလမ်းစရိတ်များ မပါဝင်ပါ။ DevSecOps ၏ အကျဉ်းချုပ် သုံးသပ်ချက်။ ဒီနာမည်ရဲ့ အရည်အချင်းကို ဆွေးနွေးဖို့ စိတ်မဝင်စားဘူးလို့ ချက်ချင်းပဲ ပြောချင်ပါတယ်။ အဓိကအချက်မှာ၊ DevOps သည် အလွန်အောင်မြင်နေသောကြောင့်၊ ကျွန်ုပ်တို့သည် ဤပိုက်လိုင်းတွင် လုံခြုံရေးကို ပေါင်းထည့်ရန် ကြိုးစားသင့်ပါသည်။

ထိုသို့သော အစီအစဥ်တစ်ခု၏ ဥပမာ-


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

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

ရလဒ်

နိဂုံးချုပ်အားဖြင့်၊ ကျွန်ုပ်သည် DevSecOps အတွက် အကြံဉာဏ်အချို့ပေးပါမည်။ သင့်စနစ်များတည်ဆောက်ခြင်းလုပ်ငန်းစဉ်တွင် စာရင်းစစ်များပါဝင်ရန်၊ ၎င်းတို့၏ပညာရေးအတွက် အချိန်ရင်းနှီးမြှုပ်နှံရန်နှင့် ၎င်းတို့နှင့် ပူးပေါင်းဆောင်ရွက်ရန် လိုအပ်ပါသည်။ ထို့အပြင်၊ သင်သည် မှားယွင်းသော အပြုသဘောများအပေါ် လုံးဝ ရက်စက်ကြမ်းကြုတ်သောစစ်ပွဲကို ဆင်နွှဲရန် လိုအပ်သည်။ သင့် signal-to-noise အချိုးကို မသိပါက ဈေးအကြီးဆုံး အားနည်းချက်ကို စကင်န်ဖတ်သည့်ကိရိယာပင်လျှင် သင့် developer များတွင် အလွန်ဆိုးရွားသော အလေ့အထများကို ဖန်တီးနိုင်မည်ဖြစ်သည်။ ဆော့ဖ်ဝဲရေးသားသူများသည် ဖြစ်ရပ်များနှင့် ရှုပ်နေပြီး ၎င်းတို့ကို ဖျက်လိုက်ရုံပင်။ Equifax အဖြစ်အပျက်ကို သင်ကြားဖူးပါက ဤနေရာတွင် ဖြစ်ပျက်ခဲ့သည်မှာ အကြမ်းဖျင်းဖြစ်သည်- ပြင်းထန်မှုအမြင့်ဆုံးအချက်ပြမှုကို လျစ်လျူရှုထားသည်။ ထို့အပြင်၊ အားနည်းချက်များသည် လုပ်ငန်းအပေါ် ၎င်းတို့၏အကျိုးသက်ရောက်မှုကို ရှင်းရှင်းလင်းလင်းပြသသည့်နည်းဖြင့် ရှင်းပြရန်လိုအပ်ပါသည်။ ဥပမာအားဖြင့်၊ ၎င်းသည် Equifax ဖြစ်ရပ်နှင့် တူညီသော အားနည်းချက်ဖြစ်သည်ဟု သင်ပြောနိုင်သည်။ လုံခြုံရေးအားနည်းချက်များကို အခြားဆော့ဖ်ဝဲပြဿနာများကဲ့သို့ပင် သဘောထားသင့်သည်၊ ဆိုလိုသည်မှာ ၎င်းတို့ကို DevOps လုပ်ငန်းစဉ်တစ်ခုလုံးတွင် ပေါင်းစည်းသင့်သည်။ ၎င်းတို့ကို Jira၊ Kanban နှင့် အခြားအရာများမှတဆင့် စီမံခန့်ခွဲသင့်သည်။ ဆော့ဖ်ဝဲရေးသားသူများသည် ဤအရာကို အခြားသူတစ်ဦးက ပြုလုပ်လိမ့်မည်ဟု မယူဆသင့်ပါ—ဆန့်ကျင်ဘက်တွင်၊ လူတိုင်းက ၎င်းကို ပြုလုပ်သင့်သည်။ နောက်ဆုံးအနေနဲ့ လူတွေကို လေ့ကျင့်ပေးရာမှာ အားထုတ်ရင်းနှီးမြှုပ်နှံဖို့ လိုပါတယ်။

အသုံးဝင်သောလင့်များ

ဤသည်မှာ သင်အသုံးဝင်နိုင်သည်ဟု DevOops ညီလာခံမှ ဆွေးနွေးချက်အချို့ဖြစ်သည်။

• Sergey Berdnikov၊ Artyom Kalichkin - အောင်မြင်မှုဇာတ်လမ်း၊ သို့မဟုတ် "Dev+DevOps+Ops" (видео, အစီရင်ခံစာ၏မှတ်တမ်း)
• Barukh Sadogursky၊ Leonid Igolnik - DevOps at Scale - တမန်တော်သုံးပါးတွင် ဂရိဖြစ်ရပ်ဆိုးတစ်ခု (видео, အစီရင်ခံစာ၏မှတ်တမ်း)
• Alexander Titov၊ Kirill Tolkachev - DevOps၊ အင်ဂျင်နီယာများနှင့် အသိုင်းအဝိုင်း
• Timothy Lister — ဇာတ်ကောင်များ၊ အသိုင်းအဝိုင်းနှင့် ယဉ်ကျေးမှု- သာယာဝပြောရေးအတွက် အရေးကြီးသောအချက်များ

ဝင်ကြည့်လိုက်ပါ။ အစီအစဉ် DevOops 2020 မော်စကို - အဲဒီမှာ စိတ်ဝင်စားစရာတွေ အများကြီးရှိတယ်။

source: www.habr.com