ရေကြီးရင်တောင် 1C အလုပ်လုပ်သင့်တယ်။ ကျွန်ုပ်တို့သည် DR ဆိုင်ရာ လုပ်ငန်းကို သဘောတူပါသည်။

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

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

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

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

• ငါတို့ဘာကိုကာကွယ်နေတာလဲ။
• ငါတို့က ဘာကိုကာကွယ်နေတာလဲ။
• ငါတို့ဘယ်လောက်ကာကွယ်မလဲ။ 

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

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

လုပ်ငန်းဝယ်ယူသူနှင့် အရေးပေါ်အခြေအနေပြီးနောက် လုပ်ဆောင်မှုအစီအစဉ်ကို ဆွေးနွေးခြင်းဖြင့် စတင်ပြင်ဆင်ခြင်းသည် ပိုမိုကောင်းမွန်ပါသည်။ ဤနေရာတွင် အဓိကအခက်အခဲမှာ ဘုံဘာသာစကားကို ရှာဖွေရန်ဖြစ်သည်။ ဖောက်သည်သည် များသောအားဖြင့် IT ဖြေရှင်းချက် မည်သို့အလုပ်လုပ်သည်ကို ဂရုမစိုက်ပါ။ ဝန်ဆောင်မှုသည် လုပ်ငန်းဆောင်တာများကို လုပ်ဆောင်နိုင်ပြီး ငွေရနိုင်သည်ဖြစ်စေ ဂရုစိုက်သည်။ ဥပမာ- ဆိုက်က အလုပ်လုပ်နေပေမယ့် ငွေပေးချေမှုစနစ်ကျနေရင်၊ ဖောက်သည်တွေဆီက ၀င်ငွေမရှိဘူး၊ "အစွန်းရောက်" တွေဟာ အိုင်တီကျွမ်းကျင်သူတွေ ဖြစ်နေတုန်းပါပဲ။ 

အိုင်တီပညာရှင်တစ်ဦးသည် အကြောင်းရင်းများစွာအတွက် ထိုသို့သောညှိနှိုင်းမှုတွင် အခက်အခဲရှိနိုင်သည်-

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

စကားဝိုင်းကို ဒီပုံစံအတိုင်း တည်ဆောက်ပါ့မယ်။ 

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

   စီးပွားရေးလုပ်ငန်းမှ ရိုးရှင်းသောအဖြေတစ်ခု လိုအပ်ပါသည်၊ ဥပမာ- call center သည် လျှောက်လွှာများကို 24/7 တွင် ဆက်လက်မှတ်ပုံတင်ရန် လိုအပ်ပါသည်။

4. ဤလုပ်ငန်းစဉ်ကို အသေးစိတ်ဖော်ပြရန် စနစ်၏အသုံးပြုသူတစ်ဦး သို့မဟုတ် နှစ်ဦးကို ကျွန်ုပ်တို့တောင်းဆိုပါသည်။ 
   သင့်ကုမ္ပဏီတွင် တစ်ခုရှိလျှင် ကူညီရန် ခွဲခြမ်းစိတ်ဖြာသူ ပါ၀င်ခြင်းသည် ပိုကောင်းပါသည်။

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

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

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

ကျွန်ုပ်တို့ ကာကွယ်သောအရာ- အန္တရာယ်များ

ထို့နောက်တွင်၊ ကျွန်ုပ်တို့သည် မိမိတို့ကိုယ်ကို ဦးစွာကာကွယ်နိုင်သည့် အန္တရာယ်များကို လုပ်ငန်းဖောက်သည်ထံမှ ရှာဖွေတွေ့ရှိပါသည်။ ဘေးအန္တရာယ်အားလုံးကို အုပ်စုနှစ်စုခွဲနိုင်သည်။ 

• ဝန်ဆောင်မှုရပ်ဆိုင်းမှုကြောင့် အချိန်ဆုံးရှုံးခြင်း၊
• ရုပ်ပိုင်းဆိုင်ရာ သက်ရောက်မှုများ၊ လူသားဆိုင်ရာအချက်များ စသည်တို့ကြောင့် ဒေတာဆုံးရှုံးမှု

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

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

