यह प्रणाली जितनी जटिल है, उतनी ही यह सभी प्रकार के अलर्ट के साथ बढ़ती है। और इन बहुत अलर्ट का जवाब देने, उन्हें एकत्र करने और कल्पना करने की आवश्यकता है। मुझे लगता है कि एक नर्वस टिक से पहले कई के लिए परिचित स्थिति है।
जिस निर्णय पर चर्चा की जाएगी, वह सबसे अप्रत्याशित नहीं है, लेकिन खोज इस विषय पर एक पूर्ण लेख का उत्पादन नहीं करती है।
इसलिए, मैंने फनकॉर्प के अनुभव को साझा करने और यह बात करने का फैसला किया कि ड्यूटी प्रक्रिया कैसे बनाई जाती है, कौन बुला रहा है, क्यों और कैसे आप इसे देख सकते हैं।
PagerDuty क्या है?
इसलिए, इन सभी समस्याओं को हल करने के लिए, हमने एक सुविधाजनक उपकरण की तलाश शुरू की। एक छोटी खोज के बाद, हमने पेजरडूट का विकल्प चुना। पीडी हमें बहुत सी एकीकरण और सेटिंग्स के साथ एक पूर्ण और संक्षिप्त समाधान लग रहा था। वह क्या है?
संक्षेप में, PagerDuty एक घटना प्रसंस्करण मंच है जो विभिन्न एकीकरणों के माध्यम से आने वाली घटनाओं को संभाल सकता है, कर्तव्य के आदेश को समायोजित कर सकता है और फिर घटना के स्तर (उच्च स्तर पर - कॉल, कम से कम आवेदन / एसएमएस से धक्का) के आधार पर कर्तव्य इंजीनियर को सतर्क कर सकता है ।
ड्यूटी पर मौजूद व्यक्ति कौन है?
यह शायद पीडी की स्थापना शुरू करने वाली पहली चीज है।
अन्य कंपनियों की तरह फनकार्प की ड्यूटी पर मानद स्थिति है। इसे दिन में एक बार इंजीनियर से इंजीनियर के रूप में प्रेषित किया जाता है। पेजरडूट से अलर्ट की प्रतिक्रिया की तथाकथित पहली और दूसरी पंक्ति है। मान लें कि एक उच्च प्राथमिकता चेतावनी आती है, और अगर पहली पंक्ति से परिचारक को कॉल करने के 10 मिनट बाद कोई प्रतिक्रिया नहीं होती है (यानी उसे स्वीकार या हल की गई स्थिति में स्थानांतरित नहीं किया जाता है), कॉल दूसरी ड्यूटी इंजीनियर को जाती है। यह Escalation नीतियों के माध्यम से PagerDuty में ही कॉन्फ़िगर किया गया है।
यदि दूसरा परिचर जवाब नहीं देता है, तो अधिसूचना
मुख्य परिचर पर वापस आ जाती है।
इस प्रकार, किसी भी आने वाली उच्च प्राथमिकता चेतावनी असुरक्षित नहीं रह सकती है।
अब देखते हैं कि घटनाएं कहां से आ सकती हैं।
हम किन एकीकरणों का उपयोग करते हैं?
विभिन्न सेवाओं से बहुत सी घटनाएं पीडी में डाली जा रही हैं। अब हमारे पास लगभग 25 ऐसी सेवाएं हैं, और उनके प्रसंस्करण के लिए हम कुछ तैयार एकीकरण का उपयोग करते हैं।
प्राथमिक मीट्रिक संग्रह प्रणाली प्रोमेथियस है। हैबर में इसके बारे में बहुत कुछ लिखा गया है, मैं सिर्फ इतना कहूंगा कि हमारे पास विभिन्न वातावरणों के लिए कई हैं: एक वर्चुअल मशीन और डॉकर्स से मैट्रिक्स इकट्ठा करता है, दूसरा अमेज़ॅन सेवाओं से, "लोहे की मशीनों" से तीसरा। मुख्य रूप से मैट्रिक्स के निर्यातक के रूप में उपयोग किया जाता है।
यहाँ भी, मुझे लगता है कि नाम से सब कुछ स्पष्ट है। इस एकीकरण का उपयोग ताज पर निष्पादित कुछ लिपियों से सूचनाएं भेजने के लिए किया जाता है। पीडी आपको एक निश्चित पता देता है जिससे आप पत्र भेजते हैं। इस एकीकरण के साथ एक सेवा बनाते समय, आप प्राथमिकताओं को निर्धारित कर सकते हैं कि आने वाली घटनाओं को किस क्रम में संसाधित किया जाएगा, अलर्ट कैसे बनाया जाए (प्रत्येक आने वाले पत्र के लिए, आने वाले पत्र के लिए + एक निश्चित नियम, आदि)।
मेरी राय में, एक बहुत ही दिलचस्प एकीकरण। कई बार कुछ ऐसा होता है, लेकिन घटनाओं को कवर नहीं किया जाता है। इसलिए, हमने घटना को बनाने के लिए स्लैक से एकीकरण जोड़ा। यही है, कॉरपोरेट स्लैक में आप लिख सकते हैं
/ callofduty सब कुछ धीमा हो जाता है और जल्द ही यह टूट जाता है और पीडी
इसे प्रोसेस करता है और ड्यूटी इंजीनियर को घटना भेजता है।
हम करते हैं:
हम देखते हैं:
HTTP एकीकरण। यहाँ, वास्तव में, विशेष रूप से दिलचस्प कुछ भी नहीं है, केवल JSON प्रारूप में एक निकाय के साथ एक POST अनुरोध है। उदाहरण के लिए, एक दिलचस्प एक से: हम इसे
https://www.statuscake.com/ का उपयोग करके बाहरी निगरानी के लिए उपयोग करते हैं। यह सेवा दुनिया भर से हमारी साइटों की उपलब्धता की जांच करती है। मामले में जब हमें अस्वीकार्य प्रतिक्रिया कोड (उदाहरण के लिए, 502) मिलता है, तो एक घटना बनती है और फिर सब कुछ ऊपर वर्णित श्रृंखला के साथ हो जाता है। StatusCake में ही आंतरिक URL, SSL प्रमाणपत्र या डोमेन की समाप्ति की निगरानी करने की क्षमता होती है।
यह एक और निगरानी प्रणाली है, इसके बारे में उनकी वेबसाइट
https://www.librenms.org/ पर अधिक पाया जा सकता है। इसकी मदद से, हम नेटवर्क इंटरफेस और सर्वर से iDRAC की निगरानी करते हैं।
डेटाडॉग, क्लाउडवेच जैसे एकीकरण भी थे। उनमें से क्या बन गया इसके बारे में अधिक
यहां पाया जा सकता
है ।
दृश्य
प्राथमिक घटना रिपोर्टिंग प्रणाली सुस्त है। पीडी में आने वाली सभी घटनाओं को एक विशेष चैट में लिखा जाता है, और यदि उनकी स्थिति बदल जाती है, तो यह चैट में भी प्रदर्शित होता है।
जब छत के नीचे लटके मॉनिटर की स्क्रीन पर उपयोगी डेटा प्रदर्शित करना संभव हो गया, तो हमें अचानक एहसास हुआ कि हमारे पास (डिवोप्स विभाग में) उनके पास प्रदर्शित करने के लिए कुछ भी नहीं है। एक अद्भुत ग्राफाना है, लेकिन यह सिर्फ कवर नहीं किया जा सकता है, और कर्मचारी अलर्ट का जवाब देते हैं, चार्ट नहीं।
पीडी के लिए एक संक्षिप्त और सूचनात्मक "बोर्ड" के लिए गीथहब पर गहन लेकिन असफल खोज के बाद, हमने अपना खुद का लिखने का फैसला किया - केवल उसी चीज के साथ जिसकी हमें ज़रूरत थी। हालांकि पहले तो पीडी इंटरफ़ेस को स्वयं प्रदर्शित करने का विचार था, लेकिन यह और भी असुविधाजनक लग रहा था।
इसे लिखने के लिए, आपको केवल पढ़ने के अधिकार के साथ पीडी की कुंजी प्राप्त करना है।
और यहाँ है कि हम क्या मिला:
स्क्रीन वर्तमान खुली घटनाओं को प्रदर्शित करती है, चयनित शेड्यूल से वर्तमान ड्यूटी इंजीनियर का नाम, और उच्च प्राथमिकता वाली घटना के बिना समय (उच्च प्राथमिकता वाली घटना वाला पैनल लाल रंग में हाइलाइट किया जाएगा)।
इस कार्यान्वयन के लिए स्रोत कोड यहां देखें ।
परिणामस्वरूप, हमें अपनी सभी घटनाओं को देखने के लिए एक सुविधाजनक डैशबोर्ड मिला। मुझे खुशी होगी अगर आप में से कोई भी हमारे अनुभव से लाभान्वित होगा।