सॉफ्टवेयर घटना प्रबंधन के 15 वर्षों से एक दर्जन (या लगभग) सीखें

एक सॉफ्टवेयर इंजीनियर के तौर पर, घटनाओं से निपटना बहुत बुरा होता है। शनिवार की सुबह 3 बजे उस ऑन-कॉल पेज को प्राप्त करना? यह भयावह, आत्मा को चूसने वाला और कुल मिलाकर एक घिनौना प्रकरण हो सकता है। यदि यह आपके कार्यस्थल पर अक्सर होता है, तो यह सचमुच PTSD को प्रेरित कर सकता है।

दुर्भाग्य से, यह सॉफ्टवेयर के युग का एक अभिन्न अंग है। यदि कुछ भी हो, तो ये वे आग हैं जिनके माध्यम से वास्तविक इंजीनियरिंग गढ़ी जाती है। ये घटनाएँ आपको सिखाती हैं कि कैसे कठोर सिस्टम को आर्किटेक्ट किया जाए, और कई मामलों में, कैसे नहीं।

यह लेख सॉफ्टवेयर दुर्घटनाओं से निपटने के दो पहलुओं पर प्रकाश डालता है:

• 🛠️ इन अनुभवों को रोकने और उनसे सीखने के लिए किसी को अपने सॉफ्टवेयर प्लेटफॉर्म और टीमों में जो अभ्यास करने की आवश्यकता है।

• 🧘 एक व्यक्ति को लचीला रवैया अपनाने की आवश्यकता है, तथा इन अनुभवों से न केवल सुरक्षित बाहर आना है, बल्कि उससे भी अधिक वापस पाना है।

हम जिन विषयों पर चर्चा करेंगे वे हैं -

1. अपने सिस्टम को जितना संभव हो सके स्वचालित बनाएं
2. अग्रणी बनाम पिछड़े संकेतकों पर नज़र रखना
3. “कार्रवाई योग्य” अलर्ट स्वतः स्पष्ट होने चाहिए
4. स्पष्ट कॉल श्रृंखला और एस्केलेशन पथ स्थापित करें
5. बड़े निर्णय लेने के लिए अग्रिम पंक्ति को सशक्त बनाना
6. सभी घटनाएँ समान नहीं होतीं
7. पहले समाधान करें, बाद में प्रश्न पूछें
8. सुनिश्चित करें कि एक व्यक्ति प्रभारी हो
9. स्पष्ट रूप से और बार-बार संवाद करें
10. दोषरहित पोस्टमार्टम महत्वपूर्ण है
11. पोस्टमार्टम के बाद की कार्रवाई महत्वपूर्ण है
12. जब तक एमटीटीडी कम है, तब तक घटनाएं बुरी नहीं हैं
13. हास्य महान समतुल्यता लाने वाला है

आइये कुछ विवरण जानें!

अपने सिस्टम को जितना हो सके उतना स्वचालित बनाएं

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

अगर चुनने के लिए बहुत सी चीजें हैं, तो बहुत उच्च-स्तर पर जाएं। आप कौन सा उच्चतम-स्तर मीट्रिक चुन सकते हैं? अगर घटक सिस्टम उम्मीद के मुताबिक काम करने में विफल हो जाते हैं, तो क्या यह मानक से अलग हो जाएगा? यह प्लेटफ़ॉर्म (ई-कॉमर्स, वित्तीय या $-आधारित प्लेटफ़ॉर्म के लिए) के माध्यम से प्रवाहित होने वाले राजस्व को ट्रैक करना हो सकता है, या वर्तमान सक्रिय उपयोगकर्ताओं की संख्या (सोशल मीडिया प्लेटफ़ॉर्म के लिए) हो सकती है।

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

अग्रणी बनाम पिछड़े संकेतकों पर नज़र रखना

