सामान्य इंटरव्यू: किसी गैर-तकनीकी स्टेकहोल्डर को SLI, SLO और SLA कैसे समझाएं?

प्रॉम्प्ट और परिदृश्य

एक सेल्स लीड अनुबंध में उल्लिखित 99.9% SLA को इस वादे के रूप में लेता है कि प्रोडक्ट कभी विफल नहीं होता और इंजीनियरिंग से किसी भी प्रकार की गिरावट न होने की गारंटी की मांग करता है। SLI, SLO और SLA को सरल भाषा में समझाएं, आप इन मापदंडों को कैसे चुनते हैं, इस गलतफहमी को कैसे दूर करते हैं, और ये शर्तें रिलीज़ तथा ग्राहक संचार को कैसे प्रभावित करती हैं।

साक्षात्कारकर्ता क्या परख रहा है

क्या आप अमूर्त विश्वसनीयता (रिलायबिलिटी) शर्तों को यूज़र जर्नी और व्यावसायिक प्रतिबद्धताओं से जोड़ते हैं।
क्या आप प्रतिशत को एक पूर्ण गारंटी मानने के बजाय आंतरिक लक्ष्य, प्रेक्षित सिग्नल और बाहरी अनुबंध के बीच अंतर करते हैं।
क्या आप समझा सकते हैं कि एरर बजट रिलीज़ करने, रोकने और जोखिम के ट्रेड-ऑफ का समर्थन कैसे करता है।
क्या आप श्रोता के अनुसार अपनी बात को ढालते हैं, उनकी समझ की पुष्टि करते हैं, और एक व्यावहारिक अगला कदम निर्धारित करते हैं।

पहले पूछे जाने वाले स्पष्टीकरण प्रश्न

99.9% किस सर्विस, यूज़र जर्नी, समय सीमा (विंडो) और उपलब्धता की परिभाषा को कवर करता है, और क्या रखरखाव या थर्ड-पार्टी निर्भरताओं को बाहर रखा गया है?
क्या SLA क्रेडिट के साथ एक अनुबंधात्मक प्रतिबद्धता है, या सेल्स सामग्री में एक गैर-अनुबंधात्मक लक्ष्य है?
क्या हमारे पास पहले से ही SLI डेटा, SLO लक्ष्य, एक एरर बजट और ग्राहक-प्रभाव रिपोर्ट मौजूद हैं?
क्या मुख्य चिंता उल्लंघन का जोखिम, ग्राहक अनुभव, रिलीज़ की गति, या आंतरिक संसाधनों की प्राथमिकता है?

30 सेकंड का उत्तर

मैं 99.9% के सर्विस दायरे और अनुबंध के अर्थ की पुष्टि करूंगा, फिर समय पर उड़ान भरने के सादृश्य का उपयोग करूंगा: SLI वह परिणाम है जिसे हम मापते हैं, SLO वह लक्ष्य है जिसे टीम हासिल करने का प्रयास करती है, और SLA ग्राहक के साथ एक औपचारिक प्रतिबद्धता है जिसमें दायरा, अपवाद और अक्सर क्रेडिट शामिल होते हैं। 99.9% शून्य विफलता नहीं है; यह एक निर्धारित विंडो के भीतर विफलता का एक अनुमत बजट है। मैं सिग्नल को यूज़र प्रभाव और शेष जोखिम में परिवर्तित करूंगा, समझाऊंगा कि बजट रिलीज़ करने, धीमा करने या रोकने के निर्णय में कैसे मदद करता है, श्रोता से इसे अपने शब्दों में दोहराने के लिए कहूंगा, और एक ओनर तथा समीक्षा के समय पर सहमति बनाऊंगा।

विस्तृत विश्लेषण

1. किसी संक्षिप्त नाम (एक्रोनम) से नहीं, बल्कि यूज़र जर्नी से शुरुआत करें

मैं पूछूंगा कि किस कार्य को उपयोग योग्य सर्विस माना जाता है, जैसे कि साइन इन करना, ऑर्डर देना या कोई रिपोर्ट पढ़ना। सर्वर-साइड सफलता दर क्लाइंट टाइमआउट या किसी विफल महत्वपूर्ण प्रवाह को छिपा सकती है, इसलिए जहां संभव हो SLI को यूज़र द्वारा अनुभव की गई उपलब्धता, लेटेंसी या शुद्धता का प्रतिनिधित्व करना चाहिए। पहले कार्य और प्रभाव को समझाएं, फिर संक्षिप्त नाम प्रस्तुत करें।

