दुर्घटनाएं आपको सीखने में मदद करती हैं

पिछले 3 वर्षों में, कंटूर में अलग-अलग डिग्री की एक हजार से अधिक घटनाएं हुईं। कारण अलग-अलग हैं: उदाहरण के लिए, 36% खराब-गुणवत्ता के रिलीज के कारण होता है, और 14% - डेटा सेंटर में लोहे के रखरखाव के कारण होता है। आँकड़े कहाँ से आते हैं? प्रत्येक घटना के बाद, एक रिपोर्ट लिखी जाती है - पोस्टमार्टम। वे ड्यूटी इंजीनियरों द्वारा लिखे गए हैं जिन्होंने दुर्घटना की सूचना पर प्रतिक्रिया दी और इसके कारणों को समझने वाले पहले व्यक्ति थे। पोस्टमार्टम का विश्लेषण, पहचान और घटनाओं के कारणों को समाप्त किया जाता है, ताकि भविष्य में ऐसी घटनाएं न घटें। लेकिन हमेशा ऐसा नहीं था।

एलेक्सी किरपिचनिकोव ( बीवी ) 2008 से यांडेक्स में प्रोग्रामिंग कर रहे हैं। ट्रैफिक जाम, खेल विशेष परियोजनाओं पर काम करता है, यह Yandex.Taxi बैकएंड की एक टीम का नेतृत्व था। 2014 के बाद से, वह कोंटूर में DevOps और बुनियादी ढांचे में लगे हुए हैं - वे ऐसे उपकरण विकसित कर रहे हैं जो उत्पाद टीमों के डेवलपर्स के लिए जीवन को आसान बनाते हैं। पोस्टमार्टम विषयों को लिखने और विश्लेषण करने का विचार पांच साल पहले आया था, और इस समय के दौरान पोस्टमार्टम विषय टेम्प्लेट, एक शब्दकोष, मेमो, स्क्रीनशॉट और एनालिटिक्स के साथ उग आए थे। लेकिन यह सबसे मुश्किल नहीं है - इंजीनियरों के लिए घटना की रिपोर्ट के अर्थ की जड़ता, भय और गलतफहमी को दूर करना अधिक कठिन था । अंततः क्या हुआ और "सोफा एनालिटिक्स" क्या अपूरणीय लाभ दे सकता है, एलेक्सी की रिपोर्ट को डिक्रिप्ट करने में है।


कृपया ध्यान दें - विभिन्न लंबाई के टेबल के नीचे "मेट्रिक्स", "टेस्ट" और "डिप्लॉय" किताबें हैं।


कांटूर में, काम पर रखने के बाद, वे स्मृति चिन्ह का एक सेट देते हैं: एक कलम, एक मग, एक नोटबुक। मैं 5 साल पहले एक नई बुनियादी ढाँचे की टीम में एसकेबी कोंटोर आया था, जब कंपनी 25 साल की हो गई।



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

उस समय, मैंने पहली बार "प्रोजेक्ट '' फीनिक्स 'पढ़ा" और देवओप्स-प्रथाओं के नए-नए विचारों से प्रेरित था। मैंने एक नोटबुक में सुधार के लिए अपने विचारों को लिखना शुरू किया, और अब यह कॉफी के दाग और ऐतिहासिक रिकॉर्ड के साथ एक कलाकृति है।

• “ निगरानी! चलिए ग्राफ्ना डालते हैं, मेट्रिक्स इकट्ठा करते हैं और ग्राफ बनाते हैं। हम बेहतर समझते हैं कि उत्पादन में क्या हो रहा है। ” 2014 के लिए, यह एक बिल्कुल नया, नया विचार और ठोस DevOps अभ्यास है। ”
• " ऑटो दुर्घटनाग्रस्त!" साझा फ़ोल्डर में कितनी ज़िप-फाइलें अपलोड की जा सकती हैं, उन्हें सर्वर पर अनज़िप करें और विंडोज में टास्क-शेड्यूलर में exe चलाएं? "चलो एक औद्योगिक परिनियोजन प्रणाली शुरू करते हैं और इसके माध्यम से रिलीज जारी करते हैं, CI!"
• “ पोस्टमार्टम ! यदि उत्पादन में किसी प्रकार की दुर्घटना होती है, तो आइए जानें कि यह क्या था, इसका कारण जानें, एक रिपोर्ट लिखें और हमारे विकास, परीक्षण, सीआई प्रक्रियाओं को बदलें ताकि भविष्य में ऐसी कोई घटना न हो।

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

