Bitrix24- "အလျင်အမြန်ထမြောက်ခြင်းသည် ပြုတ်ကျသည်ဟု မယူဆပါ"

ယနေ့တွင်၊ Bitrix24 ဝန်ဆောင်မှုတွင် ရာနှင့်ချီသော အသွားအလာ ဂစ်ဂါဘစ်များ မရှိသည့်အပြင် ၎င်းတွင် ဆာဗာအမြောက်အမြားလည်း ရှိသည် (ဟုတ်ပါတယ်၊ ရှိပြီးသား အရေအတွက် အနည်းငယ်ရှိသော်လည်း)။ သို့သော် ဖောက်သည်များစွာအတွက် ၎င်းသည် ကုမ္ပဏီတွင်အလုပ်လုပ်ရန် အဓိကကိရိယာတစ်ခုဖြစ်သည်၊ ၎င်းသည် တကယ့်စီးပွားရေးအတွက် အရေးပါသော application တစ်ခုဖြစ်သည်။ ထို့ကြောင့် လဲရန်နည်းလမ်းမရှိပါ။ ပျက်ကျမှုဖြစ်သွားသော်လည်း၊ ဝန်ဆောင်မှုသည် မည်သူမျှ သတိမပြုမိဘဲ အလွန်လျင်မြန်စွာ ပြန်လည်ကောင်းမွန်လာပါက မည်သို့ဖြစ်မည်နည်း။ အလုပ်၏အရည်အသွေးနှင့် ဖောက်သည်အရေအတွက် မဆုံးရှုံးဘဲ ရှုံးနိမ့်မှုကို မည်သို့အကောင်အထည်ဖော်နိုင်မည်နည်း။ Bitrix24 ရှိ cloud ဝန်ဆောင်မှုများ၏ ဒါရိုက်တာ Alexander Demidov သည် ထုတ်ကုန်၏တည်ရှိမှု 7 နှစ်တာကာလအတွင်း ကြိုတင်မှာယူမှုစနစ် မည်သို့ပြောင်းလဲလာသည်ကို ကျွန်ုပ်တို့၏ဘလော့ဂ်အတွက် ပြောခဲ့သည်။

"ကျွန်ုပ်တို့သည် Bitrix24 ကို SaaS အဖြစ် လွန်ခဲ့သော 7 နှစ်က စတင်ခဲ့သည်။ အဓိကအခက်အခဲမှာ အောက်ပါအတိုင်းဖြစ်နိုင်သည်- SaaS အဖြစ် လူသိရှင်ကြားမစတင်မီ၊ ဤထုတ်ကုန်သည် ထုပ်ပိုးထားသောဖြေရှင်းချက်ပုံစံဖြင့် ရိုးရိုးရှင်းရှင်းတည်ရှိနေပါသည်။ ဖောက်သည်များက ၎င်းကို ကျွန်ုပ်တို့ထံမှဝယ်ယူကာ ၎င်းတို့၏ဆာဗာများတွင် လက်ခံကျင်းပခြင်း၊ ဝန်ထမ်းဆက်သွယ်ရေးအတွက် အထွေထွေဖြေရှင်းချက်၊ ဖိုင်သိုလှောင်မှု၊ အလုပ်စီမံခန့်ခွဲမှု၊ CRM၊ ဒါတွေအားလုံးပါပဲ။ 2012 တွင်၊ ကျွန်ုပ်တို့သည် ၎င်းကို SaaS အဖြစ် စတင်လုပ်ဆောင်လိုကြောင်း၊ ၎င်းကို ကိုယ်တိုင်စီမံခန့်ခွဲကာ အမှားအယွင်းခံနိုင်ရည်ရှိမှုနှင့် ယုံကြည်စိတ်ချရမှုတို့ကို အာမခံရန် ဆုံးဖြတ်ခဲ့သည်။ လမ်းတစ်လျှောက်မှာ အတွေ့အကြုံတွေရခဲ့တယ်၊ ဘာဖြစ်လို့လဲဆိုတော့ အဲဒီအချိန်အထိ ကျွန်တော်တို့မှာ အဲဒါကို ရိုးရိုးရှင်းရှင်းမရှိခဲ့ဘဲ၊ ဝန်ဆောင်မှုပေးသူတွေမဟုတ်ဘဲ ဆော့ဖ်ဝဲလ်ထုတ်လုပ်သူတွေသာဖြစ်ခဲ့တယ်။

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