ဆွေးနွေးပြီးနောက်၊ ကျရှုံးသောအချက်များကို မည်သို့ဦးစားပေးရမည်ကို နားလည်လာပါမည်။ 

ကျွန်ုပ်တို့မည်မျှကာကွယ်သည်- RPO နှင့် RTO 

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

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

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

အသုံးပြုသူအတွက် ပြန်လည်ရယူချိန်ကို တွက်ချက်ရန် လိုအပ်သည်- သူသည် စနစ်သို့ အကောင့်ဝင်ရန် အချိန်မည်မျှကြာမည်နည်း။ ထို့ကြောင့် ပထမဦးစွာ ကျွန်ုပ်တို့သည် ကွင်းဆက်ရှိ လင့်ခ်များအားလုံး၏ ပြန်လည်ရယူချိန်ကို ပေါင်းထည့်ပါသည်။ ဤနေရာတွင် မကြာခဏအမှားလုပ်မိသည်- ၎င်းတို့သည် ဝန်ဆောင်မှုပေးသူ၏ RTO ကို SLA မှယူကာ ကျန်စည်းကမ်းချက်များကို မေ့သွားကြသည်။

တိကျတဲ့ ဥပမာကို ကြည့်ရအောင်။ အသုံးပြုသူသည် 1C သို့ဝင်ရောက်သည်၊ ဒေတာဘေ့စ်အမှားတစ်ခုဖြင့်စနစ်ဖွင့်သည်။ သူက စနစ်စီမံခန့်ခွဲသူကို ဆက်သွယ်တယ်။ ဒေတာဘေ့စ်သည် cloud တွင်တည်ရှိပြီး စနစ်စီမံခန့်ခွဲသူက ပြဿနာကို ဝန်ဆောင်မှုပေးသူထံ သတင်းပို့သည်။ ဆက်သွယ်ရေးအားလုံး 15 မိနစ်ကြာတယ်ဆိုပါစို့။ cloud တွင်၊ ဤအရွယ်အစားရှိသော ဒေတာဘေ့စ်ကို တစ်နာရီအတွင်း အရန်သိမ်းဆည်းမှုမှ ပြန်လည်ရရှိမည်ဖြစ်သည်၊ ထို့ကြောင့် ဝန်ဆောင်မှုပေးသူဘက်မှ RTO သည် တစ်နာရီဖြစ်သည်။ သို့သော် ၎င်းသည် နောက်ဆုံးသတ်မှတ်ရက်မဟုတ်ပါ၊ အသုံးပြုသူအတွက် ပြဿနာကိုရှာဖွေရန် ၎င်းတွင် 15 မိနစ်ထည့်ထားသည်။ 
 
ထို့နောက်၊ စနစ်စီမံခန့်ခွဲသူသည် ဒေတာဘေ့စ်မှန်ကန်ကြောင်း စစ်ဆေးရန်၊ ၎င်းကို 1C နှင့် ချိတ်ဆက်ပြီး ဝန်ဆောင်မှုများကို စတင်ရန် လိုအပ်သည်။ ၎င်းသည် နောက်ထပ်တစ်နာရီ လိုအပ်သည်၊ ဆိုလိုသည်မှာ စီမံခန့်ခွဲသူဘက်မှ RTO သည် 2 နာရီနှင့် 15 မိနစ်ရှိနေပြီဖြစ်သည်။ အသုံးပြုသူသည် နောက်ထပ် 15 မိနစ် လိုအပ်သည်- လော့ဂ်အင်ဝင်ပါ၊ လိုအပ်သော လွှဲပြောင်းမှုများ ပေါ်လာကြောင်း စစ်ဆေးပါ။ ဤဥပမာတွင် 2 နာရီ 30 မိနစ်သည် စုစုပေါင်းဝန်ဆောင်မှုပြန်လည်ရယူချိန်ဖြစ်သည်။

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

ကျွန်ုပ်တို့ ကာကွယ်နည်း- မတူညီသော အန္တရာယ်များအတွက် ကိရိယာများကို ရွေးချယ်ခြင်း။

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