मैं आपको बताऊंगा कि हमने पोस्टमार्टम सिस्टम कैसे लागू किया और हमें क्या लाभ मिले। शायद हमारा रेक इस तरह से तेज़ी से जाने और कम शंकु को भरने में मदद करेगा। पोस्टमार्टम के बारे में बात करने से पहले हम परिभाषा को समझेंगे।

एक घटना क्या है?

इनमें से कौन सी घटना है?

• उदाहरण संख्या १। एक लाख उपयोगकर्ताओं के साथ एक ब्लॉग मंच पर, किसी प्रकार की त्रुटि के परिणामस्वरूप, एक उपयोगकर्ता की सभी प्रविष्टियां खो जाती हैं।
• उदाहरण संख्या 2। कार्यालय कर्मचारियों के लिए सेवा सप्ताह के दिनों में 9 से 6 बजे तक काम करती है, और अन्य समय में इसमें कोई उपयोगकर्ता नहीं होते हैं। लगातार दो घंटे शनिवार से रविवार की रात तक यह सेवा अनुपलब्ध थी, किसी ने गौर नहीं किया।
• उदाहरण संख्या 3। प्रोडक्शन मेट्रिक्स वाला ग्राफाना 15 मिनट गिर गया। उत्पादन में, कुछ भी नहीं टूटा, लेकिन ग्राफिक्स उपलब्ध नहीं थे।

यह समझने के लिए कि इस फेकैपी के बारे में, हम गुरुओं के अनुभव की ओर मुड़ते हैं - Google, Atlassian, PagerDuty। गुरुओं को पता है कि कैसे शिफ्ट तैयार करना है, ऑन-कॉल इंजीनियरों और उन्हें समझने के लिए रिपोर्ट कैसे लिखना है। उनके ऑनलाइन गाइड में घटना की परिभाषा है।

पेजडूट से परिभाषा ।

एक घटना किसी भी सेवा के अनियोजित सेवा में व्यवधान या गिरावट है जो उपयोगकर्ताओं को सेवा की उपलब्धता को प्रभावित करती है। एक गंभीर घटना वह है जिसमें कई टीमों से समन्वित प्रतिक्रिया की आवश्यकता होती है।

तार्किक लगता है, लेकिन परिभाषा अस्पष्ट है। व्यवहार में, यह समझने में थोड़ा मदद करता है कि एक घटना क्या है और क्या नहीं है।

Google की साइट विश्वसनीयता इंजीनियरिंग पुस्तक में स्पष्ट मापदंड हैं:

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

कंटूर में एक फकैप की प्रकाशित परिभाषा नहीं है, लेकिन हमने एक घटना का गठन करने के लिए अपने स्वयं के मानदंड तैयार किए हैं।

बाहरी या आंतरिक उपयोगकर्ताओं ने सेवा में गिरावट देखी है । उदाहरण संख्या 3, ग्राफाना के साथ, जो कि एक स्पष्ट घटना है। उत्पादन नहीं टूटा और बाहरी उपयोगकर्ताओं ने इस पर ध्यान नहीं दिया, लेकिन इसके बावजूद, कंटूर के लिए यह एक फकैप है, क्योंकि आंतरिक उपकरण काम नहीं करते थे।

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

