DevOps အင်ဂျင်နီယာများ မရှိပါ။ အဲဒီအခါ ဘယ်သူရှိလဲ၊ အဲဒါနဲ့ ဘာလုပ်ရမလဲ။

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

ဒီ post မှာကျွန်ုပ်တို့ဒီဘဝရောက်အောင်ဘယ်လိုလုပ်ရမလဲ၊ DevOps အမှန်တကယ်ကဘာလဲ၊ အခုဘာလုပ်ရမလဲဆိုတာနည်းနည်းပြောပြချင်ပါတယ်။

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

ယဉ်ကျေးမှုနှင့် လုပ်ငန်းစဉ်များအကြောင်း

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

ဥပမာအားဖြင့်၊ စနစ်စီမံခန့်ခွဲသူနှင့် ဝန်ဆောင်မှုစီမံခန့်ခွဲမှုအတွက် SRE ချဉ်းကပ်မှုကြား ခြားနားချက်ကို ဖော်ပြခြင်း။ နာမည်ကျော် Google SRE စာအုပ်ကို စတင်ခဲ့သည်။. စိတ်ဝင်တစား လေ့လာမှုတွေ လုပ်တယ်။ DORA စစ်တမ်း — အကောင်းဆုံး developer များသည် တစ်နာရီလျှင် တစ်ကြိမ်ထက် ပိုမိုမြန်ဆန်သော ထုတ်လုပ်မှုတွင် ပြောင်းလဲမှုအသစ်များကို အသုံးချနိုင်သည်ကို ရှင်းပါသည်။ ၎င်းတို့သည် ၎င်းတို့၏လက်ဖြင့် 10% ထက်မပိုစေဘဲ စမ်းသပ်ခြင်းဖြစ်သည် (၎င်းကိုကြည့်နိုင်သည်။ မနှစ်က DORA) ဒါကို ဘယ်လို လုပ်ကြမလဲ။ “Excel or die” အစီရင်ခံစာ၏ ခေါင်းစဉ်တစ်ခုက ဆိုသည်။ စမ်းသပ်မှုအခြေအနေတွင် ဤကိန်းဂဏန်းအချက်အလက်များ၏အသေးစိတ်ဆွေးနွေးမှုအတွက်၊ Baruch Sadogursky ၏အဓိကအချက်ကို ကိုးကားနိုင်သည်။ “ကျွန်တော်တို့မှာ DevOps ရှိတယ်။ စမ်းသပ်သူအားလုံးကို ပစ်ခတ်ကြပါစို့။" Heisenbug ရဲ့ အခြားကွန်ဖရင့်မှာ

“ရဲဘော်တွေကြားမှာ သဘောတူညီမှုမရှိရင်၊
သူတို့အတွက် အဆင်မပြေတာတွေ၊
နှိပ်စက်ညှဉ်းပန်းခြင်းမျှသာ၊
တစ်ချိန်က Swan၊ Crayfish နဲ့ Pike တစ်ကောင်...

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

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

တစ်ဦးကဆိုးစက်ဝိုင်း

“devops engineering” ၏ စည်းကမ်းသည် ထိုအချိန်က ဘယ်ကလာသနည်း။ ကျွန်ုပ်တို့တွင်ဗားရှင်းတစ်ခုရှိသည်။ DevOps အတွေးအခေါ်များသည် ကောင်းမွန်သည်—သူတို့သည် ၎င်းတို့၏အောင်မြင်မှု၏ သားကောင်များဖြစ်လာကြသည်။ အရိပ်ရလူသစ်စုဆောင်းသူများနှင့် ၎င်းတို့၏ကိုယ်ပိုင်အငွေ့အသက်များရှိသည့် လူကုန်ကူးသူများသည် ဤအကြောင်းအရာတစ်ခုလုံးကို စတင်လှည့်ပတ်လာသည်။

