152-FZ ၏လိုအပ်ချက်များကို မည်သို့လိုက်နာရမည်နည်း၊ သင့်ဖောက်သည်များ၏ ကိုယ်ရေးကိုယ်တာအချက်အလက်များကို ကာကွယ်ပြီး ကျွန်ုပ်တို့၏လူယုတ်မာအပေါ် မတက်လှမ်းပါ။  

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

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

152-FZ အောက်တွင် ဒေတာကို ကျွန်ုပ်တို့ မည်သို့ကာကွယ်နိုင်မည်နည်း။

2019 ခုနှစ်အစတွင်၊ ဝန်ဆောင်မှုစီမံခန့်ခွဲမှုအတွက် ပလပ်ဖောင်းတစ်ခု၏ developer ဖြစ်သော Smart-Service LLC မှ ဆက်သွယ်ခဲ့ပါသည်။ HubEx နှင့် အဆက်အသွယ် မျှဝေခြင်း အပလီကေးရှင်းများ myQRcards.
 
ပထမဖြေရှင်းချက်သည် ရုံးခန်းဝုဏ်အတွင်း ကော်ဖီစက်များနှင့် လေအေးပေးစက်များ တပ်ဆင်ခြင်းမှ ဓာတ်ငွေ့တာဘိုင်များ ပြုပြင်ခြင်းအထိ နယ်ပယ်အမျိုးမျိုးတွင် စက်ကိရိယာများ ပြုပြင်ထိန်းသိမ်းခြင်းလုပ်ငန်းစဉ်ကို အလိုအလျောက်လုပ်ဆောင်နိုင်စေမည်ဖြစ်သည်။ ဒုတိယမှာ QR ကုဒ်များကိုအခြေခံ၍ အီလက်ထရွန်နစ်စီးပွားရေးကတ်များဖန်တီးရန်အတွက် အွန်လိုင်းဒီဇိုင်နာတစ်ဦးဖြစ်သည်။ 

အွန်လိုင်းစီးပွားရေးကတ် myQRcards။

စနစ်နှစ်ခုစလုံးသည် 152-FZ အရ "ကိုယ်ရေးကိုယ်တာ" ၏ အမျိုးအစားခွဲခြားမှုအောက်တွင် ကျရောက်နေသော သုံးစွဲသူဒေတာကို သိမ်းဆည်းပြီး စီမံဆောင်ရွက်ပါသည်။ ဤကိစ္စတွင်၊ ဥပဒေသည် လိုအပ်သော လုံခြုံရေးအဆင့်ကို သေချာစေရန်နှင့် ခိုးယူခြင်း သို့မဟုတ် အလွဲသုံးစားလုပ်ခြင်းအတွက် ရည်ရွယ်ချက်ဖြင့် ခွင့်ပြုချက်မရှိဘဲ ဝင်ရောက်ခြင်း၏အန္တရာယ်ကို ဖယ်ရှားနိုင်စေရန်အတွက် ယင်းကဲ့သို့သော ကိုယ်ရေးကိုယ်တာဒေတာအတွက် သိုလှောင်မှုစနစ်များအပေါ် ကန့်သတ်ချက်အများအပြားကို ပြဋ္ဌာန်းထားသည်။
 
ဥပဒေကို လိုက်နာရမည်ဖြစ်သော်လည်း၊ Smart Service သည် ကိုယ်ရေးကိုယ်တာအချက်အလက်များကို ကာကွယ်ရန် အရည်အချင်းကို သူ့ဘာသာသူ မြှင့်တင်ရန် အစီအစဉ်မရှိပေ။ ထို့ကြောင့်၊ ၎င်းတို့၏အသုံးပြုသူများ မျှဝေထားသော ဝန်ဆောင်မှုများနှင့် ဒေတာများကို Linxdatacenter သို့ “ရွှေ့” ထားသည်။ "Smart-Service" သည် အလုပ်ပတ်ဝန်းကျင်၏ ဆာဗာစွမ်းရည်ကို 152-FZ တွင်ဖော်ပြထားသည့် လိုအပ်ချက်များနှင့်အညီ အသိအမှတ်ပြုထားသော ကျွန်ုပ်တို့၏ဒေတာစင်တာ၏ သီးခြားကာကွယ်ထားသော ကွန်ရက်ဇုန်သို့ လွှဲပြောင်းပေးသည် - "Secure Cloud" ဟုခေါ်သော လိုအပ်ချက်များနှင့်အညီ။
 

