उपलब्धता को मापने की अपनी कार्यप्रणाली पर फिर से विचार करें और सार्थक लक्ष्य निर्धारित करने के लिए अपने ग्राहक के साथ काम करें ।
यदि आप एक बड़ी वेबसाइट चला रहे हैं, तो अपटाइम उपयोगी नहीं है। यदि आप 10 मिनट के लिए प्रश्नों को छोड़ते हैं, जब आपके ग्राहकों को उन्हें सबसे अधिक (ट्रैफिक पीक) की आवश्यकता होती है, तो रविवार को सुबह 3 बजे एक घंटे के आउटेज की तुलना में यह व्यवसाय के लिए अधिक हानिकारक हो सकता है।
कभी-कभी बड़ी वेब कंपनियां निम्नलिखित मैट्रिक्स का उपयोग करके उपलब्धता, या विश्वसनीयता को मापती हैं:
- सर्वर-साइड त्रुटि (HTTP 500s) के बिना सफलतापूर्वक पूछे जाने वाले प्रश्नों का प्रतिशत ।
- कुछ निश्चित लक्ष्य विलंबता के नीचे दिए गए प्रश्नों का प्रतिशत ।
- गिराए गए प्रश्नों को आपके आँकड़ों के विरुद्ध गिना जाना चाहिए (नीचे देखें)।
नमूना जांच का उपयोग करके उपलब्धता को मापा नहीं जाना चाहिए , जो कि बाहरी इकाई जैसे कि p षटतिंग और पिंगबिलिटी रिपोर्ट करने में सक्षम है। पूरी तरह से उस पर भरोसा मत करो। यदि आप इसे सही करना चाहते हैं, तो हर एक क्वेरी को गिनना चाहिए । अपनी वास्तविक, कथित सफलता को देखकर अपनी उपलब्धता को मापें।
सबसे प्रभावी तरीका अपने लोड-बैलेंसर से लॉग या आंकड़े एकत्र करना है और ऊपर मैट्रिक्स के आधार पर उपलब्धता की गणना करना है।
गिराए गए प्रश्नों का प्रतिशत भी आपके आँकड़ों के विरुद्ध गिना जाना चाहिए। इसे सर्वर-साइड त्रुटियों के रूप में उसी बाल्टी में देखा जा सकता है। यदि नेटवर्क या किसी अन्य बुनियादी ढांचे जैसे DNS या लोड बैलेंसरों के साथ समस्याएं हैं, तो आप अनुमान लगाने के लिए सरल गणित का उपयोग कर सकते हैं कि कितने प्रश्न खो गए हैं । यदि आपको सप्ताह के उस दिन के लिए X क्वेरी की उम्मीद है लेकिन आपको X-1000 मिला है, तो संभवत: आपने 1000 प्रश्नों को छोड़ दिया है। प्रति मिनट (या सेकंड) ग्राफ़ में अपने ट्रैफ़िक को प्रश्नों में प्लॉट करें। यदि अंतराल दिखाई देते हैं, तो आपने प्रश्न छोड़ दिए। उन अंतरालों के क्षेत्र को मापने के लिए बुनियादी ज्यामिति का उपयोग करें , जो आपको गिराए गए प्रश्नों की कुल संख्या प्रदान करता है।
अपने ग्राहक के साथ इस पद्धति पर चर्चा करें और इसके लाभ बताएं। उनकी वर्तमान उपलब्धता को मापकर आधार-रेखा निर्धारित करें । यह उनके लिए स्पष्ट हो जाएगा कि 100% एक असंभव लक्ष्य है।
फिर आप आधार रेखा पर सुधार के आधार पर एक अनुबंध पर हस्ताक्षर कर सकते हैं। कहो, अगर वे वर्तमान में 95% उपलब्धता का अनुभव कर रहे हैं, तो आप 98.5% प्राप्त करके स्थिति को दस गुना बेहतर बनाने का वादा कर सकते हैं ।
नोट: उपलब्धता को मापने के इस तरीके के नुकसान हैं। जब तक आप इसे करने के लिए मौजूदा औजारों का उपयोग नहीं करते हैं, पहले, लॉग्स को इकट्ठा करना, रिपोर्ट तैयार करना और रिपोर्ट तैयार करना आपके लिए मामूली नहीं हो सकता है। दूसरा, एप्लिकेशन बग आपकी उपलब्धता को नुकसान पहुंचा सकते हैं। यदि आवेदन कम गुणवत्ता वाला है, तो यह अधिक त्रुटियों की सेवा करेगा। इसका समाधान केवल आवेदन से आने वाले लोगों के बजाय लोड-बैलेंसर द्वारा बनाए गए 500 पर विचार करना है।
इस तरह से चीजें थोड़ी जटिल हो सकती हैं, लेकिन यह केवल आपके सर्वर अपटाइम को मापने से परे एक कदम है ।