SaaS အဖြစ် Bitrix.24

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

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

ကျွန်ုပ်တို့သည် လိုအပ်ချက်များကို ပုံဖော်ထားပါသည်- ၎င်းသည် မတူညီသောနေရာများတွင် တည်ရှိနိုင်မှု၊ ပုံတူပွားမှုကို ပံ့ပိုးပေးနိုင်ပြီး မတူညီသော ပထဝီဝင်အရ ဖြန့်ဝေထားသော ဒေတာစင်တာများတွင် ထားရှိရန် အကောင်းဆုံးဖြစ်သည်။ ထုတ်ကုန် ယုတ္တိဗေဒနှင့် အမှန်တကယ် ဒေတာသိုလှောင်မှုကို ခွဲခြားထားသည်။ load အလိုက် dynamically scale လုပ်နိုင်ပြီး၊ statics ကို လုံး၀ သည်းခံနိုင်ပါစေ။ ဤထည့်သွင်းစဉ်းစားချက်များမှ၊ အမှန်တကယ်တွင်၊ ကျွန်ုပ်တို့သည် တစ်နှစ်တာပတ်လုံး သန့်စင်ထားသည့် ထုတ်ကုန်အတွက် လိုအပ်ချက်များ ထွက်ပေါ်လာပါသည်။ ဤအချိန်အတောအတွင်း၊ ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ဝန်ဆောင်မှုအတွက် ထုပ်ပိုးထားသောဖြေရှင်းချက်များအတွက် တစ်စုတစ်စည်းတည်းဖြစ်လာသည့် ပလပ်ဖောင်းတွင်၊ ကျွန်ုပ်တို့သည် လိုအပ်သည့်အရာများအတွက် ပံ့ပိုးပေးခဲ့သည်။ ထုတ်ကုန်ကိုယ်တိုင်၏အဆင့်ရှိ mysql ကူးယူမှုအတွက် ပံ့ပိုးမှု- ဆိုလိုသည်မှာ၊ ကုဒ်ရေးသူ developer သည် ၎င်း၏တောင်းဆိုမှုများကို မည်သို့ဖြန့်ဝေမည်ကို မစဉ်းစားဘဲ၊ သူသည် ကျွန်ုပ်တို့၏ api ကိုအသုံးပြုကာ မာစတာများအကြား စာရေးဖတ်ခြင်းနှင့် တောင်းဆိုချက်များကို မှန်ကန်စွာ ဖြန့်ဝေနည်းကို သိရှိပါသည်။ ကျွန်များ။