စွန့်စားရမည့် ပထမအုပ်စုဖြင့် စကြပါစို့- ဝန်ဆောင်မှု ရပ်ဆိုင်းမှုကြောင့် ဆုံးရှုံးမှုများ။ ဤပြဿနာအတွက် ဖြေရှင်းနည်းများသည် RTO ကောင်းကောင်းကို ပေးသင့်သည်။

1. အပလီကေးရှင်းကို cloud တွင် host လုပ်ပါ။ 

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

   ဥပမာအားဖြင့်၊ သင်သည် cloud တွင် ဒေတာဘေ့စ်တစ်ခုဖြင့် virtual machine တစ်ခုကို လက်ခံကျင်းပနိုင်သည်။ အပလီကေးရှင်းသည် သတ်မှတ်ထားသောချန်နယ်တစ်ခု သို့မဟုတ် တစ်ခုတည်းသော cloud မှ ပြင်ပဒေတာဘေ့စ်သို့ ချိတ်ဆက်မည်ဖြစ်သည်။ အစုအဝေးရှိ ဆာဗာများထဲမှ တစ်ခုနှင့် ပြဿနာများ ပေါ်ပေါက်ပါက VM သည် အနီးနားရှိ ဆာဗာတွင် 2 မိနစ်အတွင်း ပြန်လည်စတင်ပါမည်။ ထို့နောက်တွင်၊ DBMS သည် ၎င်းတွင်စတင်မည်ဖြစ်ပြီး မိနစ်အနည်းငယ်အတွင်း database ကိုရရှိနိုင်မည်ဖြစ်သည်။

   OTR: မိနစ်အတွင်း တိုင်းတာသည်။ ဤစည်းကမ်းချက်များသည် ဝန်ဆောင်မှုပေးသူနှင့် သဘောတူညီချက်တွင် သတ်မှတ်နိုင်ပါသည်။
   ၏ကုန်ကျစရိတ်- သင့်အပလီကေးရှင်းအတွက် cloud အရင်းအမြစ်များ၏ ကုန်ကျစရိတ်ကို ကျွန်ုပ်တို့တွက်ချက်ပါသည်။ 
   မင်းကို ဘယ်အရာကမှ ကာကွယ်ပေးမှာ မဟုတ်ဘူး။ဥပမာ- မြို့အဆင့်တွင် မတော်တဆမှုများကြောင့် ဝန်ဆောင်မှုပေးသူ၏ဆိုက်တွင် ကြီးမားသောကျရှုံးမှုများမှ။

2. လျှောက်လွှာကို အစုလိုက်လုပ်ပါ။  

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

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

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

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

3. ဘေးဒဏ်ခံနိုင်သော တိမ်တိုက်သို့ ရွှေ့ပါ။

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

   OTR: ၀င်တတ်သည်။
   ၏ကုန်ကျစရိတ်: ဈေးအကြီးဆုံး cloud ရွေးချယ်မှု။ 
   မင်းကို ဘယ်အရာကမှ ကာကွယ်ပေးမှာ မဟုတ်ဘူး။: ၎င်းသည် ဒေတာဖောက်ပြန်မှုအပြင် လူ့အကြောင်းအရင်းမှလည်း ကူညီပေးမည်မဟုတ်သောကြောင့် တစ်ချိန်တည်းတွင် အရန်ကူးယူရန် အကြံပြုထားသည်။ 

   အလေ့အကျင့်ကနေ: ကျွန်ုပ်တို့၏ဖောက်သည်တစ်ဦးသည် ပြီးပြည့်စုံသော သဘာဝဘေးအန္တရာယ် ပြန်လည်ရယူရေးအစီအစဉ်ကို တီထွင်ခဲ့သည်။ ဒါက သူရွေးချယ်တဲ့ နည်းဗျူဟာပါ။ 

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

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

