VPN صحت کی جانچ کو ایپلیکیشن صحت کی جانچ سے الگ کریں

آپ کی ٹنل پروسیس چل رہی ہو سکتی ہے جبکہ محفوظ کنکشن ناقابل استعمال ہو، اور ناکام ہونے والا ویب صفحہ اس بات کا ثبوت نہیں کہ ٹنل ٹوٹ گئی۔ جب ایک جانچ سب کی نمائندگی کرتی ہے تو دوبارہ شروع کرنے کی پالیسی غلط جزو کو دوبارہ شروع کرتی ہے اور اسے آٹومیشن کہتی ہے۔ نیچے کی ہر جانچ وہ پرت جس کا وہ مشاہدہ کرتی ہے، وہ کارروائی جو اس کی ناکامی شروع کرتی ہے، اور اس بات کا ثبوت بتاتی ہے کہ کارروائی کام کر گئی۔ آخری مرحلہ پورے مجموعے کو ایسے صفحے میں بدل دیتا ہے جسے کوئی رات تین بجے فالو کر سکے۔

مرحلہ 1: ہر جانچ جس پرت کا مشاہدہ کرتی ہے اس کا نام دیں

ان میں سے کوئی بھی لکھنے سے پہلے پوچھیں کہ ہر جانچ واقعی کیا دیکھ سکتی ہے۔ زندگی ثابت کرتی ہے کہ ڈیمن چل رہا ہے، مصافحہ یا ہم منصبوں کی فہرست ثابت کرتی ہے کہ تعلق موجود ہے، روٹ شدہ درخواست ترسیل ثابت کرتی ہے، اور تلاش حل ثابت کرتی ہے۔ وہ اسی ترتیب میں ناکام ہوتے ہیں، اور ان میں سے کوئی بھی اگلے کا اشارہ نہیں دیتا۔ ہری پروسیس جانچ مردہ ٹنل کے ساتھ ہونا عام حالت ہے، تضاد نہیں۔

چاروں جانچ اسی ترتیب میں لکھیں، ہر ایک کے لیے درست کمانڈ اور متوقع آؤٹ پٹ کے ساتھ۔ جس جانچ کا متوقع آؤٹ پٹ آپ نہیں بتا سکتے اسے الرٹ دیکھنے والا ہر آپریٹر مختلف طریقے سے پڑھے گا۔ وہی فہرست صرف رن بک میں نہیں بلکہ الرٹ متن میں بھی رکھیں تاکہ رات کو جگایا گیا شخص علامت سے پہلے پرت سے ملے۔ ہر کمانڈ کو اس ہوسٹ پر کاپی کرنے کے قابل رکھیں جو اسے چلاتا ہے۔

پھر ایپلیکیشن جانچ کو پانچویں، الگ آئٹم کے طور پر شامل کریں۔ جس صفحے کی اکاؤنٹ سروس بند ہے وہ ٹنل دوبارہ شروع کرنے کا جواز نہیں۔

مرحلہ 2: ہر ناکامی کو ایک کارروائی سے جوڑیں

ہر جانچ کے لیے طے کریں کہ کیا دوبارہ شروع ہوگا، کیا بلاک رہے گا اور کیا کسی شخص کو بلائے گا۔ ٹنل پرت کی ناکامی ٹنل دوبارہ شروع کرنے کا جواز بن سکتی ہے؛ حل کرنے والے کی ناکامی کلائنٹ پر DNS انضمام کی طرف اشارہ کرتی ہے؛ ایپلیکیشن پرت کی ناکامی کو تقریباً کبھی ٹنل کو نہیں چھونا چاہیے۔

بتائیں کہ ناکامی کو کیا نہیں کرنا چاہیے، کیونکہ خطرناک ڈیفالٹ وہی ہوتے ہیں جو اجازت دیتے ہیں۔ غیر صحت مند حالت کبھی بھی براہ راست ایپلیکیشن ٹریفک کی اجازت نہیں بننی چاہیے، کیونکہ ٹنل کو خاموشی سے نظر انداز کرنے والا متبادل راستہ ٹنل کے وجود کی وجہ ہی ختم کر دیتا ہے۔ کارروائیوں کو بھی محدود کریں: ایک منزل کے سست ہونے پر مشترکہ جزو دوبارہ شروع کرنا مقامی مسئلے کو پورے بیڑے کا مسئلہ بنا دیتا ہے۔ یہ وجہ تلاش کرنے کے لیے درکار ثبوت بھی تباہ کر دیتا ہے۔

مرحلہ 3: جانچ کو بے ضرر اور سستا رکھیں

