ကုဒ်အဖြစ် အခြေခံအဆောက်အဦ- XP တွင် ပြဿနာများကို မည်သို့ကျော်လွှားမည်နည်း။

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

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

ငါတို့က ဘယ်သူလဲ၊ ငါတို့ဘယ်မှာလဲ၊ ငါတို့မှာ ဘယ်လိုအခက်အခဲတွေရှိလဲ။

ကျွန်ုပ်တို့သည် လက်ရှိတွင် ပရိုဂရမ်မာခြောက်ဦးနှင့် အခြေခံအဆောက်အအုံအင်ဂျင်နီယာ သုံးဦးပါ၀င်သော Sre Onboarding Team တွင် ရှိနေပါသည်။ ကျွန်တော်တို့အားလုံး Infrastructure ကို code (IaC) အဖြစ် ရေးဖို့ ကြိုးစားနေပါတယ်။ ကျွန်ုပ်တို့သည် အခြေခံအားဖြင့် ကုဒ်ရေးနည်းကို သိရှိပြီး "ပျမ်းမျှအထက်" ဆော့ဖ်ဝဲရေးသားသူများဖြစ်ခြင်း၏ သမိုင်းကြောင်းရှိသောကြောင့် ၎င်းကို ကျွန်ုပ်တို့ပြုလုပ်ခြင်းဖြစ်သည်။

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

ကျွန်ုပ်တို့၏ IaC တွင် ကျွန်ုပ်တို့အသုံးပြုသည့် နည်းပညာအစုအဝေး။

• အရင်းအမြစ်များဖန်တီးရန်အတွက် Terraform
• ပုံများ တပ်ဆင်ရန်အတွက် Packer ဤအရာများသည် Windows၊ CentOS 7 ပုံများဖြစ်သည်။
• Jsonnet သည် drone.io တွင် အစွမ်းထက်သောတည်ဆောက်မှုတစ်ခုပြုလုပ်ရန်နှင့် packer json နှင့် ကျွန်ုပ်တို့၏ terraform module များကိုထုတ်လုပ်ရန်။
• Azure ။
• ပုံတွေကို ပြင်ဆင်တဲ့အခါမှာ သိနိုင်ပါတယ်။
• အရန်ဝန်ဆောင်မှုများနှင့် script များပြင်ဆင်ခြင်းအတွက် Python။
• အဖွဲ့၀င်များအကြား မျှဝေထားသော plugins များဖြင့် VSCode တွင် ဤအရာအားလုံးကို။

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

ကျွန်ုပ်တို့သည် လက်ရှိတွင် အောက်ပါ IaC ပြဿနာများနှင့် ရင်ဆိုင်နေရသည်-

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

Extreme Programming (XP) ကို ကယ်တင်ပါ။

ဆော့ဖ်ဝဲရေးသားသူအားလုံးသည် Extreme Programming (XP) နှင့် ၎င်းနောက်ကွယ်မှ ရပ်တည်နေသော အလေ့အကျင့်များနှင့် ရင်းနှီးကြသည်။ ကျွန်ုပ်တို့အများစုသည် ဤချဉ်းကပ်နည်းဖြင့် လုပ်ဆောင်ခဲ့ပြီး အောင်မြင်ခဲ့သည်။ ဒီတော့ အခြေခံအဆောက်အအုံဆိုင်ရာ စိန်ခေါ်မှုတွေကို ကျော်လွှားဖို့ အဲဒီနေရာမှာ ချမှတ်ထားတဲ့ အခြေခံမူတွေနဲ့ အလေ့အကျင့်တွေကို ဘာကြောင့် အသုံးမချတာလဲ။ ကျွန်ုပ်တို့သည် ဤချဉ်းကပ်မှုကိုခံယူပြီး ဘာဖြစ်မည်ကို ကြည့်ရှုရန် ဆုံးဖြတ်ခဲ့သည်။

