تصور وکړئ: تاسو د لوی شاپینګ مرکز د IT زیربنا خدمت کوئ. په ښار کې باران پیل کیږي. د باران جریان د چت له لارې تیریږي، اوبه د پرچون ودانۍ د پښو ژوره ډکوي. موږ هیله لرو چې ستاسو د سرور خونه په حوزه کې نه وي، که نه نو د ستونزو مخنیوی نشي کیدی.
بیان شوې کیسه یو خیال نه دی، مګر د 2020 د څو پیښو ټولیز توضیحات. په لویو شرکتونو کې، د ناورین د بیا رغونې پالن (DRP) تل د دې قضیې لپاره په لاس کې وي. په شرکتونو کې، دا د سوداګرۍ دوام متخصصینو مسؤلیت دی. مګر په متوسط او کوچنیو شرکتونو کې، دا ډول ستونزې حل کول د معلوماتي ټکنالوجۍ په خدماتو کې راځي. تاسو اړتیا لرئ د سوداګرۍ منطق پخپله درک کړئ ، پوه شئ چې څه ناکام کیدی شي او چیرې ، د محافظت سره راشي او پلي یې کړي.
دا خورا ښه دی که چیرې د معلوماتي ټکنالوجۍ متخصص د سوداګرۍ سره خبرې اترې وکړي او د ساتنې اړتیا په اړه بحث وکړي. مګر ما له یو ځل څخه ډیر لیدلي چې څنګه یو شرکت د ناورین بیا رغونه (DR) حل ته مخه کړه ځکه چې دا یې بې ځایه ګڼلې. کله چې یوه حادثه رامنځ ته شوه، اوږده بیا رغونه د زیانونو ګواښ کوي، او سوداګرۍ چمتو نه و. تاسو کولی شئ څومره چې وغواړئ تکرار کړئ: "ما تاسو ته وویل،" مګر د معلوماتي ټکنالوجۍ خدمت به لاهم خدمتونه بحال کړي.
د معمار له موقعیت څخه، زه به تاسو ته ووایم چې څنګه د دې وضعیت څخه مخنیوی وشي. د مقالې په لومړۍ برخه کې، زه به د چمتووالي کار وښیم: د پیرودونکي سره د امنیتي وسیلو غوره کولو لپاره د دریو پوښتنو په اړه څنګه بحث وکړئ:
- موږ د څه ساتنه کوو؟
- موږ له څه څخه ساتنه کوو؟
- موږ څومره ساتنه کوو؟
په دویمه برخه کې، موږ به د پوښتنې ځواب لپاره د اختیارونو په اړه وغږیږو: څنګه د ځان دفاع وکړو. زه به د قضیو مثالونه ورکړم چې څنګه مختلف پیرودونکي خپل محافظت رامینځته کوي.
هغه څه چې موږ یې ساتو: د سوداګرۍ مهمې دندې پیژندل
دا غوره ده چې د سوداګرۍ پیرودونکي سره د بیړني حالت وروسته عمل پلان په اړه بحث کولو سره چمتو کول پیل کړئ. دلته اصلي مشکل د یوې ګډې ژبې موندل دي. پیرودونکي معمولا پروا نه کوي چې د آی ټي حل څنګه کار کوي. هغه پاملرنه کوي چې ایا خدمت کولی شي سوداګریزې دندې ترسره کړي او پیسې راوړي. د مثال په توګه: که چیرې سایټ کار کوي، مګر د تادیې سیسټم ټیټ دی، د پیرودونکو څخه هیڅ عاید شتون نلري، او "افراطي" لاهم د معلوماتي ټکنالوجۍ متخصصین دي.
د معلوماتي ټکنالوجۍ متخصص ممکن د ډیری دلایلو لپاره پدې خبرو اترو کې ستونزې ولري:
- د معلوماتي ټیکنالوژۍ خدمت په سوداګرۍ کې د معلوماتو سیسټم رول په بشپړ ډول نه پوهیږي. د مثال په توګه، که چیرې د سوداګرۍ پروسو یا د سوداګرۍ شفاف ماډل شتون شتون نلري.
- ټوله پروسه د آی ټي خدمت پورې اړه نلري. د مثال په توګه، کله چې د کار یوه برخه د قراردادیانو لخوا ترسره کیږي، او د معلوماتي ټکنالوجۍ متخصصین په دوی مستقیم نفوذ نلري.
زه به د خبرو جوړښت داسې جوړ کړم:
- موږ سوداګرۍ ته تشریح کوو چې حادثې د هرچا سره پیښیږي، او بیا رغونه وخت نیسي. تر ټولو ښه خبره دا ده چې د حالاتو څرګندونه وکړي، دا څنګه پیښیږي او کومې پایلې ممکن دي.
- موږ وښیو چې هر څه د معلوماتي ټکنالوجۍ خدمت پورې اړه نلري، مګر تاسو چمتو یاست چې د خپل مسؤلیت په ساحه کې د عمل پلان سره مرسته وکړئ.
- موږ د سوداګرۍ پیرودونکي څخه پوښتنه کوو چې ځواب راکړئ: که چیرې اپوکالیپس پیښ شي ، کوم پروسه باید لومړی بحال شي؟ څوک پکې برخه اخلي او څنګه؟
د سوداګرۍ څخه یو ساده ځواب ته اړتیا ده، د بیلګې په توګه: د تلیفون مرکز باید د 24/7 غوښتنلیکونو ثبتولو ته دوام ورکړي.
- موږ د سیسټم له یو یا دوه کاروونکو څخه غوښتنه کوو چې دا پروسه په تفصیل سره تشریح کړي.
دا غوره ده چې یو شنونکی شامل کړئ ترڅو مرسته وکړي که ستاسو شرکت ولري.د پیل کولو لپاره ، توضیحات ممکن داسې ښکاري: د تلیفون مرکز غوښتنې د تلیفون له لارې ، د بریښنالیک له لارې او د ویب پا toې څخه د پیغامونو له لارې ترلاسه کوي. بیا هغه دوی د ویب انٹرفیس له لارې 1C ته ننوځي ، او تولید یې له دې لارې له هغه ځایه اخلي.
- بیا موږ ګورو چې کوم هارډویر او سافټویر حلونه د پروسې ملاتړ کوي. د هراړخیز محافظت لپاره، موږ درې درجې په پام کې نیسو:
- په سایټ کې غوښتنلیکونه او سیسټمونه (د سافټویر کچه)،
- پخپله سایټ چیرې چې سیسټمونه چلیږي (د زیربنا کچه)،
- شبکه (دوی اکثرا د دې په اړه هیروي).
- موږ د ناکامۍ احتمالي ټکي ومومئ: د سیسټم نوډونه چې د خدماتو فعالیت پورې اړه لري. موږ په جلا توګه نوډونه یادونه کوو چې د نورو شرکتونو لخوا ملاتړ کیږي: د مخابراتو آپریټرونه، کوربه چمتو کونکي، د معلوماتو مرکزونه، او داسې نور. د دې سره، تاسو کولی شئ د بل ګام لپاره سوداګریز پیرودونکي ته بیرته راستانه شئ.
هغه څه چې موږ یې ساتو: خطرونه
بیا، موږ د سوداګرۍ پیرودونکي څخه پوهیږو چې موږ لومړی له کوم خطرونو څخه ځان ساتو. ټول خطرونه په دوه ډلو ویشل کیدی شي:
- د خدماتو د ځنډولو له امله د وخت ضایع کول؛
- د فزیکي اغیزو، انساني عواملو او نورو له امله د معلوماتو ضایع کول.
سوداګرۍ د معلوماتو او وخت دواړو له لاسه ورکولو څخه ویره لري - دا ټول د پیسو له لاسه ورکولو لامل کیږي. نو بیا موږ د هر خطر ګروپ لپاره پوښتنې کوو:
- د دې پروسې لپاره، ایا موږ اټکل کولی شو چې څومره د معلوماتو ضایع او د وخت ضایع کول په پیسو کې لګښت لري؟
- کوم معلومات موږ له لاسه نه ورکوو؟
- چیرته موږ نشو کولی د ځنډ وخت ته اجازه ورکړو؟
- کومې پیښې زموږ لپاره خورا احتمالي او خورا ګواښونکي دي؟
د بحث وروسته، موږ به پوه شو چې څنګه د ناکامۍ ټکو ته لومړیتوب ورکړو.
موږ څومره ساتنه کوو: RPO او RTO
کله چې د ناکامۍ مهم ټکي روښانه وي، موږ د RTO او RPO شاخصونه محاسبه کوو.
اجازه راکړئ تاسو ته یادونه وکړم RTO (د بیا رغونې وخت هدف) - دا د حادثې له شیبې څخه تر هغه وخته پورې د منلو وړ وخت دی چې خدمت په بشپړ ډول بحال شي. د سوداګرۍ په ژبه کې، دا د منلو وړ وخت دی. که موږ پوهیږو چې پروسې څومره پیسې راوړي، موږ کولی شو د ځنډ وخت هرې دقیقې څخه زیانونه محاسبه کړو او د منلو وړ زیان محاسبه کړو.
RPO (د بیا رغونې نقطه هدف) - د اعتبار وړ ډیټا بیرته ترلاسه کولو نقطه. دا هغه وخت ټاکي چې په جریان کې موږ کولی شو ډاټا له لاسه ورکړو. د سوداګرۍ له نظره، د معلوماتو ضایع کولی شي د جریمې پایله ولري، د بیلګې په توګه. دا ډول تاوان هم په پیسو بدلیدای شي.
د بیا رغونې وخت باید د وروستي کارونکي لپاره محاسبه شي: هغه به څومره وخت توان ولري چې سیسټم ته ننوځي. نو لومړی موږ په زنځیر کې د ټولو لینکونو د بیا رغونې وخت اضافه کوو. یوه تېروتنه اکثرا دلته کیږي: دوی د SLA څخه د چمتو کونکي RTO اخلي، او د پاتې شرایطو په اړه هیروي.
راځئ چې یو ځانګړی مثال وګورو. کارونکي 1C ته ننوځي، سیسټم د ډیټابیس غلطی سره خلاصیږي. هغه د سیسټم مدیر سره اړیکه نیسي. ډیټابیس په کلاوډ کې موقعیت لري، د سیسټم مدیر د خدماتو چمتو کونکي ته ستونزه راپور ورکوي. راځئ چې ووایو ټولې اړیکې 15 دقیقې وخت نیسي. په بادل کې، د دې اندازې ډیټابیس به په یو ساعت کې د بیک اپ څخه بیرته راستانه شي، له همدې امله، د خدماتو چمتو کونکي اړخ کې RTO یو ساعت دی. مګر دا وروستۍ نیټه نه ده؛ د کارونکي لپاره، 15 دقیقې اضافه شوي ترڅو ستونزه معلومه کړي.
بیا، د سیسټم مدیر باید وګوري چې ډیټابیس سم دی، دا د 1C سره وصل کړئ او خدمات پیل کړئ. دا یو بل ساعت ته اړتیا لري، پدې معنی چې د مدیر لوري RTO لا دمخه 2 ساعته او 15 دقیقې دي. کاروونکي نور 15 دقیقو ته اړتیا لري: ننوتل، وګورئ چې اړین لیږدونه ښکاره شوي. 2 ساعته 30 دقیقې په دې مثال کې د خدماتو د بیا رغونې ټول وخت دی.
دا حسابونه به سوداګرۍ وښیې چې د بیا رغونې موده په کوم بهرني فکتورونو پورې اړه لري. د مثال په توګه، که دفتر سیلاب شوی وي، تاسو باید لومړی لیک ومومئ او سم یې کړئ. دا به وخت ونیسي، کوم چې په IT پورې اړه نلري.
موږ څنګه ساتنه کوو: د مختلف خطرونو لپاره د وسیلو غوره کول
د ټولو ټکو په اړه بحث کولو وروسته، پیرودونکي دمخه د سوداګرۍ لپاره د حادثې لګښت پوهیږي. اوس تاسو کولی شئ وسایل وټاکئ او د بودیجې په اړه بحث وکړئ. د پیرودونکو قضیو مثالونو په کارولو سره ، زه به تاسو ته وښیم چې موږ د مختلف کارونو لپاره کوم وسیلې وړاندیز کوو.
راځئ چې د خطرونو لومړۍ ډلې سره پیل وکړو: د خدماتو د ځنډیدو له امله زیانونه. د دې ستونزې حل باید ښه RTO چمتو کړي.
- په بادل کې غوښتنلیک کوربه کړئ
د پیل کولو لپاره، تاسو کولی شئ په ساده ډول بادل ته لاړ شئ - چمتو کونکي دمخه د لوړ شتون مسلو په اړه فکر کړی. د مجازی کولو کوربه په کلستر کې راټول شوي، بریښنا او شبکه ساتل کیږي، ډاټا د غلطۍ زغمونکي ذخیره کولو سیسټمونو کې زیرمه شوي، او د خدماتو چمتو کونکي د وخت لپاره مالي مسؤل دي.
د مثال په توګه، تاسو کولی شئ په بادل کې د ډیټابیس سره یو مجازی ماشین کوربه کړئ. غوښتنلیک به د ډیټابیس سره په بهر کې د تاسیس شوي چینل له لارې یا د ورته بادل څخه وصل شي. که په کلستر کې د یو سرور سره ستونزې رامینځته شي ، نو VM به د 2 دقیقو څخه لږ وخت کې په ګاونډي سرور کې بیا پیل شي. له هغې وروسته، DBMS به په دې کې پیل شي، او په څو دقیقو کې به ډیټابیس شتون ولري.
OTR: په دقیقو کې اندازه شوی دا شرایط د چمتو کونکي سره په تړون کې مشخص کیدی شي.
د لګښت: موږ ستاسو د غوښتنلیک لپاره د بادل سرچینو لګښت محاسبه کوو.
هغه څه چې دا به ستاسو څخه ساتنه ونه کړي: د چمتو کونکي سایټ کې د لویو ناکامیو څخه، د بیلګې په توګه، د ښار په کچه د پیښو له امله. - غوښتنلیک کلستر کړئ
که تاسو غواړئ RTO ښه کړئ، تاسو کولی شئ پخوانی اختیار پیاوړی کړئ او سمدلاسه په کلاوډ کې کلستر شوی غوښتنلیک ځای په ځای کړئ.
تاسو کولی شئ په فعال - غیر فعال یا فعال فعال حالت کې کلستر پلي کړئ. موږ د پلورونکي اړتیاو پراساس ډیری VMs رامینځته کوو. د ډیر اعتبار لپاره، موږ دوی په مختلفو سرورونو او ذخیره کولو سیسټمونو کې ویشو. که چیرې سرور د یو ډیټابیس سره ناکام شي، د بیک اپ نوډ په څو ثانیو کې بار اخلي.
OTR: په ثانیو کې اندازه شوی.
د لګښت: د منظم بادل په پرتله یو څه ډیر ګران، اضافي سرچینې به د کلستر کولو لپاره اړین وي.
هغه څه چې دا به ستاسو څخه ساتنه ونه کړي: بیا هم په سایټ کې د لویو ناکامیو په وړاندې ساتنه نه کوي. مګر محلي ګډوډي به تر هغه وخته دوام ونه کړي.له تمرین څخه: پرچون شرکت څو معلوماتي سیسټمونه او ویب پاڼې درلودې. ټول ډیټابیسونه په محلي توګه د شرکت په دفتر کې موقعیت لري. د هیڅ DR په اړه فکر نه و شوی تر هغه چې دفتر په پرله پسې ډول څو ځله له بریښنا پرته پاتې شوی وي. پیرودونکي د ویب پاڼې د پیښو څخه ناخوښه وو.
د خدماتو شتون سره ستونزه بادل ته له تګ وروسته حل شوه. برسیره پردې، موږ د نوډونو تر مینځ د ټرافیک توازن کولو سره په ډیټابیسونو کې بار ښه کولو اداره کړې. - د ناورین پروف بادل ته لاړشئ
که تاسو اړتیا لرئ ډاډ ترلاسه کړئ چې کار حتی په اصلي سایټ کې د طبیعي ناورین له امله مداخله نه کوي، تاسو کولی شئ د ناورین په وړاندې مقاومت لرونکی بادل غوره کړئ. په دې اختیار کې، چمتو کوونکی د 2 ډیټا مرکزونو کې د مجازی کولو کلستر خپروي. دوامداره همغږي تکرار د ډیټا مرکزونو ترمینځ واقع کیږي ، یو له بل څخه. د ډیټا مرکزونو ترمینځ چینلونه خوندي دي او د مختلف لارو سره ځي ، نو دا ډول کلستر د شبکې ستونزو څخه ویره نلري.
OTR: ۰ ته رسیږي.
د لګښت: ترټولو ګران بادل اختیار.
هغه څه چې دا به ستاسو څخه ساتنه ونه کړي: دا به د معلوماتو د فساد پروړاندې مرسته ونکړي ، او همدارنګه د انساني فاکتور څخه ، نو سپارښتنه کیږي چې په ورته وخت کې بیک اپ جوړ کړئ.له تمرین څخه: زموږ یو پیرودونکي د ناورین د بیا رغونې جامع پلان جوړ کړ. دا هغه تګلاره ده چې هغه غوره کړه:
- د ناورین زغمونکي بادل غوښتنلیک د زیربنا په کچه د ناکامۍ څخه ساتي.
- د دوه کچې بیک اپ د انساني خطا په صورت کې محافظت چمتو کوي. دوه ډوله بیک اپ شتون لري: "سړه" او "ګرم". یو "سړه" بیک اپ په معیوب حالت کې دی او ځای په ځای کولو کې وخت نیسي. یو "ګرم" بیک اپ لا دمخه د کارونې لپاره چمتو دی او په چټکۍ سره بحال شوی. دا په ځانګړي ډول د ذخیره کولو سیسټم کې ساتل کیږي. دریم کاپي په ټیپ کې ثبت شوی او په بل خونه کې زیرمه کیږي.
په اونۍ کې یو ځل، پیرودونکي محافظت معاینه کوي او د ټولو بیک اپ فعالیت چک کوي، په شمول د ټیپ څخه. هر کال شرکت د ناورین په وړاندې مقاومت لرونکی بادل ازموي.
- بل سایټ ته نقل تنظیم کړئ
په اصلي سایټ کې د نړیوالو ستونزو څخه د مخنیوي څرنګوالي په اړه بل اختیار: جیو ریزرویشن چمتو کړئ. په بل عبارت، په بل ښار کې په یوه سایټ کې د بیک اپ مجازی ماشینونه جوړ کړئ. د DR لپاره ځانګړي حلونه د دې لپاره مناسب دي: زموږ په شرکت کې موږ د VMware vCloud شتون (vCAV) کاروو. د دې په مرسته ، تاسو کولی شئ د ډیری کلاوډ چمتو کونکي سایټونو ترمینځ محافظت تنظیم کړئ یا د پریمیس سایټ څخه کلاوډ ته بحال کړئ. ما دمخه د vCAV سره د کار کولو سکیم په اړه نور تفصیل سره خبرې کړې دي .
RPO او RTO: له ۵ دقیقو څخه.
د لګښت: د لومړي انتخاب څخه ډیر ګران، مګر د ناورین پروف بادل کې د هارډویر نقل څخه ارزانه. قیمت د VCAV جواز لګښت، د ادارې فیس، د بادل سرچینو لګښت او د PAYG ماډل سره سم د زیرمو سرچینو لګښت (د بند شوي VMs لپاره د کاري سرچینو لګښت 10٪) پورې اړه لري.
له تمرین څخه: پیرودونکي په مسکو کې زموږ په بادل کې د مختلف ډیټابیسونو سره 6 مجازی ماشینونه ساتلي. په لومړي سر کې، محافظت د بیک اپ لخوا چمتو شوی و: د بیک اپ ځینې کاپي په مسکو کې په بادل کې زیرمه شوي، او ځینې یې زموږ د سینټ پیټرزبرګ سایټ کې زیرمه شوي. د وخت په تیریدو سره، ډیټابیسونه په اندازې کې وده وکړه، او د بیک اپ څخه بیرته راګرځیدل ډیر وخت نیسي.
د VMware vCloud شتون پراساس نقل په بیک اپ کې اضافه شوی. د مجازی ماشینونو نقلونه په سینټ پیټرزبورګ کې په بیک اپ سایټ کې زیرمه شوي او په هر 5 دقیقو کې تازه کیږي. که په اصلي سایټ کې ناکامي رامنځته شي، کارمندان په خپلواکه توګه په سینټ پیټرزبورګ کې د مجازی ماشین نقل ته لاړ شي او کار ته دوام ورکړي.
ټول هغه حلونه چې په پام کې نیول شوي لوړ شتون چمتو کوي ، مګر د ransomware ویروس یا د کارمندانو ناڅاپي غلطۍ له امله د معلوماتو له لاسه ورکولو څخه ساتنه نه کوي. پدې حالت کې، موږ به بیک اپ ته اړتیا ولرو چې اړین RPO چمتو کړي.
5. د بیک اپ په اړه مه هېروئ
هرڅوک پوهیږي چې تاسو اړتیا لرئ بیک اپ جوړ کړئ، حتی که تاسو د ناورین ثبوت غوره حل لرئ. نو زه به په لنډ ډول تاسو ته یو څو ټکي یاد کړم.
په کلکه خبرې کول، بیک اپ DR نه دی. او له همدې امله:
- دا ډیر وخت دی. که معلومات په ټیرابایټ اندازه شي، بیا رغونه به له یو ساعت څخه ډیر وخت ونیسي. تاسو اړتیا لرئ بحال کړئ، شبکه وټاکئ، وګورئ چې دا فعاله ده، وګورئ چې ډاټا په ترتیب کې ده. نو تاسو کولی شئ یوازې ښه RTO چمتو کړئ که چیرې لږ معلومات شتون ولري.
- ډاټا ممکن په لومړي ځل بیا رغول نشي، او تاسو اړتیا لرئ چې د عمل تکرار لپاره وخت ته اجازه ورکړئ. د مثال په توګه، ځینې وختونه شتون لري کله چې موږ دقیقا نه پوهیږو کله چې ډاټا ورکه شوې. راځئ چې ووایو ضایع په 15.00 کې لیدل شوی، او کاپي هر ساعت جوړیږي. د 15.00 څخه موږ د بیا رغونې ټول ټکي ګورو: 14:00، 13:00 او داسې نور. که سیسټم مهم وي، موږ هڅه کوو چې د بیا رغونې نقطه عمر کم کړو. مګر که تازه بیک اپ اړین معلومات نلري، موږ راتلونکی ټکی اخلو - دا اضافي وخت دی.
په دې حالت کې، د بیک اپ مهال ویش کولی شي اړین چمتو کړي RPO. د بیک اپ لپاره، دا مهمه ده چې د اصلي سایټ سره د ستونزو په صورت کې جیو ریزرویشن چمتو کړئ. دا سپارښتنه کیږي چې ځینې بیک اپ کاپي په جلا توګه ذخیره کړئ.
د ناورین د بیا رغونې وروستی پلان باید لږترلږه دوه وسایل ولري:
- یو له 1-4 انتخابونو څخه، کوم چې سیسټمونه به د ناکامۍ او سقوط څخه ساتي.
- د ضایع کیدو څخه د معلوماتو ساتلو لپاره بیک اپ.
دا د بیک اپ مخابراتي چینل پاملرنې هم ارزښت لري که چیرې د انټرنیټ اصلي چمتو کونکي ښکته شي. او - وایلا! - DR په لږترلږه معاش کې لا دمخه چمتو دی.
سرچینه: www.habr.com