ကျွန်တော် ဒီနေ့ မျှဝေပေးချင်တဲ့ အကြောင်းအရာကတော့ AWS Cloud Environment ပေါ်မှာ ကျွန်တော်တို့အနေနဲ့ ဘယ်လိုမျိုး Disaster Recovery Strategy တွေကိုအသုံးပြုလို့ရနိုင်လဲဆိုတာ ကိုမျှဝေပေးသွားမှာ ဖြစ်ပါတယ်။
Disaster Recovery Strategies တွေလို့ပဲ ပြောပြော options လို့ပဲ ပြောပြော
ကျွန်တော်တို့အနေနဲ့ Cloud ပေါ်မှာ Disaster Recovery လုပ်မယ်ဆို အောက်ပါ
အချက် အလက်တွေ နဲ့ ရင်းနီးနေဖို့လိုပါတယ်။
- Backup & Restore
- Pilot Light
- Warm Standby
- Multi-site (Active/Active)
ဒီအထက်ပါ options တွေကို မပြောပြခင်မှာ ပထမဦးစွာ
Disaster ဆိုတဲ့အကြောင်းကို IT နဲ့ ပတ်သတ်ပြီး ရှင်းပြချင်ပါတယ်။
IT မဟုတ်တဲ့ သဘာဝပတ်ဝန်းကျင်အရဆိုရင်တော့ Disaster ဆိုတာ လေဘေး၊ ရေဘေး၊ မီးဘေး၊ မုန်းတိုင်း အစရှိတဲ့ ထိခိုက်မှုတွေဆိုတာကတော့ အားလုံးသိပြီးသားဖြစ်မှာပါ။ ဒီလို သဘာဝပတ်ဝန်းကျင်ဆိုင်ရာတွေမှာလဲ Disaster Recovery Plan တွေရှိကြပါတယ်။ အသက်ကယ်အဖွဲ့တွေ ကယ်ဆယ်ရေးတွေ အစရှိသည်တို့ဖြင့်ပေါ့လေ။ ဒါက တော့ လက်တွေ့ဘဝမှာ ရှိတဲ့ သဘာဝဘေးအန္တရာယ်တွေဖြစ်လာတဲ့အခါ ဘယ်လိုမျိုး ကြိုတင်ကာကွယ်မလဲ? ဖြစ်လာရင် ဘာလုပ်မလဲ? ဆိုတာမျိုးတွေပေါ့ဗျာ
ဒီတော့ IT ဘက်ကို ပြန်သွားကြမယ် ကျွန်တော်တို့ နည်းပညာအသိုင်းအဝိုင်းမှာတော့ Disaster ဆိုတာက တော့ မိမိတို့ manage လုပ်ရတဲ့ software တွေ infra တွေ အစရှိတဲ့ enviroments တွေက တခုခုကြောင့် Down သွားရတာမျိုး (ဥပမာ- DC မှာ မီးစက်ပျက်နေတာမျိုး ၊ Network Link တွေပျက်တောက်သွားတာမျိုး၊ နောက်ပြီး Cloud မှာဆိုလဲ Region လိုက်ကြီး Down နေတာမျိုး) ဒီလိုမျိုးအကြောင်းအရာတွေကြောင့် မိမိတို့ နဲ့ သက်ဆိုင်တဲ့ environment တွေ Down လာတဲ့အခါ ဘာလုပ်မလဲဆိုတဲ့ Disaster Recovery Plan ရှိဖို့ လိုအပ်လာပြီဖြစ်ပါတယ်။ အဓိကကတော့ Down နေတဲ့အချိန် ဘယ်လို ပြန်ပြီး Recover ဖြစ်အောင် လုပ်မလဲလို့ ဆိုလိုတာပါ။
ဒါဆိုရင်တော့ Disaster ကို နားလည်ပြီလို့ ယူဆလိုက်ပါမယ်။ ဒီတော့ Disaster ဖြစ်လာရင် သိဖို့လိုအပ်တဲ့ အသုံးအနှုန်းလေး (၂) ခုရှိပါသေးတယ်။
RTO နဲ့ RPO လို့ခေါ်တဲ့ အသုံးအနှုန်းလေး နှစ်ခုပဲဖြစ်ပါတယ်။
(၁). RTO ရဲ့ အရှည်ကောက်ကတော့ Recovery Time Objective ဖြစ်ပြီး မြန်မာလို နားလည်အောင် အဓိပ္ပါယ်ဖွင့်ဆိုရမယ်ဆိုရင် အမြင်သာဆုံးပြောမယ်ဆိုရင် Down ပြီးသွားတဲ့နောက် ဘယ်အချိန်တွင်း Recover ဖြစ်မလဲဆိုတာကို ဖော်ပြခြင်းပဲဖြစ်ပါတယ်။ ဥပမာ 1 Hour RTO လို့ project requirements မှာဖော်ပြထားတယ်ဆိုရင် ကျွန်တော်တို့အတွက် system ကြီး down ပြီးနောက် အချိန်တနာရီ အတွင်း ပြန်လည်ကောင်းမွန်အောင် ပြုလုပ်ပေးရမယ်လို့ သတ်မှတ်ပါတယ်ခဗျာ။ တကယ်လို့သာ တနာရီအတွင်း မကောင်းလာခဲ့ရင်တော့ SLA (Services Level Agreement) အလိုက် ပြန်လည်ပေးဆပ်ရမှာတွေရှိလာနိုင်ပါတယ်။ SLA အကြောင်းကိုတော့ နောက် အလျင်းသင့်ရင် ဖော်ပြပေးပါမယ်ခဗျာ။
(၂). RPO ရဲ့ အရှည်ကောက်ကတော့ Recovery Point Objective ဖြစ်ပြီး မြန်မာလို ပြောရမယ်ဆိုရင်တော့ ကျွန်တော်တို့ ရဲ့ System ကြီးက Data Loss ဘယ်လောက် ဖြစ်လို့ရလဲဆိုတာကို သတ်မှတ်တာမျိုးဖြစ်ပါတယ်။ ဥပမာအားဖြင့် 8 Hours or fewer RPO သတ်မှတ်ခဲ့မယ်ဆိုရင် ကျွန်တော်တို့ အနေနဲ့ Data ဆုံးရှူံးမှု (၈) နာရီစာ လက်ခံလို့ရတယ်လို့ ဆိုလိုချင်တာပါ။ အဓိကပြောချင်တာကတော့ဗျာ down တဲ့အချိန် မတိုင်ခင် ၈ နာရီ အတွင်း ရှိနေခဲ့တဲ့ Data တွေ ဆုံးရှူံးလို့ရတယ်လို့ ပြောချင်တာပါ။ ဥပမာဗျာ System က မနက် (၁၀) ရက်နေ့ မနက် (၁၀) နာရီမှာ Down သွားတယ်ဆိုပါစို့ ကျွန်တော်တို့ မှာက (၁၀) ရက်နေ့ မနက် (၂) နာရီမှာ Backup ရှိနေတာမျိုးကို အဓိကပြောချင်တာပါ။ ဒီတော့ ကျွန်တော်တို့အနေနဲ့ မနက် (၂) ကနေ မနက် (၁၀) နာရီကြားမှာ ရှိနေတဲ့ Data တွေကိုတော့ ဆုံးရှူံးရမှာဖြစ်ပါတယ်။ ဒါဆိုရင်တော့ မြင်ပြီးထင်ပါတယ်။ ဒီတော့ဗျာ RPO 1 hour လိုချင်ရင်တော့ တနာရီတိုင်းမှာ Backup လုပ်နေရမှာမျိုးပဲဖြစ်ပါတယ်။
ဒီလောက်ဆိုရင်တော့ RTO နဲ့ RPO ကိုနားလည်သွားပြီလို့ မျှော်လင့်ပါတယ်ခဗျာ။
ဒီတော့ ကျွန်တော်တို့ နည်းပညာသမားတွေ အထူးသဖြင့် System engineer တွေ DevOps တွေ Cloud Engineer တွေ နောက်ပြီး Cloud Architect တွေအနေနဲ့
system တခုခုကို implement လုပ်မယ် architect လုပ်မယ်ဆိုတဲ့ အချိန်တွေတိုင်းမှာ
ငါတို့ system ကြီးက RTO ဘယ်လောက်ရှိဖို့လိုမလဲ? RPO ကိုရော ဘယ်လိုသတ်မှတ်မလဲဆိုတာမျိုးကို မိမိတို့ရဲ့ System အရေးကြီးပုံပေါ်မူတည်ပြီး သတ်မှတ်ဖို့လိုပါတယ်ခဗျာ။
လုံးဝကို အရေးကြီးတဲ့ critical ဖြစ်တဲ့ system တွေ (ဥပမာ- Banking, medical, etc) ဆိုရင်တော့ RTO & RPO တွေကို အချိန်အနည်းငယ်ပဲ သတ်မှတ်ကြပါတယ်။ Medium size business တွေဆိုတဖုံ small business တွေဆိုရင်တော့ ကြာကြာ down လဲရတာမျိုးတွေတော့ ရှိတာပေါ့ခဗျာ။
RTO & RPO သတ်မှတ်ချက်တွေပေါ်မူတည်ပြီး Recovery Options တွေကလဲ ကုန်ကျစားရိတ် အနည်းအများ ကွာခြားသွားပါတယ်ခဗျာ။ ဒီ Recovery Options/Strategy အကြောင်းကိုတော့ ကျွန်တော် နောက်ထပ် အပိုင်း(၂) မှာ တင်ဆက်သွားပါမယ်ခဗျာ။
အားလုံး စောင့်မျှော်ဖတ်ရှူပေးကြဖို့ မျှော်လင့်ပါတယ်ခဗျာ။
အားလုံး သဘောကျနှစ်သက်ရင်တော့ Like & Share, Comment လေးတွေ ပြုလုပ်ပေးသွားလို့ရပါတယ်ခဗျာ...
Kaung Thant Lwin
AWS Community Builder
Myanmar
Top comments (1)
waiting for part 2