သင့်လုပ်ငန်းအတွက် XP ချဉ်းကပ်မှု၏ အသုံးချနိုင်မှုကို စစ်ဆေးခြင်း။ဤသည်မှာ XP အတွက် ကောင်းမွန်သင့်လျော်သော ပတ်ဝန်းကျင်၏ ဖော်ပြချက်ဖြစ်ပြီး ကျွန်ုပ်တို့နှင့် မည်သို့သက်ဆိုင်သည်-

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

2. နည်းပညာအသစ်များကို အသုံးပြု၍ သတ်မှတ်ထားသော အချိန်ပရောဂျက်များကြောင့် ဖြစ်ပေါ်လာသော အန္တရာယ်များ။ ကျွန်ုပ်တို့မသိသောအရာအချို့ကို အသုံးပြုသောအခါတွင် ကျွန်ုပ်တို့သည် အန္တရာယ်များကြုံတွေ့ရနိုင်သည်။ ပြီးတော့ ဒါက 100% ငါတို့ကိစ္စ။ ကျွန်ုပ်တို့၏ ပရောဂျက်တစ်ခုလုံးသည် ကျွန်ုပ်တို့နှင့် လုံးဝရင်းနှီးခြင်းမရှိသော နည်းပညာများကို အသုံးပြုခြင်းဖြစ်ပါသည်။ ယေဘူယျအားဖြင့်တော့ ဒါဟာ စဉ်ဆက်မပြတ် ပြဿနာတစ်ခုမို့... အခြေခံအဆောက်အအုံကဏ္ဍတွင် နည်းပညာအသစ်အဆန်းများစွာ ပေါ်ထွက်လျက်ရှိသည်။

၃.၄။ အသေးစား၊ ပူးတွဲတည်ရှိသော တိုးချဲ့ဖွံ့ဖြိုးရေးအဖွဲ့။ သင်အသုံးပြုနေသည့် အလိုအလျောက်နည်းပညာသည် ယူနစ်နှင့် လုပ်ဆောင်မှုဆိုင်ရာ စမ်းသပ်မှုများကို ခွင့်ပြုပေးသည်။ ဒီအချက်နှစ်ချက်က ကျွန်တော်တို့နဲ့ သိပ်မကိုက်ညီပါဘူး။ ပထမဦးစွာ၊ ကျွန်ုပ်တို့သည် ညှိနှိုင်းရေးအဖွဲ့မဟုတ်ပါ၊ ဒုတိယအချက်မှာ ကျွန်ုပ်တို့တွင် ကိုးဦးရှိသည်၊ ကြီးမားသောအသင်းဟု ယူဆနိုင်ပါသည်။ "ကြီးမားသော" အဖွဲ့၏ အချို့သော အဓိပ္ပါယ်ဖွင့်ဆိုချက်များအရ အများအပြားသည် 3,4+ ယောက်ဖြစ်သည်။

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

XP Feedback Loop Principle

ငါ့နားလည်မှုအရ၊ တုံ့ပြန်ချက်က မေးခွန်းရဲ့အဖြေပဲ၊ ငါလုပ်တာမှန်သလား၊ ငါတို့အဲဒီကိုသွားမလား။ XP တွင် ဤအရာအတွက် မြင့်မြတ်သောအစီအစဥ်တစ်ခု ရှိသည်- အချိန်တုံ့ပြန်ချက် ကွင်းဆက်။ စိတ်ဝင်စားဖို့ကောင်းတာက ကျွန်ုပ်တို့ဟာ အောက်တန်းကျလေ၊ လိုအပ်တဲ့မေးခွန်းတွေကို ဖြေဖို့ OS ကို မြန်မြန်ဆန်ဆန်ရနိုင်လေပါပဲ။

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

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

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

စိတ်ပျက်အားငယ်မှု ချောက်ထဲမှ ရုန်းထွက်နိုင်ပုံ- အလေ့အကျင့်သုံးခု

စမ်းသပ်မှုများ

