9.8 ऑन-कॉल और परिचालन तैयारी

अवलोकन और उद्देश्य

इस समय कोई व्यक्ति जाग रहा है क्योंकि आपका सिस्टम उसे पेज कर सकता है। ऑन-कॉल वह मानवीय व्यवस्था है जो किसी योग्य व्यक्ति को किसी भी समय प्रोडक्शन समस्या की पहुँच के भीतर रखती है, और परिचालन तैयारी (operational readiness) वह कार्य है जो आप पहले से करते हैं ताकि उस व्यक्ति के पास सफल होने का उचित अवसर हो। यह अध्याय उसी तैयारी और उसी मानवीय प्रणाली के बारे में है: आप ऐसा रोटेशन कैसे डिज़ाइन करें जिसे लोग वर्षों तक बनाए रख सकें, आप कैसे तय करें कि किसी को जगाना किस बात के लिए सार्थक है, और आप कैसे सुनिश्चित करें कि किसी सेवा को वास्तविक ट्रैफ़िक देने से पहले वह वास्तव में संचालित होने के लिए तैयार है।

इसे दो पड़ोसी विषयों से अलग रखें। अध्याय 9.3 इंसीडेंट प्रबंधन को कवर करता है, यानी कुछ सक्रिय रूप से टूटने के बाद की प्रतिक्रिया प्रक्रिया: कमांड भूमिकाएँ, गंभीरता स्तर, समन्वय, और पोस्टमॉर्टम। अध्याय 9.1 साइट रिलायबिलिटी इंजीनियरिंग (SRE) को कवर करता है, जो सर्विस लेवल ऑब्जेक्टिव और एरर बजट के साथ विश्वसनीयता इंजीनियरिंग का व्यापक अनुशासन है। यह अध्याय इंसीडेंट से पहले और उस अनुशासन के साथ-साथ स्थित है। यह एक संकीर्ण, अधिक व्यक्तिगत प्रश्न पूछता है: क्या सेवा चलाने के लिए तैयार है, और क्या पेजर संभालने वाला व्यक्ति सफल होने के लिए तैयार किया गया है, न कि पीड़ित होने के लिए? किसी संगठन के पास उत्कृष्ट इंसीडेंट प्रक्रिया हो सकती है और फिर भी वह अपने इंजीनियरों को जला (burn out) सकता है, क्योंकि ऑन-कॉल की पीड़ा किसी भी इंसीडेंट से बहुत पहले ही तय हो जाती है , अलर्ट की गुणवत्ता, रनबुक की स्थिति, और शेड्यूल की मानवीयता से।

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

मुख्य सिद्धांत

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

सिफ़ारिशें

एक मानवीय, टिकाऊ रोटेशन डिज़ाइन करें

शेड्यूल के स्वरूप से शुरुआत करें, क्योंकि यह किसी भी टूल से अधिक टिकाऊपन तय करता है। एक सामान्य पैटर्न साप्ताहिक रोटेशन है जिसमें एक प्राइमरी रिस्पॉन्डर होता है जो पहले पेज लेता है, और एक सेकेंडरी होता है जो बैकअप का काम करता है जब प्राइमरी स्वीकार (acknowledge) नहीं करता या मदद की आवश्यकता होती है। पूल को इतना बड़ा रखें कि कोई भी इंजीनियर चार में से एक सप्ताह से अधिक ऑन-कॉल पर न हो, और आदर्श रूप से छह या उससे अधिक में से एक। चार या उससे कम लोगों का रोटेशन एक चेतावनी संकेत है: बीमारी, छुट्टियाँ, और एट्रिशन इसे उन्हीं दो थके हुए “हीरो” तक सिमटा देंगे।

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

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

पेजिंग नीति को कार्रवाई योग्य, अत्यावश्यक, वास्तविक समस्याओं पर केंद्रित करें

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

यहाँ शत्रु है अलार्म फटीग, एक भली-भाँति प्रलेखित परिघटना जिसमें बार-बार अलार्म के संपर्क में आने वाले लोग असंवेदनशील हो जाते हैं और उन्हें नज़रअंदाज़ करना शुरू कर देते हैं, यहाँ तक कि उन्हें भी जो मायने रखते हैं। यह अस्पतालों से आई एक मरीज़-सुरक्षा अवधारणा है, और यह ठीक उसी तरह सॉफ़्टवेयर पर भी लागू होती है। जब हर शिफ्ट में बीस पेज आते हैं और उन्नीस शोर होते हैं, तो रिस्पॉन्डर आधी नींद में उन्हें स्वाइप करके हटाना सीख जाते हैं, और बीसवाँ, जो वास्तविक था, उसे भी वही प्रतिवर्ती (reflexive) अस्वीकृति मिलती है। हर शोरगुल वाला अलर्ट जिसे आप सहन करते हैं, हर दूसरे अलर्ट की विश्वसनीयता पर एक छोटा कर है।

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

कारणों पर नहीं, लक्षणों और SLO पर अलर्ट करें

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

