पेजरड्यूटी, या परिचालन विभाग रात में क्यों नहीं सो सकता

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

जिस समाधान पर चर्चा की जाएगी वह सबसे अप्रत्याशित नहीं है, लेकिन खोज इस विषय पर पूर्ण लेख नहीं लौटाती है।

इसलिए, मैंने फ़नकॉर्प के अनुभव को साझा करने और इस बारे में बात करने का निर्णय लिया कि ड्यूटी प्रक्रिया कैसे संरचित है, कौन कॉल करता है, क्यों और कैसे आप यह सब देख सकते हैं।

पेजरड्यूटी क्या है?

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

संक्षेप में, पेजरड्यूटी एक घटना प्रसंस्करण मंच है जो विभिन्न एकीकरणों के माध्यम से आने वाली घटनाओं को संसाधित कर सकता है, ड्यूटी आदेश स्थापित कर सकता है और फिर घटना के स्तर के आधार पर ड्यूटी पर इंजीनियर को सचेत कर सकता है (उच्च स्तर पर - एक कॉल, निम्न स्तर पर - एप्लिकेशन/एसएमएस से एक धक्का)।

कर्तव्य अधिकारी कौन है?

यह संभवतः पीडी की स्थापना शुरू करने वाला पहला स्थान है।

फ़नकॉर्प में, अन्य कंपनियों की तरह, ड्यूटी ऑफिसर का मानद पद होता है। यह दिन में एक बार इंजीनियर से इंजीनियर तक प्रसारित होता है। PagerDuty की ओर से किसी अलर्ट पर प्रतिक्रिया की तथाकथित पहली और दूसरी पंक्ति होती है। मान लीजिए कि एक उच्च-प्राथमिकता वाला अलर्ट आता है, और यदि ड्यूटी अधिकारी को कॉल करने के 10 मिनट बाद पहली पंक्ति से कोई प्रतिक्रिया नहीं होती है (यानी, इसे पावती या हल स्थिति में स्थानांतरित नहीं किया जाता है), तो कॉल दूसरी पंक्ति में चली जाती है ड्यूटी इंजीनियर. इसे पेजरड्यूटी में ही एस्केलेशन नीतियों के माध्यम से कॉन्फ़िगर किया गया है।

यदि दूसरा कर्तव्य अधिकारी जवाब नहीं देता है, तो अधिसूचना वापस लौट आती है मुख्य कर्तव्य अधिकारी को.

इस प्रकार, कोई भी आने वाली उच्च प्राथमिकता वाली चेतावनी असंसाधित नहीं रह सकती। 

अब देखते हैं कि घटनाएं कहां से आ सकती हैं।

हम किस एकीकरण का उपयोग करते हैं?

पीडी को विभिन्न सेवाओं से कई अलग-अलग घटनाएं प्राप्त होती हैं। वर्तमान में हमारे पास लगभग 25 ऐसी सेवाएँ हैं, और उन्हें संसाधित करने के लिए हम कुछ तैयार एकीकरणों का उपयोग करते हैं।

• प्रोमिथेउस

मुख्य मेट्रिक्स संग्रह प्रणाली प्रोमेथियस है। हैबे पर इसके बारे में पहले ही बहुत कुछ लिखा जा चुका है, मैं सिर्फ इतना कहूंगा कि हमारे पास अलग-अलग वातावरणों के लिए उनमें से कई हैं: एक वर्चुअल मशीनों और डॉकर्स से मेट्रिक्स एकत्र करता है, दूसरा अमेज़ॅन सेवाओं से, तीसरा हार्डवेयर मशीनों से। टेलीग्राफ का उपयोग मुख्य रूप से मेट्रिक्स निर्यातक के रूप में किया जाता है।

• ईमेल

यहाँ भी, मुझे लगता है, शीर्षक से ही सब कुछ स्पष्ट है। इस एकीकरण का उपयोग क्रॉन द्वारा निष्पादित कुछ स्क्रिप्ट से सूचनाएं भेजने के लिए किया जाता है। पीडी आपको एक निश्चित पता देता है जिस पर आप पत्र भेजते हैं। इस तरह के एकीकरण के साथ एक सेवा बनाते समय, आप प्राथमिकताएं निर्धारित कर सकते हैं कि आने वाली घटनाओं को किस क्रम में संसाधित किया जाएगा, वास्तव में अलर्ट कैसे बनाया जाए (प्रत्येक आने वाले पत्र के लिए, एक आने वाले पत्र के लिए + एक निश्चित नियम, आदि)।

• सुस्त

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

क र ते हैं:

हम देखते हैं:

• API

HTTP एकीकरण. वास्तव में, यहां कुछ भी विशेष रूप से दिलचस्प नहीं है, केवल JSON प्रारूप में एक मुख्य भाग के साथ एक POST अनुरोध है। उदाहरण के लिए, कुछ दिलचस्प: हम इसका उपयोग बाहरी निगरानी के लिए करते हैं https://www.statuscake.com/. यह सेवा दुनिया के विभिन्न हिस्सों से हमारी साइटों की पहुंच की जांच करती है। ऐसी स्थिति में जब हमें एक अस्वीकार्य प्रतिक्रिया कोड (उदाहरण के लिए, 502) प्राप्त होता है, तो एक घटना बन जाती है और फिर सब कुछ ऊपर वर्णित श्रृंखला का अनुसरण करता है। स्टेटसकेक में स्वयं आंतरिक यूआरएल, एसएसएल प्रमाणपत्र या डोमेन समाप्ति की निगरानी करने की क्षमता है।

• लिब्रेएनएमएस

यह एक और निगरानी प्रणाली है, आप इसके बारे में उनकी वेबसाइट पर अधिक पढ़ सकते हैं https://www.librenms.org/. इसकी मदद से हम सर्वर से नेटवर्क इंटरफेस और iDRAC की निगरानी करते हैं।

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

विज़ुअलाइज़ेशन

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

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

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

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

स्क्रीन वर्तमान खुली घटनाओं, चयनित शेड्यूल से ड्यूटी पर मौजूद वर्तमान इंजीनियर का नाम और उच्च प्राथमिकता वाली घटना के बिना समय प्रदर्शित करती है (उच्च प्राथमिकता वाली घटना वाला पैनल लाल रंग में हाइलाइट किया जाएगा)।

इस कार्यान्वयन के स्रोत यहां देखें.

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

स्रोत: www.habr.com