စစ်ဆေးမှုများကို XP တုံ့ပြန်မှု ကွင်းဆက်တွင် နှစ်ကြိမ်ဖော်ပြထားသည်။ ဒါတင်မကဘူး။ ၎င်းတို့သည် Extreme Programming နည်းပညာတစ်ခုလုံးအတွက် အလွန်အရေးကြီးပါသည်။

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

နောက်ထပ် စမ်းသပ်မှုများ ပြုလုပ်သင့်သည်ဟု ပြသသည့် ဂန္တဝင်စမ်းသပ်ပိရမစ်တစ်ခု ရှိပါသည်။

IaC ပရောဂျက်တစ်ခုတွင် ဤမူဘောင်သည် ကျွန်ုပ်တို့အပေါ် မည်သို့သက်ရောက်သနည်း။ တကယ်တော့... လုံးဝမဟုတ်ပါဘူး။

• ယူနစ်စစ်ဆေးမှုများ အများအပြားရှိသင့်သော်လည်း များစွာမများနိုင်ပါ။ သို့မဟုတ် ၎င်းတို့သည် သွယ်ဝိုက်သောနည်းဖြင့် တစ်ခုခုကို စမ်းသပ်နေကြသည်။ တကယ်တော့ ကျွန်တော်တို့က အဲဒါတွေကို လုံးဝမရေးဘူးလို့ ပြောလို့ရပါတယ်။ သို့သော် ဤအရာများသည် ကျွန်ုပ်တို့လုပ်ဆောင်နိုင်သည့် စာမေးပွဲများအတွက် လျှောက်လွှာအချို့ဖြစ်သည်။
  1. jsonnet ကုဒ်ကို စမ်းသပ်ခြင်း။ ဥပမာ၊ ၎င်းသည် ကျွန်ုပ်တို့၏ ဒရုန်းတပ်ဆင်ရေးပိုက်လိုင်းဖြစ်ပြီး၊ အလွန်ရှုပ်ထွေးပါသည်။ jsonnet ကုဒ်ကို စမ်းသပ်မှုများဖြင့် ကောင်းမွန်စွာ လွှမ်းခြုံထားသည်။
     ဒါကို ကျွန်တော်တို့ သုံးပါတယ်။ Jsonnet အတွက် ယူနစ်စမ်းသပ်မှု မူဘောင်.
  2. အရင်းအမြစ်စတင်သောအခါတွင် လုပ်ဆောင်သည့် script များအတွက် စမ်းသပ်မှုများ။ Script များကို Python ဖြင့် ရေးသားထားသောကြောင့် စမ်းသပ်မှုများကို ၎င်းတို့တွင် ရေးသားနိုင်ပါသည်။