घटना कई टीमों को चिंतित करती है । हम इस परिभाषा को PagerDuty से लेते हैं। एक घटना को पार्स करना कई टीमों के एक साथ काम करने का एक अच्छा कारण है। संस्कृति "हमारे हिस्से पर, गोली निकल गई, लेकिन आपके लिए कुछ टूट गया - यह आपकी गलती है" एक संयुक्त विश्लेषण द्वारा मिटा दिया गया है।

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

परिभाषा और विभिन्न प्रकार की क्षति के साथ। आइए जानें कि घटनाओं से कैसे लाभान्वित हों।

फकप का उपयोग क्या है?

सरल निर्देश जो मैं आगे दूंगा, आप स्वयं के लिए आवेदन कर सकते हैं, वह भी बिना लेख के अंत तक। लेकिन फिर भी अंत तक पढ़ें।

क्लासिक निर्देश

पहले दोषियों का पता लगाएं। फिर इंजीनियरों के साथ "शैक्षिक" काम करते हैं।

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

यदि निर्देश आपको गुस्सा दिलाता है, तो यह अच्छी खबर है।

इस दृष्टिकोण को एक बॉस के साथ शास्त्रीय लंबवत उन्मुख निगमों के लिए पारंपरिक माना जाता है जो हर किसी को डांटता है और उसे आग लगा सकता है। DevOps आंदोलन और DevOps विचारधारा की नींव में से एक है कर्मचारियों में अधिक विश्वास के साथ लंबवत एकीकृत संगठनों से क्षैतिज वाले तक प्रस्थान।

मैं इस प्रतिमान को जॉन ऑलसॉ के निर्देश के साथ चित्रित करूंगा, जो कि देवता आंदोलन के नेताओं में से एक है, जिन्होंने पहले एट्टी में सीटीओ के लिए काम किया था। निर्देश उनके विहित 2013 लेख, ब्लेमलेस पोस्ट मॉर्टम और एक जस्ट कल्चर से लिया गया है।

इंजीनियरों से पूछें:

• उन्होंने क्या घटनाएँ देखीं;
• कब और क्या कार्रवाई की गई;
• इन कार्यों से क्या परिणाम की उम्मीद थी;
• क्या धारणाएं आईं;
• जैसा कि घटित हुई घटनाओं के क्रम से समझा जाता है।

इंजीनियरों को सजा की धमकी के बिना पूछे जाने की आवश्यकता है।

जॉन की सिफारिश में यह मुख्य बात है।

सजा का खतरा: फिर से पकड़ना, उत्पादन या बर्खास्तगी से उन्मूलन, लोगों को झूठ बोलने के लिए प्रेरित करता है। और सत्य हमारे लिए महत्वपूर्ण है। घटना की रिपोर्ट - यह उत्पादन में सुविधाओं को विकसित करने और डालने की प्रक्रिया में बहुत ही गायब प्रतिक्रिया लिंक है।

पुराने प्रतिमान में, डेवलपर्स ने विकास किया, शिल्प को ऑपरेशन इंजीनियरों के लिए बाड़ पर फेंक दिया, और वे किसी तरह इसे काम करने की कोशिश करते हैं। वे किसी भी अपडेट से नाराज हैं, क्योंकि यह सब कुछ तोड़ सकता है, और इंजीनियरों ने इस तरह की कठिनाई के साथ यह सब शुरू किया।

प्रतिक्रिया प्रक्रिया प्रक्रिया, बुनियादी ढांचे, उपकरण और विकास के दृष्टिकोण को बदलने में मदद करती है ताकि उत्पादन में कम दुर्घटनाएं हों।

यह टीम के नेताओं और विकास प्रबंधकों को पोस्टमार्टम की उपयोगिता के बारे में बताएगा। लेकिन पकड़ यह है कि इंजीनियरों को ऐसा करना मुश्किल है जो वे सोचते हैं कि बेकार और बेकार है। हमारी कंपनी में एक इंजीनियरिंग संस्कृति है, और मैं बस नहीं आ सकता, सीईओ के फरमान को लहराना और मांग करना कि सभी लोग पोस्टमार्टम लिखें। मुझे इसके इंजीनियरों को समझाने की जरूरत है।