यह लक्षण-आधारित, SLO-संचालित दृष्टिकोण अध्याय 9.2 की ऑब्ज़र्वेबिलिटी और टेलीमेट्री पर निर्भर करता है, क्योंकि बर्न-रेट अलर्टिंग तभी काम करती है जब आपके मेट्रिक्स, लॉग, और ट्रेस संरचित और भरोसेमंद हों। इसका फल नाटकीय है: कुछ मुट्ठी भर सार्थक लक्षण-अलर्ट सैकड़ों कारण-अलर्ट की जगह ले लेते हैं, और एक पेज फिर से किसी ऐसी समस्या से संबंधित हो जाता है जो जागने लायक है। कारण अब भी मायने रखते हैं, लेकिन वे उन डायग्नोस्टिक डैशबोर्ड पर होने चाहिए जिन्हें रिस्पॉन्डर लक्षण-अलर्ट फायर होने के बाद देखता है, न कि पेजिंग पथ में।

लॉन्च से पहले परिचालन तैयारी अनिवार्य करें

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

यह समीक्षा एक बातचीत है, कोई ऐसा गेट नहीं जिसे चालाकी से पार किया जाए। इसका मूल्य यह है कि यह बनाने वाली टीम को संचालन-क्षमता का सामना उस समय करने पर मजबूर करती है जब उनके पास अभी भी संदर्भ (context) मौजूद है, बजाय इसके कि छह महीने बाद रात 2 बजे यह पता चले कि किसी ने रनबुक नहीं लिखा या अलर्ट सेट नहीं किया। तैयारी को अध्याय 9.6 की रेज़िलिएंस टेस्टिंग से जोड़ें: जिस सेवा में लॉन्च से पहले कभी डिपेंडेंसी फेल्योर इंजेक्ट नहीं किया गया, वह अपने विफल होने के तरीके के बारे में एक अपरीक्षित वादा कर रही है। उच्च-दांव वाले एंटरप्राइज़ और सरकारी लॉन्च के लिए, रेडीनेस रिव्यू को एक अनिवार्य, प्रलेखित चरण बनाएँ, क्योंकि सार्वजनिक रूप से विफल होने वाली एक अतैयार नागरिक-सम्मुख सेवा की कीमत पैसे जितनी ही भरोसे में भी मापी जाती है।

ऐसे रनबुक और प्लेबुक लिखें जो वास्तव में उपयोग किए जाएँ

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

रनबुक की असली परीक्षा यह है कि क्या उसके लेखक के अलावा कोई और व्यक्ति दबाव में उसका सफलतापूर्वक पालन कर सकता है। इसे ऑनबोर्डिंग और गेम डे के दौरान सत्यापित करें, और जिस क्षण कोई इंसीडेंट यह उजागर करे कि रनबुक गलत था, उसे तुरंत अद्यतन करें। ऐसा रनबुक जो झूठ बोलता है, बिना रनबुक के होने से भी बुरा है, क्योंकि यह एक थके हुए रिस्पॉन्डर को आत्मविश्वास के साथ गलत दिशा में भेजता है।

जो आप बनाएँ उसका स्वामित्व लें, मानवीय सीमाओं के भीतर

DevOps आंदोलन ने “you build it, you run it” (जो बनाओ, वही चलाओ) को लोकप्रिय बनाया: जो टीम किसी सेवा को लिखती है, वही उसका पेजर भी वहन करती है। इसका लाभ वास्तविक है और बचाव के योग्य है। जब निर्माता अपने ही पेज महसूस करते हैं, तो वे विश्वसनीयता में निवेश करते हैं, शोरगुल वाले अलर्ट ठीक करते हैं, और संचालन-क्षमता के लिए डिज़ाइन करते हैं, क्योंकि फ़ीडबैक लूप व्यक्तिगत रूप से उन तक पहुँचता है, न कि किसी अलग ऑपरेशंस टीम पर जो मूल कारण ठीक नहीं कर सकती।

इस मॉडल की सीमाएँ हैं जिनका सम्मान करना ज़रूरी है। इसके लिए आवश्यक है कि टीमें वास्तव में अपनी सेवाएँ चलाने के लिए सुसज्जित हों: उन्हें टूलिंग, प्लेटफ़ॉर्म, प्रशिक्षण, और संचालन को भली-भाँति करने का समय दिया जाए, जैसा कि अध्याय 1.10 की इंजीनियरिंग प्रभावशीलता और अध्याय 1.4 का कार्य-प्रणाली दोनों माँग करते हैं। पूर्ण स्वामित्व तब क्रूर हो जाता है जब इसे किसी ऐसी टीम पर थोपा जाए जो रोटेशन के लिए स्टाफ करने हेतु बहुत छोटी हो, या जिसके पास वह प्लेटफ़ॉर्म समर्थन न हो जो ऑन-कॉल को सहनीय बनाता है। कुछ संगठन एक हाइब्रिड मॉडल चलाते हैं, जिसमें एक केंद्रीय SRE या प्लेटफ़ॉर्म टीम सबसे कठिन स्तरों का सह-स्वामित्व लेती है या उच्च विश्वसनीयता मानदंड पूरा करने वाली सेवाओं के लिए ऑफ-आवर कवरेज प्रदान करती है, जिससे उत्पाद टीमें नियमित रात्रि पेज से मुक्त हो जाती हैं। बनाए रखने योग्य सिद्धांत फ़ीडबैक लूप है; इसका स्वरूप टीम के आकार, परिपक्वता, और भार की मानवीयता के अनुरूप लचीला हो सकता है।