ကျွန်ုပ်တို့သည် အမျိုးမျိုးသော cloud အရာဝတ္ထုသိုလှောင်မှုများအတွက် ထုတ်ကုန်အဆင့်တွင် ပံ့ပိုးမှုပြုလုပ်ထားပြီးဖြစ်သည်- google သိုလှောင်မှု၊ amazon s3 နှင့် open stack swift အတွက် ပံ့ပိုးမှုပြုလုပ်ထားပါသည်။ ထို့ကြောင့်၊ ၎င်းသည် ကျွန်ုပ်တို့အတွက် ဝန်ဆောင်မှုတစ်ခုအဖြစ်သာမက ထုပ်ပိုးထားသောဖြေရှင်းချက်တစ်ခုဖြင့် လုပ်ဆောင်သော developer များအတွက်ရော အဆင်ပြေပါသည်- ၎င်းတို့သည် ကျွန်ုပ်တို့၏ API ကို အလုပ်အတွက်သာ အသုံးပြုပါက၊ ဖိုင်ကို မည်သည့်နေရာတွင် သိမ်းဆည်းမည်ကို မစဉ်းစားဘဲ၊ ဖိုင်စနစ်တွင် စက်တွင်း သို့မဟုတ်၊ အရာဝတ္ထုဖိုင်သိုလှောင်မှုတွင်။

ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် ဒေတာစင်တာတစ်ခုလုံး၏အဆင့်တွင် ကြိုတင်စာရင်းသွင်းထားရန် ချက်ချင်းဆုံးဖြတ်ခဲ့သည်။ 2012 ခုနှစ်တွင် ကျွန်ုပ်တို့သည် ဤပလပ်ဖောင်းနှင့် အတွေ့အကြုံရှိပြီးသားဖြစ်သောကြောင့် ကျွန်ုပ်တို့သည် Amazon AWS တွင် လုံးလုံးလျားလျား လွှင့်တင်ခဲ့သည် - ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ဝဘ်ဆိုဒ်ကို ထိုနေရာတွင် လက်ခံကျင်းပခဲ့ပါသည်။ ဒေသတစ်ခုစီတွင် Amazon တွင် ရရှိနိုင်မှုဇုန်များစွာရှိသည် - တကယ်တော့ (၎င်းတို့၏ဝေါဟာရများတွင်) တစ်ခုနှင့်တစ်ခုအကြား အနည်းနှင့်အများ အမှီအခိုကင်းသော ဒေတာစင်တာများစွာရှိပြီး ဒေတာစင်တာတစ်ခုလုံး၏အဆင့်တွင် ကြိုတင်စာရင်းသွင်းထားနိုင်ခြင်းကြောင့် ကျွန်ုပ်တို့ကို ဆွဲဆောင်နိုင်ခဲ့သည်။ ၎င်းသည် ရုတ်တရက် ပျက်ကွက်ပါက၊ ဒေတာဘေ့စ်များကို မာစတာ-မာစတာကို ပုံတူကူးထားပြီး၊ ဝဘ်အက်ပလီကေးရှင်းဆာဗာများကို အရန်သိမ်းထားပြီး၊ တည်ငြိမ်ဒေတာကို s3 အရာဝတ္ထုသိုလှောင်မှုသို့ ရွှေ့ထားသည်။ ဝန်သည် ဟန်ချက်ညီသည် - ထိုအချိန်က Amazon elb မှ ဖြစ်သော်လည်း၊ ကျွန်ုပ်တို့သည် ပိုမိုရှုပ်ထွေးသော ယုတ္တိဗေဒကို လိုအပ်သောကြောင့် ကျွန်ုပ်တို့၏ ကိုယ်ပိုင် load balancers သို့ ရောက်လာပါသည်။

သူတို့လိုချင်တဲ့အရာက သူတို့ရခဲ့တာပဲ...

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

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

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

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

ငါတို့အားလုံး သိမ်းထားပြီလား။

