एक घटना का एनाटॉमी, या डाउनटाइम को कम करने के लिए कैसे काम करना है

किसी भी परियोजना में जल्द या बाद में, यह आपकी सेवा की स्थिरता / उपलब्धता पर काम करने का समय है। कुछ सेवाओं के लिए, प्रारंभिक स्तर पर, विकासशील सुविधाओं की गति अधिक महत्वपूर्ण है, इस समय टीम पूरी तरह से नहीं बनती है, और प्रौद्योगिकियों को बहुत सावधानी से नहीं चुना जाता है। अन्य सेवाओं (अक्सर तकनीकी बी 2 बी) के लिए, ग्राहकों का विश्वास हासिल करने के लिए, पहले सार्वजनिक रिलीज के साथ उच्च अपटाइम की आवश्यकता होती है। लेकिन मान लीजिए कि वह पल जो अभी भी नहीं आया है और आपको इस बात की परवाह होने लगी है कि रिपोर्टिंग अवधि में आपकी सेवा "झूठ" में कितना समय लेती है। कटौती के तहत, मैं यह देखने का सुझाव देता हूं कि डाउनटाइम क्या है और इसे कम करने के लिए कैसे काम करना है।

संकेतक

जाहिर है, इससे पहले कि आप कुछ सुधारें, आपको वर्तमान स्थिति को समझने की आवश्यकता है। इसलिए, अगर हमने डाउनटाइम कम करना शुरू किया, तो यह सबसे पहले है और इसे मापने के लिए शुरू करना आवश्यक है।

हम यहां पर विस्तार से बात नहीं करेंगे कि यह विशेष रूप से कैसे करें, विभिन्न दृष्टिकोणों के पेशेवरों और विपक्षों, लेकिन थीसिस प्रक्रिया कुछ इस तरह दिखती है:

• हम निकट-व्यापार मीट्रिक (सेवा में त्रुटि, सेवा प्रतिक्रिया समय, $ / सेकंड, साइनअप / सेकंड, आदि) पर भरोसा करते हैं
• निर्धारित करें कि क्या अच्छा है और क्या बुरा है
• संक्रमण अच्छा-> बुरा एक घटना की शुरुआत है
• संक्रमण बुरा-> अच्छा - घटना का अंत
• शुरुआत से अंत तक का समय - घटना की अवधि (हमारे साथ टोपी)
• अवधि (माह / तिमाही / वर्ष) के लिए घटनाओं की अवधि का योग - डाउनटाइम
• (100 - <डाउनटाइम> / <अवधि अवधि> * 100) = अवधि के लिए उपलब्धता का प्रतिशत

अपटाइम / डाउनटाइम के बारे में बात करते समय, वे अक्सर एक और संकेतक का उल्लेख करते हैं:

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

इस बार हम कुछ भी औसत नहीं करेंगे, लेकिन बस देखें कि घटना के दौरान क्या होता है।

एक घटना का एनाटॉमी

आइए देखें कि घटना के दौरान क्या महत्वपूर्ण कदम उठाए जा सकते हैं:

• पता लगाना - पहली त्रुटि के बीच का अंतराल जो हमने परिचर को एसएमएस आने से पहले उपयोगकर्ता को दिया था
• प्रतिक्रिया - किसी समस्या के बारे में उस पल की सूचना प्राप्त करने से जब किसी व्यक्ति ने इस समस्या को हल करना शुरू कर दिया (आमतौर पर उस समय निगरानी घटना को स्वीकार किए गए राज्य में स्थानांतरित कर दिया जाता है)
• जांच - एक समस्या पर काम की शुरुआत से उस क्षण तक जब घटना का कारण समझा जाता है और हम जानते हैं कि काम को बहाल करने के लिए क्या करना होगा।
• उन्मूलन - वसूली का समय, उदाहरण के लिए, रोलबैक रिलीज, एक नया प्रचारित स्वामी प्राथमिक डेटाबेस सर्वर

शायद हमारा मॉडल अधूरा है और कुछ अन्य चरण हैं, लेकिन मैं उन्हें केवल यह महसूस करने के बाद पेश करने का प्रस्ताव करता हूं कि यह हमें अभ्यास में कैसे मदद करेगा। इस बीच, प्रत्येक चरण में अधिक विस्तार से विचार करें।

खोज

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

नतीजतन, त्रुटियों का स्तर (या अन्य मैट्रिक्स) जो दैनिक उतार-चढ़ाव से अधिक है, का उपयोग किसी घटना को खोलने के लिए एक मानदंड के रूप में किया जाता है। यह ठीक वही है जो इस तथ्य की ओर जाता है कि जिम्मेदार कर्मचारियों की अधिसूचना समस्या की वास्तविक शुरुआत की तुलना में बाद में होती है।

