حتی د ناورین په جریان کې تل د یوې پیالې چای لپاره وخت شتون لري
DRP (د ناورین د بیا رغونې پلان) یو شی دی چې په مثالي توګه به هیڅکله اړتیا ونه لري. مګر که ناڅاپه د ملن موسم په جریان کې بیورونه د شاته بون آپټیکل فایبر له لارې غوڅ شي یا یو ځوان مدیر تولیدي اساس پریږدي ، تاسو حتما ډاډه اوسئ چې تاسو به د دې ټولو ذلت سره د څه کولو لپاره دمخه جوړ شوی پلان ولرئ.
پداسې حال کې چې پیرودونکي په ویره کې د تخنیکي ملاتړ تلیفونونو قطع کول پیل کوي ، ځوان د سینایډ په لټه کې دی ، تاسو په هوښیارۍ سره سور لفافه خلاص کړئ او هرڅه په ترتیب سره پیل کړئ.
پدې پوسټ کې زه غواړم د DRP لیکلو څرنګوالي په اړه وړاندیزونه شریک کړم او څه باید پکې وي. موږ به لاندې شیان هم وګورو:
- راځی چی د یو کلیوال په څیر فکر کول زده کړو.
- راځئ چې د اختر پر مهال د یوې پیالې چای ګټې وګورو.
- راځئ چې د مناسب DRP جوړښت په اړه فکر وکړو
- راځئ وګورو چې دا څنګه ازموینه وکړو
دا د کومو شرکتونو لپاره ګټور کیدی شي؟
کله چې د معلوماتي ټکنالوجۍ ډیپارټمنټ ورته شیانو ته اړتیا ولري د کرښې رسم کول خورا ستونزمن دي. زه به ووایم چې تاسو یقینا DRP ته اړتیا لرئ که:
- د سرور بندول ، غوښتنلیک یا د ځینې ډیټابیس له لاسه ورکول به په ټوله کې د سوداګرۍ لپاره د پام وړ زیان لامل شي.
- تاسو د معلوماتي ټکنالوجۍ بشپړه څانګه لرئ. د یوې څانګې په معنی د شرکت د بشپړ واحد په توګه ، د خپلې بودیجې سره ، او نه یوازې یو څو ستړي شوي کارمندان د شبکې ایښودلو ، د ویروسونو پاکول او د پرنټرونو ډکول.
- تاسو د بیړني حالت په صورت کې لږترلږه د جزوي بې ځایه کیدو لپاره ریښتیني بودیجه لرئ.
کله چې د معلوماتي ټکنالوجۍ څانګه لږترلږه د څو HDDs لپاره د بیک اپ لپاره زاړه سرور ته د میاشتو لپاره غوښتنه کوي ، نو تاسو احتمال نشئ کولی د ظرفیت ذخیره کولو لپاره د ناکام خدمت بشپړ حرکت تنظیم کړئ. که څه هم دلته اسناد به بې ځایه نه وي.
اسناد مهم دي
د اسنادو سره پیل کړئ. راځئ چې ووایو چې ستاسو خدمت په پرل سکریپټ کې پرمخ ځي چې درې نسلونه دمخه د مدیرانو لخوا لیکل شوی و، مګر هیڅوک نه پوهیږي چې دا څنګه کار کوي. جمع شوي تخنیکي پور او د اسنادو نشتوالی به په لازمي ډول تاسو نه یوازې په زنګون کې ، بلکه په نورو غړو کې هم ډزې وکړي ، دا د وخت مسله ده.
یوځل چې تاسو د خدماتو برخو ښه توضیحات ولرئ، د حادثې احصایې وګورئ. دوی به تقریبا یقینا په بشپړ ډول عادي وي. د مثال په توګه، ستاسو ډیسک وخت په وخت ډک کیږي، کوم چې د نوډ د ناکامۍ لامل کیږي تر هغه چې دا په لاسي ډول پاک نشي. یا د پیرودونکي خدمت د دې حقیقت له امله شتون نلري چې یو څوک بیا د سند نوي کول هیر کړي ، او Let's Encrypt د تنظیم کولو توان نلري یا نه غواړي.
د تخریب کونکي په څیر فکرونه
ترټولو سخته برخه د هغه حادثو وړاندوینه کول دي چې مخکې هیڅکله ندي پیښ شوي ، مګر کوم چې ممکن ستاسو خدمت په بشپړ ډول خراب کړي. دلته زما همکاران او زه معمولا د ولن لوبې کوم. ډیر قهوه او خوندور شی وخورئ او ځان د ناستې په خونه کې بند کړئ. یوازې ډاډ ترلاسه کړئ چې په ورته خبرو اترو کې تاسو هغه انجینران بند کړئ چې پخپله یې د هدف خدمت رامینځته کړی یا په منظم ډول ورسره کار کوي. بیا، یا په تخته یا په کاغذ کې، تاسو د ټولو ممکنه وحشتونو په نښه کولو پیل کوئ چې ستاسو خدمت ته پیښ کیدی شي. دا اړینه نده چې د یوې ځانګړې پاکونې میرمنې ته په تفصیل سره لاړ شئ او کیبلونه راوباسئ؛ دا کافي ده چې د "سیمه ایز شبکې بشپړتیا څخه سرغړونه" سناریو ته پام وکړئ.
عموما، ډیری عادي بیړني حالتونه په لاندې ډولونو کې راځي:
- د شبکې ناکامي
- د OS خدماتو ناکامي
- د غوښتنلیک ناکامي
- د اوسپنې ناکامي
- د مجازی کولو ناکامي
یوازې د هر ډول له لارې لاړ شئ او وګورئ چې ستاسو په خدمت کې څه پلي کیږي. د مثال په توګه، د نګینکس ډیمون ممکن راټیټ شي او پورته نشي - دا پدې مانا ده چې د OS په برخه کې ناکامي. یو نادر حالت چې ستاسو د ویب غوښتنلیک ناکامیدو لامل کیږي د سافټویر ناکامي ده. پداسې حال کې چې پدې مرحله کې کار کوي، دا مهمه ده چې د ستونزې تشخیص کار وکړو. د مثال په توګه د سقوط شوي cis ډرایو او د شبکې ناکامۍ څخه په مجازی کولو کې منجمد انٹرفیس څنګه توپیر کړئ. دا مهمه ده چې ژر تر ژره مسؤلین ومومئ او د حادثې حل کیدو پورې د دوی د لکۍ ایستل پیل کړئ.
د عادي ستونزو لیکلو وروسته، موږ ډیر کافي تویوو او د عجیب سناریوګانو په پام کې نیولو سره پیل کوو، کله چې ځینې پیرامیټونه د نورم څخه لرې ځي. د مثال په ډول:
- څه پیښیږي که چیرې د فعال نوډ وخت په کلستر کې د نورو په پرتله یوه دقیقه بیرته حرکت وکړي؟
- که وخت مخ په وړاندې ځي، څه به وي که 10 کاله؟
- څه پیښیږي که چیرې یو کلستر نوډ ناڅاپه خپل شبکه د همغږي کولو پرمهال له لاسه ورکړي؟
- څه به پیښ شي که چیرې دوه نوډونه په شبکه کې د یو بل د لنډمهاله انزوا له امله مشرتابه شریک نه کړي؟
په دې مرحله کې، برعکس طریقه خورا ګټوره ده. تاسو د ټیم خورا سخت غړی د ناروغ تصور سره واخلئ او هغه ته په لنډ ممکن وخت کې د تخریب تنظیم کولو دنده ورکړئ چې خدمت به یې کم کړي. که دا تشخیص ستونزمن وي، حتی ښه. تاسو به باور ونلرئ چې انجینران کوم عجیب او په زړه پوري نظرونه راوړي که تاسو دوی ته د یو څه ماتولو لپاره نظر ورکړئ. او که تاسو دوی ته د دې لپاره د ازموینې بنچ ژمنه وکړئ ، دا بالکل ښه دی.
ستاسو دا DRP څه دی؟!
نو تاسو د خپل ګواښ ماډل تعریف کړی. دوی هغه ځایي اوسیدونکي هم په پام کې نیولي چې د مسو په لټه کې د فایبر آپټیک کیبلونه پرې کوي، او یو نظامي رادار چې د جمعې په ورځ په 16:46 کې د راډیو ریلي لاین په کلکه غورځوي. اوس موږ باید پوه شو چې د دې ټولو سره څه وکړو.
ستاسو دنده دا ده چې هغه ډیر سور لفافې ولیکئ چې په بیړني حالت کې به خلاص شي. سمدلاسه تمه وکړئ چې کله (نه که!) هرڅه پای ته ورسیږي ، یوازې خورا بې تجربه کارګر به نږدې وي ، چې لاسونه به یې د هغه څه له وحشت څخه په شدت سره لړزیږي چې پیښیږي. وګورئ چې څنګه په طبي دفترونو کې بیړني نښې پلي کیږي. د مثال په توګه، د anaphylactic شاک په صورت کې څه وکړي. طبي کارمندان د زړه له لارې ټول پروتوکولونه پیژني ، مګر کله چې نږدې یو څوک مړ شي ، ډیری وختونه هرڅوک په بې وسۍ سره هرڅه په سترګو کې نیسي. د دې کولو لپاره، په دیوال کې واضح لارښوونې شتون لري لکه د توکو سره "د داسې او داسې کڅوړې خلاص کړئ" او "د مخدره توکو ډیری واحدونه په رګونو کې اداره کړئ."
په بیړني حالت کې فکر کول سخت دي! د نخاعي نخاع د تجزیه کولو لپاره باید ساده لارښوونې شتون ولري.
یو ښه DRP د څو ساده بلاکونو څخه جوړه ده:
- څوک د حادثې د پیل په اړه خبر کړي. دا د امکان تر حده د لرې کولو پروسې موازي کولو لپاره مهم دی.
- په سمه توګه څنګه تشخیص کول - ټریس ترسره کول، د سیسټم سیټل حالت خدمت نوم کې وګورئ او داسې نور.
- تاسو په هره مرحله کې څومره وخت لګولی شئ؟ که تاسو وخت نلرئ دا د SLA وخت کې په لاسي ډول تنظیم کړئ ، مجازی ماشین وژل شوی او د پرون بیک اپ څخه بیرته راګرځیدلی.
- څنګه ډاډ ترلاسه کړئ چې حادثه پای ته رسیدلې ده.
په یاد ولرئ چې DRP هغه وخت پیل کیږي کله چې خدمت په بشپړ ډول ناکام شوی وي او پای ته رسیږي کله چې خدمت بحال شي، حتی د کم موثریت سره. په ساده ډول د ریزرویشن له لاسه ورکول باید DRP نه رامینځته کړي. تاسو کولی شئ په DRP کې یو پیاله چای هم ولیکئ. په جدي توګه. د احصایو له مخې ، ډیری پیښې له ناخوښۍ څخه ناورین ته د دې حقیقت له امله بدلیږي چې کارمندان په ویره کې د یو څه سمولو لپاره ګړندي کوي ، په ورته وخت کې د معلوماتو سره یوازینی ژوندی نوډ وژني یا په نهایت کې د کلستر پای ته رسوي. د یوې قاعدې په توګه، د یوې پیالې چای سره 5 دقیقې به تاسو ته یو څه وخت درکړي چې آرام او تحلیل کړئ چې څه پیښیږي.
د DRP او سیسټم پاسپورت ګډوډ مه کوئ! دا د غیر ضروري معلوماتو سره مه اخلئ. یوازې دا ممکنه کړئ چې په ګړندي او اسانۍ سره د هایپر لینکونو کارولو لپاره د اسنادو مطلوب برخې ته لاړ شئ او د خدماتو جوړښت اړین برخو په اړه پراخه ب formatه کې ولولئ. او پخپله DRP کې یوازې مستقیم لارښوونې شتون لري چې چیرې او څنګه د کاپي پیسټ لپاره ځانګړي کمانډونو سره وصل شي.
څنګه سمه ازموینه وکړئ
ډاډ ترلاسه کړئ چې کوم مسؤل کارمند د دې توان لري چې ټول توکي بشپړ کړي. په خورا مهم شیبه کې ، دا ممکن وګرځي چې انجینر اړین سیسټم ته د لاسرسي حق نلري ، د اړین حساب لپاره پاسورډونه شتون نلري ، یا هغه نه پوهیږي چې څه شی د پراکسي له لارې د خدماتو مدیریت کنسول سره وصل شي. مرکزي دفتر" معنی لري. هر ټکی باید خورا ساده وي.
غلط - "ورچویلائزیشن ته لاړ شئ او مړ نوډ ریبوټ کړئ"
سمه ده - "د ویب انٹرفیس له لارې virt.example.com سره وصل شئ، د نوډونو برخه کې، نوډ بیا پیل کړئ چې د خطا لامل کیږي."
له ابهام څخه ډډه وکړئ. ډارونکی انٹرن په یاد ولرئ.
ډاډ ترلاسه کړئ چې د DRP ازموینه وکړئ. دا یوازې د نندارې لپاره پلان نه دی - دا هغه څه دي چې تاسو او ستاسو مراجعینو ته به اجازه درکړي چې ژر تر ژره له یوه نازک حالت څخه ووځي. دا غوره ده چې دا څو ځله ترسره کړئ:
- یو ماهر او څو روزونکي د ازموینې بنچ کې کار کوي چې د امکان تر حده د ریښتیني خدمت تقلید کوي. کارپوه خدمت په بیلابیلو لارو ماتوي او زده کونکو ته وړتیا ورکوي چې دا د DRP سره سم بحال کړي. ټولې ستونزې، د اسنادو ابهام او غلطۍ ثبت شوي دي. وروسته له دې چې زده کوونکي وروزل شي، DRP په ناڅرګندو سیمو کې پراخ او ساده کیږي.
- په ریښتیني خدمت کې ازموینه. په حقیقت کې، تاسو هیڅکله نشئ کولی د ریښتینې خدمت بشپړ کاپي جوړ کړئ. له همدې امله ، په کال کې څو ځله دا اړینه ده چې په منظم ډول ځینې سرورونه بند کړئ ، اړیکې پرې کړئ او د بیا رغونې پروسې ارزولو لپاره د ګواښونو له لیست څخه د نورو ناورینونو لامل شي. د شپې په نیمه کې د 10 دقیقو لپاره پلان شوې ناکامي د ډیټا له لاسه ورکولو سره د لوړ بار په جریان کې د څو ساعتونو لپاره د ناڅاپي ناکامۍ څخه غوره ده.
- اصلي ستونزه حل کول. هو، دا هم د ازموینې برخه ده. که کومه حادثه رامنځ ته شي چې د ګواښونو په لیست کې نه وي، نو دا اړینه ده چې د تحقیقاتو پایلو پراساس DRP بشپړ او نهایی کړي.
مهم ټکي
- که چیرې شی پیښ شي، دا به نه یوازې پیښ شي، مګر دا به په خورا ناورین سناریو کې ترسره کړي.
- ډاډ ترلاسه کړئ چې تاسو د بیړني بار لیږد لپاره سرچینې لرئ.
- ډاډ ترلاسه کړئ چې تاسو بیک اپ لرئ، دوی په اتوماتيک ډول جوړ شوي او په منظمه توګه د دوام لپاره چک کیږي.
- د عادي ګواښ سناریوګانو له لارې فکر وکړئ.
- انجینرانو ته فرصت ورکړئ چې د خدماتو وړاندې کولو لپاره غیر معیاري اختیارونو سره راشي.
- DRP باید یو ساده او روښانه لارښوونه وي. ټول پیچلي تشخیص یوازې وروسته له هغه ترسره کیږي کله چې د پیرودونکو خدمت بیرته راشي. حتی که د ریزرو ظرفیت کې وي.
- په DRP کې د تلیفون کلیدي شمیرې او اړیکې چمتو کړئ.
- په منظمه توګه د DRP په اړه د کارمندانو پوهه ازموینه وکړئ.
- د تولید سایټونو کې پلان شوي پیښې تنظیم کړئ. سټینډونه نشي کولی هرڅه بدل کړي.
سرچینه: www.habr.com