ကျွန်ုပ်တို့တွင် US မှဖောက်သည်များစွာ၊ ဥရောပမှဖောက်သည်များစွာ၊ အရှေ့-ဂျပန်၊ စင်္ကာပူနှင့်ပိုမိုနီးစပ်သောဖောက်သည်များစွာရှိသည်။ ဟုတ်ပါတယ်, ဖောက်သည်များ၏ကြီးမားသောရှယ်ယာဝေစုရုရှား၌ရှိပါတယ်။ ဆိုလိုသည်မှာ အလုပ်သည် ဒေသတစ်ခုတည်းတွင် မဟုတ်ပါ။ အသုံးပြုသူများသည် လျင်မြန်သော တုံ့ပြန်မှုကို လိုချင်သည်၊ ဒေသန္တရ ဥပဒေများကို လိုက်နာရန် လိုအပ်ချက်များ ရှိပြီး ဒေသတစ်ခုစီတွင် ကျွန်ုပ်တို့သည် ဒေတာစင်တာနှစ်ခုကို သိမ်းဆည်းထားသည့်အပြင် ဒေသတစ်ခုအတွင်း ထားရှိရန် အဆင်ပြေသည့် အပိုဝန်ဆောင်မှုအချို့လည်း ရှိသေးသည်--တွင်ရှိသော ဖောက်သည်များအတွက်၊ ဒီဒေသက အလုပ်လုပ်တယ်။ REST ကိုင်တွယ်သူများ၊ ခွင့်ပြုချက်ဆာဗာများ၊ ၎င်းတို့သည် client တစ်ခုလုံး၏လည်ပတ်မှုအတွက် အရေးပါမှုနည်းသည်၊ ၎င်းတို့ကို လက်ခံနိုင်လောက်သော နှောင့်နှေးမှုဖြင့် သင်ပြောင်းနိုင်သော်လည်း ၎င်းတို့ကို စောင့်ကြည့်နည်းနှင့် ဘာလုပ်ရမလဲဆိုတာအတွက် ဘီးကို ပြန်လည်မတီထွင်ချင်တော့ပါ။ သူတို့နှင့်အတူ။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် အပိုထုတ်ကုန်များတွင် အရည်အချင်းတစ်မျိုးမျိုးကို တီထွင်ဖန်တီးမည့်အစား ရှိပြီးသားဖြေရှင်းချက်များကို အများဆုံးအသုံးပြုရန် ကြိုးစားနေပါသည်။ တစ်နေရာရာတွင် ကျွန်ုပ်တို့သည် အသေးအဖွဲ DNS အဆင့်တွင် ကူးပြောင်းခြင်းကို အသုံးပြုကြပြီး ဝန်ဆောင်မှု၏ အသက်ဝင်မှုကို တူညီသော DNS ဖြင့် ဆုံးဖြတ်ပါသည်။ Amazon တွင် Route 53 ဝန်ဆောင်မှုရှိသော်လည်း ၎င်းသည် သင်ထည့်သွင်းနိုင်သည့် DNS တစ်ခုမျှသာမဟုတ်ပါ၊ ၎င်းသည် ပို၍ လိုက်လျောညီထွေရှိပြီး အဆင်ပြေပါသည်။ ၎င်းမှတစ်ဆင့် သင်သည် client ကဘယ်ကလာ၍ အချို့သောမှတ်တမ်းများပေးသည်ကိုဆုံးဖြတ်ရန် ၎င်းကိုအသုံးပြုသောအခါတွင် သင်သည် ပထဝီဝင်ဆိုင်ရာဖြန့်ဝေထားသောဝန်ဆောင်မှုများကိုတည်ဆောက်နိုင်သည် - ၎င်း၏အကူအညီဖြင့် သင်သည် failover ဗိသုကာများကိုတည်ဆောက်နိုင်သည်။ တူညီသောကျန်းမာရေးစစ်ဆေးမှုများကို Route 53 ကိုယ်တိုင်တွင် configure လုပ်ထားပြီး၊ သင်စောင့်ကြည့်သည့် endpoints များကိုသတ်မှတ်ခြင်း၊ metrics သတ်မှတ်ခြင်း၊ ဝန်ဆောင်မှု၏ "အသက်ရှင်သန်မှု" ကိုဆုံးဖြတ်ရန် မည်သည့် protocols ကိုသတ်မှတ်ပါ - tcp, http, https; ဝန်ဆောင်မှု အသက်ရှင်ခြင်း ရှိ၊ မရှိ ဆုံးဖြတ်သည့် စစ်ဆေးမှုများ၏ အကြိမ်ရေကို သတ်မှတ်ပါ။ DNS ကိုယ်တိုင်တွင်မူလတန်းဖြစ်မည့်အရာ၊ အလယ်တန်းဖြစ်မည်၊ လမ်းကြောင်း 53 တွင်ကျန်းမာရေးစစ်ဆေးမှုကိုအစပျိုးပါကမည်သည့်နေရာတွင်ပြောင်းရမည်ကိုသင်သတ်မှတ်ထားသည်။ ဤအရာအားလုံးကိုအခြားကိရိယာအချို့ဖြင့်လုပ်ဆောင်နိုင်သော်လည်းအဘယ်ကြောင့်အဆင်ပြေသနည်း - ကျွန်ုပ်တို့က၎င်းကိုသတ်မှတ်သည် တစ်ကြိမ်ပြီးရင် စစ်ဆေးမှုဘယ်လိုလုပ်တယ်၊ ဘယ်လိုပြောင်းမလဲ၊ အရာအားလုံးက သူ့ဘာသာသူ အလုပ်လုပ်တယ်။

