इकाइयाँ
1. DevOps और Cloud AI का परिचय: भूमिकाएँ, सीमाएँ, प्रमाणीकरण, सुरक्षा और रहस्य 2. आर्टिफिशियल इंटेलिजेंस के साथ सीआई/सीडी पाइपलाइन डिजाइन करना: गिटहब एक्शन और गिटलैब सीआई 3. कोड के रूप में बुनियादी ढांचे का प्रबंधन: टेराफॉर्म और आईएसी के साथ आर्टिफिशियल इंटेलिजेंस 4. कंटेनरीकरण: आर्टिफिशियल इंटेलिजेंस के साथ डॉकरफाइल और छवि अनुकूलन 5. कुबेरनेट्स: मेनिफेस्ट, हेल्म और एआई-पावर्ड ऑर्केस्ट्रेशन 6. निगरानी और अवलोकन: मीट्रिक, लॉग, ट्रेस और अलार्म नियम 7. घटना प्रबंधन और पोस्टमॉर्टम: आर्टिफिशियल इंटेलिजेंस के साथ मूल कारण विश्लेषण 8. क्लाउड कॉस्ट ऑप्टिमाइजेशन (फिनऑप्स): आर्टिफिशियल इंटेलिजेंस के साथ कचरे की तलाश 9. स्क्रिप्ट और ऑटोमेशन जेनरेशन: बैश, पायथन और पावरशेल 10. सुरक्षा और रहस्य प्रबंधन: DevSecOps और आर्टिफिशियल इंटेलिजेंस 11. उत्पाद सत्यापन, रिलीज़ रणनीतियाँ और एंड-टू-एंड एआई वर्कफ़्लो
इकाई 7 / 11

घटना प्रबंधन और पोस्टमॉर्टम: आर्टिफिशियल इंटेलिजेंस के साथ मूल कारण विश्लेषण

लाभ:

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

हर व्यवस्था अंततः टूट जाती है। अंतर यह है कि अच्छी टीमें इस अपरिहार्य घटना के लिए कैसे तैयारी करती हैं और कैसे सीखती हैं। घटना एक अप्रत्याशित घटना है जो सेवा को बाधित करती है या बाधित करने की धमकी देती है: एक सेवा दुर्घटना, प्रतिक्रिया समय आसमान छूना, डेटा हानि। घटना प्रबंधन का अर्थ है घटना का जल्द से जल्द पता लगाना, कम करना, समाधान करना और फिर उससे सीखना। यह वह अनुशासन है जो DevOps और SRE (साइट विश्वसनीयता इंजीनियरिंग) पेशेवरों को दिन-रात प्रेरित करता है।

दो महत्वपूर्ण मैट्रिक्स घटना की गुणवत्ता को मापते हैं: एमटीटीडी (पता लगाने का औसत समय) और एमटीटीआर (ठीक होने का औसत समय)। लक्ष्य दोनों को सिकोड़ना है। एआई यहां दो बड़े मूल्य जोड़ता है: संभावित मूल कारण को कम करने के लिए घटना के समय लॉग और मेट्रिक्स को जल्दी से सारांशित करना, और घटना के बाद पोस्टमॉर्टम (घटना के बाद की जांच रिपोर्ट) का तुरंत मसौदा तैयार करना। लेकिन घटनाओं के बारे में निर्णय - किस सेवा को बंद करना है, वापस लेना है, ग्राहक को क्या कहना है - आपका है।

किसी घटना का जीवन चक्र

  1. पता लगाना: अलार्म बजता है या ग्राहक की शिकायत आती है। जितनी जल्दी हो, उतना अच्छा।
  2. ट्राइएज: यह कितना गंभीर है? डोमेन क्या है? गंभीरता स्तर निर्दिष्ट हैं - आमतौर पर SEV1 (सबसे महत्वपूर्ण, संपूर्ण प्रणाली) से SEV4 (मामूली)।
  3. अपनी प्रतिक्रिया टीम को इकट्ठा करें. गंभीर घटनाओं में, एक घटना कमांडर समन्वय का कार्य करता है।
  4. कम करें: पहले रक्तस्राव रोकें - अक्सर रोलबैक या ध्वज को ढंकना। आपको मूल कारण बाद में पता चलेगा।
  5. समाधान: स्थायी समाधान लागू करें।
  6. जानें (पोस्टमॉर्टम): क्या हुआ, क्यों हुआ, हम इसे दोबारा होने से कैसे रोकें?
टिप: घटना के समय सबसे महंगी गलतियों में से एक है रक्तस्राव को रोकने में देरी करना क्योंकि "आइए पहले सटीक मूल कारण पर जाएं।" नियम: पहले कमी (सेवा बहाल/बहाल) करें, फिर पूछताछ करें। किसी ज्ञात-अच्छे संस्करण पर वापस लौटना अक्सर सबसे त्वरित शमन होता है।