• စစ်ဆေးမှုများတွင် configuration ကိုစစ်ဆေးရန် ဖြစ်နိုင်ချေရှိသော်လည်း ကျွန်ုပ်တို့ ထိုသို့မလုပ်ပါ။ အရင်းအမြစ်ဖွဲ့စည်းမှုပုံစံစည်းမျဉ်းများမှတစ်ဆင့် စစ်ဆေးခြင်းကို configure လုပ်နိုင်သည်။ tflint. သို့သော်၊ အဆိုပါစစ်ဆေးမှုများသည် terraform အတွက်ရိုးရှင်းလွန်းသော်လည်း၊ စမ်းသပ်မှုများစွာကို AWS အတွက်ရေးသားထားသည်။ ပြီးတော့ ကျွန်တော်တို့ Azure မှာ ရှိနေတဲ့အတွက် ဒါက ထပ်ပြီး သက်ရောက်မှု မရှိပါဘူး။
• အစိတ်အပိုင်းပေါင်းစည်းခြင်းဆိုင်ရာ စမ်းသပ်မှုများ- ၎င်းတို့ကို သင်မည်ကဲ့သို့ အမျိုးအစားခွဲခြားပြီး သင်ထည့်သွင်းသည့်နေရာပေါ်တွင် မူတည်သည်။ ဒါပေမယ့် သူတို့က အခြေခံအားဖြင့် အလုပ်လုပ်တယ်။

  ဤသည်မှာ ပေါင်းစည်းခြင်းဆိုင်ရာ စစ်ဆေးမှုများနှင့် အသွင်တူသည်။

  
  
  ဤသည်မှာ Drone CI တွင် ပုံများတည်ဆောက်သည့်အခါ ဥပမာတစ်ခုဖြစ်သည်။ ၎င်းတို့ထံရောက်ရှိရန်၊ Packer ပုံပေါ်လာရန်အတွက် မိနစ် 30 စောင့်ရမည်ဖြစ်ပြီး ၎င်းတို့ကျော်သွားရန်အတွက် နောက်ထပ် 15 မိနစ်စောင့်ပါ။ ဒါပေမယ့် သူတို့ရှိနေတယ်။

  ရုပ်ပုံအတည်ပြုခြင်း အယ်လဂိုရီသမ်

  1. Packer သည် ပထမဦးစွာ ပုံကို အပြီးအပိုင် ပြင်ဆင်ရပါမည်။
  2. စမ်းသပ်မှုဘေးတွင် ဤပုံကိုအသုံးပြုရန် ကျွန်ုပ်တို့အသုံးပြုသည့် ဒေသန္တရပြည်နယ်တစ်ခုပါရှိသည်။
  3. ဖြည်သောအခါ၊ ပုံနှင့်အလုပ်လုပ်ရလွယ်ကူစေရန် အနီးအနားတွင်ရှိသော သေးငယ်သော module တစ်ခုကိုအသုံးပြုသည်။
  4. ပုံမှ VM ကို အသုံးချပြီးသည်နှင့် စစ်ဆေးမှုများ စတင်နိုင်သည်။ အခြေခံအားဖြင့် ကားဖြင့် စစ်ဆေးမှုများ ပြုလုပ်သည်။ ၎င်းသည် startup တွင် scripts များမည်သို့အလုပ်လုပ်ပုံနှင့် daemons အလုပ်လုပ်ပုံကိုစစ်ဆေးသည်။ ဒါကိုလုပ်ဖို့၊ ssh သို့မဟုတ် winrm မှတစ်ဆင့် ကျွန်ုပ်တို့သည် အသစ်တင်ထားသောစက်သို့ အကောင့်ဝင်ရောက်ပြီး ဖွဲ့စည်းမှုအခြေအနေ သို့မဟုတ် ဝန်ဆောင်မှုများတက်နေသလား စစ်ဆေးပါ။

• အခြေအနေသည် terraform အတွက် modules များတွင် ပေါင်းစပ်စမ်းသပ်မှုများနှင့် ဆင်တူသည်။ ဤသည်မှာ ဤကဲ့သို့သော စမ်းသပ်မှုများ၏ အင်္ဂါရပ်များကို ရှင်းပြထားသော ဇယားအတိုဖြစ်သည်။

  
  
  ပိုက်လိုင်းအပေါ် တုံ့ပြန်မှုသည် မိနစ် ၄၀ ဝန်းကျင်ဖြစ်သည်။ အရာအားလုံးက အချိန်အတော်ကြာအောင် ဖြစ်ပျက်နေတာ။ ဆုတ်ယုတ်ခြင်းအတွက် သုံးနိုင်သော်လည်း ဖွံ့ဖြိုးတိုးတက်မှုအသစ်အတွက် ယေဘုယျအားဖြင့် လက်တွေ့မကျပါ။ သင်ဤအတွက်အလွန်ပြင်ဆင်ထားပါက run scripts များကိုပြင်ဆင်ပါ၊ ထို့နောက် 40 မိနစ်သို့လျှော့ချနိုင်သည်။ သို့သော် ၎င်းတို့သည် 10 စက္ကန့်အတွင်း 5 ပိုင်းပြုလုပ်နိုင်သည့် Unit Test များမဟုတ်သေးပါ။

