افصل فحوص صحة VPN عن فحوص صحة التطبيق

قد تكون عملية النفق عاملة بينما الاتصال المحمي غير قابل للاستخدام، وصفحة ويب فاشلة ليست دليلاً على أن النفق تعطّل. وعندما يقف مسبار واحد مكانها جميعاً، فإن سياسة إعادة التشغيل تعيد تشغيل المكوّن الخطأ وتسمّي ذلك أتمتة. كل فحص أدناه يسمّي الطبقة التي يراقبها، والإجراء الذي يطلقه فشله، والدليل على أن الإجراء نجح. والخطوة الأخيرة تحوّل المجموعة كلها إلى صفحة يستطيع شخص أن يتبعها في الثالثة صباحاً.

الخطوة 1: سمِّ الطبقة التي يراقبها كل فحص

اسأل عمّا يستطيع كل مسبار رؤيته فعلاً قبل كتابة أي منها. فحياة العملية تثبت أن الخدمة تعمل، والمصافحة أو قائمة الأقران تثبت أن العلاقة قائمة، والطلب الموجَّه يثبت التسليم، والاستعلام يثبت تحليل الاسم. وهي تفشل بهذا الترتيب، ولا واحدة منها تستلزم التالية. فحص عملية أخضر يجلس بجانب نفق ميت هو الحالة الطبيعية، لا تناقض.

اكتب الفحوص الأربعة بهذا الترتيب، مع الأمر الدقيق والمخرجات المتوقعة لكل منها. المسبار الذي لا تستطيع تحديد مخرجاته المتوقعة سيقرأه كل مشغّل يرى التنبيه قراءة مختلفة. ضع القائمة نفسها في نص التنبيه، لا في دليل التشغيل فقط، حتى يلتقي الشخص الذي يُوقظ ليلاً بالطبقة قبل العَرَض. أبقِ كل أمر قابلاً للنسخ واللصق على المضيف الذي يشغّله.

ثم أضف فحص التطبيق بنداً خامساً منفصلاً. صفحة تعطّل فيها خدمة الحساب لا تبرّر إعادة تشغيل النفق.

الخطوة 2: اربط كل فشل بإجراء واحد

لكل فحص، قرّر ما يُعاد تشغيله، وما يبقى محظوراً، وما يستدعي إنساناً. فشل طبقة النفق قد يبرّر إعادة تشغيل النفق؛ وفشل المحلّل يشير إلى تكامل DNS على العميل؛ وفشل طبقة التطبيق يجب ألا يمسّ النفق تقريباً أبداً.

بيّن ما يجب ألا يفعله الفشل، لأن الإعدادات الافتراضية الخطرة هي المتسامحة. حالة غير سليمة يجب ألا تصبح أبداً إذناً لمرور التطبيق المباشر، لأن مساراً بديلاً يتجاوز النفق بهدوء يزيل سبب وجود النفق. ضيّق الإجراءات أيضاً: إعادة تشغيل مكوّن مشترك لأن وجهة واحدة بطيئة تحوّل مشكلة محلية إلى مشكلة على مستوى الأسطول كله. وهي أيضاً تدمّر الدليل الذي تحتاجه لمعرفة السبب.

الخطوة 3: أبقِ المسابر غير ضارة ورخيصة

استخدم طلبات صغيرة للقراءة فقط: مورد ثابت، أو نقطة نهاية صحة تبلّغ عن اعتماديتها، أو اتصال TCP بمنفذ تتحكم به. تجنّب بيانات الاعتماد والتصفح الخاص وأي شيء يغيّر الحالة في كل فترة، لأن مسباراً يكتب هو اختبار حمل على جدول.

سجّل الوجهة وتوقّع المسار ومهلة الانتظار لكل مسبار. توقّع المسار هو الحقل الذي يغفله الناس، وهو ما يفصل فشل النفق عن خطأ في التوجيه عندما تقرأ التنبيه لاحقاً. اشتقّ الفترة وعتبة الفشل من زمن التعافي الذي تعِد به، وأبقِ المهلة أقصر من الفترة. المسبار الذي لا يزال يعمل عند بدء التالي يبلّغ عن فشل واحد مرتين ويبدو كتذبذب.

الخطوة 4: اكسر كل طبقة وراقب المسبار الصحيح وهو يحمرّ

أوقف عملية النفق وتأكّد من فشل فحص العملية بينما قد يجيب DNS من الذاكرة المؤقتة. غيّر مساراً وتأكّد من فشل الطلب الموجَّه بينما تبقى العملية والمصافحة سليمتين. اكسر DNS وحده وتأكّد من أن فحص التطبيق يبلّغ عن تحليل الاسم بدلاً من خطأ نفق. إذا تحرّك مسباران معاً دائماً، فلديك فحوص أقل مما تظن.

اختبر اتجاه التعافي بالانضباط نفسه. بعد استعادة الطبقة، يجب أن يُصفَّر المسبار دون إعادة تشغيل يدوية، ويجب ألا يترك الإجراء الذي اشتعل أي تجاوز خلفه. راقب دورة كاملة قبل أن تثق بالحالة الخضراء، لأن مسباراً لا يُصفَّر إلا يدوياً يخفي مسار تعافٍ معطوباً.

الخطوة 5: ضع دليل التشغيل حيث يشير التنبيه

صفحة واحدة بخمسة صفوف تحمل التصميم كله: الطبقة، الأمر، النتيجة المتوقعة، الإجراء عند الفشل، المالك. أضف لكل مسبار سطراً عمّا لا يختبره عمداً. ذلك السطر هو ما يمنع الشخص التالي من إضافة فحص سادس يقيس كل شيء ولا يميّز شيئاً. اربط الصفحة من نص التنبيه، وإلا لن يفتحها أحد أثناء الحادث.

في نشر الحاويات، تشكّل حالة الاعتمادية بدء التشغيل ولا شيء غيره. ترتيب بدء Compose وشرط الصحة توثّق كيف تحدّد الجاهزية ترتيب بدء الخدمات؛ ولا شيء من ذلك يفرض سياسة الخروج بعدها، ولا شيء من ذلك يفشل مغلقاً عندما يسقط النفق. يحتاج الإنفاذ المستمر إلى سياسته ومسباره الخاصين، مكتوبين على الصفحة نفسها.

يكون دليل التشغيل منتهياً عندما تتعافى الطبقة الصحيحة دون أن يقرأ أحد موقعاً غير متاح على أنه نفق معطوب. ذلك يختبر المستند، لا النفق.