मैं आपको अपनी सबसे दर्दनाक उत्पादन घटनाओं में से एक पर वापस ले चलता हूं: हमारा एक मुख्य डेटास्टोर उस दौरान विफल हो गया जिसे हमने रखरखाव का एक सरल कार्य माना था।

उस समय हमारे सिस्टम में डेटास्टोर एक मुख्य घटक था, और विफलता का एक बिंदु बन गया। जबकि यह बंद है, हम किसी भी अनुरोध को संसाधित नहीं कर सके।

पूर्ण पुनर्प्राप्ति में कुछ घंटे लगने का अनुमान था, जो उस समय जीवन भर की तरह लग रहा था।

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

बहुत बढ़िया लग रहा है! वास्तव में घटना प्रतिक्रिया नियम पुस्तिका में पहला नियम - "रक्तस्राव बंद करो! सिस्टम को बैक अप लें ” । खैर - यह इतना आसान नहीं निकला, नियम पुस्तिका में नियम एक के कुछ अस्पष्ट निहितार्थ हैं जिन्हें हम उजागर करने वाले थे।

इस पोस्ट में मैं समझाऊंगा कि हालांकि "सिस्टम का बैकअप लेना" हमारी पहली प्राथमिकता होनी चाहिए, इसे सुरक्षित रूप से करना - हमें पहले "अप" का अर्थ बहुत सावधानी से परिभाषित करने की आवश्यकता है ।

घटना, और प्रतिक्रिया

मेरी कहानी पर वापस चक्कर लगाते हुए - हमारा सिस्टम विफल डेटास्टोर पर निर्भर एक माइक्रोसर्विस का उपयोग करके एक संदेश बस से संदेशों को संसाधित कर रहा था।

जब हमने इस मुद्दे की पहचान की तो सबसे पहले हमने अपने उन कर्मचारियों को कम किया, जिन्होंने हमारी एक संदेश बस से अनुरोध प्राप्त किया था।

ऐसा करने से हमने सिस्टम में शोर को सीमित कर दिया, और प्रभावित सेवाओं को इष्टतम पुनर्प्राप्ति प्रदर्शन की अनुमति दी। तो वर्तमान स्थिति यह है कि अनुरोध अब हमारे संदेश बस में कतारबद्ध थे, संसाधित होने की प्रतीक्षा कर रहे थे।

कॉन्फ़िगरेशन सेटिंग पर वापस चक्कर लगाते हुए - हम बहस कर रहे थे कि इसे टॉगल करना है या नहीं।

इसे टॉगल करने का मतलब है कि हम डेटास्टोर का उपयोग करके सिस्टम को बंद कर सकते हैं, इस प्रकार सिस्टम को "अनब्लॉक" कर सकते हैं - इसे वापस स्केल करें, और अनुरोधों के बैकलॉग (पहले से ही विशाल) को संसाधित करना शुरू करें। लेकिन असफल डेटास्टोर का उपयोग करने वाली माइक्रोसेवा एक कारण से थी! इसने हमारे सिस्टम में एक महत्वपूर्ण भूमिका निभाई — क्या हम इसके बिना वैध परिणाम प्रदान कर सकते हैं?

यह बहस करीब एक घंटे तक चली और इसमें संगठन के कई लोग शामिल हुए:

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

हम ठीक होने की प्रक्रिया समाप्त होने की प्रतीक्षा में वहीं बैठे रहे। हालांकि यह सही फैसला था, फिर भी यह एक भयानक अहसास था।

लब्बोलुआब यह है कि किसी घटना को कम करना "आसान" है जब शमन प्रक्रिया अंतर्निहित समस्या को ठीक करती है और सिस्टम को उसकी सही स्थिति में लौटाती है। लेकिन जब शमन प्रक्रिया आपके सिस्टम को एक अलग खराब स्थिति में डालती है , तो यह तय करना बहुत कठिन होता है कि शमन के इस रास्ते पर जाना है या नहीं।

एसएलआई पिरामिड