မြင်ယောင်ကြည့်ပါ- မနေ့က ခင်ကီမှာ ရှဝါမာ လုပ်နေခဲ့တာ၊ ဒီနေ့တော့ အကြီးတန်း အလုပ်ခန့်အပ်သူ ဖြစ်လာမယ့်သူ။ ကိုယ်စားလှယ်လောင်းတွေကို ရှာဖွေရွေးချယ်တဲ့ လုပ်ငန်းစဉ်တစ်ခုလုံးရှိတယ်၊ အားလုံးက ရှုပ်ထွေးတယ်၊ မင်း နားလည်ရမယ်။ ဌာနတစ်ခုရဲ့ အကြီးအကဲက X မှာ ကျွမ်းကျင်သူတစ်ယောက်ကို ရှာပါလို့ ပြောတယ်ဆိုပါစို့။ "အင်ဂျင်နီယာ" ဆိုတဲ့ စကားလုံးကို X မှာ ထည့်လိုက်ရင် ပြီးပြီ။ မင်း လိုအပ်တာက Linuxအင်း၊ အဲဒါ သေချာပါတယ်။ Linuxအင်ဂျင်နီယာတစ်ယောက်ဖြစ်ပြီး DevOps ကို လိုချင်ရင် DevOps အင်ဂျင်နီယာတစ်ယောက်ပါပဲ။ အလုပ်ခေါ်စာဆိုတာ ခေါင်းစဉ်တစ်ခုတည်း မဟုတ်ပါဘူး။ အထဲမှာ စာသားတချို့ ထည့်ရပါမယ်။ အလွယ်ဆုံးနည်းလမ်းကတော့ Google ရဲ့ keyword တွေကို တတ်နိုင်သမျှ တီထွင်ဖန်တီးပြီး ရိုက်ထည့်ဖို့ပါပဲ။ DevOps မှာ "Dev" နဲ့ "Ops" ဆိုတဲ့ စကားလုံးနှစ်လုံး ပါဝင်ပါတယ်။ ဆိုလိုတာက developer တွေနဲ့ administrator တွေနဲ့ သက်ဆိုင်တဲ့ keyword တွေကို တစ်နေရာတည်းမှာ ပေါင်းစပ်ဖို့ လိုအပ်ပါတယ်။ ဒါက programming language ၄၂ မျိုးမှာ ကျွမ်းကျင်မှုနဲ့ Kubernetes နဲ့ Swarm ကို နှစ် ၂၀ တစ်ပြိုင်နက်တည်း အသုံးပြုခြင်းဖြင့် အလုပ်ခေါ်စာတွေ ဖြစ်ပေါ်လာပုံပါ။ အလုပ်ခေါ်စာတွေက အလုပ်ခေါ်စာတွေ ဖြစ်လာပုံပါ။

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

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

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

ဟုတ်ပါတယ်၊ သူတို့ကိုယ်သူတို့ "devops" လို့အမည်ပြောင်းထားတဲ့ စနစ်စီမံခန့်ခွဲသူတွေအပြင်၊ ဥပမာအားဖြင့်၊ ပရော်ဖက်ရှင်နယ် SREs သို့မဟုတ် Infrastructure-as-Code developer တွေလည်း ရှိပါသေးတယ်။

DevOps တွင်လူများဘာလုပ်ကြသည် (တကယ်)

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

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

ဦးစွာ၊ သင်သည် DevOps—လုပ်ငန်းစဉ်များနှင့် ယဉ်ကျေးမှု၏ နှလုံးသားကို ပြောပြနိုင်သည်။ ယဉ်ကျေးမှုသည် နှေးကွေးပြီး ခက်ခဲသော လုပ်ငန်းတစ်ခုဖြစ်ပြီး အစဉ်အလာအားဖြင့် မန်နေဂျာများ၏ တာဝန်ဖြစ်သော်လည်း လူတိုင်းသည် ပရိုဂရမ်မာများမှ စီမံခန့်ခွဲသူများအထိ တစ်နည်းမဟုတ်တစ်နည်း ပါဝင်ပတ်သက်နေပါသည်။ လွန်ခဲ့သောလအနည်းငယ်က Tim Lister အင်တာဗျူးတစ်ခုတွင် ပြောကြားခဲ့သည်။:

