VPN स्वास्थ्य जाँचों को एप्लिकेशन स्वास्थ्य जाँचों से अलग रखें

आपकी टनल प्रक्रिया चल सकती है जबकि संरक्षित कनेक्शन बेकार हो, और विफल होता वेब पेज इस बात का प्रमाण नहीं है कि टनल टूट गई। जब एक जाँच सबकी जगह लेती है, तो पुनःआरंभ नीति गलत घटक को पुनःआरंभ करती है और उसे ऑटोमेशन कहती है। नीचे की हर जाँच उस परत का नाम बताती है जिसे वह देखती है, उस कार्रवाई का जो उसकी विफलता से शुरू होती है, और इस प्रमाण का कि कार्रवाई काम कर गई। अंतिम चरण पूरे समूह को ऐसे पृष्ठ में बदल देता है जिसे कोई रात तीन बजे अनुसरण कर सके।

चरण 1: जिस परत को हर जाँच देखती है उसका नाम बताएँ

उनमें से कोई भी लिखने से पहले पूछें कि हर जाँच वास्तव में क्या देख सकती है। जीवंतता सिद्ध करती है कि डेमॉन चल रहा है, हैंडशेक या सहकर्मी सूची सिद्ध करती है कि संबंध मौजूद है, रूट किया गया अनुरोध डिलीवरी सिद्ध करता है, और लुकअप रिज़ॉल्यूशन सिद्ध करता है। वे इसी क्रम में विफल होते हैं, और उनमें से कोई अगले का संकेत नहीं देता। एक हरी प्रक्रिया जाँच के साथ मृत टनल सामान्य स्थिति है, विरोधाभास नहीं।

चारों जाँचें उसी क्रम में लिखें, हर एक के लिए ठीक कमांड और अपेक्षित आउटपुट के साथ। जिस जाँच का अपेक्षित आउटपुट आप बता नहीं सकते, उसे अलर्ट देखने वाला हर ऑपरेटर अलग तरह से पढ़ेगा। वही सूची अलर्ट पाठ में भी रखें, केवल रनबुक में नहीं, ताकि रात में जगाया गया व्यक्ति लक्षण से पहले परत से मिले। हर कमांड को उसे चलाने वाले होस्ट पर कॉपी-पेस्ट योग्य रखें।

फिर एप्लिकेशन जाँच को पाँचवें, अलग मद के रूप में जोड़ें। जिस पृष्ठ की खाता सेवा बंद है वह टनल को पुनःआरंभ करने का औचित्य नहीं देता।

चरण 2: हर विफलता को एक कार्रवाई से जोड़ें

हर जाँच के लिए तय करें कि क्या पुनःआरंभ होगा, क्या अवरुद्ध रहेगा और क्या किसी व्यक्ति को बुलाएगा। टनल परत की विफलता टनल को पुनःआरंभ करने का औचित्य दे सकती है; रिज़ॉल्वर विफलता क्लाइंट पर DNS एकीकरण की ओर इशारा करती है; एप्लिकेशन परत की विफलता को लगभग कभी भी टनल को छूना नहीं चाहिए।

बताएँ कि विफलता को क्या नहीं करना चाहिए, क्योंकि खतरनाक डिफ़ॉल्ट वही होते हैं जो अनुमति देते हैं। अस्वस्थ स्थिति कभी भी सीधे एप्लिकेशन ट्रैफ़िक की अनुमति नहीं बननी चाहिए, क्योंकि टनल को चुपचाप बायपास करने वाला फ़ॉलबैक टनल के होने का कारण ही हटा देता है। कार्रवाइयाँ भी सीमित करें: एक गंतव्य धीमा होने पर साझा घटक को पुनःआरंभ करना स्थानीय समस्या को पूरे बेड़े की समस्या बना देता है। यह कारण खोजने के लिए आवश्यक प्रमाण भी नष्ट कर देता है।

चरण 3: जाँचों को हानिरहित और सस्ता रखें