လုံခြုံသော Cloud ကို မည်သို့ဒီဇိုင်းထုတ်ထားသနည်း။

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

• ဒေတာသိမ်းဆည်းခြင်းနှင့် လုပ်ဆောင်ခြင်းဆာဗာများသို့ ဝင်ရောက်ခွင့်ကို GOST နှင့်အညီ ကုဒ်ဝှက်ခြင်းဖြင့် VPN ချန်နယ်တစ်ခုမှတစ်ဆင့် ပြုလုပ်ရမည်ဖြစ်ပါသည်။
• ဒေတာသိမ်းဆည်းခြင်းနှင့် လုပ်ဆောင်ခြင်း ဆာဗာများကို အားနည်းချက်များအတွက် ဗိုင်းရပ်စ်ဆန့်ကျင်ကာကွယ်မှုဖြင့် အဆက်မပြတ် စောင့်ကြည့်နေရပါမည်။
• သိုလှောင်မှုစနစ်အား သီးခြားကွန်ရက်များတွင် ထားရှိရပါမည်။ 

ကျွန်ုပ်တို့သည် 152-FZ လိုအပ်ချက်များနှင့် ကိုက်ညီသော သီးခြားနေရာများတွင် ဖောက်သည်၏ဆာဗာစွမ်းရည်များကို ထားရှိကာ လိုက်နာမှုအပေါ် နိဂုံးချုပ်ချက်ရရှိရန် ကူညီပေးပါသည်။

Smart Service LLC အတွက် လုံခြုံသော virtual အခြေခံအဆောက်အဦ၏ ဗိသုကာ။

အလုပ်၏တိုးတက်မှုကို

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

ထို့ကြောင့် အဆင့် ၄ ဆင့်ခွဲ၍ ရှင်းလင်းသော လုပ်ငန်းစီမံချက်ကို ရေးဆွဲပြီး သဘောတူညီခဲ့ပါသည်။

• ပြင်ဆင်မှု,
• ရွှေ့ပြောင်းခြင်း၊
• စမ်းသပ်ခြင်း နှင့် စမ်းသပ်ခြင်း ၊
• စောင့်ကြည့်ရေးစနစ်များကို ဖွင့်ပေးပြီး ဝင်ရောက်ခွင့် ကန့်သတ်ချက်များ။

ဘေးကင်းစေရန်အတွက်၊ ကျွန်ုပ်တို့တွင် Disaster Recovery Procedure (DRP) ကို ထည့်သွင်းထားပါသည်။ ကနဦးအစီအစဉ်အရ၊ အလုပ်သည် အချိန်နှင့် အရင်းအမြစ်များစွာ မယူဘဲ 2019 ခုနှစ် ဇူလိုင်လတွင် အပြီးသတ်ရန် စီစဉ်ထားသည်။ အဆင့်တိုင်းတွင် ကွန်ရက်ရရှိနိုင်မှုနှင့် စနစ်များ၏ လုပ်ဆောင်နိုင်စွမ်းကို စမ်းသပ်မှု အပြည့်အစုံ ပါဝင်ပါသည်။

“တစ်ခုခုမှားသွားနိုင်တယ်” ဟူသော အခက်ခဲဆုံးအဆင့်မှာ ရွှေ့ပြောင်းနေထိုင်ခြင်းပင်ဖြစ်သည်။ ကနဦးတွင်၊ ကျွန်ုပ်တို့သည် virtual machine တစ်ခုလုံးကို လွှဲပြောင်းခြင်းဖြင့် ရွှေ့ပြောင်းခြင်းကို လုပ်ဆောင်ရန် စီစဉ်ထားပါသည်။ ၎င်းသည် ပြန်လည်ဖွဲ့စည်းမှုအတွက် ထပ်လောင်းရင်းမြစ်များ ပါဝင်ရန်မလိုအပ်သောကြောင့် ၎င်းသည် ယုတ္တိအရှိဆုံးရွေးချယ်မှုဖြစ်သည်။ vMotion သည် ပိုမိုရိုးရှင်းသည်ဟု ထင်ရပေမည်။
  

