VPN के बिना चली कोई निर्धारित नौकरी ठीक दिखती है
स्थिति सफलता कहती है और डेटा गायब है। हर रन को सटीक कनेक्शन पर निर्भर करें और शेड्यूल पर भरोसा करने के बजाय छूटे हुए रन अलग से दर्ज करें।
नौकरी की स्थिति सफलता कहती है, लॉग पूरा हुआ रन दिखाता है, और डेटा पुराना या अनुपस्थित है। यह संयोजन आमतौर पर बताता है कि निर्धारित कार्य बिना उस पथ के शुरू हुआ जिसकी उसे जरूरत थी, और नीचे किसी चीज़ ने विफलता को निगल लिया। समय पर चलने वाला शेड्यूल यह नहीं बताता कि नेटवर्क तैयार था या नहीं। इन दो तथ्यों के बीच का अंतर ही वह जगह है जहाँ यह विफलता रहती है।
प्रवेश रन का है, cron फ़ाइल के अस्तित्व का नहीं।
हरा रन पूरी हुई नौकरी नहीं है
शेड्यूलर नोट करता है कि कोई प्रक्रिया शुरू हुई और बाद में बाहर निकली; उसे पता नहीं कि वह प्रक्रिया उस संसाधन तक पहुँची जिसके लिए वह मौजूद है। जो स्क्रिप्ट विफल कनेक्शन को खाली परिणाम मानती है, या त्रुटि पकड़कर शून्य के साथ बाहर निकलती है, वह हमेशा स्वस्थ दिखेगी। लक्षण लाल स्थिति नहीं है; यह गुमशुदा काम से जुड़ी एक विश्वसनीय स्थिति है।
जाँचने का तरीका तय करने से पहले नाम दें कि रन को वास्तव में क्या चाहिए। बैकअप को निजी DNS और प्रमाणित एंडपॉइंट की जरूरत हो सकती है, केवल टनल प्रक्रिया की नहीं।
कनेक्शन जाँचें, इंटरफ़ेस का नाम नहीं
tun0 नाम का इंटरफ़ेस उस महत्वपूर्ण सत्र के बिना मौजूद हो सकता है, और दूसरा कनेक्शन उस नाम का मालिक हो सकता है। उस विशिष्ट वस्तु की जाँच करें जिस पर नौकरी निर्भर है: एक प्रोफ़ाइल पहचान, एक सेवा उदाहरण, या संसाधन के विरुद्ध एक छोटा अनुमोदित ऑपरेशन। जाँच को समय-सीमित रखें, और क्रेडेंशियल को प्रक्रिया तर्कों और नैदानिक लॉग से बाहर रखें।
डिस्कनेक्ट होने का परिणाम भी परिभाषित करें। सामान्य छूट, छोटी खिड़की में पुनः प्रयास, और ऑपरेटर को दिखने वाली चूकी हुई समय-सीमा तीन अलग उत्तर हैं, और आवर्ती शेड्यूल उनके बीच चयन नहीं करता।
छूटें और विफलताएँ अलग परिणाम हैं
[Service] Type=oneshot User=worker ExecCondition=/usr/local/libexec/check-office-path ExecStart=/usr/local/bin/private-task
systemd परिनियोजन में, ExecCondition= कार्यभार से पहले उस जाँचकर्ता को चलाता है। इसका निकास व्यवहार विशिष्ट है: शून्य आगे बढ़ता है, एक से 254 तक के कोड यूनिट को विफल चिह्नित किए बिना शेष आरंभ आदेशों को छोड़ देते हैं, और 255 या असामान्य समाप्ति इसे विफल कर देती है। यह तीन अलग संकेत देता है, जो केवल तभी उपयोगी हैं जब जाँचकर्ता के अनुबंध को जानबूझकर उन पर मैप किया गया हो। सफलता को पुनः परिभाषित करने वाली सेटिंग्स तस्वीर बदल सकती हैं, इसलिए मैपिंग का दस्तावेज़ीकरण करें।
छूटों को दर्ज करना ही डिज़ाइन को ईमानदार बनाता है। कहीं न दिखने वाला छूटा हुआ रन सफल हुए रन से अलग नहीं पहचाना जा सकता, और हर जाँचकर्ता त्रुटि को शांत छूट मानना टूटी हुई परिनियोजन को अनिश्चित काल तक छिपाता है।
पूरे रन की रक्षा करें, केवल शुरुआत की नहीं
तैयारी की जाँच लॉन्च से पहले दुनिया का निरीक्षण करती है; वह बाद में हर सॉकेट पर पहरा नहीं देती। जब इस काम के लिए सीधा पथ कभी स्वीकार्य न हो, तो एक अनुमोदित निकास नीति जोड़ें जो लगातार लागू हो और DNS, IPv6 तथा टनल के अपने परिवहन को कवर करे। होस्ट की वैश्विक IPv6 स्थिति बदलना काम पर सीमित नीति का विकल्प नहीं है।
तय करें कि क्या कोई नई घटना अभी चल रही नौकरी को ओवरलैप कर सकती है, उस नियम को कार्यभार स्वामी के पास रखें, और डेटा ऑपरेशन के लिए पुनः प्रयास को सुरक्षित बनाएं। डिस्कनेक्ट पर काम रोकना काम को सीमित करता है पर फ़ॉलबैक ट्रैफ़िक के बारे में कुछ भी गारंटी नहीं देता।
तीन मामलों पर कार्यप्रवाह स्वीकारें: तैयार पथ, अनुपलब्ध पथ, और रन के बीच में हानि। इससे कम कुछ शेड्यूल की परीक्षा करता है, नौकरी की नहीं।