सबसे पहले, यह उल्लेख करना महत्वपूर्ण है कि जिस विधि का मैं प्रस्ताव करने जा रहा हूं वह हमेशा संभव नहीं होता है, और यह आपकी कंपनी के व्यावसायिक रुख के अलावा आपके पास मौजूद प्रणाली और व्यापार और प्रौद्योगिकी की आपकी समझ पर गहराई से निर्भर करता है।

जिस मुद्दे ने हमारे निर्णय को इतना कठिन बना दिया था, वह यह था कि " सिस्टम को वापस लाना " उस बिंदु पर अव्यावहारिक था, हम केवल दो अलग-अलग खराब राज्यों के बीच चयन कर सकते थे ।

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

इस पिरामिड का अर्थ यह है कि पिरामिड के शीर्ष में SLI का त्याग किया जा सकता है यदि इसका मतलब है कि हम पिरामिड के तल पर SLI को सुरक्षित कर सकते हैं - जब खराब अवस्थाओं के बीच चयन करने के लिए मजबूर किया जाता है, तो अब हमारे पास यह परिभाषित करने का एक तरीका है कि किसे प्राथमिकता दी जाए।

इसे अपने सिस्टम का मास्लो पिरामिड मानें ।

ऊपर दिए गए पिरामिड उदाहरण में, एक ऐसी स्थिति में आगे बढ़ने पर जहां दोनों मोबाइल प्लेटफॉर्म खराब स्थिति में हैं और हमारे पास डेटा गुणवत्ता का मुद्दा है - यदि मोबाइल प्लेटफॉर्म को बंद करके हम डेटा योग्यता समस्या को ठीक कर सकते हैं - हम अधिकृत हैं ( और अपेक्षित) इसे करने के लिए!

पिरामिड को उत्पाद स्वामी, व्यवसाय, और जो कोई भी इस तरह के एक महत्वपूर्ण निर्णय पर हस्ताक्षर कर सकता है, के साथ परिभाषित किया जाना चाहिए।

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

पिरामिड को 100% उपयोग के मामलों, घटनाओं और SLI को कवर करने की आवश्यकता नहीं है, लेकिन मुझे यकीन है कि आपके कुछ SLI इतने स्पष्ट हैं कि उन्हें आसानी से प्राथमिकता दी जा सकती है।

विश्लेषण पक्षाघात के बारे में एक शब्द

मेरी कहानी में, घटना प्रतिक्रिया टीम विश्लेषण पक्षाघात नामक एक स्थिति से पीड़ित थी - समस्या का अत्यधिक विश्लेषण करने के कारण निर्णय लेने में असमर्थ होना ।

इसमें हमें घंटों बहस करनी पड़ी, और विकल्पों और परिणामों को तौलना पड़ा, और तब भी कंपनी के कार्यकारी के रूप में आगे बढ़ने से हमें निर्णय लेने में मदद मिली।

इसमें होना काफी निराशाजनक परिदृश्य है — यह प्रतिक्रिया टीम के लिए निराशाजनक है जो पुनर्प्राप्ति प्रक्रिया के समाप्त होने की प्रतीक्षा में असहाय है, और रचनात्मक इंजीनियर के लिए निराशाजनक है जो एक वैकल्पिक शमन पथ के साथ आया है, क्योंकि हम इसके साथ प्रगति नहीं कर रहे हैं।

SLI पिरामिड सिस्टम के सबसे महत्वपूर्ण SLI का "पूर्व-विश्लेषण" करने की कोशिश करता है, और आउटेज के दौरान निर्णय लेने को थोड़ा आसान बनाता है

समापन विचार

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

यह पोस्ट मेरी बात पर आधारित है "द (आईआर) तर्कसंगत घटना प्रतिक्रिया: कैसे मनोवैज्ञानिक पूर्वाग्रह घटना प्रतिक्रिया को प्रभावित करते हैं" और अंग्रेजी और हिब्रू में उपलब्ध है ।

हमेशा की तरह, ट्विटर पर @cherkaskyb पर विचारों और टिप्पणियों का स्वागत है