یہاں تک کہ ایک آفت کے دوران، ہمیشہ ایک کپ چائے کا وقت ہے.
ڈی آر پی (ڈیزاسٹر ریکوری پلان) ایک ایسی چیز ہے جس کی مثالی طور پر کبھی ضرورت نہیں ہوگی۔ لیکن اگر ملاوٹ کے موسم کے دوران اچانک ہجرت کرنے والے بیور مین آپٹیکل فائبر سے گر جاتے ہیں یا کوئی جونیئر ایڈمن پیداواری بنیاد کو گرا دیتا ہے، تو آپ یقینی طور پر اس بات کا یقین کرنا چاہتے ہیں کہ آپ کے پاس پہلے سے تیار کردہ منصوبہ ہو گا کہ اس تمام رسوائی کا کیا کرنا ہے۔
جب گھبرائے ہوئے گاہک ٹیک سپورٹ کو کال کرنا شروع کر دیتے ہیں، ایک جونیئر سائینائیڈ کی تلاش میں ہوتا ہے، آپ سمجھداری سے سرخ لفافے کو کھولتے ہیں اور ہر چیز کو ترتیب دینا شروع کر دیتے ہیں۔
اس پوسٹ میں، میں ڈی آر پی لکھنے کے طریقے اور اس میں کیا ہونا چاہیے اس بارے میں سفارشات شیئر کرنا چاہتا ہوں۔ ہم مندرجہ ذیل کو بھی دیکھیں گے:
- ولن کی طرح سوچنا سیکھیں۔
- آئیے قیامت کے دوران چائے کے ایک کپ کے فوائد کا تجزیہ کرتے ہیں۔
- ایک آسان DRP ڈھانچہ پر غور کریں۔
- آئیے دیکھتے ہیں کہ اسے کیسے آزمایا جائے۔
کون سی کمپنیاں اس سے فائدہ اٹھا سکتی ہیں؟
جب آئی ٹی ڈیپارٹمنٹ کو ان چیزوں کی ضرورت پڑنے لگے تو لکیر کھینچنا بہت مشکل ہے۔ میں کہوں گا کہ آپ کو DRP کی ضرورت کی ضمانت ہے اگر:
- کسی سرور، ایپلیکیشن کو روکنا، یا کچھ ڈیٹا بیس کھو دینا مجموعی طور پر کاروبار کے لیے اہم نقصانات کا باعث بنے گا۔
- آپ کے پاس آئی ٹی کا ایک مکمل شعبہ ہے۔ میرا مطلب ہے، کمپنی کے ایک مکمل یونٹ کے طور پر ایک محکمہ، اس کے اپنے بجٹ کے ساتھ، اور نہ صرف چند تھکے ہوئے ملازمین ایک نیٹ ورک بچھا رہے ہیں، وائرس کی صفائی اور پرنٹرز کو دوبارہ بھر رہے ہیں۔
- آپ کے پاس ایمرجنسی کی صورت میں کم از کم جزوی فالتو پن کے لیے ایک حقیقت پسندانہ بجٹ ہے۔
جب آئی ٹی ڈپارٹمنٹ مہینوں سے بیک اپ کے لیے ایک پرانے سرور میں ڈالنے کے لیے کم از کم چند HDDs کا مطالبہ کر رہا ہے، تو امکان نہیں ہے کہ آپ کی صلاحیت کو محفوظ کرنے کے لیے ناکام سروس کے مکمل اقدام کو منظم کر سکیں۔ اگرچہ دستاویزات یہاں بھی ضرورت سے زیادہ نہیں ہوں گی۔
دستاویزات اہم ہیں۔
دستاویزات کے ساتھ شروع کریں۔ مان لیں کہ آپ کی سروس پرل اسکرپٹ پر چلتی ہے جو تین نسلوں پہلے ایڈمنز نے لکھی تھی، اور کوئی نہیں جانتا کہ یہ کیسے کام کرتا ہے۔ جمع شدہ تکنیکی قرض اور دستاویزات کی کمی لامحالہ آپ کو نہ صرف گھٹنے بلکہ دوسرے اعضاء میں بھی گولی مار دے گی، یہ وقت کی بات ہے۔
ایک بار جب آپ کے پاس سروس کے اجزاء کی اچھی وضاحت ہو جائے تو، حادثات کے اعدادوشمار دیکھیں۔ تقریباً یقینی طور پر وہ مکمل طور پر عام ہوں گے۔ مثال کے طور پر، آپ کی ڈسک وقتاً فوقتاً بھر جاتی ہے، جس کی وجہ سے نوڈ اس وقت تک فیل ہو جاتا ہے جب تک کہ اسے دستی طور پر صاف نہ کیا جائے۔ یا کلائنٹ سروس اس حقیقت کی وجہ سے غیر دستیاب ہو جاتی ہے کہ کوئی دوبارہ سرٹیفکیٹ کی تجدید کرنا بھول گیا، اور Let's Encrypt قابل نہیں تھا یا ترتیب دینے کو تیار نہیں تھا۔
تخریب کار کی طرح خیالات
سب سے مشکل حصہ ان حادثات کی پیشین گوئی کرنا ہے جو پہلے کبھی نہیں ہوئے، لیکن جو ممکنہ طور پر آپ کی سروس کو مکمل طور پر برباد کر سکتے ہیں۔ یہاں ہم عموماً ساتھیوں کے ساتھ ولن کا کردار ادا کرتے ہیں۔ ڈھیر ساری کافی اور کچھ مزیدار لیں اور خود کو میٹنگ روم میں بند کر لیں۔ بس اس بات کو یقینی بنائیں کہ اسی میٹنگ میں آپ نے ان انجینئرز کو لاک کیا جنہوں نے خود ٹارگٹ سروس کو بڑھایا یا اس کے ساتھ باقاعدگی سے کام کیا۔ پھر، یا تو بورڈ پر یا کاغذ پر، آپ ان تمام ممکنہ ہولناکیوں کو کھینچنا شروع کر دیتے ہیں جو آپ کی خدمت میں پیش آ سکتی ہیں۔ یہ ضروری نہیں ہے کہ کسی مخصوص صفائی کرنے والی خاتون کو تفصیل سے بتایا جائے اور کیبلز نکالیں، یہ "مقامی نیٹ ورک کی سالمیت کی خلاف ورزی" کے منظر نامے پر غور کرنا کافی ہے۔
عام طور پر، زیادہ تر عام ہنگامی حالات درج ذیل اقسام میں فٹ ہوتے ہیں:
- نیٹ ورک کی ناکامی
- OS سروس کی ناکامی۔
- درخواست کی ناکامی۔
- لوہے کی ناکامی
- ورچوئلائزیشن کی ناکامی۔
بس ہر ایک منظر کو دیکھیں اور دیکھیں کہ آپ کی خدمت پر کیا لاگو ہوتا ہے۔ مثال کے طور پر، Nginx ڈیمون گر سکتا ہے اور بڑھ نہیں سکتا - یہ OS کی طرف سے ناکامی ہے۔ ایک غیر معمولی صورتحال جو آپ کی ویب ایپلیکیشن کو غیر کام کرنے والی حالت میں لے جاتی ہے وہ سافٹ ویئر کی ناکامی ہے۔ اس مرحلے کی نشوونما کے دوران، مسئلہ کی تشخیص پر کام کرنا ضروری ہے۔ مثال کے طور پر، ایک گرے ہوئے سسکو اور نیٹ ورک کریش سے ورچوئلائزیشن پر ہینگ انٹرفیس کو کیسے الگ کیا جائے۔ یہ ضروری ہے کہ ذمہ داروں کو فوری طور پر تلاش کیا جائے اور حادثے کے ٹھیک ہونے تک ان کی دم کھینچنا شروع کر دیں۔
عام مسائل کے لکھے جانے کے بعد، ہم مزید کافی ڈالتے ہیں اور عجیب و غریب منظرناموں پر غور کرنا شروع کر دیتے ہیں، جب کچھ پیرامیٹرز معمول سے آگے بڑھنے لگتے ہیں۔ مثال کے طور پر:
- اگر فعال نوڈ پر وقت کلسٹر میں موجود دوسروں کے مقابلے میں ایک منٹ پیچھے چلا جائے تو کیا ہوگا؟
- اور اگر وقت آگے بڑھتا ہے، اور اگر 10 سال تک؟
- اگر ہم وقت سازی کے دوران کلسٹر نوڈ اچانک نیٹ ورک کھو دے تو کیا ہوگا؟
- اور کیا ہوتا ہے اگر نیٹ ورک پر ایک دوسرے سے عارضی تنہائی کی وجہ سے دو نوڈس قیادت کا اشتراک نہیں کرتے ہیں؟
اس مرحلے پر، ریورس اپروچ بہت مدد کرتا ہے۔ بیمار تخیل کے ساتھ ٹیم کے سب سے ضدی ممبر کو لے جائیں اور اسے کم سے کم وقت میں ڈائیورژن کا بندوبست کرنے کا ٹاسک دیں، جس سے سروس ختم ہوجائے گی۔ اگر اس کی تشخیص کرنا مشکل ہو تو اور بھی بہتر۔ آپ ان عجیب اور ٹھنڈے خیالات پر یقین نہیں کریں گے جو انجینئرز کے ساتھ آتے ہیں جب کسی چیز کو توڑنے کا خیال دیا جاتا ہے۔ اور اگر آپ ان سے اس کے لیے ٹیسٹ اسٹینڈ کا وعدہ کرتے ہیں تو یہ بہت اچھا ہے۔
یہ آپ کا DRP کیا ہے؟!
تو آپ نے خطرے کے ماڈل کی وضاحت کی ہے۔ انہوں نے مقامی رہائشیوں کو بھی مدنظر رکھا جو تانبے کی تلاش میں فائبر آپٹک کیبلز کاٹتے ہیں، اور ایک فوجی ریڈار جو جمعہ کو 16:46 پر سختی سے ریڈیو ریلے لائن گراتا ہے۔ اب ہمیں یہ جاننے کی ضرورت ہے کہ اس سب کے ساتھ کیا کرنا ہے۔
آپ کا کام وہی سرخ لفافے لکھنا ہے جو ایمرجنسی میں کھولے جائیں گے۔ فوری طور پر توقع کریں کہ جب (نہیں تو!) سب کچھ خراب ہو جائے گا، صرف سب سے زیادہ ناتجربہ کار ٹرینی قریب ہو گا، جس کے ہاتھ جو کچھ ہو رہا ہے اس کی ہولناکی سے شدید لرز اٹھے گا۔ دیکھیں کہ طبی دفاتر میں ہنگامی اشارے کیسے نافذ کیے جاتے ہیں۔ مثال کے طور پر، anaphylactic جھٹکا کے ساتھ کیا کرنا ہے. طبی عملہ تمام پروٹوکول کو دل سے جانتا ہے، لیکن جب کوئی قریبی شخص مرنے لگتا ہے، تو اکثر ہر کوئی بے بسی سے ہر چیز کو پکڑ لیتا ہے۔ ایسا کرنے کے لیے، ایک واضح ہدایات دیوار پر لٹکی ہوئی ہیں جیسے "فلاں فلاں کا پیکج کھولیں" اور "دوائی کے اتنے یونٹ نس کے ذریعے انجیکشن لگائیں۔"
ایمرجنسی میں سوچنا مشکل ہے! ریڑھ کی ہڈی کی تجزیہ کے لیے آسان ہدایات ہونی چاہئیں۔
ایک اچھا DRP چند سادہ بلاکس پر مشتمل ہوتا ہے:
- حادثے کے آغاز کی اطلاع کسے دی جائے۔ یہ ممکنہ حد تک خاتمے کے عمل کو متوازی کرنے کے لیے ضروری ہے۔
- صحیح طریقے سے تشخیص کیسے کریں - ہم ٹریس کرتے ہیں، سسٹم سی ٹی ایل اسٹیٹس سروس نام میں دیکھتے ہیں وغیرہ۔
- ہر مرحلے پر کتنا وقت گزارا جا سکتا ہے۔ اگر آپ کے پاس SLA وقت کے دوران اسے اپنے ہاتھوں سے ٹھیک کرنے کا وقت نہیں ہے تو، ورچوئل مشین کو کل کے بیک اپ سے مار کر رول کر دیا جاتا ہے۔
- یہ کیسے یقینی بنایا جائے کہ کریش ختم ہو گیا ہے۔
یاد رکھیں کہ DRP تب شروع ہوتا ہے جب سروس مکمل طور پر ناکام ہو جاتی ہے اور ریکوری کے ذریعے مکمل ہو جاتی ہے، یہاں تک کہ کم کارکردگی کے باوجود۔ صرف ریزرویشن کھونے سے DRP کو فعال نہیں ہونا چاہیے۔ آپ DRP میں ایک کپ چائے بھی لکھ سکتے ہیں۔ سنجیدگی سے۔ اعداد و شمار کے مطابق، بہت سے حادثات ناخوشگوار سے تباہ کن ہو جاتے ہیں اس حقیقت کی وجہ سے کہ گھبراہٹ میں عملہ کچھ ٹھیک کرنے کے لیے دوڑتا ہے، بیک وقت ڈیٹا کے ساتھ واحد زندہ نوڈ کو مار ڈالتا ہے یا آخر کار کلسٹر کو ختم کر دیتا ہے۔ ایک اصول کے طور پر، ایک کپ چائے کے لیے 5 منٹ آپ کو پرسکون ہونے اور کیا ہو رہا ہے اس کا تجزیہ کرنے کے لیے تھوڑا وقت دے گا۔
ڈی آر پی اور سسٹم پاسپورٹ کو الجھائیں نہ! اسے غیر ضروری ڈیٹا کے ساتھ اوورلوڈ نہ کریں۔ بس موقع دیں کہ جلدی اور آسانی سے ہائپر لنکس کے ذریعے دستاویزات کے مطلوبہ حصے میں جائیں اور سروس کے فن تعمیر کے ضروری حصوں کے بارے میں توسیع شدہ فارمیٹ میں پڑھیں۔ اور خود DRP میں، کاپی پیسٹ کے لیے مخصوص کمانڈز کے ساتھ کہاں اور کیسے جڑنا ہے، اس بارے میں صرف براہ راست ہدایات موجود ہیں۔
صحیح طریقے سے ٹیسٹ کرنے کا طریقہ
اس بات کو یقینی بنائیں کہ کوئی بھی ذمہ دار ملازم تمام اشیاء کو مکمل کرنے کے قابل ہو۔ انتہائی اہم لمحے میں، یہ معلوم ہو سکتا ہے کہ انجینئر کے پاس مطلوبہ سسٹم تک رسائی کے حقوق نہیں ہیں، مطلوبہ اکاؤنٹ کے لیے کوئی پاس ورڈ نہیں ہیں، یا اسے اس بات کا کوئی اندازہ نہیں ہے کہ "سروس مینجمنٹ کنسول سے پراکسی کے ذریعے جڑیں۔ ہیڈ آفس" کا مطلب ہے۔ ہر آئٹم کو ہر ممکن حد تک آسان ہونا چاہئے۔
غلط - "ورچوئلائزیشن پر جائیں اور ڈیڈ نوڈ کو دوبارہ شروع کریں"
صحیح طریقے سے - "ویب انٹرفیس کے ذریعے virt.example.com سے جڑیں، نوڈ سیکشن میں، اس نوڈ کو دوبارہ لوڈ کریں جو خرابی کا سبب بن رہا ہے۔"
ابہام سے بچیں۔ خوفزدہ انٹرن کو یاد رکھیں۔
DRP ٹیسٹ ضرور کریں۔ یہ صرف شو کا منصوبہ نہیں ہے - یہ ایک ایسی چیز ہے جو آپ کو اور آپ کے کلائنٹس کو ایک نازک صورتحال سے فوری طور پر نکلنے کی اجازت دے گی۔ یہ کئی بار کرنا بہتر ہے:
- ایک ماہر اور کئی انٹرنز ایک ایسے ٹیسٹ بینچ پر کام کرتے ہیں جو زیادہ سے زیادہ حقیقی خدمت کی نقل کرتا ہے۔ ماہر مختلف طریقوں سے سروس کو توڑتا ہے اور تربیت حاصل کرنے والوں کو DRP کے مطابق اسے بحال کرنے کے قابل بناتا ہے۔ تمام مسائل، دستاویزات میں ابہام اور غلطیاں درج ہیں۔ تربیت یافتہ افراد کو تربیت دینے کے بعد، غیر واضح جگہوں پر DRP کو مکمل اور آسان بنایا جاتا ہے۔
- ایک حقیقی خدمت پر جانچ۔ درحقیقت، آپ کبھی بھی حقیقی سروس کی ایک بہترین کاپی نہیں بنا سکتے۔ لہٰذا، سال میں دو بار سرورز کے کچھ حصے کو منصوبہ بند بنیادوں پر بند کرنا، کنکشن توڑنا اور خطرات کی فہرست سے دیگر حادثات کا بندوبست کرنا ضروری ہے تاکہ ریکوری آرڈر کا جائزہ لیا جا سکے۔ ڈیٹا کے نقصان کے ساتھ چوٹی کے بوجھ پر کئی گھنٹوں تک اچانک ناکامی سے آدھی رات میں 10 منٹ کی منصوبہ بند بندش بہتر ہے۔
- حادثے کا حقیقی خاتمہ۔ ہاں، یہ بھی جانچ کا حصہ ہے۔ اگر کوئی حادثہ پیش آتا ہے جو خطرات کی فہرست میں نہیں تھا، تو اس کی تحقیقات کے نتائج کی بنیاد پر ڈی آر پی کی تکمیل اور اسے حتمی شکل دینا ضروری ہے۔
اہم نکات
- اگر بدتمیزی ہو سکتی ہے، تو یہ صرف نہیں ہو گا، بلکہ یہ سب سے زیادہ تباہ کن منظر نامے میں کرے گا۔
- یقینی بنائیں کہ آپ کے پاس فیل اوور کے وسائل ہیں۔
- یقینی بنائیں کہ آپ کے پاس بیک اپ ہیں، وہ خود بخود بن جاتے ہیں اور مستقل مزاجی کے لیے باقاعدگی سے چیک کیے جاتے ہیں۔
- عام خطرے کے منظرناموں پر غور کریں۔
- انجینئرز کو سروس پیش کرنے کے لیے غیر معیاری اختیارات کے ساتھ آنے کا موقع دیں۔
- DRP سادہ اور گونگی ہدایات ہونی چاہئیں۔ تمام پیچیدہ تشخیص صرف اس کے بعد جب صارفین کی سروس بحال ہو جائے۔ چاہے وہ اسٹینڈ بائی پر ہو۔
- DRP میں اہم فون نمبرز اور رابطوں کی فہرست بنائیں۔
- ڈی آر پی کو سمجھنے کے لیے ملازمین کی باقاعدگی سے جانچ کریں۔
- مصنوعات پر منصوبہ بند حادثات کا بندوبست کریں۔ اسٹینڈ ہر چیز کی جگہ نہیں لے سکتا۔
ماخذ: www.habr.com