ऑन-कॉल इंजीनियरों को सोच-समझकर ऑनबोर्ड करें और गेम डे चलाएँ

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

गेम डे वह पूर्वाभ्यास है जो ऑन-कॉल को वास्तविक बनाता है। किसी गेम डे में आप जानबूझकर किसी विफलता का अभ्यास कराते हैं, आदर्श रूप से एक यथार्थवादी परिवेश में, और ऑन-कॉल इंजीनियर को केवल उन्हीं टूल और रनबुक का उपयोग करके प्रतिक्रिया देने देते हैं जो उसके पास वास्तविक इंसीडेंट में होते। यहीं आप पता लगाते हैं कि रनबुक पुराना हो चुका है, डैशबोर्ड में कोई संकेत गायब है, या अलर्ट कभी फायर ही नहीं होता। गेम डे वह मांसपेशी-स्मृति (muscle memory) और आत्मविश्वास बनाते हैं जो पहले वास्तविक पेज को घबराहट से प्रक्रिया में बदल देते हैं, और ये स्वाभाविक रूप से अध्याय 9.6 की कैओस इंजीनियरिंग से जुड़ते हैं।

स्वच्छ हैंडऑफ़ चलाएँ और ऑन-कॉल स्वास्थ्य मापें

शिफ्टों के बीच का हैंडऑफ़ वह जगह है जहाँ संदर्भ (context) रिसता है। एक छोटा, संरचित हैंडऑफ़ स्थापित करें: वर्तमान में क्या घटित हुआ है, कौन से अलर्ट फायर हुए और दबा दिए गए, कौन से बदलाव प्रगति में हैं, किस पर नज़र रखनी है। इसे बुनियादी ऑन-कॉल स्वच्छता के साथ जोड़ें, जिसमें यह नीति भी शामिल है कि आउटगोइंग रिस्पॉन्डर इनकमिंग रिस्पॉन्डर के लिए गड़बड़ी नहीं छोड़ता, और आधा-अधूरा ठीक की गई कोई भी चीज़ लिखित रूप में दर्ज की जाती है।

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

ट्रेड-ऑफ़: फ़ायदे और नुकसान

विकल्प	फ़ायदे	नुकसान
जो बनाओ, वही चलाओ	सशक्त विश्वसनीयता फ़ीडबैक लूप; मालिक मूल कारण ठीक करते हैं	कम-संसाधन या बहुत छोटी टीमों के लिए क्रूर; असमान रात्रि भार
केंद्रीय SRE या प्लेटफ़ॉर्म ऑन-कॉल	उत्पाद टीमों को नियमित रात्रि पेज से बचाता है; गहन परिचालन कौशल	निर्माता फ़ीडबैक लूप को कमज़ोर करता है; एक डंपिंग ग्राउंड बन सकता है
फॉलो-द-सन रोटेशन	रात में किसी को पेज नहीं; मानवीय और स्वस्थ	कई क्षेत्रों में स्टाफ की आवश्यकता; भारी हैंडऑफ़ ओवरहेड
छोटा स्थानीय रोटेशन	सरल; सभी को सिस्टम की जानकारी	बीमारी या एट्रिशन के तहत ढह जाता है; तेज़ बर्नआउट
लक्षण और SLO अलर्टिंग	कम, सार्थक पेज; कम थकान	परिपक्व टेलीमेट्री की आवश्यकता; धीरे-धीरे बनने वाले कारण छूट सकते हैं
कारण-आधारित अलर्टिंग	समस्याओं को जल्दी और विशिष्ट रूप से पकड़ता है	रिस्पॉन्डरों को बाढ़ में डुबो देता है; अलार्म फटीग पैदा करता है
सख़्त रेडीनेस रिव्यू	प्रोडक्शन में कम अप्रिय आश्चर्य	लॉन्च धीमे करता है; चालाकी से पार किए जाने पर नौकरशाही जैसा महसूस हो सकता है