2. तीन परिभाषाओं के साथ सीमाएं स्थापित करें

एक SLI एक दोहराने योग्य सिग्नल है, जैसे कि महत्वपूर्ण अनुरोधों की सफलता दर या लेटेंसी सीमा के भीतर का अनुपात। एक SLO एक निश्चित विंडो में उस सिग्नल के लिए एक लक्ष्य है, जैसे 30 दिनों में 99.9%। एक SLA किसी ग्राहक या पार्टनर के साथ एक औपचारिक प्रतिबद्धता है जो दायरा, अपवाद, नोटिस और क्रेडिट को परिभाषित कर सकता है। संख्याएं संबंधित हो सकती हैं, लेकिन ज़िम्मेदारी, साक्ष्य और परिणाम भिन्न होते हैं।

3. प्रतिशत को एरर बजट में बदलें

एक निश्चित विंडो के भीतर, एक एरर बजट लगभग अनुमत विफलता का हिस्सा होता है। 30 दिनों में 99.9% के लिए, इसका पैमाना लगभग 43 मिनट की अनुपलब्धता है; यह एक सांकेतिक परिमाण है और इसे अनुबंध की मापन पद्धति के अनुसार होना चाहिए। जब तक बजट स्वस्थ है, रिलीज़ जोखिम सीमाओं के भीतर आगे बढ़ सकती हैं। यदि बजट तेजी से समाप्त हो रहा है या पूरी तरह खत्म हो गया है, तो उच्च जोखिम वाले बदलावों को रोकें और सुधार को प्राथमिकता दें।

4. समझाएं कि SLA का अर्थ "कभी विफल न होना" नहीं है

मैं समझाऊंगा कि एक अनुबंध आम तौर पर मापन, बहिष्करण, दायरा और क्रेडिट को परिभाषित करता है; यह वादा नहीं करता कि प्रत्येक अनुरोध हमेशा सफल होगा। यदि सेल्स को बाहरी शब्दावली की आवश्यकता है, तो अनुबंधात्मक वादे के स्थान पर आंतरिक लक्ष्य को रखने के बजाय SLO, SLA, स्टेटस पेज, सपोर्ट फ्लो और घटना-नोटिस समय को संरेखित करें। लीगल, सेल्स और इंजीनियरिंग को मिलकर अपवादों की पुष्टि करनी चाहिए।

5. विश्वसनीयता को रिलीज़ विकल्पों से जोड़ें

रिलीज़ समीक्षा एरर बजट को एक साझा गेट के रूप में उपयोग कर सकती है: जब तक यह स्वस्थ है, योजना के अनुसार रिलीज़ करें; जब बजट का जलना (burn) असामान्य हो, तो बैच का आकार घटाएं, अधिक समय तक निरीक्षण करें या रोकें; जब बजट समाप्त हो जाए, तो पहले सुधार करें जब तक कि कोई दस्तावेजी अपवाद स्वीकृत न हो। विकल्पों में यूज़र प्रभाव, राजस्व या प्रतिबद्धता पर प्रभाव, रिकवरी समय और रोलबैक शर्तें शामिल होनी चाहिए ताकि विश्वसनीयता कोई एकतरफा वीटो न बन जाए।

6. समझ की पुष्टि करें और निरंतर प्रबंधन करें

बातचीत के बाद, श्रोता से तीनों परिभाषाओं और वर्तमान जोखिम को अपने शब्दों में दोहराने के लिए कहें, फिर प्रश्नों और प्रतिबद्धताओं को रिकॉर्ड करें। प्रत्येक विंडो में समीक्षा करें कि क्या SLI अभी भी उपयोगकर्ताओं का प्रतिनिधित्व करता है, क्या SLO उपयोगी व्यवहार को प्रेरित करता है, और क्या SLA अनुबंध से मेल खाता है। यदि मेट्रिक वास्तविक अनुभव से भटकता है, तो उच्च प्रतिशत पर बहस करने से पहले मापन को ठीक करें।

एक संपूर्ण और प्रभावी उत्तर

