पोस्टमॉर्टम को blameless क्या बनाता है, और उसमें क्या क्या होना चाहिए?

blameless का मतलब है कि लिखत यह पूछती है कि सिस्टम ने एक समझदार इंसान को वह कदम उठाने कैसे दिया, यह नहीं कि तोड़ा किसने। इसमें टाइमलाइन, SLO के मुकाबले नापा गया यूजर पर असर, योगदान देने वाले कारण, क्या अच्छा रहा, और नाम तथा तारीख वाले action item होने चाहिए। ऐसा होना चाहिए था जैसे काल्पनिक वाक्य बंद करें। असली परीक्षा यह है कि वे काम सच में पूरे होते हैं या नहीं, तो उन्हें किसी और काम की तरह ट्रैक करें।

blameless होना भला बनने की बात नहीं, सच निकालने की बात है। अगर लोगों को सजा की उम्मीद हो, तो आपको धुली पुंछी टाइमलाइन मिलती है और आप कभी नहीं जान पाते कि असल में हुआ क्या, तो अगला इंसिडेंट हूबहू वैसा ही होता है। ठोस तौर पर मुझे समय के ठप्पों वाली टाइमलाइन चाहिए, नापा हुआ असर (हमने महीने के एरर बजट का 60% जला दिया और 12,000 checkout फेल हुए), एक अकेले root cause के बजाय योगदान देने वाले कारण, और क्या अच्छा रहा वाला हिस्सा, जिसे लोग छोड़ देते हैं और जिससे पता चलता है कि runbook या rollback की टूलिंग ने आपको बचाया। action item का एक मालिक और तारीख चाहिए, और वे असली प्राथमिकता के साथ सामान्य backlog में जाते हैं, वरना आपने एक सुंदर दस्तावेज लिखा है जो कुछ बदलता नहीं। भाषा का जो नियम मैं लागू करता हूं वह है कोई काल्पनिक वाक्य नहीं: यह नहीं कि इंजीनियर को ध्यान देना चाहिए था, बल्कि यह कि डिप्लॉय टूल ने बिना canary और बिना पुष्टि के बदलाव जाने दिया। यह नए सिरे से रखना लगभग हमेशा किसी ट्रेनिंग की याद दिलाने से बेहतर हल देता है।