SLI, SLO, SLA

प्रोडक्शन चलाने वाले तीन अक्षर

बिना माप के विश्वसनीयता सिर्फ़ नाटक है। SRE विश्वसनीयता को एक संख्या बनाता है, जिस पर पहले से सहमति होती है और जिसे हर कोई सत्यापित कर सकता है।

सर्विस लेवल इंडिकेटर (SLI): सेवा के व्यवहार का मापन। उदाहरण: रिक्वेस्ट लेटेंसी, एरर रेट, थ्रूपुट, क्यू डेप्थ। SLI वह चीज़ है जिसे आप ग्राफ़ कर सकते हैं।

सर्विस लेवल ऑब्जेक्टिव (SLO): SLI के लिए लक्ष्य मान या रेंज। उदाहरण: 'रोलिंग 28-दिन की विंडो में 99.9% HTTP रिक्वेस्ट सफल रहें।' SLO आपके और आपके यूज़र्स के लिए स्वीकार्य सेवा गुणवत्ता का वादा है।

सर्विस लेवल एग्रीमेंट (SLA): एक संविदात्मक प्रतिबद्धता, आमतौर पर उल्लंघन पर वित्तीय दंड के साथ। उदाहरण: 'अगर मासिक उपलब्धता 99.9% से कम हो तो 10% रिफंड करेंगे।' SLA वकीलों द्वारा लागू किया गया वादा है।

महत्वपूर्ण अंतर: आपका SLA हमेशा आपके SLO से ढीला होना चाहिए। अगर आप आंतरिक रूप से 99.9% टारगेट करते हैं और बाहरी रूप से 99.9% कॉन्ट्रैक्ट करते हैं, तो आपके पास कोई मार्जिन नहीं है। SRE आमतौर पर SLO को SLA से एक नाइन टाइट रखते हैं: 99.95% टारगेट, 99.9% कॉन्ट्रैक्ट। यह गैप अनिवार्य रूप से आने वाले खराब हफ्ते को संभालता है।

Error Budgets: The Inverse SLO

विश्वसनीयता लक्ष्यों से इंजीनियरिंग निर्णयों तक

एक SLO विश्वसनीयता लक्ष्य निर्धारित करता है। error budget वह शेष राशि है: लक्ष्य चूकने से पहले आप जितनी विफलता खर्च कर सकते हैं।

यदि आपका SLO 28 दिनों में 99.9% सफलता का वादा करता है, तो आपका error budget 0.1% अनुरोधों का है, या प्रति माह लगभग 40 मिनट की पूर्ण डाउनटाइम। यह बजट आपका है—इसे आप किसी भी तरह खर्च कर सकते हैं: नियोजित रिलीज़, प्रयोगात्मक सुविधाओं, chaos engineering, या किसी गलत व्यवहार करने वाली निर्भरता को सहन करने पर।

Error budgets dev और ops के बीच के संघर्ष को नया रूप देते हैं। बिना बजट के, हर आउटेज इस बात पर बहस शुरू कर देता है कि किसने गलत बदलाव भेजा और अगले को कैसे रोका जाए। बजट के साथ:

- बजट शेष है: तेजी से शिप करें, अधिक जोखिम लें, प्रयोग चलाएं। बजट इसके लिए भुगतान करता है।

- बजट समाप्त: नई सुविधाएँ लॉन्च करना बंद करें, जोखिम भरे बदलाव फ्रीज करें, बजट फिर से बनने तक विश्वसनीयता कार्य पर ध्यान दें।

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

Toil को परिभाषित करना

Toil में क्या शामिल है

हर ऑपरेशंस टास्क toil नहीं माना जाता। SRE toil को सटीक रूप से परिभाषित करता है: ऐसा काम जो manual, repetitive, automatable, tactical, enduring value से रहित, और सेवा बढ़ने के साथ linearly scale करने वाला हो।

सभी छह गुण मौजूद होने चाहिए। एक बार का डेटा माइग्रेशन manual है लेकिन repetitive नहीं: यह toil नहीं माना जाएगा। एक सीनियर इंजीनियर नई सेवा आर्किटेक्चर डिज़ाइन करते समय tactical निर्णय लेता है लेकिन enduring value जोड़ता है: यह toil नहीं माना जाएगा।

Toil के उदाहरण:

- मेमोरी लीक क्रैश के बाद सर्विस को मैन्युअली रीस्टार्ट करना

- इंसिडेंट ट्राइएज के दौरान चैट चैनल में लॉग फ्रैगमेंट्स पेस्ट करना

- नया डेटाबेस प्रोविज़न करने के लिए टिकट फॉर्म भरना

