Kubernetes နှင့် အလိုအလျောက်စနစ်ကြောင့် နှစ်နာရီအတွင်း cloud သို့ ပြောင်းရွှေ့နည်း

URUS ကုမ္ပဏီသည် Kubernetes ကို ပုံစံအမျိုးမျိုးဖြင့် စမ်းသပ်ခဲ့သည်- သတ္တုမပါသော၊ Google Cloud တွင် သီးခြားဖြန့်ကျက်ပြီး ၎င်း၏ပလက်ဖောင်းကို Mail.ru Cloud Solutions (MCS) cloud သို့ လွှဲပြောင်းခဲ့သည်။ Igor Shishkin က ၎င်းတို့သည် cloud ဝန်ဆောင်မှုပေးသူအသစ်ကို မည်သို့ရွေးချယ်ခဲ့ပုံနှင့် ၎င်းတို့ထံ စံချိန်တင်နှစ်နာရီအတွင်း ပြောင်းရွှေ့နိုင်ပုံကို ပြောပြသည် (t3ran) URUS မှ အကြီးတန်း စနစ်စီမံခန့်ခွဲသူ။

URUS ဘာလုပ်သလဲ။

မြို့ပြပတ်ဝန်းကျင်၏ အရည်အသွေးကို မြှင့်တင်ရန် နည်းလမ်းများစွာရှိပြီး ၎င်းတို့ထဲမှ တစ်ခုမှာ ပတ်ဝန်းကျင်နှင့် သဟဇာတဖြစ်အောင် ပြုလုပ်ခြင်းဖြစ်သည်။ ၎င်းသည် URUS - Smart Digital Services ကုမ္ပဏီတွင် လုပ်ဆောင်နေသည့်အရာဖြစ်သည်။ ဤတွင် ၎င်းတို့သည် စီးပွားရေးလုပ်ငန်းများအတွက် အရေးကြီးသော သဘာဝပတ်ဝန်းကျင်ဆိုင်ရာ ညွှန်ကိန်းများကို စောင့်ကြည့်ရန်နှင့် သဘာဝပတ်ဝန်းကျင်အပေါ် ၎င်းတို့၏ အပျက်သဘောဆောင်သော သက်ရောက်မှုများကို လျှော့ချရန် ကူညီပေးသည့် ဖြေရှင်းချက်များကို ဖော်ဆောင်ပေးပါသည်။ အာရုံခံကိရိယာများသည် လေထုဖွဲ့စည်းမှု၊ ဆူညံသံအဆင့်နှင့် အခြားကန့်သတ်ချက်များဆိုင်ရာ အချက်အလက်များကို စုဆောင်းကာ ခွဲခြမ်းစိတ်ဖြာပြီး အကြံပြုချက်ပြုလုပ်ရန်အတွက် ပေါင်းစည်းထားသော URUS-Ekomon ပလပ်ဖောင်းသို့ ပေးပို့ပါ။

အတွင်းမှ URUS အလုပ်လုပ်ပုံ

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

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

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

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

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

ဒေတာတွေကို ဘယ်လိုသိမ်းဆည်းမလဲ။ သတ္တုမပါသော Kubernetes ၏ဇာတ်လမ်း

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

လွန်ခဲ့သောနှစ်ပေါင်းများစွာက ကျွန်ုပ်တို့၏ သိုလှောင်မှုပြဿနာကို ဖြေရှင်းရန် ရှာဖွေစဉ်တွင်၊ Kubernetes နှင့် OpenStack ပလပ်ဖောင်း ရွေးချယ်မှုနှစ်ခုရှိသည်။ သို့သော် နောက်ပိုင်းတွင် အလွန်ဆိုးရွားလှသည် (၎င်း၏ဗိသုကာလက်ရာကို ယုံကြည့်ရန်) ကြောင့် ကျွန်ုပ်တို့ Kubernetes တွင် အခြေချခဲ့သည်။ ၎င်း၏မျက်နှာသာပေးထားသော နောက်ထပ်အငြင်းအခုံမှာ အရင်းအမြစ်များအလိုက် ဟာ့ဒ်ဝဲဆုံမှတ်များကိုပင် ပိုမိုပျော့ပြောင်းစွာ ဖြတ်တောက်နိုင်သည့် ရိုးရှင်းသော ဆော့ဖ်ဝဲထိန်းချုပ်မှုဖြစ်သည်။