मूल तनाव कवरेज और मानवता के बीच है। अधिकतम कवरेज के लिए ज़ोर दें तो आपको बड़े रोटेशन, आक्रामक अलर्टिंग, और हर जगह पूर्ण स्वामित्व मिलता है, जो सिस्टम की रक्षा करता है जबकि लोगों को पीसता (grind down) है। केवल रिस्पॉन्डर के आराम के लिए अनुकूलन करें तो आप उन अंतरालों का जोखिम उठाते हैं जहाँ कोई वास्तविक समस्या बिना ध्यान दिए प्रतीक्षा करती रहती है। इसे अंतर को बाँटकर नहीं, बल्कि गुणवत्ता बढ़ाकर हल करें: उत्कृष्ट अलर्ट, काम करने वाले रनबुक, और तैयार सेवाएँ एक छोटे, शांत रोटेशन को अधिक ज़मीन सुरक्षित रूप से कवर करने देती हैं। जो संगठन सबसे अच्छा संचालन करते हैं, वे आमतौर पर वही होते हैं जिनके रिस्पॉन्डर सबसे कम पेज किए जाते हैं, क्योंकि उन्होंने सहनशक्ति के बजाय तैयारी में निवेश किया। शोरगुल वाले अलर्ट को हटाने या रनबुक ठीक करने में बिताया गया हर घंटा मानवीय ध्यान के कई घंटे वापस खरीदता है और पूरे सिस्टम की विश्वसनीयता की रक्षा करता है।

अपनी टीम के साथ चर्चा के लिए प्रश्न

1. क्या आप व्यक्तिगत रूप से एक वर्ष तक इस रोटेशन को वहन करने के इच्छुक होंगे, और यदि उत्तर नहीं है तो आप क्या बदलेंगे? यह प्रश्न अमूर्तता को भेदता है क्योंकि यह भार को व्यक्तिगत बना देता है। बातचीत में वास्तविक आँकड़े लाएँ: पिछले महीने कितने पेज फायर हुए, कितने आधी रात के बाद या सप्ताहांत में गिरे, और औसत एक्नॉलेजमेंट में कितना समय लगा। रोटेशन के हर व्यक्ति से पूछें कि क्या वर्तमान स्वरूप ऐसा है जिसे वे अपने ऑन-कॉल सप्ताह से डरे बिना बनाए रख सकते हैं, और शांत उत्तरों को भी उतना ही सुनें जितना ज़ोरदार उत्तरों को। यदि ईमानदार उत्तर यह हो कि रोटेशन केवल इसलिए जीवित है क्योंकि दो-तीन “हीरो” इसका सबसे बुरा हिस्सा सोख लेते हैं, तो आपने एक ऐसी कमज़ोरी खोज ली है जो उनमें से किसी के जाते ही टूट जाएगी। जो परिणाम आप चाहते हैं वह बदलावों की एक ठोस सूची है ( चाहे बड़ा पूल हो, फॉलो-द-सन विभाजन हो, रात्रि-पेज में कमी हो, या अलर्टिंग की सफाई हो ) जिनमें से प्रत्येक के साथ एक मालिक और एक तारीख जुड़ी हो।

2. किसी इंसान को पेज करने वाले हर अलर्ट के लिए, क्या आप वह कार्रवाई बता सकते हैं जो रिस्पॉन्डर से अपेक्षित है? अधिकांश रोटेशनों ने इसका कभी ऑडिट नहीं किया है, और यह अभ्यास प्रकट करने वाला होता है। पेजिंग अलर्ट की पूरी सूची निकालें और हर एक के लिए पूछें कि जब वह फायर होता है तो रिस्पॉन्डर से क्या करना अपेक्षित है, और पिछली तिमाही में वह बिना किसी वास्तविक कार्रवाई के कितनी बार फायर हुआ। जो अलर्ट इस परीक्षण में विफल होते हैं ( जिनसे कोई कार्रवाई जोड़ी नहीं जा सकती, या जो किसी के छूने से पहले ही लगातार स्वयं हल हो जाते हैं ) वही वह शोर है जो हर दूसरे अलर्ट के प्रति विश्वास को खत्म करता है। यदि आपके पास एक्नॉलेज-टू-एक्शन डेटा है तो उसे लाएँ, और आक्रामक रूप से हटाने या डाउनग्रेड करने के लिए तैयार रहें। लक्ष्य एक ऐसा पेजिंग पथ है जहाँ हर अलर्ट मानवीय सहायता का वास्तविक अनुरोध हो, और बैठक को शुरुआत से छोटी और अधिक तीक्ष्ण अलर्ट सूची के साथ समाप्त होना चाहिए।

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

4. हमारे ऑफ-आवर पेज वास्तव में कहाँ गिरते हैं, और क्या हम लोगों की नींद की रक्षा के लिए स्टाफिंग या कवरेज बदलने को तैयार हैं? रात और सप्ताहांत के पेज एक ऐसा स्वास्थ्य खर्च वहन करते हैं जिसे कच्ची पेज-संख्या छुपा देती है, इसलिए एक रोटेशन जो औसतन सहनीय लगता है, वह चुपचाप उन कुछ लोगों को तबाह कर सकता है जिन्हें संयोगवश रात 3 बजे की विफलताएँ मिलती हैं। घंटे और सप्ताह के दिन के अनुसार पेजों का विभाजन लाएँ, सेवा और रिस्पॉन्डर के अनुसार बाँटें, और औसत के बजाय सघनता (concentration) देखें। प्रतिस्पर्धी विचार वास्तविक है: फॉलो-द-सन कवरेज के लिए एक से अधिक क्षेत्रों में स्टाफ चाहिए और हैंडऑफ़ ओवरहेड बढ़ता है, जबकि एक छोटा स्थानीय रोटेशन सरल तो है पर किसी को रातों का मालिक बना देता है। सोच-समझकर तय करें कि समाधान दूसरे क्षेत्र का रोटेशन है, केंद्रीय प्लेटफ़ॉर्म टीम द्वारा ऑफ-आवर स्तर लेना है, गारंटीशुदा रिकवरी समय के साथ छोटे रात्रि ब्लॉक हैं, या एक अलर्टिंग सफाई है जो रात के शोर को उसके स्रोत पर ही हटा देती है। एंटरप्राइज़ और सरकारी ऑपरेटरों के लिए, ऑन-कॉल स्टाफ के प्रति देखभाल के दायित्व को एक मालिक और एक रिपोर्ट किए गए मेट्रिक के साथ औपचारिक दायित्व के रूप में मानें, न कि कल्याण का नारा, क्योंकि कोई नियामक या वर्क्स काउंसिल अंततः आपसे इसे दिखाने को कह सकता है।