- हाथ से तिमाही क्षमता रिपोर्ट चलाना

- एक-एक करके नियमित डिप्लॉयमेंट अनुरोध स्वीकृत करना

पचास प्रतिशत नियम toil को SRE के समय के आधे तक सीमित रखता है। 50% से ऊपर जाने पर टीम को जिम्मेदारी उत्पाद टीम को वापस सौंपनी होगी या अधिक इंजीनियर नियुक्त करने होंगे, लेकिन लक्ष्य स्पष्ट रहता है: toil को शून्य की ओर ले जाना, इसे इंजीनियर किए गए सिस्टम से बदलकर जो बिना मानवीय हस्तक्षेप के वही कार्य करें।

ऑटोमेशन केवल समय बचाने का काम नहीं करता। यह मानवीय त्रुटियों की एक पूरी श्रेणी को पूरी तरह हटा देता है। एक स्क्रिप्ट जो डेटाबेस प्रोविज़न करती है, लंबी शिफ्ट के बाद स्टेप्स नहीं भूलती।

Toil Audit Reasoning

आपकी टीम ट्रैक करती है कि उसका समय कैसे खर्च होता है। पिछले क्वार्टर में ब्रेकडाउन था: 30% डिप्लॉय, 25% इंसिडेंट रिस्पॉन्स, 20% क्षमता कार्य, 15% फीचर इंजीनियरिंग, 10% उत्पाद टीमों के एकमुश्त अनुरोध।

ऑन-कॉल हाइजीन

इंजीनियर्स, न कि पेजर्स

ऑन-कॉल का वास्तविक खर्च होता है। नींद बाधित होती है, सप्ताहांत बाधित होते हैं, और अज्ञात समस्याओं का तनाव बढ़ता है। SRE ऑन-कॉल को एक सीमित संसाधन मानता है जिसे टिकाऊ रखना आवश्यक है, न कि किसी ऐसे व्यक्ति द्वारा उठाया जाने वाला वीरतापूर्ण बोझ जो सबसे अधिक परवाह करता है।

स्वस्थ ऑन-कॉल रोटेशन कई सिद्धांतों का पालन करते हैं:

- मुआवजा समय: ऑन-कॉल घंटे छुट्टी, अतिरिक्त वेतन या समकक्ष लाभ से जुड़े होते हैं। मुफ्त ऑन-कॉल टीम को जलाता है।

- उचित रोटेशन गहराई: छह सदस्यों की टीम प्राथमिक और द्वितीयक के साथ चलाने पर प्रत्येक इंजीनियर को हर तीन सप्ताह में एक शिफ्ट लेनी पड़ती है। दो सदस्यों की रोटेशन करियर नष्ट कर देती है।

- पेज वॉल्यूम बजट: Google की SRE पुस्तक सुझाव देती है कि बारह घंटे की शिफ्ट में अधिकतम दो पेजिंग घटनाएँ होनी चाहिए। इससे अधिक होने पर टीम को केवल सहन करने के बजाय अलर्ट वॉल्यूम कम करने में इंजीनियरिंग समय लगाना चाहिए।

- केवल कार्रवाई योग्य अलर्ट: प्रत्येक पेज के लिए मानवीय कार्रवाई आवश्यक होनी चाहिए। यदि कोई पेज अनदेखा किया जाएगा, स्वचालित किया जाएगा, या सामान्य संचालन के दौरान बार-बार आएगा, तो वह अस्तित्व में नहीं होना चाहिए। अलर्ट थकान एक विश्वसनीयता दोष है।

- फॉलो-द-サン हैंडऑफ: वैश्विक रूप से वितरित टीमें टाइमज़ोन सीमाओं पर शिफ्ट हैंडऑफ करती हैं ताकि कोई भी सुबह 3 बजे पेज न हो जब तक कि सिस्टम वास्तव में सुबह तक इंतजार न कर सके।

Blameless Postmortems

How Outages Become Improvements

हर महत्वपूर्ण घटना के बाद एक पोस्टमॉर्टम तैयार किया जाता है: एक लिखित विश्लेषण जिसमें यह बताया जाता है कि क्या हुआ, क्यों हुआ, क्या ठीक किया गया और भविष्य में दोबारा न होने के लिए कौन-कौन से बदलाव किए जाएंगे। पोस्टमॉर्टम SRE के लिए चक्रवृद्धि ब्याज के समान है: प्रत्येक पोस्टमॉर्टम सिस्टम में स्थायी विश्वसनीयता जोड़ता है।