Kubernetes ကိုယ်တိုင် ကျွမ်းကျွမ်းကျင်ကျင်နှင့်အပြိုင်၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ သိုလှောင်မှုအားလုံးကို Kubernetes တွင် ကျွန်ုပ်တို့၏ကိုယ်ပိုင် ဟာ့ဒ်ဝဲတွင် သိမ်းဆည်းထားစဉ်တွင် ဒေတာသိမ်းဆည်းရန် နည်းလမ်းများကိုလည်း လေ့လာခဲ့သည်။ Kubernetes တွင် ကျွန်ုပ်တို့နေထိုင်ခဲ့သမျှ- နိုင်ငံပိုင်သိုလှောင်မှု၊ စောင့်ကြည့်စနစ်၊ CI/CD။ Kubernetes သည် ကျွန်ုပ်တို့အတွက် all-in-one platform တစ်ခုဖြစ်လာသည်။

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

Google Cloud Platform သို့ပြောင်းခြင်းသည် ယာယီဖြေရှင်းချက်တစ်ခုဖြစ်သည်။

၎င်းသည် ဆက်၍မရနိုင်ကြောင်း ကျွန်ုပ်တို့သဘောပေါက်ပြီး ကျွန်ုပ်တို့၏ဒေတာကို သတ္တုဗလာမှ Google Cloud Platform သို့ ရွှေ့လိုက်ပါသည်။ တကယ်တော့ အဲဒီအချိန်တုန်းက ရုရှားကုမ္ပဏီအတွက် စိတ်ဝင်စားစရာကောင်းတဲ့ ရွေးချယ်စရာတွေ အများကြီးမရှိဘူး၊ Google Cloud Platform အပြင် Amazon ကပဲ အလားတူ ဝန်ဆောင်မှုကို ပေးခဲ့ပေမယ့် Google က ဖြေရှင်းချက်အပေါ် အခြေချနေတုန်းပါပဲ။ ထို့နောက်တွင် Google ကိုယ်တိုင်သည် ထုတ်လုပ်မှုတွင် PoC Kubernetes အမျိုးအစားဖြစ်သည်ဟူသောအချက်ကို ဖော်ပြခြင်းမပြုဘဲ Upstream နှင့် ပိုမိုနီးစပ်သော စီးပွားရေးအရအမြတ်အစွန်းပိုမိုရရှိပုံရသည်။

ကျွန်ုပ်တို့၏ဖောက်သည်အခြေခံ ကြီးထွားလာသည်နှင့်အမျှ ပထမဆုံးသော အဓိကပြဿနာသည် မိုးကုတ်စက်ဝိုင်းတွင် ပေါ်လာသည်။ ကျွန်ုပ်တို့တွင် ကိုယ်ရေးကိုယ်တာအချက်အလက်များကို သိမ်းဆည်းရန် လိုအပ်သောအခါတွင်၊ ကျွန်ုပ်တို့သည် Google နှင့် အလုပ်လုပ်ပြီး ရုရှားဥပဒေများကို ချိုးဖောက်သည်ဖြစ်စေ သို့မဟုတ် ရုရှားဖက်ဒရေးရှင်းတွင် အခြားရွေးချယ်စရာတစ်ခုကို ရှာဖွေနေပါသည်။ ရွေးချယ်မှု တစ်ခုလုံးကို ခန့်မှန်းနိုင်ခဲ့သည်။ 🙂

စံပြ cloud ဝန်ဆောင်မှုကို ကျွန်ုပ်တို့ ဘယ်လိုမြင်လဲ။

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