इंजीनियरों को पोस्टमार्टम इंजीनियरों के विचार को "कैसे" बेचना है? आपत्तियों के चारों ओर पाने के लिए, यह दिखाने के लिए कि पोस्टमार्टम क्यों शांत है, रिपोर्टों के लाभ को प्रदर्शित करने के लिए, कि यह केवल एक सदस्यता समाप्त नहीं है, यदि केवल मालिक पीछे है।

आपत्ति संख्या 1: एक बार

यह इंजीनियर की पहली समस्या है जो फकप को मिटा देता है - युद्ध समाप्त हो जाएगा, फिर हम बात करेंगे! जब एक फेकैप होता है, तो मैं इसे जल्दी से ठीक करना चाहता हूं, लेकिन मैं समझ से बाहर की बोरिंग और लंबी रिपोर्ट नहीं लिखना चाहता।

समस्या को हल करने के लिए, एक जीवन हैक है, कैसे एक दुर्घटना के दौरान कुछ सही लिखने के लिए। उन्हें आर्टेम लेबेदेव द्वारा लोकप्रिय बनाया गया था:

“समय को व्यवस्थित करने का एक सरल तरीका है -“ प्रगतिशील जीपिंग ”विधि। किसी भी समय, कोई भी परियोजना 100% तैयार है, हालांकि यह 4% अधिक विकसित हो सकती है। उपलब्ध समय के आधार पर, परियोजना को एक पिक्सेल तक पूरा किया जा सकता है, या इसे वैचारिक स्केचिंग चरण में छोड़ा जा सकता है। ”

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



आग के दौरान, आपको एक शांत और लंबी रिपोर्ट लिखने की आवश्यकता नहीं है। ऊपरी बाएँ कोने में यह आपके लिए पर्याप्त है। यह उन चीजों को चिह्नित करने के लिए पर्याप्त है जो स्मृति से पुनर्प्राप्त करना मुश्किल होगा। एक ऐसे समय में एक सुसंगत साहित्यिक पाठ लिखने की कोशिश न करें जब उत्पादन पर सब कुछ टूट गया हो।

एक सरल क्रिया करें - घटनाओं के कालक्रम को लिखें।

घटनाओं के कालक्रम

समय को बहाल करना बहुत मुश्किल है, अगर तुरंत दर्ज नहीं किया गया है। सर्किट में एक वास्तविक पोस्टमार्टम से रिकॉर्डिंग का एक उदाहरण।

15.01.18 17:25 YEKT    PrefixSearch  50   . ,     . 

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

स्क्रीनशॉट

एक आसान बात, खासकर जब एक वेबसाइट या डेस्कटॉप एप्लिकेशन के साथ काम करना। स्थिति को कभी-कभी शब्दों में वर्णित करना मुश्किल होता है, और एक स्क्रीनशॉट एक गर्म कुंजी का सिर्फ एक क्लिक होता है।



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

आपत्ति संख्या 2: आलस्य

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

पूरी तरह से हारने के लिए समस्या से काम नहीं चलेगा। लेकिन आप पहले से अपने काम को सुविधाजनक बना सकते हैं।

टेम्पलेट

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

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

उदाहरणों के साथ एक मेमो बनाएँ

हमारे टेम्पलेट में उप-अनुभागों के साथ एक "नुकसान" अनुभाग है।

अनुभाग "गुणात्मक मूल्यांकन"। यह बताता है कि जब वह टेम्पलेट के इस हिस्से को भरता है तो इंजीनियर उसके सामने क्या देखता है:

• क्या कार्यक्षमता काम नहीं करती थी, कब तक और किसके लिए;
• चाहे डेटा का नुकसान हो या भ्रष्टाचार का।

टेम्पलेट में इस स्थान पर पहुंचने के बाद, इंजीनियर लिखते हैं: "हमारे ब्लॉग प्लेटफ़ॉर्म में एक मिलियन उपयोगकर्ता हैं, हमने उनमें से एक की सभी प्रविष्टियाँ खो दी हैं।" यह एक खरोंच से निबंध लिखने की तुलना में बहुत आसान है, जैसा कि एक साहित्य पाठ में।

