เทมเพลต Postmortem ทางวิศวกรรม (ไม่โทษกัน นำไปปฏิบัติได้)

ทำไม Postmortem ถึงกลายเป็นการหาคนผิด

Postmortem ล้มเหลวในรูปแบบเฉพาะตัว คือห้องประชุมเริ่มระบุสาเหตุก่อนที่ห้องจะมีไทม์ไลน์ร่วมกัน มีคนพูดว่า "การดีพลอยทำให้เกิดเรื่องนี้" ก่อนที่เวลาการดีพลอยจะถูกยืนยัน อีกคนพูดว่า "การแจ้งเตือนไม่ทำงาน" โดยไม่รู้ว่าการแจ้งเตือนนั้นถูกตั้งค่าไว้สำหรับสถานการณ์นี้หรือไม่ การสนทนากลายเป็นการโต้เถียงเรื่องสาเหตุก่อนที่ใครจะยืนยันได้ว่าเกิดอะไรขึ้นจริง ในลำดับใด

การแก้ไขเป็นเรื่องเชิงโครงสร้าง สร้างไทม์ไลน์ของเหตุการณ์ร่วมกันตั้งแต่ต้นของ Postmortem ก่อนที่ใครจะระบุสาเหตุราก เมื่อทั้งห้องได้ดูลำดับเหตุการณ์ — อะไรเปลี่ยนเมื่อไร ใครเห็นอะไรตอนไหน — สาเหตุก็จะถกเถียงได้ง่ายขึ้นมาก และมีแนวโน้มน้อยลงมากที่จะกลายเป็นการโทษกัน นี่คือความผิดพลาดเรื่องลำดับที่เทมเพลตส่วนใหญ่ทำ คือวางสาเหตุรากไว้ก่อนไทม์ไลน์เพราะสาเหตุรากคือสิ่งที่เทมเพลตมีไว้เพื่อทำ แต่ไทม์ไลน์ต่างหากที่ทำให้สาเหตุรากซื่อตรง

วาระการประชุม (คัดลอกไปใช้ได้เลย)

ระยะเวลา: 60 นาทีสำหรับเหตุการณ์ที่ตรงไปตรงมา 90 นาทีสำหรับความล้มเหลวที่ซับซ้อนหลายระบบ
รูปแบบ: มีผู้ดำเนินรายการ ทุกคนที่รับมือเหตุการณ์และวิศวกรที่อยู่เวรอยู่ร่วมด้วย เตรียมตัวแบบ async ด้วยเอกสารอ่านล่วงหน้า

ส่วนที่ 1 — สรุปเหตุการณ์ (5 นาที)

วันที่และระยะเวลาของเหตุการณ์
การจำแนกระดับความรุนแรงและระบบที่ได้รับผลกระทบ
ใครเป็นคนตรวจพบและพบได้อย่างไร (รายงานจากลูกค้า การแจ้งเตือน วิศวกร ระบบเฝ้าติดตาม)
ส่วนนี้ว่าด้วยข้อเท็จจริงเท่านั้น ยังไม่มีการวิเคราะห์

ส่วนที่ 2 — ไทม์ไลน์ (20 นาที)

สร้างไทม์ไลน์ร่วมกันบนหน้าจอ — ไม่ใช่เอกสารที่เขียนไว้ล่วงหน้า
ลำดับ: อะไรเปลี่ยน สังเกตเห็นอะไร ใครลงมือทำ ตัดสินใจอะไร
ทุกจุดเวลาควรมีแหล่งอ้างอิง (บรรทัดใน log, PagerDuty, ข้อความ Slack)
เมื่อไทม์ไลน์เสร็จ ถามว่า: ทุกคนเห็นด้วยไหมว่านี่คือสิ่งที่เกิดขึ้น? แก้ข้อขัดแย้งให้จบก่อนไปต่อ

ส่วนที่ 3 — สรุปผลกระทบ (5 นาที)