“ယဉ်ကျေးမှုကို အဖွဲ့အစည်းရဲ့ အဓိကတန်ဖိုးတွေက ဆုံးဖြတ်တယ်။ အများအားဖြင့် လူတွေက ဒါကိုသတိမထားမိပေမယ့် အတိုင်ပင်ခံလုပ်ငန်းမှာ နှစ်အတော်ကြာအောင် လုပ်ခဲ့တာကို သတိထားမိလေ့ရှိတယ်။ ကုမ္ပဏီတစ်ခုသို့ သင်ဝင်ရောက်ပြီး မိနစ်အနည်းငယ်အတွင်း ဖြစ်ပျက်နေသည့်အရာကို သင်စတင်ခံစားရသည်။ ဒါကို "အရသာ" လို့ခေါ်တယ်။ တစ်ခါတလေ ဒီရနံ့က အရမ်းကောင်းပါတယ်။ တစ်ခါတစ်ရံ ပျို့အန်ခြင်းကို ဖြစ်စေသည်။ (...) သီးခြားလုပ်ဆောင်ချက်တွေရဲ့နောက်ကွယ်က တန်ဖိုးထားမှုတွေနဲ့ ယုံကြည်ချက်တွေကို နားလည်တဲ့အထိ ယဉ်ကျေးမှုတစ်ခုကို သင်မပြောင်းလဲနိုင်ပါဘူး။ အပြုအမူသည် မှတ်သားရန် လွယ်ကူသော်လည်း ယုံကြည်ချက်ကို ရှာဖွေရန် ခက်ခဲသည်။ DevOps သည် အရာများ ပို၍ ပို၍ ရှုပ်ထွေးလာပုံ၏ ကောင်းမွန်သော ဥပမာတစ်ခုမျှသာဖြစ်သည်။”

ပြဿနာရဲ့ နည်းပညာပိုင်းလည်း ပါတာပေါ့။ သင့်ကုဒ်အသစ်ကို တစ်လအတွင်း စမ်းသပ်ခံရသော်လည်း တစ်နှစ်အကြာတွင် ထွက်ရှိပြီး ၎င်းကို အရှိန်မြှင့်ရန် ရုပ်ပိုင်းဆိုင်ရာအရ မဖြစ်နိုင်ပါက၊ သင်သည် ကောင်းမွန်သော အလေ့အကျင့်များကို လိုက်နာနိုင်မည်မဟုတ်ပေ။ အလေ့အကျင့်ကောင်းများကို ကိရိယာကောင်းများဖြင့် ပံ့ပိုးပေးသည်။ ဥပမာအားဖြင့်၊ Infrastructure-as-Code ၏စိတ်ကူးဖြင့်၊ သင်သည် AWS CloudFormation နှင့် Terraform မှ Chef-Ansible-Puppet အထိ မည်သည့်အရာကိုမဆို သင်အသုံးပြုနိုင်ပါသည်။ ဒါတွေအားလုံးကို သိပြီး လုပ်နိုင်ဖို့လိုတယ်၊ ဒါက အင်ဂျင်နီယာ စည်းကမ်းတစ်ခု ဖြစ်နေပါပြီ။ အကြောင်းအရင်းကို အကျိုးသက်ရောက်မှုနှင့် ရောထွေးခြင်းမပြုရန် အရေးကြီးသည်- ပထမဦးစွာ သင်သည် SRE ၏ အခြေခံမူများနှင့်အညီ လုပ်ဆောင်ပြီးမှသာ အချို့သော နည်းပညာပိုင်းဆိုင်ရာ ဖြေရှင်းချက်ပုံစံဖြင့် ဤအခြေခံမူများကို အကောင်အထည်ဖေါ်ပါ။ တစ်ချိန်တည်းမှာပင်၊ SRE သည် Jenkins ကိုမည်သို့တပ်ဆင်ရမည်ကို သင့်အားမပြောပြဘဲ အလွန်ပြည့်စုံသောနည်းစနစ်တစ်ခုဖြစ်ပြီး အခြေခံမူငါးခုအကြောင်း-

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

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

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