• လျင်မြန်ပြီး လိုက်လျောညီထွေ ရှိသည်။. ကျွန်ုပ်တို့သည် node အသစ်တစ်ခုကို အမြန်ထည့်နိုင်သည် သို့မဟုတ် အချိန်မရွေး တစ်ခုခုကို ဖြန့်ကျက်နိုင်စေရန်။
• ဈေးမကြီးဘူး။. ကျွန်ုပ်တို့သည် အရင်းအမြစ်များ ကန့်သတ်ထားသောကြောင့် ငွေကြေးဆိုင်ရာ ပြဿနာနှင့် ပတ်သက်၍ ကျွန်ုပ်တို့ အလွန်စိုးရိမ်ခဲ့ပါသည်။ ကျွန်ုပ်တို့သည် Kubernetes နှင့် လက်တွဲလိုကြောင်း ကျွန်ုပ်တို့သိထားပြီးဖြစ်ပြီး၊ ယခုလုပ်ဆောင်ရမည့်တာဝန်မှာ ဤဖြေရှင်းချက်အသုံးပြုမှု၏ထိရောက်မှုကို တိုးမြှင့်ရန် သို့မဟုတ် အနည်းဆုံးထိန်းသိမ်းထားရန် ၎င်း၏ကုန်ကျစရိတ်ကို လျှော့ချရန်ဖြစ်သည်။
• အလိုအလျောက်. မန်နေဂျာများနှင့် ဖုန်းခေါ်ဆိုမှုများ သို့မဟုတ် အရေးပေါ်မုဒ်တွင် နံပါတ်များစွာကို ကိုယ်တိုင်တင်ရန် လိုအပ်သည့် အခြေအနေများမပါဘဲ API မှတစ်ဆင့် ဝန်ဆောင်မှုနှင့် လုပ်ဆောင်ရန် စီစဉ်ထားပါသည်။ ကျွန်ုပ်တို့၏ လုပ်ငန်းစဉ်အများစုသည် အလိုအလျောက်လုပ်ဆောင်နေသောကြောင့် cloud ဝန်ဆောင်မှုမှ အလားတူမျှော်လင့်ထားပါသည်။
• ရုရှားဖက်ဒရေးရှင်းရှိဆာဗာများနှင့်. ကျွန်ုပ်တို့သည် ရုရှားဥပဒေများနှင့် တူညီသော 152-FZ ကို လိုက်နာရန် စီစဉ်ထားပါသည်။

ထိုအချိန်တွင်၊ ရုရှားတွင် Kubernetes aaS ဝန်ဆောင်မှုပေးသူ အနည်းငယ်သာရှိပြီး ဝန်ဆောင်မှုပေးသူကို ရွေးချယ်သည့်အခါ ကျွန်ုပ်တို့၏ ဦးစားပေးများကို အလျှော့မပေးမိရန် အရေးကြီးပါသည်။ ကျွန်ုပ်တို့ စတင်လုပ်ဆောင်ပြီး ပူးပေါင်းဆောင်ရွက်ဆဲဖြစ်သော Mail.ru Cloud Solutions အဖွဲ့သည် API ပံ့ပိုးမှုနှင့် Horizon ပါဝင်သော အဆင်ပြေသော ထိန်းချုပ်မှုဘောင်တစ်ခုဖြင့် အပြည့်အဝ အလိုအလျောက် ဝန်ဆောင်မှုတစ်ခု ပေးစွမ်းနိုင်သည် - ၎င်းနှင့်အတူ ကျွန်ုပ်တို့သည် မတရားသော node အရေအတွက်ကို လျင်မြန်စွာ မြှင့်တင်နိုင်ပါသည်။

နှစ်နာရီအတွင်း MCS သို့ ပြောင်းရွှေ့နိုင်ပုံ