چھوٹی، صرف پڑھنے والی درخواستیں استعمال کریں: کوئی مستقل وسیلہ، اپنی انحصاری بتانے والا صحت کا اینڈ پوائنٹ، یا آپ کے زیر کنٹرول پورٹ پر TCP کنکشن۔ اسناد، نجی براؤزنگ اور ہر وقفے پر حالت بدلنے والی ہر چیز سے بچیں، کیونکہ لکھنے والی جانچ شیڈول کے مطابق لوڈ ٹیسٹ ہے۔

ہر جانچ کے لیے منزل، راستے کی توقع اور وقت کی حد درج کریں۔ راستے کی توقع ہی وہ خانہ ہے جو لوگ چھوڑ دیتے ہیں، اور بعد میں الرٹ پڑھتے وقت ٹنل کی ناکامی کو روٹنگ کی غلطی سے الگ کرنے والی یہی ہے۔ وقفہ اور ناکامی کی حد آپ کے وعدہ کردہ بحالی وقت سے نکالیں، اور وقت کی حد وقفے سے کم رکھیں۔ اگلی شروع ہوتے وقت بھی چلنے والی جانچ ایک ناکامی دو بار بتاتی ہے اور لرزش جیسی لگتی ہے۔

مرحلہ 4: ہر پرت توڑیں اور دیکھیں کہ صحیح جانچ سرخ ہوتی ہے

ٹنل پروسیس روکیں اور تصدیق کریں کہ پروسیس جانچ ناکام ہوتی ہے جبکہ DNS شاید ابھی کیش سے جواب دے سکتا ہے۔ کوئی راستہ بدلیں اور تصدیق کریں کہ روٹ شدہ درخواست ناکام ہوتی ہے جبکہ پروسیس اور مصافحہ صحت مند رہتے ہیں۔ صرف DNS توڑیں اور تصدیق کریں کہ ایپلیکیشن جانچ ٹنل کی خرابی کے بجائے حل بتاتی ہے۔ اگر دو جانچ ہمیشہ ساتھ چلتی ہیں تو آپ کے پاس سوچ سے کم جانچ ہیں۔

اسی نظم سے بحالی کی سمت جانچیں۔ پرت بحال کرنے کے بعد جانچ کو بغیر دستی دوبارہ شروع کے صاف ہونا چاہیے، اور شروع ہونے والی کارروائی نے پیچھے کوئی بائی پاس نہیں چھوڑنا چاہیے۔ ہری حالت پر بھروسہ کرنے سے پہلے ایک پورا چکر دیکھیں، کیونکہ صرف ہاتھ سے صاف ہونے والی جانچ ٹوٹا ہوا بحالی راستہ چھپاتی ہے۔

مرحلہ 5: رن بک وہاں رکھیں جہاں الرٹ اشارہ کرتا ہے

پانچ قطاروں والا ایک صفحہ پورا ڈیزائن اٹھاتا ہے: پرت، کمانڈ، متوقع نتیجہ، ناکامی پر کارروائی، مالک۔ ہر جانچ کے بارے میں ایک سطر شامل کریں کہ وہ دانستہ کیا نہیں جانچتی۔ وہی سطر اگلے شخص کو چھٹی جانچ شامل کرنے سے روکتی ہے جو سب کچھ ناپتی ہے اور کچھ بھی الگ نہیں کرتی۔ الرٹ متن سے صفحہ لنک کریں، ورنہ واقعہ کے دوران کوئی اسے نہیں کھولے گا۔

کنٹینر تعیناتیوں میں، انحصار کی شرط صرف آغاز کو شکل دیتی ہے اور کچھ نہیں۔ Compose کا آغاز ترتیب اور صحت کی شرط دستاویز بیان کرتی ہے کہ تیاری خدمات کے شروع ہونے کی ترتیب کیسے طے کرتی ہے؛ ان میں سے کچھ بھی بعد میں اخراج کی پالیسی نافذ نہیں کرتا، اور ٹنل گرنے پر ان میں سے کچھ بھی بند ہو کر ناکام نہیں ہوتا۔ مسلسل نفاذ کو اپنی پالیسی اور اپنی جانچ چاہیے، اسی صفحے پر لکھی ہوئی۔

رن بک تب مکمل ہوتی ہے جب صحیح پرت بحال ہو جائے اور کوئی بھی دستیاب نہ ہونے والی ویب سائٹ کو ٹوٹی ہوئی ٹنل نہ پڑھے۔ یہ ٹنل کی نہیں، دستاویز کی جانچ ہے۔