တစ်ဖန်၊ Cloud Native ဖြေရှင်းချက်များသည် ယခုအခါ အလွန်ရေပန်းစားလာပါသည်။ ယနေ့ Cloud Native Computing Foundation မှ သတ်မှတ်ထားသည့်အတိုင်း၊ Cloud Native နည်းပညာများသည် အဖွဲ့အစည်းများအား အများသူငှာ၊ ပုဂ္ဂလိကနှင့် ပေါင်းစပ်ထားသော cloud များကဲ့သို့သော ယနေ့ခေတ်ပြောင်းနိုင်သော ပတ်ဝန်းကျင်များတွင် အရွယ်တင်နိုင်သော အပလီကေးရှင်းများကို ဖွံ့ဖြိုးတိုးတက်စေပြီး လုပ်ဆောင်နိုင်စေပါသည်။ ဥပမာများတွင် ကွန်တိန်နာများ၊ ဝန်ဆောင်မှု meshes၊ microservices၊ မပြောင်းလဲနိုင်သော အခြေခံအဆောက်အအုံနှင့် declarative API များ ပါဝင်သည်။ ဤနည်းပညာများအားလုံးသည် ပျော့ပျောင်းစွာ ပေါင်းစပ်ထားသော စနစ်များကို ပျော့ပျောင်းစွာ၊ စီမံခန့်ခွဲနိုင်သော၊ လွန်စွာမြင်နိုင်စေပါသည်။ ကောင်းမွန်သော အလိုအလျောက်စနစ်သည် အင်ဂျင်နီယာများကို ကြီးကြီးမားမားပြောင်းလဲမှုများ မကြာခဏပြုလုပ်နိုင်ပြီး ၎င်းကို အလုပ်မဖြစ်ဘဲ မှန်းဆနိုင်သောရလဒ်များဖြင့် အင်ဂျင်နီယာများကို မကြာခဏပြုလုပ်နိုင်စေပါသည်။ ဤအရာအားလုံးကို Docker နှင့် Kubernetes ကဲ့သို့သော နာမည်ကြီး ကိရိယာအစုအဝေးမှ ပံ့ပိုးပေးထားသည်။

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

ဒါတွေအားလုံးနဲ့ ဘာလုပ်ရမလဲ

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

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

• လုပ်ငန်းစဉ်များနှင့်ယဉ်ကျေးမှု;
• Site Reliability Engineering;
• တိမ်တိုက်ဇာတိ;

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

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

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

• အခြေခံအဆောက်အအုံတည်ဆောက်ရေးတွင် လုပ်ကိုင်သော developer များ။ SRE နှင့် Cloud Native အကြောင်း အစီရင်ခံစာအုပ်စုများသည် သင့်အတွက် အသင့်တော်ဆုံးဖြစ်သည်။
• စနစ်စီမံခန့်ခွဲသူများ။ ဒီမှာ ပိုရှုပ်ထွေးတယ်။ DevOops သည် စနစ်စီမံခန့်ခွဲမှုအကြောင်းမဟုတ်ပါ။ ကံကောင်းထောက်မစွာ၊ စနစ်စီမံခန့်ခွဲခြင်းဆိုင်ရာ ခေါင်းစဉ်ဖြင့် အင်တာနက်ပေါ်ရှိ စာအုပ်များ၊ ဆောင်းပါးများ၊ ဗီဒီယိုများ စသည်တို့ အများအပြားရှိသည်။ အခြားတစ်ဖက်တွင်၊ သင်သည် ယဉ်ကျေးမှုနှင့် လုပ်ငန်းစဉ်များကို နားလည်ခြင်း၊ cloud နည်းပညာများအကြောင်း လေ့လာခြင်းနှင့် Cloud Native ဖြင့် ဘဝ၏အသေးစိတ်အချက်အလက်များကို လေ့လာခြင်းအတွက် သင့်ကိုယ်သင် ဖွံ့ဖြိုးတိုးတက်ရန် စိတ်ဝင်စားပါက၊ ကျွန်ုပ်တို့သည် သင့်ကိုတွေ့ချင်ပါသည်။ ဒါကို စဉ်းစားကြည့်ပါ- မင်း အုပ်ချုပ်မှု လုပ်နေတာ၊ ပြီးတော့ မင်း ဘာလုပ်မလဲ။ မနှစ်မြို့ဖွယ်အခြေအနေတစ်ခုတွင် သင့်ကိုယ်သင် ချက်ခြင်းတွေ့ရှိခြင်းမှ ရှောင်ရှားရန် ယခုသင်သင်ယူသင့်သည်။

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

လျှော Konstantin Diener ၏အစီရင်ခံစာ မြူးနစ်မှာ

DevOops 2020 Moscow ကို ဧပြီလ 29 မှ 30 ရက်နေ့အထိ မော်စကိုတွင် ကျင်းပမည်ဖြစ်ပြီး လက်မှတ်များ ရရှိနေပြီဖြစ်သည်။ တရားဝင် website တွင်ဝယ်ယူပါ။.

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

source: www.habr.com