ရုပ်ပုံများ သို့မဟုတ် terraform module များ တပ်ဆင်သည့်အခါ Unit tests များမရှိခြင်းသည် REST သို့မဟုတ် Python scripts များမှတဆင့် ရိုးရှင်းစွာလုပ်ဆောင်နိုင်သော သီးခြားဝန်ဆောင်မှုများသို့ အလုပ်ပြောင်းခြင်းကို အားပေးပါသည်။

ဥပမာအားဖြင့်၊ virtual machine စတင်သောအခါ၊ ၎င်းသည် ဝန်ဆောင်မှုတွင် သူ့ဘာသာသူ စာရင်းသွင်းကြောင်း သေချာရန် လိုအပ်ပါသည်။ ScaleFTနှင့် virtual machine ကို ဖျက်ဆီးလိုက်သောအခါ၊ ၎င်းသည် သူ့အလိုလို ပျက်သွားသည်။

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

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

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

ပရိုဂရမ်းမင်း တွဲပါ။

စာမေးပွဲတွေက ကောင်းတာပေါ့။ အများကြီးရေးနိုင်တယ်၊ အမျိုးအစားအမျိုးမျိုးရှိနိုင်တယ်။ ၎င်းတို့သည် ၎င်းတို့၏အဆင့်တွင် လုပ်ဆောင်မည်ဖြစ်ပြီး ကျွန်ုပ်တို့အား တုံ့ပြန်ချက်ပေးပါမည်။ ဒါပေမယ့် အမြန်ဆုံး OS ကိုပေးစွမ်းတဲ့ မကောင်းတဲ့ Unit tests တွေမှာ ပြဿနာရှိနေဆဲပါ။ တစ်ချိန်တည်းမှာပင်၊ ငါနှင့်အတူအလုပ်လုပ်ရလွယ်ကူပြီးနှစ်သက်ဖွယ်ကောင်းသောမြန်ဆန်သော OS ကိုလိုချင်ပါသေးသည်။ ရလာတဲ့အဖြေရဲ့ အရည်အသွေးကို ပြောစရာမရှိပါဘူး။ ကံကောင်းထောက်မစွာ၊ ယူနစ်စမ်းသပ်မှုများထက်ပင် ပိုမိုမြန်ဆန်သော တုံ့ပြန်မှုကို ပေးနိုင်သော နည်းပညာများ ရှိပါသည်။ ဒါက pair programming ပါ။

ကုဒ်ရေးသောအခါတွင်၊ သင်သည် ၎င်း၏အရည်အသွေးနှင့်ပတ်သက်သည့် အကြံပြုချက်များကို တတ်နိုင်သမျှ မြန်မြန်ရယူလိုပါသည်။ ဟုတ်ကဲ့၊ အင်္ဂါရပ်ဌာနခွဲတစ်ခုတွင် အရာအားလုံးကို သင်ရေးနိုင်သည် (မည်သူ့ကိုမျှ မထိခိုက်စေရန်)၊ Github တွင် ဆွဲတင်တောင်းဆိုချက်တစ်ခုပြုလုပ်ကာ အလေးချိန်ရှိသူအား ပေးဆောင်ရန် တာဝန်ပေးကာ တုံ့ပြန်မှုကို စောင့်ပါ။

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

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

1. ဂန္ထဝင်၊ အတွေ့အကြုံရှိ+အတွေ့အကြုံရှိပြီး၊ အချိန်တိုင်းကိရိယာဖြင့် ပြောင်းပါ။ ရာထူးနှစ်ခု – ယာဉ်မောင်းနှင့် လမ်းပြသူ။ လူနှစ်ယောက်။ ၎င်းတို့သည် တူညီသောကုဒ်ပေါ်တွင် အလုပ်လုပ်ပြီး သတ်မှတ်ထားသော အချိန်ကာလတစ်ခုပြီးနောက် အခန်းကဏ္ဍများပြောင်းသည်။

စတိုင်လ်ဖြင့် ကျွန်ုပ်တို့၏ ပြဿနာများ၏ လိုက်ဖက်မှုကို သုံးသပ်ကြည့်ကြပါစို့။

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