लेकिन हमारे मूल कार्य पर वापस - घटनाओं की अवधि को कम करना। हम पता लगाने के समय को छोटा कैसे कर सकते हैं? सूचित करने के लिए तेज़? विसंगतियों का पता लगाने के लिए एक सुपर तर्क के साथ आ रहा है?

मैं अभी तक कुछ भी नहीं करने का सुझाव देता हूं, लेकिन अगले चरणों को देखने के लिए, क्योंकि वास्तव में वे परस्पर जुड़े हुए हैं।

प्रतिक्रिया

यहां हमारा विशुद्ध रूप से मानवीय कारक है। हम मानते हैं कि निगरानी समस्या का पता लगाने में कामयाब रही और हमने सफलतापूर्वक इंजीनियर को ड्यूटी पर जगा दिया (पूरे विस्तार ने पिछले चरण में भी काम किया)।

"सबसे खराब" मामले पर विचार करें, हमारे पास एक समर्पित कर्तव्य सेवा नहीं है, और चेतावनी ने शांति से सोए हुए व्यवस्थापक को पकड़ लिया। उनके कार्य:

• एसएमएस का जवाब: यहां संवेदनशील कान वाली पत्नी बहुत मदद करती है, फोन के लिए विभिन्न एप्लिकेशन, एसएमएस प्राप्त करने के प्रभाव को बढ़ाते हैं (1-5%)
• एक निर्णय लें कि वह अभी भी बिस्तर से बाहर क्रॉल करेगा: यदि अलर्ट सही तरीके से सेट नहीं किए गए हैं, तो एक व्यक्ति 2 मिनट इंतजार कर सकता है "यदि समाधान आता है तो क्या होगा?" और सो जाओ (1-15 मिनट)
• लैपटॉप पर जाएं, अपनी आँखें खोलें, जागें, निगरानी करें, Ack दबाएं: (1-15 मिनट)

नतीजतन, सबसे खराब स्थिति में, हमें 35 मिनट की प्रतिक्रिया मिलती है। मेरी टिप्पणियों के अनुसार, ऐसी प्रतिक्रिया का समय सही प्रतीत होता है।

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

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

• 5 मिनट से पहचान का समय बढ़ाएँ
• घटनाओं की संख्या कम हो जाती है: आम तौर पर 1 मिनट के भीतर त्रुटियों के सभी छोटे फटने लगते हैं। इन छोटी घटनाओं को दर्ज किया जाना चाहिए, लेकिन लोगों को सूचित किए बिना। अक्सर, वे कुल में एक बहुत बड़ा डाउनटाइम देते हैं, लेकिन आप व्यवसाय के घंटों के दौरान उनसे निपट सकते हैं। इस कार्य के लिए, आपको निगरानी में उच्च ग्रैन्युलैरिटी की आवश्यकता होगी, क्योंकि समस्या पहले ही समाप्त हो चुकी है, और अधिकांश भाग के लिए नैदानिक ​​उपकरण इतिहास नहीं रखते हैं।
• यदि किसी व्यक्ति को महीने में एक बार या उससे कम बार अलर्ट का जवाब देने के लिए मजबूर किया जाता है, और हर दूसरे दिन नहीं, तो वह इसे और अधिक पर्याप्त रूप से जवाब देगा और इसे दिनचर्या नहीं मानता है।
• विलंबित अधिसूचना किसी व्यक्ति को सोचने की अनुमति नहीं देती है: यदि कोई एसएमएस आता है, तो सब कुछ गंभीर है और इसे स्वयं ठीक नहीं किया जाएगा

संभावित रूप से, यह दृष्टिकोण कुल प्रतिक्रिया समय को 15+ मिनट तक कम कर देगा। यदि इस तरह की प्रतिक्रिया का समय आपको सूट नहीं करता है, तो आपको कर्तव्य सेवा के बारे में सोचना चाहिए।

जांच

शायद यह एक दुर्घटना का सबसे कठिन चरण है जब आपको यह समझने की आवश्यकता होती है कि क्या हो रहा है और क्या करना है। वास्तविकता में, इस चरण को अक्सर उपाय करने के चरण के साथ जोड़ा जाता है, क्योंकि आमतौर पर यह प्रक्रिया इस प्रकार होती है:

• हम निगरानी, ​​लॉग को देखते हैं (यदि निगरानी पर्याप्त नहीं है), हम कुछ अन्य नैदानिक ​​उपकरण लॉन्च करते हैं
• परिकल्पना को आगे बढ़ाया
• हम परिकल्पना का परीक्षण या तो मेट्रिक्स द्वारा करते हैं, या कुछ क्रिया करके (सब कुछ पुनः आरंभ करते हैं :)
• परिवर्तनों के परिणामों का मूल्यांकन करें
• यदि किसी विशेष उप-प्रणाली का आपका ज्ञान पर्याप्त नहीं है, तो सहकर्मियों के साथ संवाद करें
  और इसी तरह प्रबुद्धता या घटना के अंत तक।