5. क्या हमारा प्रोडक्शन रेडीनेस रिव्यू इस बारे में एक वास्तविक बातचीत है कि सेवा कैसे विफल होती है, या गेट पार करने के लिए चालाकी से भरी गई चेकलिस्ट है? रेडीनेस रिव्यू तभी फल देता है जब वह बदल दे कि क्या शिप होता है, और विफलता का रूप यह है कि लॉन्च से पहले दोपहर में एक फ़ॉर्म भर दिया जाता है ताकि किसी ऐसी प्रक्रिया को संतुष्ट किया जा सके जिस पर कोई विश्वास नहीं करता। पिछली कुछ पूरी हुई समीक्षाएँ लाएँ और पूछें कि हर एक ने वास्तव में क्या पकड़ा: एक गायब रनबुक, एक अपरीक्षित रोलबैक, एक अलर्ट जो कभी फायर नहीं हुआ, या कुछ भी नहीं। तनाव लॉन्च की गति और परिचालन कठोरता के बीच है, और जो समीक्षा नौकरशाही जैसी महसूस होती है उसे चालाकी से पार कर लिया जाएगा जबकि जो वास्तविक विफलता-मोड उजागर करती है उसे तब तक नापसंद किया जाएगा जब तक वह पहली बार किसी की रात न बचा ले। तय करें कि समीक्षा कौन चलाता है, क्या वह बनाने वाली टीम से बाहर का कोई व्यक्ति है, और कौन-सा प्रमाण ( जैसे एक इंजेक्ट किया गया डिपेंडेंसी फेल्योर या किसी अजनबी द्वारा पालन किया गया रनबुक ) पास होने के रूप में गिना जाता है। एंटरप्राइज़ और सरकारी लॉन्च में, पूरी हुई समीक्षा को एक ऑडिट आर्टिफ़ैक्ट के रूप में सुरक्षित रखें और इसे अध्याय 9.6 की रेज़िलिएंस टेस्टिंग से जोड़ें, क्योंकि सार्वजनिक रूप से विफल होने वाली एक अतैयार नागरिक-सम्मुख सेवा भरोसे की वह कीमत चुकाती है जिसे कोई रोलबैक वापस नहीं ला सकता।

6. “जो बनाओ, वही चलाओ” हमारी वास्तव में कहाँ सेवा करता है, और यह किसी ऐसी टीम के प्रति चुपचाप कहाँ क्रूर है जिसे हमने उसकी सेवा चलाने के लिए संसाधन नहीं दिए? पूर्ण स्वामित्व वह फ़ीडबैक लूप बनाता है जो निर्माताओं को शोरगुल वाले अलर्ट ठीक करने और संचालन-क्षमता के लिए डिज़ाइन करने पर मजबूर करता है, लेकिन किसी ऐसी टीम पर थोपे जाने पर जो मानवीय रोटेशन के लिए स्टाफ करने हेतु बहुत छोटी है, यह जवाबदेही के रूप में सजा एक धीमा बर्नआउट इंजन बन जाता है। यह नक्शा लाएँ कि कौन सी टीम किस पेजर की मालिक है, हर रोटेशन वास्तव में कितना बड़ा है जब आप उन लोगों को हटा दें जो कभी कठिन पेज नहीं लेते, और हर टीम के पास संचालन को भली-भाँति चलाने के लिए कौन-सा प्लेटफ़ॉर्म, टूलिंग, और प्रशिक्षण है। प्रतिस्पर्धी खिंचाव सार्वभौमिक स्वामित्व के स्वच्छ सिद्धांत और इस गड़बड़ हक़ीक़त के बीच है कि कुछ स्तरों को सबसे कठिन विश्वसनीयता कार्य का सह-स्वामित्व लेने या ऑफ-आवर कवरेज प्रदान करने के लिए एक केंद्रीय SRE या प्लेटफ़ॉर्म टीम की आवश्यकता होती है। जो परिणाम आप चाहते हैं वह हर सेवा का एक ईमानदार वर्गीकरण है ( पूर्ण-स्वामित्व, सह-स्वामित्व, या केंद्रीय रूप से कवर की गई ) जिसमें किसी भी ऐसी टीम के लिए संसाधन की कमी को नामित किया गया हो जिससे आप कुछ ऐसा चलाने को कह रहे हैं जिसे वह बनाए नहीं रख सकती। किसी बड़े या सार्वजनिक संगठन के लिए, प्लेटफ़ॉर्म समर्थन और हेडकाउंट के लिए खरीद और भर्ती की लीड टाइम भी जोड़ें जो मानवीय स्वामित्व मान लेता है, क्योंकि जिस टीम को आप प्रासंगिक समय-सीमा में स्टाफ नहीं कर सकते, उसे आप विफल होने के लिए तैयार कर रहे हैं।