IaC တွင် ဤစတိုင်ကို အသုံးပြုခြင်း၏ အဓိက ပြဿနာမှာ အလုပ်၏ အရှိန်အဟုန် မညီမျှခြင်း ဖြစ်သည်။ သမားရိုးကျ ဆော့ဖ်ဝဲလ် ဖွံ့ဖြိုးတိုးတက်မှုတွင် သင်သည် အလွန်တူညီသော လှုပ်ရှားမှုတစ်ခုရှိသည်။ ငါးမိနစ်လောက်အချိန်ပေးပြီး N ရေးနိုင်ပါတယ်။ 10 မိနစ်လောက်အချိန်ပေးပြီး 2N၊ 15 မိနစ် - 3N ရေးပါ။ ဒီမှာ ငါးမိနစ်လောက်အချိန်ပေးပြီး N ရေးနိုင်တယ်၊ ပြီးတော့ နောက်ထပ် မိနစ် 30 လောက်သုံးပြီးတော့ N ရဲ့ ဆယ်ပုံတစ်ပုံကိုရေးပါ။ ဒီမှာ ဘာမှမသိဘူး၊ မင်း မိုက်မဲနေတယ်။ စုံစမ်းစစ်ဆေးမှုသည် အချိန်ယူရပြီး ပရိုဂရမ်ရေးဆွဲခြင်းမှ အာရုံလွဲသွားစေသည်။

နိဂုံး- ၎င်း၏ ဖြူစင်သောပုံစံဖြင့် ကျွန်ုပ်တို့အတွက် မသင့်လျော်ပါ။

2. ပင်းပေါင်။ ဤချဉ်းကပ်မှုတွင် လူတစ်ဦးသည် စာမေးပွဲကို ရေးပြီး နောက်တစ်ဦးသည် ၎င်းအတွက် အကောင်အထည်ဖော်ရန် ပါဝင်သည်။ Unit tests တွေနဲ့ အရာအားလုံးက ရှုပ်ထွေးနေတယ် ဆိုတဲ့အချက်ကို ထည့်သွင်းစဉ်းစားပြီး program လုပ်ဖို့ အချိန်ကြာတဲ့ integration test တစ်ခုကို ရေးရမှာဖြစ်တဲ့အတွက် ping-pong ရဲ့ လွယ်ကူမှု အားလုံးက ပျောက်ကွယ်သွားပါပြီ။

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

နိဂုံး- ဖြစ်ချင်တော့၊ အလုပ်၏အရှိန်အဟုန်သည် IaC တွင် တွဲဖက်ပရိုဂရမ်းမင်းလေ့ကျင့်မှုအဖြစ် ပင်ပေါင်အသုံးပြုခြင်းကို ခွင့်မပြုပါ။

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

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

နိဂုံး- ၎င်းကို အသုံးချနိုင်သည်၊ ကျွန်ုပ်တို့သည် ကြိုးစားခြင်းကို လက်မလျှော့ပါ။

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

pair programming အသုံးပြုခြင်းဆိုင်ရာ အထွေထွေရလဒ်များ

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

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

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

စီမံကိန်းနှင့်ဆက်သွယ်ရေး

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

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

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

လုပ်ငန်းဆောင်တာများ၏ အမြင်အာရုံ၏ အားသာချက်များ-