यह चरण आमतौर पर घटना की कुल अवधि में सबसे महत्वपूर्ण है। इसे कैसे कम करें?
यहां सब कुछ बहुत स्पष्ट नहीं है, कई वैक्टर हैं:

• अपने इन्फ्रास्ट्रक्चर को सरल बनाएं : कल्पना करें कि एक डेटाबेस और एक सेवा क्रैश वाले लोग कितनी जल्दी हैं
• एक टीम में ज्ञान का प्रसार : आदर्श यदि लोगों का संचार घटना के दौरान नहीं होता है, लेकिन दैनिक कार्य के दौरान (लोगों का संचार आमतौर पर एक बहुत लंबी प्रक्रिया है)
• निगरानी : कई लोग सोचते हैं कि निगरानी केवल "डिटेक्शन" चरण में काम करती है, लेकिन वास्तव में यह परिकल्पना परीक्षण प्रक्रिया के अनुकूलन के रूप में कार्य कर सकती है ("डेटाबेस ठीक से काम करता है?", "क्या मेरी सेवा संसाधनों में चलती है?") और परिवहन के रूप में भी। एक टीम में ज्ञान का प्रसार। "सर्ज, जाँच करें कि क्या एक्स में त्रुटियाँ हैं गतिरोध के बारे में?" एक ट्रिगर में बदल दिया जा सकता है, जिसमें से विवरण निर्देश के साथ विकी का लिंक होगा ।

उन्मूलन

जैसा कि मैंने ऊपर कहा, यह चरण अक्सर पिछले एक के साथ विलीन हो जाता है। लेकिन ऐसा होता है कि कारण तुरंत स्पष्ट है, लेकिन वसूली बहुत लंबी होगी। उदाहरण के लिए, आपके पास एक सर्वर मृत है स्वामी प्राथमिक (मैं लंबे समय तक इसका उपयोग करने में सक्षम नहीं होगा :) एक डेटाबेस के साथ, और आपने कभी भी एक प्रतिकृति को बढ़ावा नहीं दिया, अर्थात, आप दस्तावेज़ पढ़ेंगे, एक नया एप्लिकेशन कॉन्फ़िगरेशन रोल आउट करेंगे, आदि।

स्वाभाविक रूप से, प्रत्येक महत्वपूर्ण घटना के बाद, आपको यह पता लगाने की आवश्यकता है कि इसे फिर से होने से कैसे रोका जाए या वसूली में बहुत तेजी लाई जाए। लेकिन देखते हैं कि हम किन दिशाओं में लगातार काम करने की कोशिश कर सकते हैं:

• अवसंरचना प्रबंधन उपकरण : यदि आपको एक नया कॉन्फ़िगरेशन रोल करने की आवश्यकता है, तो सब कुछ ठीक करने के लिए, लेकिन यह कम से कम 20 मिनट में किया जाता है - यह आपकी सीमा है। क्या हो सकता है के परिदृश्यों के साथ आने की कोशिश करें और कुछ प्रक्रियाओं को तत्काल तेज करने का एक तरीका है। उदाहरण के लिए, अनुदैर्ध्य में आपने धारावाहिक (कार्य निष्पादन समानता) = 3 निर्धारित किया है, लेकिन यदि आप अभी भी झूठ बोलते हैं, तो आप धारावाहिक = 30 के साथ रोल कर सकते हैं, आपको हर किसी को इसे फिर से परिभाषित करने के लिए सिखाने की आवश्यकता है (इसी तरह कुबेटी में रोलिंग अपडेट रणनीति)।
• अभ्यास : यदि आप जानते हैं कि विफलता के संभावित परिदृश्य और पुनर्प्राप्ति स्वचालित नहीं है, तो आपके पास ऐसे निर्देश होने चाहिए जिनका परीक्षण किया जाना चाहिए । डाउनटाइम की योजना बनाएं (यदि आवश्यक हो), अभ्यास करें। अक्सर, इस स्तर पर, ऐसे मामलों को स्वचालित किया जाता है, क्योंकि अभ्यास के दौरान पहली नज़र में भी सबसे जटिल प्रक्रियाओं के नुकसान को स्पष्ट किया जाता है।
• ठेकेदारों के साथ बातचीत : आपको पहले से पता होना चाहिए कि यदि आपका होस्टिंग प्रदाता बीमार हो जाता है तो आप क्या करेंगे। अक्सर, किसी समस्या की संभावना और जोखिम बंद होने की लागत के बारे में जागरूकता से निष्कर्ष निकलता है - "हम अभी ठीक होने की प्रतीक्षा कर रहे हैं।" लेकिन दूसरी तरफ, इंजीनियर और व्यवसाय इस तरह के परिदृश्य के लिए तैयार होंगे। उदाहरण के लिए, आप अपने ट्रैफ़िक को पूर्व-तैयार स्टब पर स्विच करने के मुद्दे के माध्यम से काम कर सकते हैं, पूर्व-तैयार पत्र के साथ उपयोगकर्ताओं को सूचित कर सकते हैं, आदि। या इसके विपरीत, आप एक निर्देश बनाते हैं जिसके अनुसार हम होस्टर को पुनर्प्राप्त करने के लिए 30 मिनट का समय देते हैं, और फिर हम दूसरे डीसी में जाना शुरू करते हैं, जहां पहले से ही डेटाबेस की प्रतिकृति है, लेकिन आपको बाकी सब का विस्तार करने की आवश्यकता है। और यहाँ फिर से, शिक्षाओं, हम आगे बढ़ने का समय नोट करते हैं, आदि।