4. အခြားဆိုက်တစ်ခုသို့ ပုံတူပွားခြင်းကို စုစည်းပါ။ 

   ပင်မဆိုက်ရှိ ကမ္ဘာလုံးဆိုင်ရာပြဿနာများကို မည်သို့ရှောင်ရှားရန် အခြားရွေးချယ်စရာတစ်ခု- ပထဝီ ကြိုတင်မှာယူမှုကို ပေးဆောင်ပါ။ တစ်နည်းဆိုရသော်၊ အခြားမြို့တစ်ခုရှိ ဆိုက်တစ်ခုတွင် အရန် virtual machine များကို ဖန်တီးပါ။ DR အတွက် အထူးဖြေရှင်းနည်းများသည် ၎င်းအတွက် သင့်လျော်သည်- ကျွန်ုပ်တို့၏ ကုမ္ပဏီတွင် VMware vCloud Availability (vCAV) ကို အသုံးပြုပါသည်။ ၎င်း၏အကူအညီဖြင့်၊ သင်သည် cloud ဝန်ဆောင်မှုပေးသည့်ဆိုက်များစွာကြားတွင် အကာအကွယ်ကို စီစဉ်သတ်မှတ်နိုင်သည် သို့မဟုတ် ပရဝုဏ်အတွင်းရှိ ဝဘ်ဆိုက်တစ်ခုမှ cloud သို့ ပြန်လည်ရောက်ရှိနိုင်သည်။ vCAV နှင့် လုပ်ဆောင်ရန် အစီအစဉ်အကြောင်း အသေးစိတ်ကို ကျွန်ုပ်ပြောခဲ့ပြီးဖြစ်သည်။ ဒီမှာ. 

   RPO နှင့် RTO: 5 မိနစ်မှ။ 

   ၏ကုန်ကျစရိတ်: ပထမရွေးချယ်မှုထက် ပိုစျေးကြီးသော်လည်း ဘေးဥပဒ်ဒဏ်ခံနိုင်သော cloud တွင် ဟာ့ဒ်ဝဲပုံတူကူးခြင်းထက် စျေးသက်သာပါသည်။ စျေးနှုန်းတွင် vCAV လိုင်စင်ကုန်ကျစရိတ်၊ စီမံခန့်ခွဲမှုစရိတ်၊ cloud အရင်းအမြစ်များ၏ ကုန်ကျစရိတ်နှင့် PAYG မော်ဒယ်လ်အရ အရန်အရင်းအမြစ်များ (VM များကို ပိတ်ထားရန်အတွက် အလုပ်လုပ်သောအရင်းအမြစ်ကုန်ကျစရိတ်၏ 10%) ပါဝင်ပါသည်။

   အလေ့အကျင့်ကနေ: client သည် မော်စကိုရှိ ကျွန်ုပ်တို့၏ cloud တွင် မတူညီသောဒေတာဘေ့စ်များပါသည့် virtual machine 6 ခုကို သိမ်းဆည်းထားသည်။ အစပိုင်းတွင်၊ အရန်ကူးခြင်းဖြင့် အကာအကွယ်ပေးသည်- အချို့သော အရန်မိတ္တူများကို မော်စကိုရှိ cloud တွင် သိမ်းဆည်းထားပြီး အချို့ကို ကျွန်ုပ်တို့၏ စိန့်ပီတာစဘတ်ဆိုက်တွင် သိမ်းဆည်းထားသည်။ အချိန်ကြာလာသည်နှင့်အမျှ ဒေတာဘေ့စ်များသည် အရွယ်အစားကြီးလာပြီး အရန်သိမ်းဆည်းမှုမှ ပြန်လည်ရယူရန် အချိန်ပိုကြာလာသည်။ 
    
   VMware vCloud ရရှိနိုင်မှုအပေါ် အခြေခံ၍ ကူးယူခြင်းအား အရန်ကူးများထဲသို့ ထည့်ထားသည်။ virtual machines များ၏ ပုံတူများကို စိန့်ပီတာစဘတ်ရှိ အရန်ဆိုက်တွင် သိမ်းဆည်းထားပြီး 5 မိနစ်တိုင်း အပ်ဒိတ်လုပ်ပါသည်။ ပင်မဆိုက်တွင် ချို့ယွင်းချက်တစ်ခုဖြစ်ပေါ်ပါက ဝန်ထမ်းများသည် စိန့်ပီတာစဘတ်ရှိ virtual machine ၏ပုံတူသို့ လွတ်လပ်စွာပြောင်းကာ ၎င်းနှင့် ဆက်လက်လုပ်ဆောင်သည်။ 

