VPN आरोग्य तपासण्या अ‍ॅप्लिकेशन आरोग्य तपासण्यांपासून वेगळ्या ठेवा

तुमची टनेल प्रक्रिया चालू असतानाही संरक्षित कनेक्शन निरुपयोगी असू शकते, आणि अयशस्वी होणारे वेब पृष्ठ हे टनेल तुटल्याचा पुरावा नाही। जेव्हा एकच प्रोब सर्वांचे प्रतिनिधित्व करते, तेव्हा रीस्टार्ट धोरण चुकीचा घटक रीस्टार्ट करते आणि त्याला ऑटोमेशन म्हणते। खालील प्रत्येक तपासणी ती निरीक्षण करणारा स्तर, तिच्या अपयशाने सुरू होणारी क्रिया आणि ती क्रिया चालली याचा पुरावा सांगते। शेवटची पायरी संपूर्ण संचाला रात्री तीन वाजता कोणीही अनुसरू शकेल अशा पृष्ठात बदलते।

पायरी 1: प्रत्येक तपासणी कोणत्या स्तराचे निरीक्षण करते ते सांगा

त्यापैकी कोणतीही लिहिण्यापूर्वी प्रत्येक प्रोब प्रत्यक्षात काय पाहू शकते ते विचारा। जिवंतपणा डीमन चालू असल्याचे सिद्ध करतो, हँडशेक किंवा पीअर यादी संबंध असल्याचे सिद्ध करते, राउट केलेली विनंती वितरण सिद्ध करते आणि शोध निराकरण सिद्ध करतो। ते नेमक्या त्याच क्रमाने अयशस्वी होतात आणि त्यापैकी कोणीही पुढील गोष्टीचा अर्थ देत नाही। हिरवी प्रक्रिया तपासणी मृत टनेलच्या शेजारी असणे ही सामान्य स्थिती आहे, विरोधाभास नाही।

चारही तपासण्या त्या क्रमाने लिहा, प्रत्येकासाठी नेमका आदेश आणि अपेक्षित आउटपुटसह। ज्या प्रोबचे अपेक्षित आउटपुट तुम्ही सांगू शकत नाही ते अलर्ट पाहणारा प्रत्येक ऑपरेटर वेगळ्या पद्धतीने वाचेल। तीच यादी केवळ रनबुकमध्ये नाही तर अलर्ट मजकुरातही ठेवा, जेणेकरून रात्री उठवलेली व्यक्ती लक्षणापूर्वी स्तराला भेटेल। प्रत्येक आदेश तो चालवणाऱ्या होस्टवर कॉपी करण्यायोग्य ठेवा।

नंतर अ‍ॅप्लिकेशन तपासणी पाचवी, स्वतंत्र बाब म्हणून जोडा। ज्या पृष्ठाची खाते सेवा बंद आहे ते टनेल रीस्टार्ट करण्याचे समर्थन करत नाही।

पायरी 2: प्रत्येक अपयशाला एका क्रियेशी जोडा

प्रत्येक तपासणीसाठी काय रीस्टार्ट होईल, काय अडवलेले राहील आणि काय माणसाला बोलावेल ते ठरवा। टनेल स्तराचे अपयश टनेल रीस्टार्ट करण्याचे समर्थन करू शकते; रिझॉल्व्हरचे अपयश क्लायंटवरील DNS एकत्रीकरणाकडे निर्देश करते; अ‍ॅप्लिकेशन स्तराच्या अपयशाने टनेलला जवळपास कधीही स्पर्श करू नये।

अपयशाने काय करू नये ते सांगा, कारण धोकादायक डीफॉल्ट अनुमती देणारे असतात। अस्वस्थ स्थिती कधीही थेट अ‍ॅप्लिकेशन ट्राफिकची परवानगी बनू नये, कारण टनेलला गुपचूप टाळणारा फॉलबॅक टनेल असण्याचे कारणच काढून टाकतो। क्रिया देखील मर्यादित करा: एक गंतव्य संथ आहे म्हणून सामायिक घटक रीस्टार्ट करणे स्थानिक समस्येला संपूर्ण ताफ्याची समस्या बनवते। ते कारण शोधण्यासाठी आवश्यक पुरावाही नष्ट करते।

