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