ပထမ "ဒါပေမယ့်": လမ်းကြောင်း 53 ကို ဘယ်လိုကြိုတင်ပြင်ဆင်ရမလဲ။ သူတစ်ခုခုဖြစ်သွားရင် ဘယ်သူသိမလဲ။ ကံကောင်းထောက်မစွာ၊ ကျွန်ုပ်တို့သည် ဤဂျုတ်ကိုမနင်းဖူးသော်လည်း၊ ကြိုတင်စာရင်းသွင်းရန် လိုအပ်နေသေးသည်ဟု ကျွန်ုပ်တို့ထင်မှတ်ထားသော ဇာတ်လမ်းတစ်ပုဒ်ကို ထပ်မံပြောပြပါမည်။ ဒီမှာ ကောက်ရိုးတွေ ကြိုချထားတယ်။ ကျွန်ုပ်တို့သည် လမ်းကြောင်း 53 တွင်ရှိသော ဇုန်အားလုံးကို တစ်နေ့လျှင် အကြိမ်များစွာ အပြည့်အ၀ သယ်ယူပါသည်။ Amazon ၏ API သည် ၎င်းတို့အား JSON တွင် အလွယ်တကူ ပေးပို့နိုင်စေပြီး ကျွန်ုပ်တို့တွင် ၎င်းကို ပြောင်းလဲပေးသည့် အရန်ဆာဗာများစွာ ရှိသည်၊ ၎င်းကို configs ပုံစံဖြင့် အပ်လုဒ်လုပ်ကာ အကြမ်းဖျင်းအားဖြင့် အရန်ဖွဲ့စည်းမှုပုံစံတစ်ခုရှိသည်။ တစ်ခုခုဖြစ်လာပါက၊ DNS ဆက်တင်ဒေတာကို မဆုံးရှုံးစေဘဲ ၎င်းကို ကျွန်ုပ်တို့ကိုယ်တိုင် လျင်မြန်စွာ အသုံးပြုနိုင်ပါသည်။

ဒုတိယ "ဒါပေမယ့်": ဒီပုံမှာ ဘာကို လက်ဝယ်မထားရသေးတာလဲ။ ဟန်ချက်ညီသူကိုယ်တိုင်။ ကျွန်ုပ်တို့၏ ဖောက်သည်များကို ဒေသအလိုက် ဖြန့်ဖြူးခြင်းသည် အလွန်ရိုးရှင်းပါသည်။ ကျွန်ုပ်တို့တွင် bitrix24.ru၊ bitrix24.com၊ .de ဒိုမိန်းများ ရှိသည် - ယခုအခါ ဇုန်အမျိုးမျိုးတွင် လုပ်ဆောင်နေသော မတူညီသော ဒိုမိန်း ၁၃ ခုရှိသည်။ အောက်ဖော်ပြပါသို့ ကျွန်ုပ်တို့ရောက်လာသည်- ဒေသတစ်ခုစီတွင် ၎င်း၏ကိုယ်ပိုင်မျှတမှုရှိသည်။ ၎င်းသည် ကွန်ရက်ပေါ်ရှိ အမြင့်ဆုံး load ရှိသည့်နေရာပေါ်မူတည်၍ ဒေသအနှံ့ ဖြန့်ဝေရန် ပိုမိုအဆင်ပြေစေသည်။ အကယ်၍ ၎င်းသည် ချိန်ခွင်လျှာတစ်ခုတည်းအဆင့်တွင် ပျက်ကွက်ပါက ၎င်းကို ဝန်ဆောင်မှုမှ ဖယ်ရှားပြီး dns မှ ဖယ်ရှားမည်ဖြစ်သည်။ ချိန်ခွင်လျှာအဖွဲ့တွင် ပြဿနာအချို့ရှိလျှင် ၎င်းတို့ကို အခြားဆိုက်များတွင် အရန်သိမ်းထားပြီး ၎င်းတို့ကြားတွင် တူညီသောလမ်းကြောင်း 13 ကို အသုံးပြု၍ TTL တိုတောင်းသောကြောင့် ကူးပြောင်းခြင်းသည် အများဆုံး 53၊ 2၊ 3 မိနစ်အတွင်း ဖြစ်ပေါ်ပါသည်။ .