• အကျိုးတရား။ အလုပ်တစ်ခုစီသည် ကမ္ဘာလုံးဆိုင်ရာ ပန်းတိုင်သို့ ဦးတည်သည်။ လုပ်ဆောင်စရာများကို သေးငယ်သောပန်းတိုင်များအဖြစ် အုပ်စုဖွဲ့ထားသည်။ Infrastructure Domain ကိုယ်တိုင်က နည်းပညာပိုင်းအရ တော်တော်ကောင်းပါတယ်။ ဥပမာအားဖြင့်၊ အခြား nginx သို့ ပြောင်းရွှေ့ခြင်းဆိုင်ရာ စာအုပ်တစ်အုပ်ရေးခြင်းသည် လုပ်ငန်းအပေါ် မည်သို့အကျိုးသက်ရောက်မှုရှိသည်ကို အမြဲတမ်း ရှင်းရှင်းလင်းလင်း မသိရသေးပါ။ ပစ်မှတ်ကတ်အနီးတွင်ရှိခြင်းက ပိုရှင်းလင်းစေသည်။
  
  အကြောင်းတရားသည် ပြဿနာများ၏ အရေးကြီးသော ပိုင်ဆိုင်မှုတစ်ခုဖြစ်သည်။ ၎င်းသည် မေးခွန်းကို တိုက်ရိုက်ဖြေသည်- "ငါလုပ်တာမှန်သလား"
• ပြိုင်တူဝါဒ။ ကျွန်ုပ်တို့တွင် ကိုးဦးရှိပြီး၊ လူတိုင်းကို အလုပ်တစ်ခုတည်းတွင် ထားရန်မှာ ရုပ်ပိုင်းဆိုင်ရာအရ မဖြစ်နိုင်ပေ။ နယ်ပယ်တစ်ခုမှ လုပ်ဆောင်စရာများသည် အမြဲတမ်း မလုံလောက်နိုင်ပါ။ လုပ်ငန်းအဖွဲ့ငယ်များကြားတွင် ကျွန်ုပ်တို့သည် အလုပ်ကို ပြိုင်တူလုပ်ခိုင်းသည်။ တစ်ချိန်တည်းမှာပင် အဖွဲ့များသည် ၎င်းတို့၏ လုပ်ငန်းတာဝန်များကို အချိန်အတော်ကြာ ထိုင်ကာ အခြားသူတစ်ဦးမှ အားဖြည့်ပေးနိုင်သည်။ တစ်ခါတရံမှာ လူတွေက ဒီအလုပ်အဖွဲ့ကနေ ထွက်သွားကြတယ်။ တစ်စုံတစ်ယောက်သည် အားလပ်ရက်ခရီးထွက်သည်၊ တစ်စုံတစ်ယောက်သည် DevOps conf အတွက် အစီရင်ခံစာတစ်ခု ပြုလုပ်သည်၊ တစ်စုံတစ်ဦးသည် Habr တွင် ဆောင်းပါးတစ်ပုဒ်ရေးသည်။ ပန်းတိုင်နှင့် အလုပ်များကို ပြိုင်တူလုပ်ဆောင်နိုင်သည်ကို သိရန်မှာ အလွန်အရေးကြီးပါသည်။

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

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

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

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

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

အစီရင်ခံစာကို စစ်ဆေးရန်စာရင်းကို အသုံးပြု၍ လုပ်ဆောင်နိုင်သည်။1. အကြောင်းအရာထဲသို့ ထည့်သွင်းပါ။ အလုပ်က ဘယ်ကလာတာလဲ၊ ဘာကြောင့် လိုအပ်တာလဲ။

2. အရင်က ပြဿနာကို ဘယ်လိုဖြေရှင်းခဲ့လဲ။ ဥပမာအားဖြင့်၊ မောက်စ်ကို ကြီးမားစွာ နှိပ်ရန် လိုအပ်သည်၊ သို့မဟုတ် လုံးဝ လုပ်ရန် မဖြစ်နိုင်ပါ။

3. ကျွန်ုပ်တို့သည် ၎င်းကို မည်သို့တိုးတက်စေသနည်း။ ဥပမာ- "ကြည့်စမ်း၊ အခု scriptosik ရှိတယ်၊ ဒီမှာ readme"