क्षेत्रीय परिप्रेक्ष्य

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

लघु व्यवसाय। संभावना है कि आपके पास कोई समर्पित SRE नहीं है और आप रात्रि रोटेशन के लिए स्टाफ नहीं कर सकते, इसलिए जो आप बनाते हैं उसके बजाय जो आप खरीदते हैं उस पर निर्भर रहें। ऐसी मैनेज्ड सेवाओं और होस्टिंग को प्राथमिकता दें जिनका प्रदाता गहरे इन्फ्रास्ट्रक्चर पेज वहन करता हो, और अपना खुद का एस्केलेशन बनाने के बजाय एक होस्टेड पेजिंग टूल का उपयोग करें। तैयारी को एक छोटी चेकलिस्ट और ग्राहक को दिखने वाली चीज़ों से जुड़े कुछ मुट्ठी भर सार्थक अलर्ट के रूप में तैयार करें, और ईमानदार रहें कि कुछ सेवाओं को रातभर किसी इंसान को पेज नहीं करना चाहिए जब सुबह का टिकट ही काफ़ी हो।

एंटरप्राइज़। समस्या कई टीमों में स्थिरता की है: एक साझा प्रोडक्शन रेडीनेस रिव्यू, एक सामान्य पेजिंग नीति, और वर्ज़न कंट्रोल में एक रनबुक रिपॉज़िटरी ताकि टीमों के बीच जाने वाला इंजीनियर ऑन-कॉल सिस्टम को तुरंत समझ सके। ऑन-कॉल स्वास्थ्य को एक शासित मेट्रिक बनाएँ जिसमें ऑफ-आवर पेज सीमाएँ समीक्षा को ट्रिगर करती हों, एस्केलेशन और हैंडऑफ़ को मानकीकृत करें ताकि कोई पेज चुपचाप न गिरे, और एक केंद्रीय प्लेटफ़ॉर्म टीम को सबसे कठिन स्तरों का सह-स्वामित्व लेने दें। रोटेशन के पोर्टफ़ोलियो को उसी तरह प्रबंधित करें जैसे आप सेवाओं के पोर्टफ़ोलियो का प्रबंधन करते हैं, जिसमें तोइल, पेज लोड, और बर्नआउट जोखिम का डेटा एक नियमित परिचालन समीक्षा को फ़ीड करता हो।

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

उदाहरण

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

एंटरप्राइज़। एक वैश्विक भुगतान कंपनी “जो बनाओ, वही चलाओ” मॉडल के तहत सैकड़ों सेवाएँ चलाती है, जिसे एक केंद्रीय प्लेटफ़ॉर्म टीम का समर्थन प्राप्त है जो पेजिंग सिस्टम, रेडीनेस रिव्यू प्रक्रिया, और वर्ज़न कंट्रोल में एक साझा रनबुक रिपॉज़िटरी प्रदान करती है। हर सेवा लॉन्च से पहले एक प्रलेखित प्रोडक्शन रेडीनेस रिव्यू पास करती है, जो SLO, अलर्टिंग, रनबुक, क्षमता, और रोलबैक को कवर करती है। ऑन-कॉल स्वास्थ्य एक ट्रैक किया गया मेट्रिक है: जिन टीमों के ऑफ-आवर पेज एक सीमा से अधिक हो जाते हैं वे एक स्वचालित समीक्षा को ट्रिगर करती हैं, और प्लेटफ़ॉर्म टीम तब तक विश्वसनीयता कार्य का सह-स्वामित्व लेने की पेशकश करती है जब तक भार कम न हो जाए। गेम डे त्रैमासिक रूप से यथार्थवादी फेल्योर इंजेक्शन के खिलाफ चलाए जाते हैं। क्योंकि मानक एकसमान है और टूलिंग साझा है, कोई इंजीनियर टीमों के बीच जा सकता है और तुरंत ऑन-कॉल सिस्टम को समझ सकता है, और नेतृत्व प्रति टीम यह देख सकता है कि मानवीय भार टिकाऊ है या नहीं।

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

व्यावसायिक तर्क: प्रेरणाएँ, ROI, और TCO