တတိယ "ဒါပေမယ့်": ဘာတို့ ဘာတို့ ၊ S3 မှန်ပါတယ်။ အသုံးပြုသူများအတွက် s3 တွင် သိမ်းဆည်းထားသည့် ဖိုင်များကို ထားရှိသောအခါ၊ ၎င်းသည် ချပ်ဝတ်တန်ဆာဖောက်ခြင်းဖြစ်သည်ဟု ကျွန်ုပ်တို့ ရိုးသားစွာ ယုံကြည်ခဲ့ပြီး ထိုနေရာတွင် မည်သည့်အရာမှ သိမ်းဆည်းရန်မလိုအပ်ပါ။ ဒါပေမယ့် သမိုင်းက အဖြစ်အပျက်တွေ မတူဘူးဆိုတာ ပြနေတယ်။ ယေဘုယျအားဖြင့်၊ Amazon သည် S3 ကို အခြေခံဝန်ဆောင်မှုတစ်ခုအဖြစ် ဖော်ပြသည်၊ အကြောင်းမှာ Amazon ကိုယ်တိုင်က S3 ကို စက်ရုပ်ပုံများ၊ configs၊ AMI ပုံများ၊ လျှပ်တစ်ပြက်ရိုက်ချက်များ သိမ်းဆည်းရန်အတွက် S3 ကိုအသုံးပြုထားသောကြောင့်ဖြစ်သည်။ bitrix7၊ ၎င်းသည် ပန်ကာကဲ့သို့ ၎င်းနောက်တွင် ပေါ်လာသည့်အရာများ အများအပြားရှိသည် - virtual machines မစတင်နိုင်ခြင်း၊ api ချို့ယွင်းမှုစသည်ဖြင့် ပေါ်လာပါသည်။

S3 သည် တစ်ကြိမ် ပြုတ်ကျနိုင်သည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် အောက်ပါအစီအစဥ်သို့ ရောက်လာသည်- လွန်ခဲ့သော နှစ်အနည်းငယ်က ရုရှားတွင် လေးနက်သော အများသူငှာ သိုလှောင်ရုံများ မရှိတော့ဘဲ၊ ကျွန်ုပ်တို့ကိုယ်တိုင် တစ်ခုခုလုပ်ရန် ရွေးချယ်ခွင့်ကို စဉ်းစားခဲ့ကြသည်... ကံကောင်းစွာပင်၊ ကျွန်ုပ်တို့သည် ဤအရာကို မစတင်ခဲ့ဘဲ၊ ငါတို့မှာမရှိသော ကျွမ်းကျင်မှုကို တူးဖော်ပြီး ရှုပ်ပွနေပေလိမ့်မည်။ ယခု Mail.ru တွင် s3-compatible storage ရှိပြီး Yandex တွင် ၎င်းနှင့် အခြားပံ့ပိုးပေးသူအများအပြားရှိနေပြီဖြစ်သည်။ နောက်ဆုံးတွင် ကျွန်ုပ်တို့သည် ပထမဦးစွာ၊ အရန်ကူးရန်နှင့် ဒုတိယအချက်မှာ၊ ဒေသဆိုင်ရာမိတ္တူများနှင့် လုပ်ဆောင်နိုင်သည့်စွမ်းရည်ကို ကျွန်ုပ်တို့ ရရှိလိုသည့် စိတ်ကူးကို ရရှိလာပါသည်။ ရုရှားဒေသအတွက် အထူးအားဖြင့်၊ ကျွန်ုပ်တို့သည် API နှင့် တွဲဖက်အသုံးပြုနိုင်သည့် Mail.ru Hotbox ဝန်ဆောင်မှုကို အသုံးပြုပါသည်။ ကျွန်ုပ်တို့သည် အပလီကေးရှင်းအတွင်းကုဒ်အတွက် ကြီးကြီးမားမားမွမ်းမံပြင်ဆင်မှုများ မလိုအပ်ဘဲ အောက်ပါယန္တရားကို ပြုလုပ်ခဲ့သည်- s3 တွင် အရာဝတ္ထုများ ဖန်တီးခြင်း/ဖျက်ခြင်းအား အစပျိုးပေးသည့် အစပျိုးမှုများ၊ Amazon တွင် Lambda ဟုခေါ်သော ဝန်ဆောင်မှုတစ်ခု ရှိသည် - ၎င်းသည် ဆာဗာမဲ့ကုဒ်ကို စတင်ခြင်းဖြစ်သည် အချို့သော triggers များကို အစပျိုးသည့်အခါတွင် ၎င်းသည် လုပ်ဆောင်မည်ဖြစ်သည်။

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

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

အိုး Amazon က ထွက်ပြေးသွားတယ်...

ယခုနှစ် ဧပြီလသည် ရုရှားတွင် Telegram ပိတ်ဆို့ခြင်း၏ နှစ်ပတ်လည်နေ့ဖြစ်သည်။ အထိခိုက်ဆုံး ဝန်ဆောင်မှုပေးသူမှာ Amazon ဖြစ်သည်။ ကံမကောင်းစွာပဲ၊ တစ်ကမ္ဘာလုံးအတွက် အလုပ်လုပ်တဲ့ ရုရှားကုမ္ပဏီတွေက ပိုနစ်နာတယ်။