ผลกระทบต่อลูกค้า: ใครได้รับผลกระทบ นานเท่าไร ในลักษณะใด
ผลกระทบทางธุรกิจ: รายได้ SLA ชื่อเสียง
ผลกระทบภายใน: ชั่วโมงการอยู่เวร การรบกวนทีม
เก็บส่วนนี้ไว้ที่ข้อเท็จจริง มันยึดคำถาม "มันแย่แค่ไหน" ไว้โดยไม่ต้องใส่ความเห็น

ส่วนที่ 4 — สาเหตุรากและปัจจัยร่วม (20 นาที)

สาเหตุราก: การเปลี่ยนแปลงหรือเงื่อนไขที่ใกล้ที่สุดซึ่งทำให้เหตุการณ์เกิดขึ้นได้
ปัจจัยร่วม: เงื่อนไขที่ทำให้มันแย่ลง ตรวจจับยากขึ้น หรือแก้ไขได้ช้าลง
Postmortem ที่มีประโยชน์ที่สุดมักระบุปัจจัยร่วม 3-5 ข้อควบคู่กับสาเหตุราก การแก้แค่สาเหตุรากมักมองข้ามเงื่อนไขเชิงระบบ
ถามสำหรับแต่ละปัจจัย: มีบุคคลหรือทีมใดตัดสินใจในแบบที่ดูสมเหตุสมผลตามข้อมูลที่มีอยู่ตอนนั้นหรือไม่? ถ้าใช่ ปัจจัยนั้นเป็นเชิงระบบ ไม่ใช่เรื่องส่วนบุคคล

ส่วนที่ 5 — สิ่งที่ทำได้ดี (5 นาที)

การตรวจจับหรือการตอบสนองอะไรที่ทำได้ดีกว่าที่คาด?
กระบวนการหรือเครื่องมือที่มีอยู่อะไรที่จำกัดวงความเสียหาย?
เหล่านี้คือแนวปฏิบัติที่ควรทำให้เป็นทางการ — ถ้า runbook ช่วยประหยัดเวลาได้ 20 นาที ให้จดไว้ เพื่อให้ runbook ได้รับการดูแลรักษาต่อไป

ส่วนที่ 6 — Action item (15 นาที)

แต่ละ action item ต้องจัดการกับสาเหตุรากหรือปัจจัยร่วม — ไม่ใช่การปรับปรุงทั่วไป
หนึ่งผู้รับผิดชอบต่อหนึ่งข้อ กำหนดส่งที่สะท้อนความเร่งด่วน
จัดหมวดหมู่: ตรวจจับเร็วขึ้น / กู้คืนเร็วขึ้น / ป้องกันการเกิดซ้ำ
จำกัดไว้ที่การกระทำที่ทีมทำได้จริงก่อนเหตุการณ์ครั้งถัดไป ไม่ใช่ Roadmap ความน่าเชื่อถือแบบครอบจักรวาล

อะไรที่ทำให้เทมเพลต Postmortem ล้มเหลว

ลำดับที่เอาสาเหตุรากขึ้นก่อนเป็นปัญหาเชิงโครงสร้างหลัก — ครอบคลุมไปแล้วข้างต้น ปัญหาที่สองคือการมอง "action item" เป็นหมวดหมู่เดียว การปรับปรุงการตรวจจับ การปรับปรุงการกู้คืน และการปรับปรุงการป้องกัน ต้องการผู้รับผิดชอบและกรอบเวลาที่ต่างกัน การผสมมันเข้าด้วยกันจะได้ลิสต์ที่กินเวลาหกเดือนและครอบคลุมสามทีม ซึ่งทำให้ความรับผิดชอบกระจายและไม่มีข้อไหนได้ถูกทำจริง

รูปแบบความล้มเหลวที่สามคือการข้าม "สิ่งที่ทำได้ดี" เพราะรู้สึกเหมือนเป็นการมองโลกในแง่ดีที่ไม่เหมาะสมหลังเกิดเหตุ แต่มันไม่ใช่ — มันเป็นวิธีเดียวที่เป็นระบบในการระบุและทำให้แนวปฏิบัติที่ได้ผลภายใต้แรงกดดันเป็นทางการ ถ้าระบบเฝ้าติดตามที่ตรวจจับปัญหาไม่ได้อยู่ใน Roadmap ของใครเลย การได้เรียนรู้ว่ามันสำคัญก็คุ้มค่าที่จะบันทึกไว้ มิฉะนั้นมันจะถูกลดความสำคัญหลังเหตุการณ์จางหายไป และคุณจะตาบอดในครั้งถัดไป