छोटे, केवल-पढ़ने वाले अनुरोध इस्तेमाल करें: कोई स्थिर संसाधन, अपनी निर्भरता बताने वाला स्वास्थ्य एंडपॉइंट, या आपके नियंत्रण वाले पोर्ट पर TCP कनेक्शन। क्रेडेंशियल, निजी ब्राउज़िंग और हर अंतराल पर स्थिति बदलने वाली हर चीज़ से बचें, क्योंकि लिखने वाली जाँच समय-सारणी पर चलने वाला लोड टेस्ट है।

हर जाँच के लिए गंतव्य, मार्ग अपेक्षा और टाइमआउट दर्ज करें। मार्ग अपेक्षा वही क्षेत्र है जिसे लोग छोड़ देते हैं, और यही बाद में अलर्ट पढ़ते समय टनल विफलता को रूटिंग गलती से अलग करती है। अंतराल और विफलता सीमा उस रिकवरी समय से निकालें जिसका आप वादा करते हैं, और टाइमआउट को अंतराल से छोटा रखें। जो जाँच अगली शुरू होते समय भी चल रही हो, वह एक विफलता दो बार बताती है और फ्लैप जैसी लगती है।

चरण 4: हर परत तोड़ें और देखें कि सही जाँच लाल होती है

टनल प्रक्रिया रोकें और पुष्टि करें कि प्रक्रिया जाँच विफल होती है जबकि DNS शायद कैश से उत्तर दे सकता है। कोई मार्ग बदलें और पुष्टि करें कि रूट किया गया अनुरोध विफल होता है जबकि प्रक्रिया और हैंडशेक स्वस्थ रहते हैं। केवल DNS तोड़ें और पुष्टि करें कि एप्लिकेशन जाँच टनल त्रुटि के बजाय रिज़ॉल्यूशन बताती है। यदि दो जाँचें हमेशा साथ चलती हैं, तो आपके पास सोच से कम जाँचें हैं।

उसी अनुशासन से रिकवरी की दिशा जाँचें। परत बहाल करने के बाद जाँच को बिना मैन्युअल पुनःआरंभ के साफ़ हो जाना चाहिए, और जो कार्रवाई चली उसे पीछे कोई बायपास नहीं छोड़ना चाहिए। हरी स्थिति पर भरोसा करने से पहले एक पूरा चक्र देखें, क्योंकि केवल हाथ से साफ़ होने वाली जाँच टूटा हुआ रिकवरी मार्ग छिपाती है।

चरण 5: रनबुक को वहाँ रखें जहाँ अलर्ट इशारा करता है

पाँच पंक्तियों वाला एक पृष्ठ पूरा डिज़ाइन उठाए रखता है: परत, कमांड, अपेक्षित परिणाम, विफलता पर कार्रवाई, मालिक। हर जाँच के लिए एक पंक्ति जोड़ें कि वह जानबूझकर क्या नहीं जाँचती। वही पंक्ति अगले व्यक्ति को छठी जाँच जोड़ने से रोकती है जो सब कुछ मापती है और कुछ भी अलग नहीं करती। अलर्ट पाठ से पृष्ठ को लिंक करें, वरना घटना के दौरान कोई उसे नहीं खोलेगा।

कंटेनर परिनियोजन में, निर्भरता की शर्त केवल स्टार्टअप को आकार देती है और कुछ नहीं। Compose का स्टार्टअप क्रम और स्वास्थ्य शर्त दस्तावेज़ बताता है कि तैयारी सेवाओं के शुरू होने का क्रम कैसे तय करती है; इसमें से कुछ भी बाद में एग्रेस नीति लागू नहीं करता, और इसमें से कुछ भी टनल गिरने पर बंद होकर विफल नहीं होता। निरंतर प्रवर्तन को अपनी नीति और अपनी जाँच चाहिए, उसी पृष्ठ पर लिखी हुई।

रनबुक तब पूरा होता है जब सही परत बहाल हो जाती है और कोई अनुपलब्ध वेबसाइट को टूटी टनल के रूप में नहीं पढ़ता। वह दस्तावेज़ की परीक्षा है, टनल की नहीं।