Blameless का अर्थ है कि दस्तावेज़ में विफलताओं को सिस्टम और प्रक्रियाओं से जोड़ा जाता है, कभी भी व्यक्तियों को दोष नहीं दिया जाता। यदि किसी इंजीनियर ने गलत कमांड चलाई, तो पोस्टमॉर्टम पूछता है: सिस्टम ने वह कमांड क्यों चलने दी? कोई सुरक्षा उपाय क्यों नहीं पकड़ा? सिस्टम, दस्तावेज़ीकरण या टूलिंग में कौन-सा बदलाव अगले इंजीनियर को वही गलती करने से रोक सकता है?

Blamelessness का एकमात्र कारण यह है कि जब लोगों को सजा का डर होता है, तो वे गलतियाँ छिपाते हैं। छिपी हुई गलतियाँ अगली घटना बन जाती हैं। Blameless संस्कृति की लागत उन अघोषित दोषों के संचय की लागत की तुलना में बहुत कम है।

Postmortems आमतौर पर निम्नलिखित को कवर करते हैं:

- Summary: घटना और उसके प्रभाव का एक-पैराग्राफ विवरण

- Timeline: मिनट-दर-मिनट पुनर्निर्माण के साथ टाइमस्टैम्प

- मूल कारण विश्लेषण: तकनीकी और प्रक्रिया संबंधी कारक जिन्होंने विफलता को संभव बनाया

- पहचान: टीम को घटना की जानकारी कैसे मिली, और इसमें कितना समय लगा

- समाधान: सेवा बहाल करने के लिए किए गए कार्य

- सीखे गए पाठ: क्या काम किया, क्या नहीं किया

- कार्य मदें: ठोस, स्वामित्व वाली, समय-बद्ध इंजीनियरिंग कार्य

कार्य मदें एक ट्रैकर में रहती हैं। उन्हें किसी भी अन्य इंजीनियरिंग कार्य की तरह प्राथमिकता दी जाती है। बिना कार्य मदों के पोस्टमॉर्टम कहानी सुनाने तक सीमित रह जाते हैं। कार्य कुछ भी नहीं बदलता।

The Four Golden Signals

What Every Service Must Measure

Google की SRE पुस्तक चार सिग्नल्स प्रस्तावित करती है जिन्हें हर यूज़र-फ़ेसिंग सर्विस को एक्सपोज़ करना चाहिए: latency, traffic, errors, और saturation. ये चारों मिलकर यूज़र के नज़रिए से सर्विस की सेहत का वर्णन करते हैं। कम सिग्नल्स से मॉनिटरिंग करने पर अंधेरे क्षेत्र रह जाते हैं; सैकड़ों मेट्रिक्स से मॉनिटरिंग करने पर टीम अलर्ट थकान में डूब जाती है।

Latency: अनुरोधों में कितना समय लगता है। औसत नहीं, वितरण ट्रैक करें। p50 (मीडियन) सामान्य अनुभव को दर्शाता है। p99 सबसे खराब 1% यूज़र्स को दर्शाता है। औसत अकेला लंबी पूंछ छुपा लेता है: एक सर्विस जिसका मीडियन 50 ms और p99 5,000 ms है, औसत पर ठीक लगती है लेकिन सौ में से एक यूज़र को बर्बाद कर देती है।

Traffic: सर्विस पर माँग। वेब सर्विस के लिए इसका मतलब प्रति सेकंड अनुरोध। स्ट्रीमिंग सर्विस के लिए समकालिक कनेक्शन। बैच जॉब के लिए प्रति मिनट प्रोसेस किए गए आइटम। ट्रैफ़िक क्षमता निर्णयों से जुड़ता है और वर्कलोड विसंगतियाँ दिखाता है।

Errors: असफल अनुरोधों की दर। स्पष्ट विफलताएँ (HTTP 500), निहित विफलताएँ (HTTP 200 लेकिन खराब डेटा), और नीति विफलताएँ (SLO पूरा करने के लिए बहुत धीमा रिस्पॉन्स) सभी गिनती में आती हैं। इनमें अंतर करना ज़रूरी है: खराब पेलोड वाला 200 अक्सर यूज़र्स को ईमानदार 500 से ज़्यादा नुकसान पहुँचाता है।

संतृप्ति (Saturation): सिस्टम कितना भरा हुआ चल रहा है। CPU उपयोग, क्यू गहराई, मेमोरी दबाव, कनेक्शन पूल अधिभोग। संतृप्ति भविष्य की विलंबता की भविष्यवाणी करती है: 95% CPU पर चलने वाले सिस्टम में उपयोगकर्ता-दृश्यमान विलंबता बढ़ने से पहले बहुत कम जगह बचती है।