अनुभाग "परिमाणीकरण":

• कितने अनुरोध गायब हो गए हैं;
• एप्लिकेशन और क्लाइंट एप्लिकेशन मैट्रिक्स में कितनी विलंबता बढ़ी है;
• कितनी पुकार खो जाती है;
• समस्या के लिए उपयोगकर्ता तकनीकी सहायता के लिए कतार का आकार।

इस तरह के सवालों का एक सेट पैटर्न है।

पूरा किए गए टेम्प्लेट में से एक का एक उदाहरण।

एक शब्दकोष जोड़ें

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

रिपोर्ट में प्रयुक्त सभी शब्दों का वर्णन करते हुए एक छोटी शब्दावली लिखिए।

सभी कलाकृतियों को कॉपी करें

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

कलाकृतियों को कॉपी करें - यह जीवन हैक रिपोर्ट को भरना आसान बनाता है।

आपत्ति संख्या 3: कोई भी नहीं पढ़ेगा

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

पोस्टमार्टम विकास प्रक्रियाओं के निरंतर सुधार की प्रक्रिया में एक प्रतिक्रिया है।

किसी भी गुरु पुस्तक में, उदाहरण के लिए, एटलसियन हादसा पुस्तिका में , यह लिखा है कि प्रत्येक पोस्टमार्टम के परिणामों के अनुसार, यह आवश्यक है:

• विकास में कार्यों को तैयार करना;
• बगट्रैकर में कार्य बनाएं जिससे आपके डेवलपर्स उन्हें ले जाएंगे;
• पोस्टमार्टम से लेकर इन कार्यों तक के लिंक दिए।

प्रतिक्रिया बंद है : यहां एक पोस्टमार्टम किया गया है, यहां इसमें एक्शन आइटम - कार्यों को पूरा करने की आवश्यकता है ताकि दुर्घटना फिर से न हो। कार्य टीम के बैकलॉग में आते हैं, टीम उन्हें विकसित करती है, रोल आउट करती है - फिर से फकैप और पोस्टमार्टम। संसार का पहिया बंद हो गया है।

इसी पर सभी गुरु जुटे। बहस करने के लिए कुछ भी नहीं है - लाभ स्पष्ट हैं।

वास्तविक पोस्टमार्टम से एक्शन आइटम कार्यों का एक उदाहरण।



लेकिन हमने कोंतूर में एक विश्लेषक को इसमें जोड़ा।

सोफा एनालिटिक्स

हम अलगाव में घटना का विश्लेषण करते थे। विफलता एक ही टीम में, एक होस्टिंग सिस्टम में हुई - कुछ टूट गया, हमने इसे ठीक कर दिया।

लेकिन कई घटनाएं हैं। पिछले तीन वर्षों में, 1,000 से अधिक घटना रिपोर्ट सर्किट में जमा हुई हैं। मैं जानना चाहूंगा कि क्या संचित रिपोर्टों के संपूर्ण द्रव्यमान से लाभ उठाना संभव है, न कि प्रत्येक व्यक्तिगत रूप से। क्या सिस्टम के आंकड़ों की गणना करना और समग्र रूप से प्रणाली में क्या सुधार करना है, यह देखना उनके आधार पर संभव है।

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

सोफे एनालिटिक्स में हम क्या विश्लेषण करते हैं?

फकप अवधि

आरेख में, अंतिम कॉलम के अलावा, जहां समय अज्ञात है, दो और अधिक स्पष्ट चोटियां हैं।

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

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

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

गुणवत्ता की क्षति

गुणात्मक क्षति को कई श्रेणियों में विभाजित किया गया है। शीर्ष 3 में शामिल हैं:

• दुर्गमता, त्रुटियां;
• ब्रेक, वृद्धि हुई विलंबता;
• गलत व्यवहार।

