अच्छा postmortem किन बातों से बनता है?

अच्छा postmortem blameless, ठोस और बदलाव पैदा करने वाला होता है। उसमें सही टाइमलाइन होती है, यूज़र पर असली असर, समस्या कैसे पकड़ी और कैसे संभाली गई, और एक अकेले root cause की जगह योगदान देने वाले कारण। actions ठोस, किसी के नाम और बाकी काम जैसी प्राथमिकता वाली होती हैं, इच्छाओं की सूची नहीं। ध्यान इस पर रहता है कि सिस्टम ने यह नाकामी होने क्यों दी, जिसमें alerting और सुरक्षा उपायों की कमियां शामिल हैं, न कि इस पर कि command किसने टाइप की।

सबसे पहले blameless, और शिष्टाचार के तौर पर नहीं। अगर लोगों को लगता है कि उनका नाम लिया जाएगा तो वे बताना बंद कर देते हैं कि असल में हुआ क्या था, और फिर आपकी टाइमलाइन कहानी बन जाती है और आप कुछ नहीं सीखते। तो ढांचा हमेशा यही रहता है कि सिस्टम ने ऐसा होने क्यों दिया, यह नहीं कि किसने किया। सामग्री में मुझे timestamps वाली ईमानदार टाइमलाइन चाहिए, यूज़र पर असली असर नंबरों में, न कि सिर्फ खराब शब्द, कब शुरू हुआ बनाम कब पकड़ा, और कब संभाला बनाम कब समझा। शुरू होने और पकड़ने के बीच का वह अंतर आमतौर पर पूरे दस्तावेज़ की सबसे कीमती चीज़ होती है, और उससे अक्सर मूल bug ठीक करने से बेहतर action निकलता है। मैं root cause शब्द से बचता हूं क्योंकि वह लोगों को पहले ठीक ठाक लगने वाले जवाब पर रुक जाने का न्योता देता है; आमतौर पर तीन चार योगदान देने वाले कारण होते हैं और दिलचस्प वही होते हैं जो गायब guardrails हैं। actions का एक नाम और तारीख होनी चाहिए, आकार ईमानदारी से आंका जाए, और वे असली backlog में जाएं। जिस postmortem की actions कभी schedule ही नहीं होतीं वह न होने से बुरा है, क्योंकि वह लोगों को सिखाता है कि यह प्रोसेस सजावट है।