Player Unknown’s Bug: क्या अज्ञात कारण वाले मुद्दों को दर्ज करने से हम बेहतर हो सकते हैं?

संयोग से बनाए गए एक issue page के ज़रिए, टीम की psychological safety बढ़ाकर और information sharing को विस्तृत करके, एक अधिक मज़बूत organization और service बनाने की कहानी साझा कर रहा/रही हूँ.

---

डेवलपमेंट करते समय अक्सर ऐसे problems मिलते हैं जिनका कारण समझ में नहीं आता.
खासकर web frontend, server जैसी चीज़ों की स्थिति के अलावा भी browser के प्रकार या version, Chrome extensions जैसे अनगिनत external factors से प्रभावित होता है.

अगर हमें समस्या का कारण न पता हो, या समस्या का कारण हमारी तरफ़ न हो, तो अचानक यह सवाल उठा कि क्या केवल postmortem के सहारे ही हम एक मज़बूत structure बना सकते हैं (क्या यह पर्याप्त है?).

शुरुआत

एक बार ऐसा हुआ कि एक अज्ञात कारण वाले issue की report मिलने से लेकर उसे बंद करने तक 9 घंटे लग गए.
Issue debugging में 4 घंटे लगाने के बाद ही पता चला कि समस्या का कारण internal code या infra में नहीं था, बल्कि user के Chrome Extension के bug से हुआ था.

समस्या का कारण कहाँ है, यह समझना ही मुश्किल था, लेकिन उससे भी ज़्यादा गुस्सा इस बात पर आया कि कारण बाहरी है, यह पहचानने में पूरे 4~5 घंटे लग गए.
Notion में Player Unknown’s Bug(PUB) नाम का एक page बनाया, और गुस्से के साथ issue को संभालते हुए किए गए प्रयास, जो कमी रह गई, और किन बातों को बेहतर किया जा सकता है, उन्हें लिख लिया.

संस्कृति के रूप में स्थापित होना, और आगे बढ़ना

पुनरावलोकन करते हुए हमने issue का कारण, उसे खोजते समय अतिरिक्त रूप से जो बातें पता चलीं, और जहाँ गलत आकलन हुआ, उन पर चर्चा की. टीम के साथियों ने अपने सवाल और सुधार के बिंदु बताए, और उन्हें इकट्ठा करके incident response process को व्यवस्थित किया.

इस प्रक्रिया की अच्छी बात यह रही कि issue response के दौरान जो कठिनाई महसूस हुई थी, उस पर टीम के लोगों ने सहानुभूति दिखाई, और नई चीज़ें साझा करने में मज़ा भी आया. साथ ही, checklist बनाकर यह संभव हुआ कि अगली बार मिलती-जुलती स्थिति आने पर समस्या को और जल्दी समझा जा सके. टीम से बात करके इसे औपचारिक संस्कृति के रूप में अपनाया गया.

AB180 की development organization मूल रूप से postmortem चलाती है. जहाँ internal postmortem का केंद्र Resolution और Action Items हैं, वहीं PUB का उद्देश्य Lesson Learn, issue response के प्रति psychological safety बनाना, और अज्ञात समस्याओं में पहले किन factors की जाँच करनी चाहिए, उन्हें व्यवस्थित करना है.

स्वैच्छिक information sharing की संस्कृति

टीम में यह संस्कृति स्थापित होने के साथ, दूसरे टीम सदस्यों द्वारा संभाले गए issues भी एक-एक करके जमा होने लगे.
पुनरावलोकन के दौरान जो बातें पहले पता नहीं थीं, उन पर चर्चा करना और उन्हें और गहराई से देखना, एक छोटे लेकिन स्वैच्छिक 'knowledge sharing session' की तरह चलने लगा.

इस संस्कृति को थोड़ा और बढ़ाने के लिए, हमने एक Slack channel भी चलाना शुरू किया है जहाँ सीखी गई और नई पता चली बातों को समय-समय पर साझा किया जाता है. अभी तक यह अच्छे से चल रहा है.

Lesson Learn

• Incident को संभालने वाली पूरी टीम की psychological safety बढ़ानी चाहिए, और इसके लिए अधिक बातचीत ज़रूरी है.
• अगर ऐसा नहीं होता, तो समस्याएँ दोहराई जाती हैं, और organization के भीतर यह सोच जमने लगती है कि ‘समस्या = ऐसी चीज़ जिसके बारे में बात नहीं करनी चाहिए’.
• Information sharing के ज़रिए organization की psychological safety बनाना, और यहाँ तक कि उसे बढ़ाना भी संभव है.
• और ऐसी information sharing culture शायद हमारी सोच से कहीं ज़्यादा छोटी चीज़ से भी शुरू हो सकती है.

[kunggom]

मैंने तो आज इसका उलटा अनुभव किया—एक ऐसी outage से पूरे दिन जूझने के बाद दफ्तर से निकला, जिसके बारे में लग रहा था कि उसका कारण किसी खास external factor की वजह से बिल्कुल साफ है, लेकिन internal परिस्थितियों के कारण उस पर आसानी से कार्रवाई नहीं की जा सकती, इसलिए बस बेबस होकर परेशान हो रहा था; जबकि असल में वह सिर्फ config file की एक लाइन बदलने से ही हल हो जाने वाला मामला था। यह लेख देखकर सच में बहुत मदद मिली।

[hiddenest]

आज भी आपने पूरे दिन बहुत मेहनत की। फिर भी यह अच्छी बात है कि आपने समस्या हल कर ली। ऊपर के लेख में जिन समस्याओं का ज़िक्र किया था, वे भी कभी-कभी याद आती हैं। उस समय मुश्किल था, लेकिन अब लगता है कि उन्हें खुशी से स्वीकार कर सकता हूँ।
kunggom-ssi ने आज जो मुश्किल दिन झेला, क्या समय बीतने पर उसे भी खुशी से याद नहीं कर पाएँगे? haha

मेरी कमज़ोर-सी लिखाई पढ़ने के लिए धन्यवाद।

[kunggom]

सच कहूँ तो, न पहले कभी और न अब, मैंने कभी यह नहीं सोचा कि incident handling की तकलीफ़ को आनंददायक कहा जा सकता है।
उदाहरण के लिए, आज जिस incident को संभाला, वह भी संयोग से ऐसे product में हुआ था जहाँ हमारी टीम के लिए production server तक सीधी पहुँच रोकी गई थी, इसलिए incident का पता लगाने और उसके लक्षण समझने वाले शुरुआती हिस्से तथा बड़ी मुश्किल से server access permission हासिल करने के बाद के बाद वाले हिस्से को छोड़ दें, तो हम अपेक्षाकृत लाचार ही रह सकते थे। हमारी टीम अगर फलाँ-फलाँ कार्रवाई करने का अनुरोध करती, तो server operations team अपनी तरफ़ की परिस्थितियों का हवाला देकर मना कर देती थी। ऐसी लाचारी को भला आनंद से कैसे स्वीकार किया जा सकता है।
इसलिए, दफ़्तर से निकलने से पहले postmortem document लिखते समय जो महसूस हुआ, वह शायद इस बात के ज़्यादा करीब था: ‘चाहे झुंझलाहट में ही सही, अगली बार ऐसी गलती नहीं करूँगा!’

[hiddenest]

आपकी बात सुनकर लगता है कि आपको काफ़ी मुश्किल हुई होगी। जैसा आपने कहा, वही गलती दोबारा न करते हुए ही हम धीरे-धीरे बेहतर हो सकते हैं... टीटी

[kunggom]

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