परिचालन तैयारी और मानवीय ऑन-कॉल पर प्रतिफल दो खातों में दिखाई देता है: सिस्टम की विश्वसनीयता और टीम की अवधारण (retention)। विश्वसनीयता के पक्ष में, जो सेवाएँ रेडीनेस रिव्यू पास करती हैं और लक्षण-आधारित अलर्ट वहन करती हैं, वे कम बार विफल होती हैं और तेज़ी से रिकवर होती हैं, क्योंकि रनबुक मौजूद है, अलर्ट सार्थक है, और रिस्पॉन्डर का पूर्वाभ्यास हो चुका है। एक्नॉलेज करने का औसत समय और रिकवर करने का औसत समय दोनों तब घटते हैं जब कोई पेज किसी तैयार व्यक्ति तक एक लिंक किए गए रनबुक के साथ पहुँचता है, बजाय किसी उलझे हुए व्यक्ति के जो संदर्भ ढूँढ रहा हो। मानवीय पक्ष में, ऑन-कॉल इंजीनियर एट्रिशन का एक प्रमुख कारण है, और किसी वरिष्ठ इंजीनियर को बदलने की लागत उस निवेश से कई गुना अधिक होती है जो रोटेशन को ठीक करने में लगता। ऑक्यूपेशनल बर्नआउट, जो पुरानी कार्यस्थल-थकावट की वह स्थिति है जिसे World Health Organization एक व्यावसायिक परिघटना के रूप में मान्यता देता है, ठीक इसीलिए महंगी है क्योंकि यह आपके सबसे अनुभवी लोगों को, जो सिस्टम को समझते हैं, ले जाती है और उन्हें बाहर धकेल देती है।

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

एंटी-पैटर्न और नुकसान

• हीरो रोटेशन: दो या तीन लोग चुपचाप हर कठिन पेज सोख लेते हैं, इसलिए शेड्यूल कागज़ पर ठीक दिखता है और उनमें से किसी के जाते ही ढह जाता है।
• कारणों पर पेजिंग: उपयोगकर्ता को दिखने वाले लक्षणों के बजाय CPU, मेमोरी, और डिस्क पर अलर्टिंग करना, जिससे रिस्पॉन्डरों को ऐसे पेजों की बाढ़ में डुबो देना जिन्हें कभी किसी इंसान की ज़रूरत ही नहीं थी।
• अलर्ट फटीग सहन की गई: ज्ञात-शोरगुल वाले अलर्ट महीनों तक पेजिंग पथ में छोड़ दिए जाते हैं क्योंकि उन्हें हटाना जोखिम भरा लगता है, जब तक कि रिस्पॉन्डर सब कुछ नज़रअंदाज़ करना शुरू नहीं कर देते।
• रनबुक का क्षरण: लॉन्च के समय एक बार लिखे गए दस्तावेज़, कभी अद्यतन नहीं किए गए, और रात 3 बजे किसी थके हुए रिस्पॉन्डर द्वारा पालन करने पर आत्मविश्वास से गलत।
• समर्थन के बिना स्वामित्व: किसी ऐसी टीम पर “जो बनाओ, वही चलाओ” थोपना जो रोटेशन के लिए स्टाफ करने हेतु बहुत छोटी है या जिसके पास इसे मानवीय ढंग से चलाने के लिए प्लेटफ़ॉर्म और टूलिंग नहीं है।
• रेडीनेस थिएटर: एक रिव्यू चेकलिस्ट जिसे गेट पार करने के लिए भरा जाता है, न कि यह वास्तव में समझने के लिए कि सेवा कैसे विफल होती है।
• लॉन्च करो और छोड़ दो: बिना किसी रोटेशन, बिना अलर्ट, और बिना रनबुक के किसी सेवा को शिप करना, फिर पहले आउटेज के दौरान अंतर की खोज करना।
• अमापित भार: प्रति शिफ्ट पेज या ऑफ-आवर पेज पर कोई डेटा नहीं, इसलिए बर्नआउट तब तक अदृश्य रहता है जब तक लोग नौकरी नहीं छोड़ देते।
• पहला पेज, कोई पूर्वाभ्यास नहीं: बिना किसी शैडोइंग और बिना किसी गेम डे के नए इंजीनियर को ऑन-कॉल पर लगाना, फिर उनके ठिठक जाने पर आश्चर्यचकित होने का नाटक करना।

परिपक्वता मॉडल

