GitHub द्वारा बनाई गई on-call संस्कृति

GitHub Ruby on Rails से बना एक बड़ा monolith system था.

monolith on-call संरचना में सबसे कठिन हिस्से

• इसमें बड़े और कई product तथा feature शामिल थे, इसलिए ज़्यादातर engineers को भरोसा नहीं था कि वे codebase को पर्याप्त रूप से समझते हैं और on-call के दौरान incident का जवाब दे सकते हैं। जब उन्हें call मिलती थी, तो वे दूसरे team को escalate करते हुए engineer से ज़्यादा एक connection operator जैसा महसूस करने लगते थे.

• on-call के बीच का अंतराल लंबा था और एक बार की on-call 24 घंटे की होती थी। engineers साल में 4 बार से भी कम on-call करते थे और on-call के दौरान पर्याप्त context हासिल नहीं कर पाते थे.

• monitoring और alert system कई teams में बिखरे हुए थे, और क्योंकि on-call का अनुभव केवल 24 घंटे के लिए होता था, इसलिए on-call monitoring और documentation अच्छी तरह maintain नहीं होती थी.

• क्योंकि ज़्यादातर engineers monolith on-call को लेकर आश्वस्त नहीं थे, पूरे system को अच्छी तरह जानने वाले 5~10 लोग हर production incident में शामिल हो जाते थे, और on-call ज़िम्मेदारी में असंतुलन पैदा हो जाता था.

नई on-call संस्कृति

कामकाजी संगठन से जुड़ी बाधाएँ

• file ownership को स्पष्ट करने के लिए service catalog बनाया गया, जिसमें files को services से map किया गया और services को फिर teams से map किया गया.

• monitoring और alerts पूरे monolith पर सेट थे, इसलिए हर team को अपने ज़िम्मेदारी वाले क्षेत्र की monitoring बनाने के लिए कहा गया.

• यह काम करने वाली teams की संख्या ज़्यादा थी, इसलिए हर team के लिए GitHub में issue बनाए गए और checklist दी गई.

सांस्कृतिक और शैक्षिक बाधाएँ

• pandemic का लोगों पर नकारात्मक प्रभाव पड़ा था, इसलिए पहले सोचे गए तरीके से भी ज़्यादा empathy-first approach अपनानी पड़ी.

• ज़्यादातर engineers के पास on-call का अनुभव नहीं था, और operations का अनुभव भी कम था, इसलिए training तैयार करके दी गई। on-call experts के साथ office hours तय किए गए, पर्याप्त tools और documentation बनाई गई, और मदद पाने के लिए Slack channels बनाए गए.

• कई engineers इस बात को लेकर चिंतित थे कि on-call उनके जीवन पर कितना असर डालेगी। अगर अनुभव कम हो, तो on-call के दौरान रोज़मर्रा की ज़िंदगी के समय को समायोजित करना मुश्किल हो सकता है। इसके लिए on-call experts की tips/tricks संकलित की गईं और ऐसी व्यवस्थाएँ की गईं कि अगर कोई call miss हो जाए तो दूसरा व्यक्ति backup दे सके। यह अपरिचय की समस्या है, इसलिए training से ज़्यादा कई बार on-call करने और समय बीतने के साथ ही सहजता आएगी.

• लोग इस बात को लेकर भी बहुत चिंतित थे कि कहीं वे on-call में अच्छा प्रदर्शन न कर पाएं, इसलिए यह भरोसा देने की कोशिश की जा रही है कि गलती हो जाना ठीक है और चाहे आप कितना भी अच्छा करें, incidents फिर भी हो सकते हैं.

• हर product का severity level अलग होता है, इसलिए कुछ teams को 5 मिनट के भीतर response देना पड़ता है, जबकि कुछ teams अगले दिन तक भी संभाल सकती हैं। कुछ लोग इसे unfair कहते हैं, लेकिन यह बस engineers की अलग-अलग रुचियों का मामला है.

• बदलाव लागू करते समय हर team on-call अनुभव को बेहतर बनाने में बहुत समय नहीं दे सकती। जब on-call ठीक से काम नहीं कर रही हो, तभी on-call process को बेहतर करना चाहिए। teams से कहा गया कि वे लगभग 20% समय technical debt चुकाने में और लगभग 20% on-call experience सुधारने में लगाएँ, और इसके लिए leadership का long-term नज़रिया ज़रूरी है.

[galadbran]

मुझे ठीक-ठीक समझ नहीं है कि on-call लगभग कैसा होता है... क्या यह support request जैसा कुछ है? शायद हमारे यहाँ की तरह फोन पर जवाब देने वाला काम नहीं होगा...

[andrewchaa]

हमारी कंपनी में आम तौर पर on-call का मतलब होता है कि लगभग हर दो महीने में एक हफ्ते तक काम के घंटों के बाहर सिस्टम आउटेज पर रियल-टाइम में प्रतिक्रिया देना। PagerDuty नाम का एक ऐप बहुत इस्तेमाल होता है; अगर high severity की कोई समस्या हो जाए — जैसे dead letter बन जाए, या API failure rate किसी तय स्तर से ऊपर चला जाए ... — तो तुरंत मोबाइल फोन पर alarm आता है, और फिर कंपनी के laptop से कनेक्ट होकर logs चेक करते हुए ज़रूरी कार्रवाई की जाती है।

[sukso96100]

शायद आप इसे ऑन-कॉल ड्यूटी समझ सकते हैं.

[bach80]

यह कुछ हद तक ड्यूटी रोस्टर या साप्ताहिक जिम्मेदारी जैसा लगता है। यानी, incident response बारी-बारी से करना..