एनालिटिक्स के अनुसार, ऐसी त्रुटियों का बड़ा हिस्सा। एक ओर, यह अच्छी खबर है। तीन प्रकार की सबसे आम त्रुटियों का पता लगाना आसान है - हम मीट्रिक को विलंबता और त्रुटियों की संख्या को समायोजित करते हैं, और ऐसी चीजों को जल्दी से नोटिस करते हैं।

बुरी खबर यह है कि इनमें से अधिकांश गलतियाँ हैं। ये सरल तकनीकी त्रुटियां हैं, जिसका अर्थ है कि हम पाइपलाइन परीक्षण में कुछ सुधार कर सकते हैं, अधिक तनाव परीक्षण कर सकते हैं और निगरानी प्रणाली में सुधार कर सकते हैं।

ट्रिगर्स

यह वही है जो सीधे तौर पर टूटने की ओर ले जाता है, जो कि दुर्घटना का मूल कारण नहीं है, लेकिन "अंतिम पुआल": लॉग ने डिस्क को भर दिया और इस वजह से, सब कुछ टूट गया, रिलीज में डाल दिया - सब कुछ विस्फोट हो गया।



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

यह सभी एनालिटिक्स का बिंदु है - यह समझने के लिए कि सीमित संसाधनों की स्थितियों में एक छोटी इन्फ्रास्ट्रक्चर टीम को अभी कहां निवेश करना चाहिए।

क्या सुधार करना है - अलर्ट या तैनाती? क्या करें - होस्टिंग या रेखांकन की सुंदरता?

यहाँ एक और अच्छी जानकारी है। दूसरे स्थान पर "कारण अज्ञात है।" यह घटना रिपोर्ट की खराब रिपोर्टिंग का एक संकेतक है।

संभव "गोलियां"

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

• क्लाइंट से HTTP त्रुटियों की संख्या पर - 10%;
• लॉग में नई प्रकार की त्रुटियों की उपस्थिति पर: स्थापना, अधिसूचना सेटिंग्स - 8%;
• सिस्टम संसाधनों पर: CPU, मेमोरी, डिस्क, थ्रेड्स, GC - 6%।

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

यहां मैं एक बार फिर हमारे मोइरा अलर्ट सिस्टम का विज्ञापन करूंगा, जो ओपन सोर्स में स्थित है।



यदि आपके पास ग्रेफाइट है, तो आप इसे डाउनलोड और उपयोग कर सकते हैं। मुझे उम्मीद है कि कम घटनाएं होंगी।

सिफारिशें

संगठनात्मक सिफारिशें जो टीम का पालन कर सकती हैं, और दुर्घटनाओं की संख्या को भी कम कर सकती हैं। हमारे शीर्ष 3।

• परीक्षण और युद्ध स्थलों की समानता । 5% घटनाएं इस तथ्य के कारण हुईं कि परीक्षण स्थल मुकाबला एक के समान नहीं था।
• रिलीज में पिछड़ी अनुकूलता । रिलीज को अपवित्र किया गया था, पिछले एक के साथ संगत नहीं था, डेटा माइग्रेशन उत्पन्न हुआ - 4% त्रुटियां।
• रात को रिलीज होने से इंकार यदि आप उस विराम को फैलाना छोड़ देते हैं, तो शाम को, घटनाओं का 4% गायब हो जाएगा।

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

कैसे लिखें?

यदि आपको लगता है कि घटना विश्लेषिकी एक अच्छी बात है और आपको रिपोर्ट लिखने की आवश्यकता है, तो मैं आपको बताऊंगा कि यह कैसे करना है।

पोस्टमार्टम और कार्यों को एक बग ट्रैकर में पोस्ट करें

बगट्रॉकर में, Google डॉक्स या विकी के विपरीत, ऐसे निश्चित क्षेत्र हैं जिनके लिए आप मानों का एक सेट निर्धारित कर सकते हैं। यह बाद में रेखांकन आँकड़ों के विश्लेषण की सुविधा प्रदान करता है।