• स्तर 1, आरंभ: ऑन-कॉल अनौपचारिक और प्रतिक्रियात्मक है। जब चीज़ें टूटती हैं तो कुछ लोगों को फ़ोन किया जाता है, अलर्ट कारणों पर फायर होते हैं और ज़्यादातर शोर होते हैं, रनबुक गायब या बासी हैं, सेवाएँ बिना किसी रेडीनेस जाँच के लॉन्च होती हैं, और कोई भी मानवीय भार नहीं मापता जब तक कि कोई बर्नआउट न हो जाए या नौकरी न छोड़ दे।
• स्तर 2, विकास: बुनियादी प्रथाएँ दिखाई देती हैं लेकिन टीम के अनुसार भिन्न होती हैं। कुछ रोटेशनों में परिभाषित प्राइमरी, सेकेंडरी, और एस्केलेशन है, कुछ अलर्ट ट्यून किए गए हैं और कुछ रनबुक लिखे गए हैं, और एक रेडीनेस चेकलिस्ट मौजूद है लेकिन असंगत रूप से लागू होती है। जिन टीमों को परवाह है वहाँ पेज गिने जा सकते हैं, रात्रि पेज आम हैं, और ऑन-कॉल के लिए ऑनबोर्डिंग डिज़ाइन किए जाने के बजाय तात्कालिक है।
• स्तर 3, मानकीकरण: रेडीनेस रिव्यू लॉन्च से पहले एक प्रलेखित चरण है, जो टीमों में लागू होता है। पेजिंग एक सामान्य नीति के अनुसार लक्षण और SLO पर आधारित है, रनबुक वर्ज़न कंट्रोल में रहते हैं और अलर्ट से लिंक होते हैं, ऑनबोर्डिंग में शैडोइंग और गेम डे शामिल हैं, हैंडऑफ़ एक संरचित प्रारूप का पालन करते हैं, और एस्केलेशन इतना एकसमान है कि टीमों के बीच जाने वाला इंजीनियर सिस्टम को तुरंत पहचान लेता है।
• स्तर 4, प्रबंधन: ऑन-कॉल को बेसलाइन के मुक़ाबले मापा और नियंत्रित किया जाता है। प्रति शिफ्ट पेज, ऑफ-आवर हिस्सा, एक्नॉलेज करने का समय, एस्केलेशन आवृत्ति, और एक्नॉलेज-टू-एक्शन अनुपात प्रति टीम ट्रैक किए जाते हैं और लक्ष्यों से तुलना किए जाते हैं, इसलिए बर्नआउट की ओर बहती हुई कोई रोटेशन लोगों के छोड़ने से पहले ही दिखाई दे जाती है, बाद में नहीं। सीमाएँ समीक्षा को ट्रिगर करती हैं, अलर्ट की गुणवत्ता का ऑडिट इस प्रमाण पर होता है कि कौन से पेज वास्तविक कार्रवाई तक ले गए, और स्टाफिंग व स्वामित्व के निर्णय किस्से-कहानी के बजाय डेटा से संचालित होते हैं।
• स्तर 5, समन्वय: ऑन-कॉल स्वास्थ्य पूरे संगठन में एकीकृत एक निरंतर सुधरने वाला परिणाम है। सिस्टम के बढ़ने पर भी पेज और ऑफ-आवर रुझान घटते हैं, तोइल को व्यवस्थित रूप से स्वचालित करके हटाया जाता है, फॉलो-द-सन या समकक्ष व्यवस्था नींद की रक्षा करती है, गेम डे और फेल्योर इंजेक्शन नियमित हैं, और संगठन हर शिफ्ट से सीखते हुए स्वामित्व, कवरेज, और रेडीनेस मानकों को अनुकूलित करता है, जोखिम की तस्वीर बदलने पर टीमों और क्षेत्रों में भार को पुनर्संतुलित करता है।

चर्चा के लिए विचार

1. वास्तविक कार्रवाई तक ले जाने वाले पेजों बनाम स्वयं हल हो जाने वाले पेजों का आपका वर्तमान अनुपात क्या है, और इसे मापने के लिए क्या करना पड़ेगा?
2. यदि आपका सबसे जानकार रिस्पॉन्डर कल छोड़ दे, तो कौन-सी सेवाएँ संचालित करने के लिए असुरक्षित हो जाएँगी, और क्यों?
3. “जो बनाओ, वही चलाओ” आपकी कहाँ भली-भाँति सेवा करता है, और यह किसी संसाधन-विहीन टीम के प्रति चुपचाप कहाँ क्रूर है?
4. आपने आखिरी बार कब किसी नए इंजीनियर को यथार्थवादी परिस्थितियों में अपने किसी रनबुक का पालन करते देखा, और क्या टूटा?
5. पिछली चार तिमाहियों में आपके ऑफ-आवर पेज बढ़ने की दिशा में हैं या घटने की, और क्या इस संख्या का कोई मालिक है?
6. यदि आप रेडीनेस-रिव्यू के किसी आइटम को सख़्ती से लागू करते, तो वह आपके सबसे हालिया खराब लॉन्च को रोक सकता था?

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

• Betsy Beyer, Chris Jones, Jennifer Petoff, और Niall Richard Murphy (संपादक), Site Reliability Engineering: How Google Runs Production Systems
• Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, और Stephen Thorne (संपादक), The Site Reliability Workbook: Practical Ways to Implement SRE
• Rob Ewaschuk, “My Philosophy on Alerting,” Site Reliability Engineering के परिशिष्ट में
• John Allspaw और Jesse Robbins (संपादक), Web Operations: Keeping the Data on Time
• Nicole Forsgren, Jez Humble, और Gene Kim, Accelerate: The Science of Lean Software and DevOps
• Gene Kim, Jez Humble, Patrick Debois, और John Willis, The DevOps Handbook
• Michael T. Nygard, Release It! Design and Deploy Production-Ready Software
• World Health Organization, ICD-11, व्यावसायिक परिघटना के रूप में बर्न-आउट पर प्रविष्टि