ထည့်သွင်းစဉ်းစားထားသော ဖြေရှင်းချက်အားလုံးသည် မြင့်မားသောရရှိနိုင်မှုအား ပေးစွမ်းသော်လည်း ransomware ဗိုင်းရပ်စ် သို့မဟုတ် မတော်တဆဝန်ထမ်းအမှားကြောင့် ဒေတာဆုံးရှုံးမှုကို မကာကွယ်နိုင်ပါ။ ဤကိစ္စတွင်၊ ကျွန်ုပ်တို့သည် လိုအပ်သော RPO ကိုပံ့ပိုးပေးမည့် အရန်များ လိုအပ်ပါမည်။

5. အရန်ကူးရန် မမေ့ပါနှင့်

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

အတိအကျပြောရလျှင်၊ အရန်ကူးခြင်းသည် DR မဟုတ်ပါ။ အဲဒါကြောင့်- 

• အချိန်တော်တော်ကြာပါတယ်။ ဒေတာကို terabytes ဖြင့် တိုင်းတာပါက ပြန်လည်ရယူရန် တစ်နာရီထက်ပိုကြာပါမည်။ သင်ပြန်လည်ရယူရန်၊ ကွန်ရက်တစ်ခုသတ်မှတ်ပေးရန်၊ ၎င်းကိုဖွင့်ထားကြောင်းစစ်ဆေးရန်၊ ဒေတာသည်အစီအစဥ်ရှိမရှိကြည့်ရှုရန်လိုအပ်သည်။ ဒါကြောင့် ဒေတာအနည်းငယ်သာရှိမှသာ RTO ကောင်းကောင်းကို ပေးနိုင်ပါတယ်။ 
• ဒေတာကို ပထမအကြိမ်တွင် ပြန်လည်ရယူနိုင်မည်မဟုတ်ပါ၊ လုပ်ဆောင်ချက်ကို ထပ်ခါတလဲလဲလုပ်ရန် အချိန်ပေးရပါမည်။ ဥပမာအားဖြင့်၊ မည်သည့်အချိန်တွင် ဒေတာ ပျောက်ဆုံးသွားသည်ကို ကျွန်ုပ်တို့ အတိအကျ မသိသည့် အချိန်များ ရှိပါသည်။ 15.00 တွင် ဆုံးရှုံးမှုကို သတိပြုမိပြီး နာရီတိုင်း မိတ္တူထုတ်သည် ဆိုကြပါစို့။ 15.00 မှ 14:00၊ 13:00 စသည်ဖြင့် ပြန်လည်ရယူသည့်အချက်အားလုံးကို ကြည့်ရှုပါသည်။ စနစ်သည် အရေးကြီးပါက၊ ပြန်လည်ရယူသည့်အချက်၏ အသက်ကို လျှော့ချရန် ကြိုးစားသည်။ သို့သော် လတ်ဆတ်သော မိတ္တူတွင် လိုအပ်သောဒေတာ မပါဝင်ပါက၊ ကျွန်ုပ်တို့သည် နောက်ထပ်အချက်ကို ယူသည် - ဤအချိန်သည် အပိုအချိန်ဖြစ်သည်။ 

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

နောက်ဆုံး ဘေးအန္တရာယ် ပြန်လည် ထူထောင်ရေး အစီအစဉ်တွင် အနည်းဆုံး ကိရိယာ ၂ ခု ပါဝင်သင့်သည်-  

• စနစ်များ ကျရှုံးခြင်းမှ ကာကွယ်ပေးမည့် ရွေးချယ်မှု 1-4 များထဲမှ တစ်ခု။
• ဒေတာဆုံးရှုံးမှုမှကာကွယ်ရန် Backup ။ 

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

source: www.habr.com