تقسيم النفق مقابل سياسة الشركة: أي قاعدة تسود

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

قبل أن تجادل حول مربع الاختيار، حدد أي خاصية وُجدت السياسة لحمايتها.

الخاصية التي تقف خلف القاعدة

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

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

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

ثمة ادعاءان يستحقان الرفض مبكرًا. فالأنفاق الكاملة لا تمنح المسؤولين كل صفحة نص عادي، لأن تشفير التطبيقات وضوابط نقاط النهاية هما ما يحدد المرئي. وتقسيم النفق ليس غير آمن على الإطلاق أيضًا، لأن DNS المُدار وسياسات كل تطبيق ووكلاء نقاط النهاية يمكن أن تصمد بصرف النظر عن المسار.

نفّذ الفحوص بالترتيب

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

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

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

اطلب استثناءً ضيقًا

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

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

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

اجعل الاستثناء قابلًا للبقاء

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

resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status

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

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