မမျှော်လင့်ဘဲ

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

virtual machine တစ်ခုစီသည် 500 - 1 GB ကိုယူထားသောကြောင့် data center တစ်ခုအတွင်း၌ပင်ထို volumes များကိုကူးယူခြင်းသည်စက်တစ်စက်လျှင် 000-3 နာရီခန့်ကြာသည်။ ရလဒ်အနေဖြင့် ကျွန်ုပ်တို့သည် သတ်မှတ်ထားသော အချိန်ပြတင်းပေါက်နှင့် မကိုက်ညီပါ။ ဒေတာကို vCloud သို့ လွှဲပြောင်းရာတွင် disk ခွဲစနစ်၏ ရုပ်ပိုင်းဆိုင်ရာ ကန့်သတ်ချက်များကြောင့် ဖြစ်ပေါ်လာခြင်းဖြစ်သည်။

အသုံးပြုထားသော vCloud ဗားရှင်းရှိ ချွတ်ယွင်းချက်တစ်ခုသည် သိုလှောင်မှု vMotion ကို ဒစ်အမျိုးအစားအမျိုးမျိုးရှိသည့် virtual machine တစ်ခုအတွက် စီစဉ်ခွင့်မပြုသောကြောင့် ဒစ်ခ်များကို ပြောင်းလဲရမည်ဖြစ်သည်။ ရလဒ်အနေဖြင့်၊ ၎င်းသည် virtual machines များကို လွှဲပြောင်းရန် ဖြစ်နိုင်သော်လည်း စီစဉ်ထားသည်ထက် ပိုကြာပါသည်။ 
 
ကျွန်ုပ်တို့မဖြည့်ဆည်းပေးခဲ့သည့် ဒုတိယအချက်မှာ ဒေတာဘေ့စ်အစုအဝေး (Failover Cluster MS SQLServer) ကို ရွှေ့ရန် ကန့်သတ်ချက်များဖြစ်သည်။ ရလဒ်အနေဖြင့်၊ node တစ်ခုနှင့်အလုပ်လုပ်ရန် cluster ကိုပြောင်းပြီး ကာကွယ်ထားသောဇုန်အပြင်ဘက်တွင်ထားရန် လိုအပ်သည်။ 

မှတ်သားထိုက်သည်- မရှင်းလင်းသေးသော အကြောင်းပြချက်ကြောင့်၊ virtual machines များ လွှဲပြောင်းခြင်း၏ ရလဒ်အနေဖြင့်၊ application cluster ကွဲသွားကာ ပြန်လည်ဖွဲ့စည်းရမည်ဖြစ်ပါသည်။

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

ကြိုးစားမှု နံပါတ် ၂

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

ရလဒ်အနေဖြင့်၊ သဘာဝထိန်းသိမ်းရေးနယ်မြေရှိ အစုအဝေးများ လုံးလုံးပွားသွားသောအခါ ရွှေ့ပြောင်းခြင်းမှာ ပြဿနာမရှိခဲ့ပေ။

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

ထိရောက်သောရလဒ်နှင့် အသုံးဝင်သောသင်ခန်းစာ

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

1. သီးခြားကွန်ရက်ခွဲတစ်ခုကို စီစဉ်ပြီးပါပြီ။
2. စုစုပေါင်း၊ အစုအဝေးနှစ်ခုကို virtual machines ငါးခုပါ၀င်သည်- Failover database cluster ( virtual machines နှစ်ခု) ၊ Service Fabric application cluster ( virtual machines သုံးခု )
3. ဒေတာကာကွယ်ရေးနှင့် ကုဒ်ဝှက်စနစ်များကို စီစဉ်သတ်မှတ်ထားသည်။

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

source: www.habr.com