ကုမ္ပဏီသည် ကမ္ဘာလုံးဆိုင်ရာဖြစ်ပြီး ရုရှားသည် ၎င်းအတွက် အလွန်သေးငယ်ပါက 3-5% - ကောင်းစွာ၊ တစ်နည်းမဟုတ်တစ်နည်းဖြင့် ၎င်းတို့ကို စတေးနိုင်သည်။

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

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

၂၀၁၈ ခုနှစ် မတ်လနှောင်းပိုင်းတွင် Roskomnadzor သည် အကြီးဆုံးအော်ပရေတာများထံ Zello messenger ကို ပိတ်ဆို့ရန်အတွက် Amazon IP လိပ်စာ သန်းပေါင်းများစွာကို ပိတ်ဆို့ရန် ၎င်းတို့၏အစီအစဉ်များကို အသိပေးစာတစ်စောင် ပေးပို့ခဲ့သည်။ ထိုပံ့ပိုးပေးသူများကြောင့် ၎င်းတို့သည် စာကို လူတိုင်းထံ အောင်မြင်စွာ ပေါက်ကြားစေခဲ့ပြီး Amazon နှင့် ချိတ်ဆက်မှု ပြိုကွဲနိုင်ကြောင်း ရှင်းရှင်းလင်းလင်း သိလာခဲ့ရသည်။ သောကြာနေ့ဖြစ်ပြီး ကျွန်ုပ်တို့သည် servers.ru ရှိ ကျွန်ုပ်တို့၏လုပ်ဖော်ကိုင်ဖက်များထံ ထိတ်လန့်တကြားပြေးသွားပြီး "သူငယ်ချင်းတို့၊ ရုရှားမှာမဟုတ်ဘဲ Amazon မှာမဟုတ်ဘဲ အမ်စတာဒမ်မှာ တစ်နေရာရာမှာ ရှိမယ့် ဆာဗာအများအပြား လိုအပ်ပါတယ်" ဟု ပြောခဲ့သည်။ ထို့ကြောင့် အနည်းဆုံးတော့ ထိုနေရာတွင် ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ဆာဗာများကို တည်ဆောက်နိုင်မည်ဖြစ်သည်။ VPN ပြီးတော့ S3 endpoint တွေလိုမျိုး ကျွန်တော်တို့ ထိန်းချုပ်လို့မရတဲ့ endpoint အချို့အတွက် proxy တွေကိုတော့ ကျွန်တော်တို့ ထိန်းချုပ်လို့မရပါဘူး။ ဝန်ဆောင်မှုအသစ်တစ်ခု တည်ဆောက်ပြီး တခြား IP address တစ်ခု ရယူဖို့ ကြိုးစားလို့ မရပါဘူး။ ကျွန်တော်တို့ သူတို့ကို ဆက်သွယ်နိုင်ဖို့ လိုအပ်ပါသေးတယ်။ ရက်အနည်းငယ်အတွင်းမှာပဲ ဒီ server တွေကို configure လုပ်ပြီး လည်ပတ်နိုင်အောင် လုပ်ဆောင်နိုင်ခဲ့ပြီး ပိတ်ဆို့ခြင်း စတင်ဖို့ အခြေခံအားဖြင့် ပြင်ဆင်ခဲ့ပါတယ်။ စိတ်ဝင်စားစရာကောင်းတာက Roskomnadzor က ရှုပ်ထွေးမှုနဲ့ ထိတ်လန့်မှုတွေကို မြင်တွေ့ပြီးနောက် "မဟုတ်ဘူး၊ ကျွန်တော်တို့ အခု ဘာမှ မပိတ်ဆို့ပါဘူး" လို့ ပြောခဲ့ပါတယ်။ (ဒါပေမယ့် Telegram ကို ပိတ်ဆို့ဖို့ စတင်ခဲ့တဲ့အချိန်အထိပါပဲ။) bypass option တွေကို တည်ဆောက်ပြီး ပိတ်ဆို့ခြင်းကို မလုပ်ဆောင်ရသေးဘူးဆိုတာ သဘောပေါက်ပြီးနောက်မှာတော့ ကျွန်တော်တို့ဟာ ဒီကိစ္စတစ်ခုလုံးကို မစုံစမ်းဖို့ ဆုံးဖြတ်ခဲ့ကြပါတယ်။ ဖြစ်နိုင်ခြေရှိအောင်လို့ပါ။