अधिकांश SRE अलर्ट इन चार संकेतों से प्राप्त होते हैं। लक्षण-आधारित अलर्टिंग (जब उपयोगकर्ता नोटिस करेंगे तो अलर्ट) कारण-आधारित अलर्टिंग (जब CPU 80% से अधिक हो जाए तो अलर्ट) से बेहतर प्रदर्शन करती है। चार गोल्डन सिग्नल लक्षणों का वर्णन करते हैं।

SRE Career Paths

Where SRE Skills Pay

SRE careers diverge based on what part of the discipline an engineer enjoys most:

इंफ्रास्ट्रक्चर SRE: अन्य टीमों द्वारा चलाए जाने वाले प्लेटफ़ॉर्म बनाता है। Kubernetes, सर्विस मेश, इंटरनल क्लाउड। भारी सिस्टम्स इंजीनियरिंग, डिस्ट्रीब्यूटेड सिस्टम्स थ्योरी और प्लेटफ़ॉर्म डिज़ाइन। बड़े कंपनियों में बेहद अच्छा वेतन मिलता है क्योंकि काम स्केल करता है: एक इंफ्रास्ट्रक्चर SRE सैकड़ों प्रोडक्ट इंजीनियरों को सपोर्ट करता है।

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

रिलायबिलिटी टूलिंग: ऑब्ज़र्वेबिलिटी स्टैक बनाता है: मॉनिटरिंग, अलर्टिंग, डैशबोर्ड, पोस्टमॉर्टम टूल्स, इंसिडेंट मैनेजमेंट प्लेटफ़ॉर्म। भारी फ्रंटएंड और डेटा इंजीनियरिंग कार्य। आउटपुट हर दूसरी टीम द्वारा इस्तेमाल किया जाता है।

प्रोडक्शन इंजीनियरिंग: Facebook/Meta का SRE के लिए इस्तेमाल किया जाने वाला शब्द जो क्षमता, डिप्लॉयमेंट और ट्रैफ़िक मैनेजमेंट पर केंद्रित होता है। भारी नेटवर्किंग और सिस्टम्स कार्य।

टेक्निकल सर्टिफिकेशन जो रखने लायक हैं: Google Cloud Professional Cloud Architect, AWS Solutions Architect Professional, और CNCF सर्टिफिकेशन (Kubernetes Administrator, Kubernetes Application Developer) क्लाउड-नेटिव दक्षता का संकेत देते हैं। Linux Foundation सर्टिफिकेशन सिस्टम्स की गहराई दर्शाते हैं। ये सर्टिफिकेशन पोर्टफोलियो वर्क का विकल्प नहीं हैं, लेकिन रिक्रूटर स्क्रीनिंग में मदद करते हैं।

समापन

अब आप क्या जानते हैं

साइट विश्वसनीयता इंजीनियरिंग (SRE) गूगल के स्केलिंग समस्या के समाधान के रूप में शुरू हुई और अब यह पूरे उद्योग में प्रचलित एक अनुशासन बन चुकी है। आपने निम्नलिखित विषयों को कवर किया है:

- मैनुअल ऑपरेशन्स से इंजीनियर्ड विश्वसनीयता की ओर बदलाव

- SLI, SLO, SLA और एरर बजट की अवधारणा (inverse-SLO)

- टॉयल की परिभाषा, 50% नियम और इंजीनियरिंग-आधारित कमी

- सस्टेनेबल ऑन-कॉल रोटेशन और ब्लेमलेस पोस्टमॉर्टम प्रैक्टिस

- सर्विस मॉनिटरिंग के लिए चार गोल्डन सिग्नल्स

- SRE करियर ट्रैक्स और वे सर्टिफिकेशन जो नए अवसर खोलते हैं

दो विचार सबसे महत्वपूर्ण हैं। विश्वसनीयता एक संख्या है, जिस पर पहले से सहमति बनाई जाती है। और परिश्रम एक दोष है, न कि नौकरी का विवरण। इन दो बातों को आगे ले जाएँ और बाकी SRE स्वाभाविक रूप से अनुसरण करता है।

अनुशंसित पठन: Google की SRE पुस्तक (निःशुल्क ऑनलाइन: sre.google/books/), व्यावहारिक अभ्यासों के लिए SRE कार्यपुस्तिका, और Charity Majors का ऑब्ज़र्वेबिलिटी पर लेखन। ज्यामिति-का साथी पाठ SRE अभ्यास के अंतर्गत दृश्य संरचना पर गहराई से चर्चा करता है: विलंबता वितरण, त्रुटि बजट शंकु, निर्भरता ग्राफ़, और डैशबोर्ड लेआउट।