अग्रणी संकेतक प्रकृति में पूर्वानुमानित होते हैं और होने वाली किसी समस्या की ओर संकेत करते हैं जबकि पिछड़े संकेतक बाद में होने वाले होते हैं और समस्या के अच्छी तरह से प्रगति करने के बाद होने वाले परिणाम का प्रतिनिधित्व करते हैं। यदि आप पिछड़े संकेतकों (जैसे कि “सत्र अवधि” कम होने लगती है) के अलावा या उनके स्थान पर अग्रणी संकेतकों (जैसे कि “ऑर्डर की संख्या में गिरावट”) का उपयोग कर सकते हैं, तो आप संभवतः किसी ऐसी चीज़ को टाल सकते हैं जो बहुत ही भयावह हो सकती है।

“कार्रवाई योग्य” अलर्ट स्वयं स्पष्ट होने चाहिए

आपके अलर्ट स्वतः स्पष्ट होने चाहिए ताकि यह स्पष्ट हो जाए कि जब उन्हें नौकरी से निकाल दिया जाए तो अगला कदम क्या उठाना है। चाहे समस्या की गंभीरता का पता लगाना हो, घटना का निवारण करना हो या समस्या का समाधान करना हो, अलर्ट से जुड़े पर्याप्त विवरण होने चाहिए। आप यह सुनिश्चित करना चाहते हैं कि अलर्ट के साथ क्या करना है, यह निर्धारित करने के लिए बहुत अधिक चर्चा की आवश्यकता न हो।

आप इन विवरणों को अलर्ट की विषय-वस्तु में ही शामिल कर सकते हैं, या यदि यह काफी विस्तृत है, तो आप उस रनबुक से लिंक कर सकते हैं जिसे टीम इन प्रकार के मुद्दों के लिए बनाए रखती है।

स्पष्ट कॉल चेन और एस्केलेशन पथ स्थापित करें

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

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

बड़े निर्णय लेने के लिए अग्रिम पंक्ति को सशक्त बनाना

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

सभी घटनाएँ समान नहीं होतीं

कॉल चेन और एस्केलेशन पथ जैसी चीज़ों के साथ-साथ, एक और महत्वपूर्ण चीज़ घटना प्राथमिकता पैमाना है। यह आमतौर पर पहले उत्तरदाता या घटना कमांडर के लिए एक त्वरित संदर्भ है। यह उन्हें घटना की गंभीरता को जल्दी से पहचानने और इसे इस तरह लेबल करने में मदद करता है क्योंकि यह प्रतिक्रियाओं के विभिन्न ग्रेड की गारंटी दे सकता है।

गंभीर घटनाओं (जैसे सिस्टम आउटेज या वित्तीय डेटा भ्रष्टाचार) और छोटी समस्याओं (जैसे रंग पैलेट गड़बड़ियाँ) के बीच अंतर करना उत्तरदाताओं के लिए झूठे अलार्म से बचने के लिए आवश्यक है। यह यह भी सुनिश्चित करता है कि टीम की प्रतिक्रिया प्रभावी और केंद्रित बनी रहे।

पहले समाधान करें, बाद में प्रश्न पूछें

बिना किसी संदेह के, सबसे महत्वपूर्ण कामों में से एक है घटना को जल्द से जल्द सुलझाना। आप घटना के दौरान यह सोचने में समय बर्बाद नहीं करना चाहते कि कुछ क्यों हुआ या इसे कैसे रोका जा सकता था। आप इसे पोस्टमार्टम के लिए बचा सकते हैं। फिलहाल, बस घटना को सुलझाने पर ध्यान केंद्रित करें और बाद में कठिन सवाल पूछें।

सुनिश्चित करें कि एक ही व्यक्ति प्रभारी हो

कभी-कभी, घटनाएँ बहुत बड़ी हो सकती हैं। वे बहुत सी सेवाओं को प्रभावित करती हैं, वे कई व्यावसायिक डोमेन में फैली होती हैं, या वे राजस्व या प्रतिष्ठा के मामले में बहुत प्रभावशाली होती हैं। तब यह बिल्कुल ज़रूरी होता है कि पूरी घटना को "ट्रैफ़िक कॉप" करने के लिए एक व्यक्ति नियुक्त किया जाए। प्लेस एक्सचेंज में, हमने "घटना कमांडरों" की स्थापना की है जो लोगों का एक छोटा समूह है जो जटिल घटना प्रतिक्रिया में प्रशिक्षित हैं।

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

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