ထိုသို့သော လှုပ်ရှားမှုများတွင် ကုမ္ပဏီများစွာသည် အခက်အခဲများနှင့် ဆုတ်ယုတ်မှုများ ကြုံတွေ့ရသော်လည်း ကျွန်ုပ်တို့၏ အခြေအနေတွင် တစ်ခုမျှ မရှိခဲ့ပါ။ ကျွန်ုပ်တို့ ကံကောင်းပါသည်- ကျွန်ုပ်တို့သည် ရွှေ့ပြောင်းခြင်းမစတင်မီ Kubernetes တွင် အလုပ်လုပ်နေပြီးဖြစ်သောကြောင့်၊ ကျွန်ုပ်တို့သည် ဖိုင်သုံးဖိုင်ကို ရိုးရိုးရှင်းရှင်းပြင်ဆင်ပြီး cloud ပလပ်ဖောင်းအသစ်ဖြစ်သော MCS တွင် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုများကို စတင်လိုက်ပါသည်။ ထိုအချိန်တွင် ကျွန်ုပ်တို့သည် နောက်ဆုံးတွင် သတ္တုဗလာဖြင့် ကျန်ရစ်ခဲ့ပြီး Google Cloud Platform တွင် နေထိုင်ခဲ့ကြောင်း ကျွန်ုပ်အား သတိပေးပါရစေ။ ထို့ကြောင့်၊ ရွှေ့ခြင်းသည် နှစ်နာရီထက် မပိုဘဲ၊ ကျွန်ုပ်တို့၏ စက်များမှ ဒေတာကို ကူးယူရန် အချိန်အနည်းငယ် (တစ်နာရီခန့်) ပိုကြာသည်။ ထိုအချိန်တွင် ကျွန်ုပ်တို့သည် Spinnaker (အဆက်မပြတ် ပို့ဆောင်ပေးရန်အတွက် Multi-cloud CD ဝန်ဆောင်မှုတစ်ခု) ကို အသုံးပြုနေပြီဖြစ်သည်။ ကျွန်ုပ်တို့သည် ၎င်းကို အစုအသစ်သို့ လျင်မြန်စွာ ထည့်သွင်းပြီး ပုံမှန်အတိုင်း ဆက်လက်လုပ်ဆောင်ခဲ့သည်။

ဖွံ့ဖြိုးတိုးတက်မှုလုပ်ငန်းစဉ်များနှင့် CI/CD တို့၏ အလိုအလျောက်စနစ်ကြောင့်၊ URUS ရှိ Kubernetes ကို ကျွမ်းကျင်သူတစ်ဦး (ထိုသူမှာ ကျွန်ုပ်ဖြစ်သည်) မှ ကိုင်တွယ်ပါသည်။ အချို့သောအဆင့်တွင်၊ အခြားစနစ်စီမံခန့်ခွဲသူသည် ကျွန်ုပ်နှင့်အလုပ်လုပ်သော်လည်း၊ ကျွန်ုပ်တို့သည် ပင်မလုပ်ရိုးလုပ်စဉ်အားလုံးကို အလိုအလျောက်လုပ်ဆောင်ပြီးဖြစ်ကြောင်းနှင့် ကျွန်ုပ်တို့၏ပင်မထုတ်ကုန်၏အပိုင်းတွင် လုပ်ဆောင်စရာများ ပိုများလာကာ ဤအရာအတွက် အရင်းအမြစ်များကို ညွှန်ပြရန် အဓိပ္ပါယ်ရှိလာပါသည်။

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

ကျွန်ုပ်သည် ကျွန်ုပ်၏အတွေ့အကြုံကို Google Cloud Platform နှင့် နှိုင်းယှဉ်ပါက၊ ၎င်းတို့တွင် တုံ့ပြန်ချက်ခလုတ်သည် မည်သည့်နေရာတွင်ရှိသည်ကိုပင် ကျွန်ုပ်မသိခဲ့ပါ။ ပြဿနာတစ်စုံတစ်ရာ ဖြစ်ပေါ်လာပါက၊ Google ကိုယ်တိုင်က သတိပေးချက်များကို တစ်ဖက်သတ် ပေးပို့ခဲ့သည်။ ဒါပေမယ့် MCS ကိစ္စမှာတော့၊ ပထဝီဝင်အရရော စိတ်ပိုင်းဆိုင်ရာရော ရုရှားဖောက်သည်တွေနဲ့ပါ နီးစပ်နိုင်သမျှ နီးစပ်အောင် လုပ်နိုင်မယ်လို့ ထင်ပါတယ်။

အနာဂတ်တွင် cloud များနှင့် အလုပ်လုပ်ပုံကို ကျွန်ုပ်တို့မြင်သည်။

