अपटाइम हाँ/ना का सवाल नहीं है

एक पाठक ने पूछा कि जो सर्वर उनके ब्राउज़र में ठीक खुलता है, उसे हमने अगम्य क्यों चिह्नित किया। वे भी सही थे और हम भी। सर्वर अधिकांश समय उत्तर देता है — और बाकी समय कनेक्शन गिरा देता है।

एक सर्वर, दो सच

हमने उसे पच्चीस अनुरोध भेजे। लगभग एक-तिहाई ऐसे लौटे:

curl: (56) Recv failure: Connection reset by peer

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

एक जाँच झूठ क्यों बोलती है

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

अलर्ट में हाल और बुरा है। लगातार दो विफलताएँ आउटेज जैसी दिखती हैं। 31% विफलता दर पर लगातार दो लगभग 9% संभावना से होती हैं — यदि आप हर दो घंटे में जाँचते हैं तो दिन में करीब एक बार। वह आउटेज नहीं है। वह अंकगणित है।

यह कितना आम है?

हमने कैटलॉग में ऐसे सर्वर खोजे जो न भरोसेमंद रूप से चालू हैं, न भरोसेमंद रूप से बंद। लगभग 180 अस्थिर बीच में हैं, जिनकी विफलता दर 10% से 90% के बीच है। इकोसिस्टम का छोटा हिस्सा — पर भ्रम का बड़ा हिस्सा।

इसका क्या करें

• यदि आप सर्वर चुन रहे हैं: बैज नहीं, प्रतिशत पढ़िए। 70% वाला सर्वर उत्पादन में चुपचाप विफल होगा — हर तीन कॉल में एक।
• यदि आप सर्वर चलाते हैं: रुक-रुक कर होने वाले कनेक्शन रीसेट आम तौर पर ऐप के आगे लगे प्रॉक्सी या लोड बैलेंसर की ओर इशारा करते हैं, ऐप की ओर नहीं। एप्लिकेशन लॉग साफ़ दिखेंगे।
• यदि आप मॉनिटरिंग बनाते हैं: कभी एक नमूने पर निर्णय मत लीजिए। लगातार विफलता की शर्त रखिए और दर को स्पष्ट कहिए।