एक Outage का सार्वजनिक Post Mortem

जीवन में कई चीजों के लिए एक आम तौर पर स्वीकृत “रूढ़िवादी” दृष्टिकोण और एक आम तौर पर स्वीकृत “जोखिम भरा” दृष्टिकोण होता है जिसे कम से कम लोकप्रिय भावना के अनुसार, टाला जाना चाहिए। निवेश में, उदाहरण के लिए, हम अक्सर सरकारी या नगरपालिका bonds खरीदने को कम जोखिम और equities (corporate stocks) में निवेश करने को उच्च जोखिम के रूप में देखते हैं – लेकिन सांख्यिकीय संख्याएँ हमें बताती हैं कि यह उल्टा है और लगभग सभी bonds पर पैसे गँवाते हैं और stocks पर कमाते हैं। आम “ज्ञान”, जब परखा जाता है, तो पूरी तरह से भावनाओं पर आधारित निकलता है, जो बदले में गलत धारणाओं पर आधारित होती हैं, और निवेश में सबसे जोखिम भरी बात निवेश रणनीतियों को चलाने के लिए भावनाओं का उपयोग करना है।

इसी तरह, business risk assessments के साथ, सामान्य दृष्टिकोण खतरे के प्रति भावनात्मक प्रतिक्रिया महसूस करना है और यह एक panic response को trigger करता है और लोगों की कथित जोखिम के लिए अत्यधिक क्षतिपूर्ति करने की प्रवृत्ति बनाता है। हम इसे आमतौर पर छोटी companies के साथ देखते हैं जिनका IT infrastructure बहुत कम revenue generate करता है या अल्पकालिक operations के लिए बहुत महत्वपूर्ण नहीं है, जो एक ऐसे जोखिम से बचाने के लिए बड़ी रकम खर्च करती हैं जो केवल आंशिक रूप से perceived है और बहुत खराब तरीके से articulated है। यह अक्सर इतना नाटकीय हो जाता है कि mitigation process को intellectual की बजाय emotional रूप से handle किया जाता है और हम नियमित रूप से companies को ऐसे bad system designs implement करते हुए पाते हैं जो वास्तव में जोखिम को कम करने के बजाय बढ़ाते हैं, जबकि बहुत बड़ी रकम खर्च करते हैं और फिर, चूंकि जोखिम अधिकांशतः काल्पनिक था, गलत धारणाओं की परत दर परत के आधार पर project को सफल कहते हैं: काल्पनिक जोखिम, काल्पनिक जोखिम शमन और काल्पनिक सफलता।

हाल के अतीत में मुझे एक small business के लिए एक पूर्ण आपदा में शामिल होने का अवसर मिला। आपदा लगभग “worst case scenario” तक पहुँच गई। बिल्कुल नहीं, लेकिन बहुत करीब। उस समय आपदा के प्रति emotional response तीव्र था और एक बार जब आपदा पूरी तरह से चल पड़ी तो लगभग हर कोई यह कहने और दोहराने लगा कि disaster planning में खामी थी और समस्या से बचा जाना चाहिए था। यह किसी भी disaster situation में बहुत सामान्य है, मनुष्य महसूस करते हैं कि हमेशा किसी को दोष देना होना चाहिए और यदि हम अपना काम सही से करें तो zero risk scenarios होने चाहिए, लेकिन यह पूरी तरह गलत है।

सौभाग्य से हमने एक पूर्ण post mortem किया, जैसा किसी भी वास्तविक disaster के बाद करना चाहिए, यह निर्धारित करने के लिए कि क्या गलत हुआ, क्या सही हुआ, हम उन processes और decisions को कैसे ठीक कर सकते थे जो विफल हो गए थे और हम उन्हें कैसे maintain कर सकते थे जिन्होंने हमारी रक्षा की थी। आम तौर पर, जब कोई बड़ा systems event होता है, तो मैं इसके बारे में publicly बात नहीं कर पाता। लेकिन कभी-कभी ऐसा होता है। किसी भी disaster पर react करना, किसी भी disaster पर, और सोचना “ओह, अगर हमने केवल....” बहुत सामान्य है। लेकिन आपको disaster की जांच करनी होगी। processes और स्वयं के बारे में जानने के लिए बहुत कुछ है।

पहले, कुछ पृष्ठभूमि। एक enterprise datacenter में चल रहा एक critical server कई companies के लिए महत्वपूर्ण कई key workloads को hold करता है। यह चार साल से थोड़ा अधिक पुराना है और कई वर्षों से isolation में चल रहा है। पुराने servers हमेशा थोड़े चिंताजनक होते हैं जब वे end of life के करीब पहुँचते हैं। चार साल enterprise class server के लिए end of life से बहुत दूर है लेकिन यह निश्चित रूप से young भी नहीं था।