2019 တွင်၊ ကျွန်ုပ်တို့သည် ပိတ်ဆို့ခြင်း၏အခြေအနေတွင် အသက်ရှင်ဆဲဖြစ်သည်။ မနေ့ညက ငါကြည့်ခဲ့တယ်- IP ပေါင်း တစ်သန်းခန့် ဆက်လက်ပိတ်ဆို့နေပါသည်။ မှန်ပါတယ်၊ Amazon ဟာ လုံး၀ပိတ်ဆို့လုနီးပါးဖြစ်ပြီး အထွတ်အထိပ်မှာ လိပ်စာပေါင်း သန်း 20 ကိုရောက်ရှိခဲ့ပါတယ်... ယေဘူယျအားဖြင့်၊ အဖြစ်မှန်မှာ ညီညွတ်မှု မရှိနိုင်သလို ကောင်းမွန်တဲ့ ပေါင်းစပ်မှုလည်း ဖြစ်နိုင်ပါတယ်။ ရုတ်တရက်။ နည်းပညာဆိုင်ရာ အကြောင်းပြချက်များကြောင့် မီးလောင်မှုများ၊ တူးဖော်ခြင်းများ၊ သို့မဟုတ်၊ ကျွန်ုပ်တို့တွေ့မြင်ခဲ့သည့်အတိုင်း၊ လုံးလုံးလျားလျားနည်းပညာမဟုတ်ပေ။ ထို့ကြောင့်၊ ၎င်းတို့၏ကိုယ်ပိုင် ASs ဖြင့် ကြီးကြီးကျယ်ကျယ် တစ်စုံတစ်ဦးသည် ၎င်းကို အခြားနည်းလမ်းများဖြင့် စီမံခန့်ခွဲနိုင်သည် - တိုက်ရိုက်ချိတ်ဆက်ခြင်းနှင့် အခြားအရာများသည် l2 အဆင့်တွင် ရှိနှင့်ပြီးဖြစ်သည်။ သို့သော် ကျွန်ုပ်တို့၏ သို့မဟုတ် ပိုသေးသော ရိုးရှင်းသောဗားရှင်းတွင်၊ အခြားတစ်နေရာတွင် မြှင့်တင်ထားသော ဆာဗာများအဆင့်တွင် ထပ်နေခြင်း၊ vpn၊ ပရောက်စီကို ကြိုတင်ပြင်ဆင်ထားသော၊ ထိုအပိုင်းများတွင် ၎င်းတို့ထံ configuration ကို လျင်မြန်စွာပြောင်းနိုင်သည့်စွမ်းရည်ဖြင့် သင်သည်၊ အဲဒါက မင်းရဲ့ချိတ်ဆက်မှုအတွက် အရေးကြီးတယ်။ Amazon ၏ပိတ်ဆို့ခြင်းစတင်သောအခါ၊ ဤအရာသည် ကျွန်ုပ်တို့အတွက် တစ်ကြိမ်ထက်ပို၍ အဆင်ပြေလာပါသည်၊ အဆိုးဆုံးအခြေအနေတွင်၊ ၎င်းတို့ကို S3 ဖြတ်သန်းသွားလာမှုကိုသာ ခွင့်ပြုထားသော်လည်း၊ ဤအရာအားလုံးကို တဖြည်းဖြည်းဖြေရှင်းပြီးဖြစ်သည်။

ဝန်ဆောင်မှုပေးသူတစ်ခုလုံးကို ဘယ်လိုကြိုတင်မှာရမလဲ။

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

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

automation အကြောင်း စကားအနည်းငယ်

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

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

ကောက်ချက်

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

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

ဤစာသားသည် ကွန်ဖရင့်တွင် Alexander Demidov ၏ အစီရင်ခံစာ၏ မွမ်းမံပြင်ဆင်ထားသောဗားရှင်းဖြစ်သည်။ အလုပ်ချိန်နေ့ ၄.

source: www.habr.com