SRE पुस्तक में, Google Google डॉक्स में एक टेम्पलेट प्रदान करता है जिसमें वे अपने आंतरिक दस्तावेज़ में रिपोर्ट लिखते हैं। मैं कल्पना नहीं कर सकता कि कैसे हम उन गैर-ज़िम्मेदार दस्तावेज़ों को इकट्ठा कर सकते हैं जिन्हें हम असंरचित Google दस्तावेज़ों से एकत्र करते हैं।

हम मुख्य कार्यों के रूप में एक ही बग ट्रैकर में रिपोर्ट लिखते हैं, क्योंकि हम कार्य को पोस्टमार्टम से जोड़ सकते हैं। आइए पोस्टमार्टम पर गौर करें और तुरंत देखें कि कौन से कार्य बंद हैं, जो नहीं हैं, और जिन्हें करना बाकी है।

विशेष क्षेत्र बनाएँ

मैंने पहले से ही विशेष क्षेत्रों के बारे में बात की। हमारे पास निम्नलिखित हैं।

• फकप की शुरुआत और अंत का स्वचालित रूप से विश्लेषण किया जा सकता है। यदि आप मशीन-पठनीय समय-टिकट लगाते हैं, तो आप फकैप की अवधि को प्लॉट कर सकते हैं।
• जांच की शुरुआत और अंत।
• उत्प्रेरक। ट्रिगर की ड्रॉप-डाउन सूची सेट करें, यह अधिक सुविधाजनक है।
• जैसा नोट किया गया।
• मात्रात्मक और गुणात्मक क्षति।
• टीमों और सेवाओं को प्रभावित किया।

विशेष क्षेत्रों के सभी डेटा आपको यह समझने की अनुमति देते हैं कि आपका बुनियादी ढांचा कैसे काम करता है।

हमारी पूरी की गई रिपोर्ट का एक उदाहरण।



दाएं कॉलम के फ़ील्ड ड्रॉप-डाउन सूचियों से चयन के माध्यम से भरे गए हैं।

इंजीनियरों की एक टीम इकट्ठा करें जो गुणवत्ता की परवाह करते हैं

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

हमारी टीम को क्यू-टीम कहा जाता है - "गुणवत्ता" शब्द से। इसमें 3 लोग हैं - कंपनी के सबसे प्रतिभाशाली इंजीनियरों में से एक जो बुनियादी ढांचे में काम करते हैं।

कुल मिलाकर

गुरु पढ़ें - जॉन अल्लसॉ के लेख और घटना प्रबंधन पुस्तकें: साइट विश्वसनीयता इंजीनियरिंग , पेजरडूट पोस्टमार्टम प्रक्रिया , एटलसियन हादसा पुस्तिका ।

और जब आप कल काम करने आते हैं, तो पहले कदम उठाएं :

• बगट्रैक में फेकैप्स के लिए एक परियोजना शुरू करें जिसमें आप कार्य करते हैं;
• कोई भी टेम्प्लेट लें - अपना लिखने का प्रयास न करें, हमारा , या Google से SRE में लें;
• जब कुछ विस्फोट होता है, तो बस लिखें।

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

हमें उम्मीद है, फिर आप एलेक्सी को इस तरह के अनुभव की कहानी के लिए याद करेंगे और धन्यवाद करेंगे। और हम, बदले में, DevOpsConf कार्यक्रम में नई उपयोगी रिपोर्ट एकत्र करने की कोशिश करेंगे, सिफारिशें जिनसे आप जा सकते हैं और आवेदन कर सकते हैं। यह सम्मेलन 30-1 सितंबर , 2019 को आयोजित किया जाएगा , 20 अगस्त तक हम अभी भी DevOps समर्थकों के आवेदन की प्रतीक्षा कर रहे हैं, लेकिन 12 पहले ही स्वीकृत हो चुके हैं, अर्थात प्रतियोगिता समय सीमा के अधिक नजदीक होगी।

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