घटना कमांडर आमतौर पर वॉयस कम्युनिकेशन की एक सिंक्रोनस लाइन शुरू करेंगे, जैसे कि स्लैक हडल या गूगल मीट मीटिंग। यह सुनिश्चित करता है कि घटना के समाधान के लिए महत्वपूर्ण लोग लगातार संपर्क में हैं। यह आश्चर्यजनक है कि यह छोटी सी चीज लोगों को चैट का उपयोग करके चीजों को असिंक्रोनस रूप से हल करने की अनुमति देने की तुलना में कितनी प्रभावी है।

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

जैसा कि वे कहते हैं, यदि आप दो लोगों को घोड़े को खिलाने के लिए कहते हैं, तो घोड़ा मर जाता है। घटना कमांडर ऐसा होने से रोकता है और अंततः घटना के त्वरित समाधान के लिए जिम्मेदार होता है।

स्पष्ट रूप से और बार-बार संवाद करें

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

सुनिश्चित करें कि संचार आपके आंतरिक और बाहरी दोनों भागीदारों के लिए संक्षिप्त, लगातार और पारदर्शी हो क्योंकि इससे सद्भावना बनाने में मदद मिलेगी।

दोषरहित पोस्टमार्टम महत्वपूर्ण है

सीखने की संस्कृति बनाने के लिए पोस्टमार्टम या घटना के बाद की घटनाओं का पुनरावलोकन महत्वपूर्ण है, और उन्हें बिल्कुल दोषरहित होना चाहिए। प्रक्रिया की आलोचना करें, व्यक्ति की नहीं। कोई भी व्यक्ति खुद पर उतना कठोर नहीं होता जितना कि वह व्यक्ति जिसने ऐसा किया हो, और आपको सार्वजनिक रूप से उन्हें कोड़े मारने से कुछ हासिल नहीं होता। अगर कुछ भी हो, तो सभी शोध बताते हैं कि ऐसा करने से आप वास्तव में नुकसान उठाते हैं। Etsy के लोग इस बारे में बात करने में बहुत बेहतर हैं, इसलिए अगर आप और अधिक जानना चाहते हैं तो https://www.etsy.com/codeascraft/blameless-postmortems पढ़ें।

पोस्टमार्टम के बाद की कार्रवाई महत्वपूर्ण है

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

घटनाओं को होने से रोकना कठिन है, और आम तौर पर आपके व्यवसाय और ग्राहकों के साथ इस पर बातचीत करना कठिन होता है। लेकिन अगर एक ही घटना बार-बार होती है, तो इसका बचाव करना और भी कठिन हो जाता है और यह टीम के स्वास्थ्य और कौशल कौशल में गंभीर समस्या का संकेत देता है।

जब तक MTTD कम है, तब तक घटनाएं बुरी नहीं हैं

हर कोई इसे समझता है। यहां तक कि व्यवसायी भी इसे समझते हैं। सॉफ्टवेयर बनाना कठिन है, और ऐसी दुनिया में जहां हमारे सभी सॉफ्टवेयर में 100 से 1000 निर्भरताएं हैं, जहां दोष रेखाएं टूट सकती हैं, भविष्यवाणी करना असंभव है। मुसीबतें आएंगी, और यह ठीक है। हम घटनाओं को होने से नहीं रोक सकते। हालाँकि, जो वास्तव में मदद करता है वह यह सुनिश्चित करना है कि आपकी घटनाओं के लिए MTTD वास्तव में कम है।

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

हास्य आपको उस क्षण के दर्द से राहत देता है

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

इससे सौहार्द की भावना पैदा होती है, जिससे टीम को ऐसा महसूस होता है कि वे एक साथ हैं, न कि नरक के किसी द्वीप पर हैं।

यह लेख यहीं समाप्त होता है। पढ़ने के लिए धन्यवाद!

⭐ यदि आपको इस प्रकार की सामग्री पसंद है, तो मुझे फॉलो करना सुनिश्चित करें या https://a1engineering.substack.com/subscribe पर सदस्यता लें! ⭐

फ़ीचर फ़ोटो: जूलियन एल द्वारा अनस्प्लैश पर