यह बिना किसी failover mechanism के एक single server था। Backups को उसी datacenter में एक enterprise backup appliance पर externally handle किया जाता था। एक बहुत सरल system design।

मैं सभी आंतरिक विवरण शामिल नहीं करूँगा क्योंकि ऐसी किसी भी situation में planning और operation में कई जटिलताएँ होती हैं। वे एक internal post mortem process के लिए सबसे उपयुक्त हैं।

जब server fail हुआ, तो यह शानदार तरीके से fail हुआ। विफलता इतनी पूर्ण थी कि हम इसे remotely diagnose करने में असमर्थ थे, यहाँ तक कि datacenter में on site techs की सहायता से भी। यहाँ तक कि server vendor भी समस्या diagnose करने में असमर्थ था। इसने हमें एक कठिन स्थिति में छोड़ दिया – एक dead server से कैसे deal किया जाए जब hardware को विश्वसनीय रूप से ठीक नहीं किया जा सकता। हम drives बदल सकते थे, हम power supplies बदल सकते थे, हम motherboard बदल सकते थे। कौन जानता था कि क्या fix हो सकता है।

अंत में निर्णय यह था कि server के साथ-साथ backup system को भी main office वापस relocate किया जाए जहाँ उन्हें personally और अधिकतम resources के साथ triage किया जा सके। अंत में system को repair किया जा सका और कोई data नहीं खोया गया। Backup पर जाने से बचने का निर्णय इसलिए किया गया क्योंकि system availability से अधिक data recovery महत्वपूर्ण था।

जब सब कुछ हो गया तो disaster उन सबसे complete में से एक थी जिसकी कल्पना की जा सकती थी, बिना actual data loss के। Outage कई दिनों तक चली और बहुत सारे spare equipment, man hours और repair attempts का उपयोग किया गया। Process थका देने वाला था लेकिन जब पूरा हो गया तो system सफलतापूर्वक restore हो गया।

लंबे outage और chaos की भावना ने, जैसे-जैसे चीजें diagnose की गईं और repair attempts किए गए, failure की समग्र भावना उत्पन्न की। लोगों ने यह कहना शुरू किया और इससे लोग इसे believe करने लगे। Emergency response condition के तहत अत्यधिक emotional हो जाना बहुत आसान है, खासकर जब बहुत कम नींद होती है।

लेकिन जब हमने वापस कदम रखा और final outcome को देखा, तो जो हमें मिला उसने लगभग सभी को आश्चर्यचकित कर दिया: triage operation और initial risk planning सफल रहे थे।

एक triage के दौरान जो mayhem होता है वह अक्सर चीजों को उससे कहीं बदतर महसूस कराता है जितना वे वास्तव में हैं। लेकिन हमारी triage handling बेहतरीन रही थी। Triage का मतलब magic नहीं है और एक discovery phase और एक reaction phase होती है। जब हमने घटनाओं के क्रम का विश्लेषण किया और उन्हें एक time line में रखा तो हमने पाया कि हमने इतना अच्छा काम किया था कि लगभग कोई जगह नहीं थी जहाँ हम time frame को कम कर सकते थे। हमने अच्छे diagnostics किए थे, सही समय पर सही parties को engage किया था, जितनी जल्दी हो सके parts को logistical motion में लाया था और अधिकांश जो frenetic, wasted time लग रहा था वह वास्तव में “filler time” था जहाँ हम यह निर्धारित करने की कोशिश कर रहे थे कि additional options मौजूद हैं या mistakes हुई हैं जबकि हम repair के लिए needed parts का इंतजार कर रहे थे। इसने चीजों को उससे कहीं बदतर महसूस कराया जितना वे वास्तव में थीं, लेकिन यह सब actions का सही set था।

Triage और recovery के नज़रिए से, process बेदाग रही भले ही outage कई दिनों तक चली। एक बार जब disaster हो गई और उस अविश्वसनीय हद तक हो गई, recovery वास्तव में अविश्वसनीय रूप से smoothly चली। कुछ भी बिल्कुल perfect नहीं है, लेकिन यह बेहद अच्छी तरह से चला। Machine ने इरादे के अनुसार काम किया।