मैं 99.9% के पीछे की सर्विस, यूज़र जर्नी, समय सीमा और अनुबंध की सीमा की पुष्टि करूंगा, फिर यूज़र के कार्य से शुरुआत करूंगा। SLI एक मापने योग्य परिणाम है, SLO एक विंडो में टीम का लक्ष्य है, और SLA दायरे, अपवादों और क्रेडिट के साथ ग्राहक की एक औपचारिक प्रतिबद्धता है। मैं अनुबंध के मापन का पालन करते हुए उदाहरण के रूप में 30-दिवसीय 99.9% के लिए लगभग 43-मिनट के पैमाने का उपयोग कर सकता हूं। जब तक बजट स्वस्थ है, रिलीज़ करें; जब बर्न असामान्य हो, धीमा करें या निरीक्षण करें; और समाप्त होने पर उच्च जोखिम वाले बदलावों को तब तक रोकें जब तक कि कोई संयुक्त अपवाद स्वीकृत न हो जाए। मैं सेल्स से इस मॉडल को दोहराने के लिए कहूंगा, स्टेटस और सपोर्ट संचार को संरेखित करूंगा, और समीक्षा करूंगा कि क्या मेट्रिक्स वास्तव में उपयोगकर्ताओं का सही प्रतिनिधित्व करते हैं।

सामान्य विफलता के तरीके

ज़िम्मेदारी की सीमाओं को समझाए बिना SLI, SLO और SLA को समानार्थी मानना।
विंडो, दायरे और अपवादों को नज़रअंदाज़ करते हुए 99.9% को किसी भी समय विफलता न होने का वादा कहना।
महत्वपूर्ण जर्नी और क्लाइंट अनुभव को सत्यापित किए बिना केवल सर्वर मेट्रिक्स को देखना।
एरर बजट का उल्लेख तो करना लेकिन उन्हें रिलीज़, रोकने और अपवाद के निर्णयों से न जोड़ना।
समझ की जांच किए बिना या कोई कार्रवाई सौंपे बिना श्रोता पर तकनीकी संक्षिप्त नामों का बोझ डालना।

फॉलो-अप और विस्तार

फॉलो-अप 1: क्या होगा यदि सेल्स आंतरिक SLO को अनुबंध में शामिल करने के लिए कहे?

मापन, दायरा, अपवाद, नोटिस और क्रेडिट की पुष्टि करें, फिर लीगल, सेल्स, सपोर्ट और इंजीनियरिंग से एक साथ लागत और जोखिम का आकलन कराएं। एक आंतरिक लक्ष्य किसी प्रतिबद्धता को सूचित कर सकता है, लेकिन अनुबंध की परिभाषा और परिचालन क्षमता को अभी भी सत्यापन की आवश्यकता होती है।

फॉलो-अप 2: आप एकाधिक SLIs का चयन कैसे करते हैं?

यूज़र जर्नी के आधार पर उपलब्धता, लेटेंसी, शुद्धता या ताजगी (freshness) को विभाजित करें ताकि एक औसत किसी महत्वपूर्ण पथ को छिपा न सके। प्रत्येक SLI के लिए, डेटा स्रोत, सैंपलिंग, विंडो, छूटे हुए डेटा का प्रबंधन और परिणामी कार्रवाई को परिभाषित करें।

फॉलो-अप 3: क्या होगा यदि SLO पूरा हो रहा है लेकिन ग्राहक फिर भी शिकायत कर रहे हैं?

जांचें कि क्या SLI वास्तविक कार्य को मापता है और क्या यह किसी क्षेत्र, किरायेदार (tenant), क्लाइंट या व्यावसायिक-सफलता की स्थिति को छोड़ देता है। शिकायत के नमूनों को शुरू से अंत तक (end-to-end) सिग्नलों के साथ सहसंबंधित करें, फिर एक SLI जोड़ें या बदलें और लक्ष्य को समायोजित करें।

फॉलो-अप 4: एरर बजट क्रेडिट से कैसे संबंधित हैं?

एक एरर बजट एक आंतरिक जोखिम और रिलीज़ तंत्र है; क्रेडिट एक अनुबंधात्मक SLA परिणाम हैं। वे एक ही घटना रिकॉर्ड का उपयोग कर सकते हैं लेकिन एक दूसरे की जगह नहीं ले सकते। अनुबंध से बाहरी क्रेडिट की गणना करें और इंजीनियरिंग प्राथमिकता तथा परिवर्तन की गति के लिए आंतरिक बजट का उपयोग करें।