पायरी 3: प्रोब हानिकारक नसलेले आणि स्वस्त ठेवा

छोट्या, फक्त-वाचन विनंत्या वापरा: स्थिर संसाधन, स्वतःचे अवलंबन कळवणारा आरोग्य एंडपॉइंट, किंवा तुम्ही नियंत्रित करता त्या पोर्टवर TCP कनेक्शन। क्रेडेन्शियल्स, खाजगी ब्राउझिंग आणि प्रत्येक अंतराने स्थिती बदलणारे काहीही टाळा, कारण लिहिणारा प्रोब हा वेळापत्रकानुसारचा लोड चाचणी आहे।

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

पायरी 4: प्रत्येक स्तर तोडा आणि योग्य प्रोब लाल होतो का पाहा

टनेल प्रक्रिया थांबवा आणि DNS अजून कॅशमधून उत्तर देऊ शकत असताना प्रक्रिया तपासणी अयशस्वी होते याची खात्री करा। मार्ग बदला आणि प्रक्रिया व हँडशेक निरोगी असताना राउट केलेली विनंती अयशस्वी होते याची खात्री करा। फक्त DNS तोडा आणि अ‍ॅप्लिकेशन तपासणी टनेल त्रुटीऐवजी निराकरण कळवते याची खात्री करा। जर दोन प्रोब नेहमी एकत्र हलत असतील, तर तुमच्याकडे विचारापेक्षा कमी तपासण्या आहेत।

त्याच शिस्तीने पुनर्प्राप्तीची दिशा तपासा। स्तर पुनर्संचयित केल्यानंतर प्रोबला हाताने रीस्टार्ट न करता स्वच्छ व्हावे लागते, आणि सुरू झालेल्या क्रियेने मागे कोणताही बायपास सोडू नये। हिरव्या स्थितीवर विश्वास ठेवण्यापूर्वी एक पूर्ण चक्र पाहा, कारण फक्त हाताने स्वच्छ होणारा प्रोब तुटलेला पुनर्प्राप्ती मार्ग लपवतो।

पायरी 5: रनबुक अलर्ट दाखवतो तिथे ठेवा

पाच ओळींचे एक पृष्ठ संपूर्ण रचना वाहते: स्तर, आदेश, अपेक्षित निकाल, अपयशावर क्रिया, मालक। प्रत्येक प्रोबबद्दल तो जाणूनबुजून काय तपासत नाही याची एक ओळ जोडा। तीच ओळ पुढच्या व्यक्तीला सर्व काही मोजणारी आणि काहीही वेगळे न करणारी सहावी तपासणी जोडण्यापासून रोखते। अलर्ट मजकुरातून पृष्ठ लिंक करा, नाहीतर घटना सुरू असताना कोणीही ते उघडणार नाही।

कंटेनर तैनातीमध्ये, अवलंबन अट फक्त स्टार्टअप घडवते आणि दुसरे काही नाही। Compose स्टार्टअप क्रम आणि आरोग्य अट दस्तऐवज स्पष्ट करतो की तयारी सेवा सुरू होण्याचा क्रम कसा ठरवते; यापैकी काहीही नंतर बाहेर जाण्याचे धोरण लागू करत नाही, आणि टनेल पडल्यावर यापैकी काहीही बंद होऊन अयशस्वी होत नाही। सतत अंमलबजावणीसाठी स्वतःचे धोरण आणि स्वतःचा प्रोब लागतो, त्याच पृष्ठावर लिहिलेला।

योग्य स्तर पुनर्प्राप्त होतो आणि कोणीही अनुपलब्ध वेबसाइटला तुटलेली टनेल म्हणून वाचत नाही तेव्हा रनबुक पूर्ण होतो। ते टनेलची नाही, दस्तऐवजाची चाचणी करते।