इंजीनियरिंग पोस्टमॉर्टम टेम्पलेट (दोषरहित, कार्रवाई-योग्य)

पोस्टमॉर्टम दोषारोपण सत्र में क्यों बदल जाते हैं

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

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

एजेंडा (इसे कॉपी-पेस्ट करें)

अवधि: एक सीधे-सादे इंसिडेंट के लिए 60 मिनट; जटिल मल्टी-सिस्टम विफलताओं के लिए 90 मिनट
फॉर्मैट: संचालित; सभी रेस्पॉन्डर और ऑन-कॉल इंजीनियर मौजूद; एक पूर्व-पठन दस्तावेज़ के साथ असिंक तैयारी करें

सेक्शन 1 — इंसिडेंट सारांश (5 मिनट)

इंसिडेंट की तारीखें और अवधि
गंभीरता वर्गीकरण और प्रभावित सिस्टम
इसे किसने और कैसे पकड़ा (ग्राहक रिपोर्ट, अलर्ट, इंजीनियर, मॉनिटरिंग)
यह सेक्शन केवल तथ्यात्मक है; अभी कोई विश्लेषण नहीं

सेक्शन 2 — टाइमलाइन (20 मिनट)

टाइमलाइन को स्क्रीन पर साथ मिलकर बनाएँ — पहले से लिखा दस्तावेज़ नहीं
क्रम: क्या बदला, क्या देखा गया, किसने कार्रवाई की, क्या तय हुआ
हर टाइमस्टैम्प का स्रोत होना चाहिए (लॉग लाइन, PagerDuty, Slack मैसेज)
जब टाइमलाइन पूरी हो जाए, तो पूछें: क्या सब सहमत हैं कि यही हुआ था? आगे बढ़ने से पहले असहमतियाँ सुलझाएँ

सेक्शन 3 — प्रभाव सारांश (5 मिनट)

ग्राहक प्रभाव: कौन प्रभावित हुआ, कितनी देर तक, किस तरह
कारोबारी प्रभाव: रेवेन्यू, SLA, प्रतिष्ठा
आंतरिक प्रभाव: ऑन-कॉल घंटे, टीम में व्यवधान
इसे तथ्यात्मक रखें; यह बिना संपादकीय टिप्पणी के "यह कितना बुरा था" वाले सवाल को आधार देता है

सेक्शन 4 — रूट कॉज और योगदान देने वाले कारक (20 मिनट)

रूट कॉज: वह सबसे निकटतम बदलाव या स्थिति जिसने इंसिडेंट को संभव बनाया
योगदान देने वाले कारक: वे स्थितियाँ जिन्होंने इसे बदतर, पकड़ने में कठिन, या सुलझाने में धीमा बनाया
सबसे उपयोगी पोस्टमॉर्टम रूट कॉज के साथ 3-5 योगदान देने वाले कारक पहचानते हैं; सिर्फ रूट कॉज ठीक करना अक्सर व्यवस्थागत स्थितियों को चूक जाता है
हर कारक के लिए पूछें: क्या किसी व्यक्ति या टीम ने ऐसा फैसला लिया जो उस वक्त उपलब्ध जानकारी को देखते हुए वाजिब लगता था? अगर हाँ, तो कारक व्यवस्थागत है, व्यक्तिगत नहीं

सेक्शन 5 — क्या अच्छा रहा (5 मिनट)

कौन-सी डिटेक्शन या प्रतिक्रिया उम्मीद से बेहतर काम आई?
किस मौजूदा प्रक्रिया या टूल ने ब्लास्ट रेडियस को सीमित किया?
ये औपचारिक बनाने लायक तौर-तरीके हैं — अगर रनबुक ने 20 मिनट बचाए, तो यह दर्ज करें ताकि रनबुक बनाए रखी जाए

सेक्शन 6 — एक्शन आइटम (15 मिनट)

हर एक्शन आइटम किसी रूट कॉज या योगदान देने वाले कारक को संबोधित करता है — न कि कोई सामान्य सुधार
प्रति आइटम एक जिम्मेदार; एक डिलीवरी तारीख जो तात्कालिकता को दर्शाए
वर्गीकृत करें: जल्दी पहचानो / तेज़ी से उबरो / पुनरावृत्ति रोको
केवल उन कार्रवाइयों तक सीमित रहें जिन्हें टीम अगले इंसिडेंट से पहले वास्तविक रूप से पूरा कर सके, न कि एक व्यापक रिलायबिलिटी रोडमैप

पोस्टमॉर्टम टेम्पलेट्स को क्या नाकाम बनाता है

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

तीसरा विफलता का तरीका "क्या अच्छा रहा" को छोड़ देना है, क्योंकि किसी इंसिडेंट के बाद यह अनुचित आशावाद जैसा लगता है। यह ऐसा नहीं है — यह दबाव में काम आए तौर-तरीकों को पहचानने और औपचारिक बनाने का एकमात्र व्यवस्थित तरीका है। अगर वह मॉनिटरिंग जिसने समस्या पकड़ी, किसी के रोडमैप पर बनाने के लिए थी ही नहीं, तो यह जानना कि वह मायने रखती थी, दर्ज करने लायक है। वरना इंसिडेंट के फीके पड़ते ही उसकी प्राथमिकता घट जाती है और अगली बार आप अंधे होते हैं।

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

पोस्टमॉर्टम कैप्चर अनूठे तौर पर कठिन क्यों है

पोस्टमॉर्टम चर्चाएँ तेज़ी से सघन, असंरचित सामग्री पैदा करती हैं: टाइमलाइन का पुनर्निर्माण, परस्पर विरोधी व्याख्याएँ, कई लोगों को सौंपे गए एक्शन आइटम, और ऐसा तकनीकी ब्यौरा जो संदर्भ के बिना किसी ट्रांसक्रिप्ट में समझ में नहीं आएगा। याद से या संपादित ऑडियो से लिखा गया पोस्टमॉर्टम रीकैप लगभग हमेशा अधूरा होता है, और अधूरे पोस्टमॉर्टम रिकॉर्ड इंसिडेंट्स के बीच पैटर्न पहचानने के लिए बेकार होते हैं।

Pavleur पूरी पोस्टमॉर्टम चर्चा को कैप्चर करता है और रिपोर्ट अपने-आप जनरेट करता है — पुनर्निर्मित टाइमलाइन, नाम लिए गए योगदान देने वाले कारक, और मीटिंग में बताए अनुसार जिम्मेदारों व श्रेणियों सहित एक्शन आइटम। अगर किसी ने एक लॉग एक्सट्रैक्ट, एक मॉनिटरिंग ग्राफ़, या वह अलर्ट कॉन्फ़िगरेशन दिखाने के लिए अपनी स्क्रीन साझा की जो फ़ायर होने में नाकाम रही, तो वह दृश्य रिपोर्ट का हिस्सा होता है। सिर्फ-ऑडियो वाले टूल्स इसे पूरी तरह चूक जाते हैं; बिना ग्राफ़ के एक पोस्टमॉर्टम रिकॉर्ड बिना सबूत के रिकॉर्ड है। टीम का कोई भी सदस्य — जिनमें वे इंजीनियर भी शामिल हैं जो इंसिडेंट के बाद जुड़ते हैं — किसी से इसे फिर से गढ़वाए बिना पूरा, दृश्य-संदर्भ-सहित रिकॉर्ड पढ़ सकता है। इस पर दूसरे टूल्स से सीधी तुलना के लिए: Pavleur बनाम विकल्प।

पोस्टमॉर्टम की नियमितता पर

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