कहीं अधिक चौंकाने वाला हिस्सा disaster impact को देखना था। इसे देखने के दो तरीके हैं। एक समझदार है, “no hindsight” दृष्टिकोण। यहाँ हम disaster को देखते हैं, disaster का impact cost, mitigation cost और यह संभावना apply करते हैं कि disaster होती और निर्धारित करते हैं कि क्या सही planning decision किया गया था। इसकी गणना करना कठिन है क्योंकि risk factor हमेशा एक fudged number होता है, लेकिन आप आम तौर पर यह जानने के लिए पर्याप्त accurate हो सकते हैं कि आपकी planning कितनी अच्छी थी। दूसरा तरीका है 20/20 hindsight दृष्टिकोण – क्या होता यदि हम जानते कि यह disaster होने वाली है, हम इसे रोकने के लिए क्या करते? Risk factor को हटाना और disaster cost को raw numbers में देखना स्पष्ट रूप से पूरी तरह अनुचित है क्योंकि हम नहीं जान सकते कि क्या गलत होगा और केवल उसी एक संभावना के लिए plan करें या असीमित पैसा खर्च करें किसी ऐसी चीज़ के लिए जो हमें नहीं पता कि होगी या नहीं। Companies अक्सर बाद की गणना का उपयोग करने की गलती करती हैं और planners को perfect foresight न रखने के लिए blame करती हैं।

इस case में, हम काफी confident थे कि हमने शुरू से सही gamble किया था। System लगभग एक decade तक बिना किसी downtime के जगह पर था। Overall system cost कम था, triage cost मध्यम था और event बेहद unlikely था। Risk factor को ध्यान में रखते हुए कि हमने अच्छी planning की थी, यह आम तौर पर किसी को भी surprise नहीं करता था।

जो surprising था वह यह कि जब हमने risk factor के बिना calculations चलाई, तो यहाँ तक कि यदि हम जानते कि system fail होगा और extended outage होगी, तो भी हम वही decision करते! यह बिल्कुल shocking था। Extended outage की cost वास्तव में एक functional risk mitigation system बनाने के लिए आवश्यक equipment, hosting और labour की cost से कम थी – इस case में वह production में जो था उसके साथ datacenter में एक fully redundant server होना होता। वास्तव में, इस extended outage को accept करके cost savings लगभग दस हजार dollars था!

यह एक extreme case निकला जहाँ outage devastatingly bad था, predict करना कठिन था, जल्दी repair नहीं हो सका और फिर भी massive long term cost savings में परिणत हुआ, लेकिन यह एक महत्वपूर्ण सबक है। किसी भी disaster के साथ इतना emotional baggage आता है, यदि हम proper post mortem analysis नहीं करते और अपने decision making से emotional responses को हटाने का काम नहीं करते तो हम अक्सर large scale financial loss की ओर छलांग लगाएंगे या गलत तरीके से blame करेंगे, यहाँ तक कि जब चीजें अच्छी तरह से चली हों। कई companies इस disaster को देखकर उसी unlikely event को दोबारा होने से रोकने के लिए dramatically overspend करने की प्रतिक्रिया देतीं, भले ही उनके सामने math हो जो उन्हें बताती कि ऐसा करना पैसे बर्बाद करेगा, यहाँ तक कि अगर वह event दोबारा हो!

इस outage से सीखने के लिए और भी सबक थे। हमने सीखा कि communications कहाँ आदर्श नहीं थीं, सही लोग हमेशा सही decision making spot पर नहीं थे, customer communications वैसी नहीं थीं जैसी होनी चाहिए थीं, customer ने हमें परिवर्तनों के बारे में ठीक से सूचित नहीं किया था और बहुत कुछ। लेकिन बड़े पैमाने पर, सबक यह थे कि हमने सही planning की थी, और हमारा triage operation सही ढंग से काम किया था और हमने customer को कई हजार dollars बचाए थे जो उस चीज़ से अधिक लगती जो “conservative” दृष्टिकोण होती और एक अच्छा post mortem करके उन्हें और हमें एक अच्छे decision को बुरे में बदलने से overreact करने से रोका। Post mortem के बिना हम बहुत संभावना के साथ अपनी अच्छी processes को बदल देते, यह सोचकर कि वे बुरी थीं।

यहाँ जो takeaway lessons मैं आपको, पाठक को, बताना चाहता हूँ, वे यह हैं कि post mortems किसी भी disaster में एक critical step हैं, पारंपरिक रूढ़िवादी सोच अक्सर बहुत जोखिम भरी होती है और जोखिम के प्रति emotional reactions अक्सर technical disasters से भी बड़े financial disasters का कारण बनते हैं जिनसे वे बचाने की कोशिश करते हैं।