4. ၎င်းသည်မည်သို့အလုပ်လုပ်သည်ကိုပြသပါ။ အသုံးပြုသူအချို့၏ မြင်ကွင်းကို တိုက်ရိုက်အကောင်အထည်ဖော်ရန် အကြံပြုလိုပါသည်။ ငါ X လိုချင်တယ်၊ ငါ Y လုပ်တယ်၊ ငါ Y (သို့မဟုတ် Z) ကိုတွေ့တယ်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်သည် NGINX ကိုအသုံးပြုပြီး url ကိုမီးခိုးထုတ်ကာ 200 OK ကိုရယူပါ။ လုပ်ဆောင်ချက်ရှည်ပါက နောက်မှပြသနိုင်စေရန် ကြိုတင်ပြင်ဆင်ပါ။ ပျက်စီးလွယ်ပါက ဒီမိုမပြသမီ တစ်နာရီအလိုတွင် ၎င်းကို အလွန်အကျွံမချိုးရန် အကြံပြုလိုပါသည်။

5. ပြဿနာကို အောင်မြင်စွာဖြေရှင်းနိုင်ပုံ၊ ဘယ်လိုအခက်အခဲတွေရှိနေသလဲ၊ မပြီးပြတ်သေးတာ၊ အနာဂတ်မှာ ဘယ်လိုတိုးတက်မှုတွေရှိလာနိုင်လဲ ရှင်းပြပေးပါ။ ဥပမာအားဖြင့်၊ ယခု CLI သည် CI တွင် အလိုအလျောက်စနစ် အပြည့်ရှိလိမ့်မည်။

စပီကာတစ်ခုစီအတွက် 5-10 မိနစ်အထိထားရန် အကြံပြုလိုပါသည်။ သင်၏မိန့်ခွန်းသည် သိသာထင်ရှားပြီး အရေးကြီးပြီး ပိုကြာမည်ဆိုပါက၊ ၎င်းကို sre-takeover ချန်နယ်တွင် ကြိုတင်ညှိနှိုင်းပါ။

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

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

ရှည်လျားသော ကောက်ချက်နှင့် နောက်တစ်ခုက ဘာလဲ။

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

၎င်းတို့၏ လက်ရှိပုံစံတွင် စမ်းသပ်မှုများသည် တစ်စိတ်တစ်ပိုင်းကုဒ်အကျုံးဝင်မှုကိုသာ ပေးပါသည်။ configuration function အများအပြားသည် စမ်းသပ်မခံရဘဲ အဆုံးသတ်သွားပါသည်။ ကုဒ်ရေးတဲ့အခါ သူတို့ရဲ့ တကယ့်အလုပ်အပေါ် လွှမ်းမိုးမှုနည်းတယ်။ သို့သော်၊ ပေါင်းစပ်စစ်ဆေးမှုများမှ အကျိုးသက်ရောက်မှုရှိသည်၊ ၎င်းတို့သည် သင့်အား refactorings များကို မကြောက်မရွံ့လုပ်ဆောင်နိုင်စေသည်။ ဒါဟာ ကြီးမားတဲ့ အောင်မြင်မှုတစ်ခုပါ။ ထို့အပြင်၊ အဆင့်မြင့်ဘာသာစကားများ (ကျွန်ုပ်တို့တွင် python၊ go) တွင် ဖွံ့ဖြိုးတိုးတက်မှုဆီသို့ အာရုံစူးစိုက်မှုပြောင်းသွားသဖြင့် ပြဿနာက ပျောက်သွားပါသည်။ "ကော်" အတွက် စစ်ဆေးမှု အများကြီး မလိုအပ်ပါဘူး၊ အထွေထွေ ပေါင်းစည်းမှု စစ်ဆေးခြင်း လုံလောက်ပါတယ်။

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

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

စာကြောင်းတစ်ကြောင်းတွင် ကောက်ချက်တိုများ

• HR ပညာရှင်များသည် IaC တွင် အလုပ်လုပ်သော်လည်း ထိရောက်မှုနည်းသည်။
• အလုပ်လုပ်တာတွေကို အားကောင်းစေတယ်။
• သင့်ကိုယ်ပိုင် လျော်ကြေးပေးချေမှု ယန္တရားများနှင့် ကျင့်ထုံးများနှင့်အတူ တက်လာပါ။

source: www.habr.com