ယခုကျွန်ုပ်တို့၏အလုပ်သည် Kubernetes နှင့် နီးကပ်စွာချိတ်ဆက်ထားပြီး အခြေခံအဆောက်အအုံဆိုင်ရာလုပ်ဆောင်မှုများ၏ရှုထောင့်မှကျွန်ုပ်တို့ကိုလုံးဝလိုက်ဖက်ပါသည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ပုံမှန်အလုပ်များကို ရိုးရှင်းစေရန်နှင့် အသစ်များကို အလိုအလျောက်လုပ်ဆောင်ရန်၊ ဝန်ဆောင်မှုများ၏ တည်ငြိမ်မှုနှင့် ယုံကြည်စိတ်ချရမှုကို တိုးမြှင့်ရန်အတွက် အလေ့အကျင့်အသစ်များနှင့် ဝန်ဆောင်မှုများကို အဆက်မပြတ်မိတ်ဆက်ပေးနေသော်လည်း ၎င်းမှ မည်သည့်နေရာမှ ပြောင်းရွှေ့ရန် အစီအစဉ်မရှိပါ။ ကျွန်ုပ်တို့သည် chaoskube ကိုအသုံးပြုသည်၊ သို့သော်၎င်းသည်မူလက Netflix မှဖန်တီးခဲ့သည့်အယူအဆကိုမပြောင်းလဲပါ။ Chaos Monkey သည် ရိုးရှင်းသော အရာတစ်ခုကို လုပ်ဆောင်သည်- ၎င်းသည် ကျပန်း Kubernetes pod တစ်ခုကို တစ်ချိန်တည်းတွင် ဖျက်ပစ်သည်။ ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုသည် သာဓက နံပါတ်-၁ ဖြင့် ပုံမှန်အတိုင်းနေထိုင်ရန်အတွက် ၎င်းသည် လိုအပ်သောကြောင့် ကျွန်ုပ်တို့သည် ပြဿနာများအတွက် ကြိုတင်ပြင်ဆင်ထားရန် မိမိကိုယ်ကို လေ့ကျင့်ပေးပါသည်။

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

cloud ဝန်ဆောင်မှုများနှင့် လုပ်ဆောင်ခြင်းမှ ကျွန်ုပ်တို့ သင်ယူခဲ့ရာ

ကျွန်ုပ်တို့သည် Kubernetes ကို သတ္တုဗလာဖြင့် စတင်အသုံးပြုခဲ့ပြီး ထိုနေရာတွင်ပင် ၎င်းသည် ၎င်း၏ကိုယ်ပိုင်နည်းလမ်းဖြင့် ကောင်းမွန်ပါသည်။ သို့သော် ၎င်း၏အားသာချက်များကို cloud ရှိ aaS အစိတ်အပိုင်းတစ်ခုအဖြစ် အတိအကျဖော်ပြခဲ့သည်။ သင်ရည်မှန်းချက်တစ်ခုသတ်မှတ်ပြီး အရာအားလုံးကို တတ်နိုင်သမျှအလိုအလျောက်ပြန်လုပ်ပါက၊ ရောင်းချသူလော့ခ်ချခြင်းကို ရှောင်ရှားနိုင်ပြီး cloud ဝန်ဆောင်မှုပေးသူများကြားတွင် နာရီအနည်းငယ်ကြာကြာရွှေ့နိုင်ပြီး အာရုံကြောဆဲလ်များသည် ကျွန်ုပ်တို့နှင့်အတူရှိနေမည်ဖြစ်သည်။ ကျွန်ုပ်တို့သည် အခြားကုမ္ပဏီများကို အကြံပေးနိုင်သည်- အကယ်၍ သင်သည် သင်၏ကိုယ်ပိုင် (cloud) ဝန်ဆောင်မှုကို စတင်လိုပါက၊ အကန့်အသတ်ရှိသော အရင်းအမြစ်များနှင့် ဖွံ့ဖြိုးတိုးတက်မှုအတွက် အမြင့်ဆုံးအမြန်နှုန်းရှိလိုပါက၊ cloud အရင်းအမြစ်များကို ငှားရမ်းခြင်းဖြင့် ယခုစတင်ပါ၊ Forbes က သင့်အကြောင်းရေးသားပြီးနောက် သင့်ဒေတာစင်တာကို တည်ဆောက်ပါ။

source: www.habr.com