अपराध-मुक्त पोस्टमॉर्टम संस्कृति

स्वस्थ टीमों की रीढ़ दोषरहित पोस्टमॉर्टम की संस्कृति है: लक्ष्य यह नहीं है कि "यह किसने किया," बल्कि "किस प्रणाली और प्रक्रिया ने इस गलती की अनुमति दी?" क्या प्रश्न है। लोग गलती छिपाते हैं अगर उन्हें पता हो कि उन्हें सज़ा मिलेगी; छिपी हुई त्रुटि दोहराई जाती है. पोस्टमॉर्टम कोई आरोप रिपोर्ट नहीं, बल्कि एक सीख देने वाला दस्तावेज़ है.

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

सावधानी: एआई के साथ पोस्टमॉर्टम लिखते समय, आरोप लगाने वाली भाषा (अर्थात् "व्यक्ति एक्स ने गलती की") को हटा देना सुनिश्चित करें। एआई को इवेंट डेटा फीड करते समय क्लाइंट आईडी, आंतरिक आईपी और रहस्यों को भी छिपाएं - पोस्टमॉर्टम अक्सर व्यापक रूप से साझा किए जाते हैं।

मूल कारण विश्लेषण: 5 क्यों और एआई

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

गंभीरता तालिका

स्तर

प्रभाव

उदाहरण

हस्तक्षेप

SEV1

संपूर्ण सिस्टम/गंभीर व्यावसायिक हानि

भुगतान पूरी तरह से गिरा दिया गया

तुरंत, पूरी टीम, कमांडर

SEV2

प्रमुख शिथिलता

लॉगिन विफल

तेज़, ऑन-कॉल + समर्थन

SEV3

आंशिक/सीमित प्रभाव

एक रिपोर्ट में देरी हो रही है

काम के घंटों के दौरान

SEV4

छोटा/कॉस्मेटिक

टाइपो

सामान्य कार्य कतार

तीन मिनी मामले

केस 1 - 45 मिनट से 8 मिनट तक एमटीटीआर। भुगतान सेवा क्रैश हो गई. ड्यूटी पर मौजूद इंजीनियर ने एआई को नकाबपोश लॉग और अंतिम तैनाती की जानकारी दी और पूछा "पिछले 20 मिनट में सबसे संभावित ट्रिगर क्या है?" उसने पूछा. एआई ने दिखाया कि पतन अंतिम तैनाती के उसी मिनट में शुरू हुआ। इंजीनियर ने तुरंत उस संस्करण को वापस ले लिया; सेवा 8 मिनट में वापस आ गई. फिर मूल कारण (नए संस्करण में एक कनेक्शन पूल बग) की आसानी से जांच की गई।

केस 2—20 मिनट में पोस्टमॉर्टम स्केच। SEV2 के बाद, टीम थक गई थी और उसमें रिपोर्ट लिखने की ताकत नहीं थी; अक्सर रिपोर्ट में हफ्तों की देरी होती थी। इस बार, उन्होंने एआई को समयरेखा और घटना नोट्स दिए और एक अपराध-मुक्त पोस्टमॉर्टम स्केच तैयार किया। एआई ने प्रभाव, समयरेखा और कार्रवाई वस्तुओं के लिए एक साफ-सुथरा ढांचा तैयार किया; टीम ने इसे तथ्यों से भरकर 20 मिनट में प्रकाशित कर दिया। सबक खोया नहीं था.

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

चार प्रतिलिपि योग्य टेम्पलेट

1) घटना के समय त्वरित परीक्षण:

हम एक उत्पादन कार्यक्रम का अनुभव कर रहे हैं। नकाबपोश लक्षण: [लक्षण]। अंतिम परिवर्तन: [अंतिम परिनियोजन/परिवर्तन]। मुझे बताएं:(1) संभाव्यता के क्रम में 3 सबसे संभावित मूल कारण परिकल्पनाएं,(2) आदेश/मीट्रिक जो प्रत्येक को 1 मिनट में सत्यापित करेगा,(3) सबसे तेज़ सुरक्षित शमन कदम (उदाहरण के लिए रोलबैक)।सख्ती से कहें तो; बताएं कि मुझे प्रत्येक परिकल्पना को सत्यापित करना होगा।

2) मासूम का पोस्टमॉर्टम स्केच:

नीचे दी गई घटना के नोट्स से एक दोषरहित पोस्टमॉर्टम स्केच लिखें। अनुभाग: सारांश, प्रभाव (उपयोगकर्ता/अवधि/लागत), समयरेखा, मूल कारण, क्या अच्छा हुआ, क्या बुरा हुआ, कार्रवाई आइटम (प्रत्येक स्वामी + दिनांक फ़ील्ड के साथ)। नामकरण, प्रक्रिया और प्रणाली पर ध्यान दें। टिप्पणियाँ: [नकाबपोश]

3)5 क्यों विश्लेषण:

निम्नलिखित लक्षण से शुरू करते हुए, "5 क्यों" श्रृंखला बनाएं: [लक्षण]। दिखाएँ कि क्या प्रत्येक चरण में एक से अधिक संभावित शाखाएँ हैं। प्रत्येक "क्यों" के आगे वह साक्ष्य (लॉग/मीट्रिक) लिखें जिसे मैं सत्यापित करने के लिए देखूंगा। अंत में, चिह्नित करें कि कौन से चरण अभी तक सत्यापित नहीं किए गए हैं।

4) क्रियाशील वस्तुएँ बनाना:

इस मूल कारण के अनुसार, कार्रवाई योग्य वस्तुओं का सुझाव दें जो उसी घटना को दोबारा होने से रोकें। प्रत्येक आइटम को निम्न आधार पर वर्गीकृत करें: (ए) रोकथाम, पता लगाना या कमी करना, (बी) अनुमानित प्रयास, (सी) प्रभाव। उच्चतम प्रभाव/प्रयास अनुपात के आधार पर क्रमबद्ध करें। मूल कारण: [एक्स]

कमजोर संकेत/मजबूत संकेत

कमज़ोर: "सेवा क्रैश हो गई है, मुझे क्या करना चाहिए?"

परिणाम: कोई संदर्भ नहीं; एआई सामान्य सिफारिशें कर सकता है जो आपके मामले में फिट नहीं बैठती हैं, और यहां तक ​​कि एक निश्चित मूल कारण भी बता सकता है।

मजबूत: "उत्पादन भुगतान सेवा 5 मिनट के लिए 5xx दे रही है। अंतिम तैनाती 6 मिनट पहले हुई थी। संभावना के क्रम में 3 सबसे संभावित मूल कारण परिकल्पनाएं दें, उस कमांड को बताएं जो उनमें से प्रत्येक को सत्यापित करेगा, और सबसे तेज़ सुरक्षित शमन का सुझाव देगा। विशिष्ट न बनें, बताएं कि मुझे सत्यापित करने की आवश्यकता है।"

अंतर: दूसरा संकेत लक्षण, समय और अंतिम परिवर्तन बताता है; यह परिकल्पना + सत्यापन + कमी की मांग करता है और एआई को अस्पष्ट रखता है।

सामान्य गलतियाँ

  • शमन करने से पहले सटीक मूल कारण की तलाश करें। यह रक्तस्राव को रोकने में देरी करता है और एमटीटीआर बढ़ाता है।
  • एआई की पहली परिकल्पना को बिना सत्यापित किए प्रकाशित करना। रिपोर्ट में तरल लेकिन गलत मूल कारण लीक हो गया है।
  • आरोप लगाने वाली भाषा. गुमनाम रूप से लिखा गया पोस्टमॉर्टम छिपाने और गलती दोहराने को बढ़ावा देता है।
  • बुलेट प्वाइंट के बिना कार्रवाई-उन्मुख रिपोर्ट। बिना स्वामी और तारीख वाला प्रस्ताव कभी लागू नहीं किया जाएगा।
  • इवेंट डेटा को छुपाए बिना साझा करना। पोस्टमॉर्टम व्यापक दर्शकों तक जाता है; गुप्त/व्यक्तिगत डेटा लीक हो गया है।
  • रोलबैक पथ पहले से तैयार न करना. यदि उत्क्रमण व्यावहारिक नहीं है, तो कटौती धीमी हो जाती है।

सारांश

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

आवेदन कार्य

किसी अतीत (या काल्पनिक) घटना पर विचार करें। (1) एआई को "ऑन-द-सीन रैपिड ट्राइएज" टेम्पलेट के साथ परिकल्पना और सत्यापन कदम तैयार करने दें; ध्यान दें कि डेटा द्वारा किस परिकल्पना की पुष्टि की जा सकती है। (2) "दोषी नहीं पोस्टमॉर्टम रूपरेखा" टेम्पलेट का उपयोग करके एक रिपोर्ट बनाएं और इसे तथ्यों से भरें। (3) कम से कम दो कार्रवाई योग्य वस्तुओं की पहचान करें और प्रत्येक को एक मालिक और तारीख निर्दिष्ट करें।

चेकलिस्ट

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