ပရိုဂရမ်မာများ၊ devops နှင့် Schrödinger ၏ကြောင်များ

ကွန်ရက်အင်ဂျင်နီယာတစ်ယောက်ရဲ့ အဖြစ်မှန် (ခေါက်ဆွဲနဲ့ ဆား...?)

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

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

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

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

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

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

Developer များသည် အဆုံးအဖြတ်ပေးသော ကိရိယာများဖြင့် လုပ်ဆောင်လေ့ရှိသည်။ ဟုတ်ပါတယ်၊ compilers၊ linkers၊ operating systems - ဒါတွေအားလုံးဟာ ရှုပ်ထွေးတဲ့စနစ်တွေဖြစ်ကြပေမယ့်၊ သူတို့က အဆုံးအဖြတ်ရလဒ်တစ်ခုပေးတယ်ဆိုတဲ့အချက်ကို ကျင့်သားရပြီး၊ အဲဒါတွေကို အဆုံးအဖြတ်ပေးတယ်လို့ စိတ်ကူးကြည့်ကြတယ်- တူညီတဲ့ input data တွေကို ပေးမယ်ဆိုရင်၊ များသောအားဖြင့် ကျွန်တော်တို့ မျှော်လင့်ပါတယ်။ ဤစနစ်များမှ တူညီသော အထွက်နှုန်း။ output (“bug”) တွင် ပြဿနာရှိလျှင် developer များသည် input data (အသုံးပြုသူ သို့မဟုတ် developer လုပ်ငန်းစဉ်အတွင်း tool အစုံမှ) ကို ခွဲခြမ်းစိတ်ဖြာခြင်းဖြင့် ၎င်းကို developer များက ဖြေရှင်းပေးသည်။ သူတို့က "အမှား" ကိုရှာဖွေပြီးနောက်ထည့်သွင်းဒေတာကိုပြောင်းလဲပါ။ ၎င်းသည် "bug" ကိုပြင်သည်။

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

အမှန်မှာ၊ အဆုံးအဖြတ်မရှိသောရလဒ်ကို သူ့ကိုယ်သူ bug တစ်ခုဟု ယူဆသည်- အကယ်၍ မျှော်လင့်မထားသော သို့မဟုတ် မှားယွင်းသော output ကို ပြန်မထုတ်ပါက၊ developer များသည် စုံစမ်းစစ်ဆေးမှုကို stack ၏ အခြားအစိတ်အပိုင်းများ (အော်ပရေးရှင်းစနစ်၊ ကွန်ရက် စသည်ဖြင့်) သို့ တိုးချဲ့လေ့ရှိပါသည်။ အနည်းနှင့်အများ အဆုံးအဖြတ်ပေးသည်၊ တူညီသောထည့်သွင်းမှုဒေတာဖြင့် တူညီသောရလဒ်ကိုထုတ်ပေးသည်... နှင့် ဒါမဟုတ်ရင်ဒါဆို ဒါက bug တစ်ခုလို့ ယူဆနေတုန်းပဲ။ ၎င်းသည် ယခုအခါ လည်ပတ်မှုစနစ် သို့မဟုတ် ကွန်ရက် ချို့ယွင်းချက်တစ်ခုဖြစ်သည်။

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

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

ထို့ကြောင့် အတွေ့အကြုံရှိ အင်ဂျင်နီယာများသည် အဖြစ်အပျက်အားလုံးတွင် အရင်းခံအကြောင်းတရားတစ်ခုရှိသည်ကို သံသယဝင်ရန် လွယ်ကူသည်၊ “Five Whys” ကဲ့သို့သော နည်းပညာများသည် ထိုအရင်းအမြစ်ကို မှန်ကန်စွာ (ထပ်ခါထပ်ခါ!) ဖြစ်ပေါ်စေလိမ့်မည်။ တကယ်တော့၊ ဒါက လက်တွေ့မှာ သေသေသပ်သပ်နဲ့ မကိုက်ညီတဲ့ ပဟေဠိအပိုင်းအစတွေက သူတို့ရဲ့ ကိုယ်ပိုင်အတွေ့အကြုံနဲ့ ဆန့်ကျင်ဘက်ပါ။ ထို့ကြောင့် သူတို့သည် ဤအယူအဆကို ပိုမိုလွယ်ကူစွာ လက်ခံကြသည်။

ဟုတ်ပါတယ်၊ developer တွေက နုံအတာ၊ မိုက်မဲတာ ဒါမှမဟုတ် linearity ကို ဘယ်လိုလှည့်စားနိုင်တယ်ဆိုတာ နားမလည်ဘူးလို့ မပြောပါဘူး။ အတွေ့အကြုံရှိ ပရိုဂရမ်မာများသည် ၎င်းတို့၏အချိန်များတွင် အဆုံးအဖြတ်မဟုတ်သော သတ်မှတ်ချက်များစွာကိုလည်း တွေ့မြင်ဖူးကြပေမည်။

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

၎င်းသည် လေ့လာတွေ့ရှိထားသော developer တုံ့ပြန်မှုများကို အပြည့်အဝရှင်းပြနိုင်မည်မဟုတ်သော်လည်း ကျွန်ုပ်တို့၏တုံ့ပြန်မှုများသည် အချက်များစွာ၏ ရှုပ်ထွေးသောရောနှောမှုဖြစ်ကြောင်း ခိုင်လုံသောသတိပေးချက်တစ်ခုဖြစ်သည်။

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

source: www.habr.com