ต้นทุนที่ทบต้นของเหตุการณ์ที่ปัจจัยร่วมไม่ได้รับการแก้ไข และ runbook ที่ได้ผลแต่ไม่ได้รับการดูแลรักษา สะสมเร็วมาก ภาษีการประชุม ครอบคลุมว่าภาระการประชุมที่วนซ้ำและหนี้จากการทบทวนเหตุการณ์มีปฏิสัมพันธ์กันอย่างไร

ทำไมการเก็บบันทึก Postmortem จึงยากเป็นพิเศษ

การถกเถียงใน Postmortem สร้างเนื้อหาที่หนาแน่นและไร้โครงสร้างอย่างรวดเร็ว: การประกอบไทม์ไลน์ การตีความที่ขัดแย้งกัน การมอบหมาย action item ที่มีหลายคนเกี่ยวข้อง รายละเอียดทางเทคนิคที่จะไม่มีความหมายในบันทึกคำต่อคำหากไม่มีบริบท สรุป Postmortem ที่เขียนจากความทรงจำหรือเสียงที่ตัดต่อแล้วมักไม่ครบถ้วนเสมอ และบันทึก Postmortem ที่ไม่ครบถ้วนก็ไร้ประโยชน์สำหรับการมองหารูปแบบข้ามเหตุการณ์

Pavleur เก็บการถกเถียง Postmortem ฉบับเต็มและสร้างรายงานโดยอัตโนมัติ — ไทม์ไลน์ตามที่ประกอบขึ้น ปัจจัยร่วมตามที่ระบุ action item พร้อมผู้รับผิดชอบและหมวดหมู่ตามที่พูดในการประชุม ถ้าใครแชร์หน้าจอเพื่อแสดง log ที่ตัดออกมา กราฟการเฝ้าติดตาม หรือการตั้งค่าการแจ้งเตือนที่ไม่ทำงาน ภาพนั้นจะเป็นส่วนหนึ่งของรายงาน เครื่องมือแบบเสียงอย่างเดียวพลาดสิ่งนี้ไปหมด บันทึก Postmortem ที่ไม่มีกราฟก็คือบันทึกที่ไม่มีหลักฐาน ใครก็ตามในทีม — รวมถึงวิศวกรที่เข้ามาหลังเกิดเหตุ — สามารถอ่านบันทึกฉบับเต็มที่มีบริบทภาพได้โดยไม่ต้องขอให้ใครมาประกอบร่างใหม่ สำหรับการเปรียบเทียบโดยตรงกับเครื่องมืออื่นในเรื่องนี้: Pavleur เทียบกับทางเลือกอื่น

ว่าด้วยความถี่ของ Postmortem

ทำ Postmortem ภายใน 48 ชั่วโมงหลังแก้ไขเหตุการณ์เสร็จ ในขณะที่รายละเอียดยังสดใหม่ ยิ่งรอนานเท่าไร การประกอบไทม์ไลน์ก็ยิ่งพึ่งพาความทรงจำมากกว่า log และความทรงจำก็ไม่น่าเชื่อถือภายใต้ความเครียด สำหรับเหตุการณ์ความรุนแรงสูง 24 ชั่วโมงดีกว่า สำหรับเหตุการณ์เล็กน้อย Postmortem แบบ async — เอกสารร่วมที่มีคำถามชี้นำแบบมีโครงสร้าง แล้วทบทวนพร้อมกัน — อาจมีประสิทธิภาพกว่าการประชุมเต็มรูปแบบ รูปแบบการประชุมมีค่ามากที่สุดเมื่อเหตุการณ์กำกวมหรือมีเดิมพันสูงพอที่การตีความร่วมกันจะสำคัญ