MTBF (विफलताओं के बीच का समय)

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

यहाँ इस सवाल का सबसे आगे आता है कि आपने अपनी सेवा के दोष सहिष्णुता का कितना ध्यान रखा है:

• क्या बुनियादी ढांचे में विफलता (SPOF) के एकल बिंदु हैं, विफलता की संभावना क्या है?
• आप कितने आश्वस्त हैं कि कोई SPOF नहीं है जिसके बारे में आप नहीं जानते हैं? (यह वास्तव में समस्या है कि अराजकता बंदर हल करती है)
• क्या लोड बैलेंसर्स अच्छी तरह से काम कर रहे हैं? ( संतुलन पर मेरी रिपोर्ट )
• नेटवर्क कितना लचीला है?
• डेटा सेंटर कितना विश्वसनीय है?

कभी-कभी, इन सभी की गणना / भविष्यवाणी करने के लिए, वे एक "जोखिम मानचित्र" बनाते हैं, जहां प्रत्येक परिदृश्य (जिसे हम मान सकते थे, निश्चित रूप से हमेशा ऐसे होते हैं जिन्हें हम अभी तक नहीं जानते हैं) एक संभावना + प्रभाव (कम / लंबे समय तक, डेटा हानि, प्रतिष्ठा हानि) है आदि)। फिर, वे व्यवस्थित रूप से इस तरह के एक कार्ड पर काम करते हैं, जो प्रभाव के मामले में सबसे अधिक संभावित और गंभीर परिदृश्यों में से सबसे पहले बंद करते हैं।

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

• मानवीय त्रुटियां : उत्पादन में मैन्युअल क्रियाओं की संख्या को कम करना, ऑपरेटर त्रुटियों के खिलाफ विभिन्न सुरक्षा
• असफल रिलीज़ : यह परीक्षण में सुधार के लायक है (लोड परीक्षण सहित)
• आवेदन त्रुटियों : मरम्मत लीक, दुर्घटनाओं और अन्य जमा देता है
• नेटवर्क : उपकरण खरीदें, सेट अप करें, नेटवर्क किराए पर लें, ठेकेदार बदलें
• डेटाबेस : एक DBA को किराए पर लें, दोष सहिष्णुता का ख्याल रखें, बेहतर हार्डवेयर खरीदें
• डीसी : बैकअप या स्थानांतरण के बारे में सोचें
• बाहरी प्रभाव (ddos, ब्लॉकिंग, सर्टिफिकेट रिव्यू, डोमेन): एंटीडोस खरीदें, प्रॉक्सी पर स्टॉक करें, डोमेन / सर्टिफिकेट की वैधता की निगरानी करें, अलग-अलग CA से कई सर्टिफिकेट हों।

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

कुल मिलाकर

सभी घटनाएं अलग हैं:

अपटाइम बढ़ाने के लिए काम करने के लिए एल्गोरिदम किसी भी अन्य अनुकूलन के समान है:

 ->  ->   ->   

मैं अपने स्वयं के अनुभव से कह सकता हूं कि अपटाइम में एक महत्वपूर्ण सुधार के लिए बस इसका पालन करना और घटनाओं के कारणों का विश्लेषण करना पर्याप्त है। यह आमतौर पर होता है कि सबसे सरल परिवर्तन सबसे महत्वपूर्ण प्रभाव लाते हैं।

हमारी निगरानी सेवा न केवल "डिटेक्शन" चरण के साथ मदद करती है, बल्कि "जांच" को भी कम करती है (ग्राहक पुष्टि करेंगे)