หน้าจอของตัวเชื่อมขึ้นว่า timeout คนดูแลจึงส่งรายการอีกครั้ง หลังจากนั้นฝ่ายบัญชีพบใบแจ้งหนี้สองใบสำหรับการส่งสินค้าครั้งเดียว เหตุการณ์สมมตินี้ต่อจากตอน 5 ของชุดสร้างทีม ครั้งนี้เราจะไล่ตั้งแต่เมื่อไรควรนัดทบทวน ไปจนถึงหลักฐานที่ต้องเห็นก่อนปิดงานแก้ ชุดสร้างทีม ตอน 5
Blameless postmortem คือการบันทึกและทบทวนเหตุขัดข้องโดยดูว่าคนตัดสินใจจากข้อมูลและเงื่อนไขอะไรในตอนนั้น เมื่อเข้าใจว่าเหตุใดทางเลือกนั้นจึงดูสมเหตุสมผล ทีมจะออกแบบหน้าจอ ขั้นตอน หรือการตรวจสอบที่ช่วยให้ครั้งหน้าตัดสินใจได้ดีขึ้น งานแก้ยังต้องมีเจ้าของ กำหนดส่ง และผลทดสอบที่ตรวจซ้ำได้ Google SRE เรื่องวัฒนธรรมการทบทวนเหตุขัดข้อง
ตกลงเกณฑ์ไว้ก่อนเกิดเหตุ
Google SRE ยกตัวอย่างเหตุที่ควรทบทวน เช่น ผู้ใช้ได้รับผลกระทบเกินเกณฑ์ ข้อมูลสูญหาย ต้องมีคนเข้าแทรกแซง ระบบเฝ้าระวังไม่ตรวจพบ หรือใช้เวลาแก้นานเกินที่กำหนด และเปิดให้ผู้เกี่ยวข้องขอทบทวนได้ สำหรับทีม ERP ผมจะเริ่มจากเหตุที่กระทบความถูกต้องของข้อมูล เช่น เอกสารซ้ำหรือยอดคลาดเคลื่อน เหตุที่ขวางงานสำคัญอย่างปิดบัญชีหรือส่งสินค้า และเหตุที่เกิดซ้ำแม้แต่ละครั้งใช้เวลาแก้ไม่นาน ให้ทีมตกลงเกณฑ์เวลาตามผลกระทบและความรับผิดชอบในโครงการ เกณฑ์เริ่มทบทวนจาก Google SRE
ช่วงที่เหตุยังดำเนินอยู่ ให้หยุดความเสียหายและดูแลผู้ใช้ก่อน เก็บลำดับเวลา หลักฐาน และขอบเขตผลกระทบไว้ตามสิทธิ์ที่กำหนด เมื่องานเริ่มนิ่งจึงตั้งคนนำประชุม คนจด และชวนคนที่เห็นเหตุการณ์คนละด้าน เช่น คนดูแลตัวเชื่อม ฝ่ายบัญชี และผู้รับผิดชอบการสื่อสารกับลูกค้า
ใช้เวลา 40 นาทีให้ได้ข้อสรุปที่ตามต่อได้
- นาที 0–5 ยืนยันผลกระทบและเป้าหมายการคุย ถามว่าลูกค้าทำงานอะไรไม่ได้ มีรายการใดได้รับผลกระทบ และข้อมูลส่วนไหนยังรอตรวจ
- นาที 5–15 ไล่ลำดับเวลา เทียบ log ของตัวเชื่อมกับเวลาที่ ERP สร้างเอกสารและเวลาที่ฝ่ายบัญชีพบปัญหา กำหนดเขตเวลาเดียวกัน และระบุว่าเวลาไหนเป็นการประมาณ
- นาที 15–30 หาเงื่อนไขที่ทำให้เกิดเหตุ ถามว่า “ตอนกดส่งซ้ำ หน้าจอแสดงอะไร?” และ “ถ้าเอกสารถูกสร้างแล้ว คนดูแลมีทางรู้ได้อย่างไร?” แยกหลักฐานที่ยืนยันได้จากสิ่งที่ยังเป็นสมมติฐาน
- นาที 30–40 ตกลงงานแก้และนัดตรวจผล ระบุคนรับผิดชอบ กำหนดส่ง และวิธีพิสูจน์ว่าแก้ได้ ถ้ายังขาดหลักฐาน ให้ตั้งงานตรวจเพิ่มพร้อมเวลาที่จะกลับมาสรุป
ในกรณีสมมตินี้ ERP สร้างใบแจ้งหนี้ใบแรกได้ แต่ตัวเชื่อมไม่ได้รับคำตอบทันเวลา ฝ่ายบัญชีพบเอกสารซ้ำหนึ่งคู่ก่อนส่งให้ลูกค้า ทีมพักการส่งซ้ำของตัวเชื่อมแล้วเทียบรายการในช่วงที่ได้รับผลกระทบ เวลาด้านล่างใช้เวลาไทย (UTC+7)
| เวลา | เหตุการณ์และหลักฐาน |
|---|---|
| 09:02 | ERP บันทึกใบแจ้งหนี้ใบแรก ส่วนตัวเชื่อมบันทึกว่าไม่ได้รับคำตอบทันเวลา |
| 09:06 | คนดูแลส่งรายการเดิมอีกครั้ง และ ERP บันทึกใบที่สองสำหรับรายการส่งสินค้าเดียวกัน |
| 09:24 | ฝ่ายบัญชีพบเอกสารสองใบตอนกระทบยอด |
| 09:30 | ทีมพักการส่งซ้ำและเริ่มตรวจเอกสารทั้งหมดในช่วงที่เกี่ยวข้อง |
| 10:10 | ฝ่ายบัญชียืนยันขอบเขตผลกระทบและจัดการเอกสารซ้ำตามขั้นตอน ทีมจึงกลับมาเดินงานหลังตรวจเงื่อนไขที่ตกลง |
หน้าจอแสดง timeout โดยยังแยกไม่ได้ว่าการบันทึกสำเร็จหรือไม่ ตัวเชื่อมส่งคำขอเดิมอีกครั้งได้โดยไม่มีตัวควบคุมการสร้างซ้ำ และการเฝ้าระวังเห็นเฉพาะความล้มเหลวของงานเชื่อมต่อ เหตุจึงมาปรากฏตอนฝ่ายบัญชีกระทบยอด งานแก้ควรแตะทั้งการป้องกัน การช่วยคนตัดสินใจ และการตรวจพบ แนวทางวิเคราะห์เหตุและกำหนดงานแก้จาก Google SRE Workbook
กำหนดหลักฐานสำหรับปิดงานแก้
- หัวหน้าทีมเชื่อมระบบ ภายใน 5 วันทำการ ใช้เลขอ้างอิงคงที่ของรายการต้นทางกับตัวควบคุมการสร้างซ้ำ ทดสอบกรณี ERP บันทึกสำเร็จแต่คำตอบหาย แล้วส่งคำขอเดิมอีกครั้ง ผลต้องเหลือใบแจ้งหนี้หนึ่งใบ
- ผู้รับผิดชอบหน้าจอปฏิบัติการ ภายใน 7 วันทำการ แสดงสถานะ “ยังไม่ทราบผล” และเลขอ้างอิงสำหรับตรวจใน ERP ให้คนที่เข้าเวรลองสถานการณ์จำลองและยืนยันว่ารู้ว่าต้องตรวจอะไรจึงจะส่งซ้ำได้
- ผู้รับผิดชอบการเฝ้าระวัง ภายใน 10 วันทำการ เพิ่มการตรวจเลขอ้างอิงซ้ำ ใช้ข้อมูลทดสอบตรวจว่าแจ้งถึงคนที่รับผิดชอบพร้อมข้อมูลพอให้ตามรายการได้
แบบฟอร์มคัดลอกไปใช้
เหตุการณ์ / วันที่ / เขตเวลา / คนประสาน
ผลกระทบต่อผู้ใช้และข้อมูล / ส่วนที่ยังไม่ยืนยัน
ลำดับเวลา (เวลา | สิ่งที่เกิด | หลักฐานหรือแหล่งข้อมูล)
สิ่งที่ผู้ปฏิบัติงานเห็นตอนตัดสินใจ
เงื่อนไขที่ทำให้เกิดเหตุ / สิ่งที่ช่วยลดผลกระทบ
งานแก้ (สิ่งที่จะทำ | เจ้าของ | กำหนดส่ง | วิธีตรวจผล)
ลิงก์หลักฐานแบบจำกัดสิทธิ์ / วันติดตามก่อนแชร์ ให้แทนชื่อและเลขเอกสารลูกค้าด้วยรหัสอ้างอิงเท่าที่จำเป็น เก็บ log ดิบหรือข้อมูลบัญชีไว้ในที่จำกัดสิทธิ์ รายงานสำหรับทีมวงกว้างใช้เฉพาะรายละเอียดที่ช่วยให้เรียนรู้ ส่วนการแจ้งลูกค้าใช้ช่องทางและผู้รับผิดชอบของโครงการ
เมื่อครบหนึ่งเดือน ให้ตรวจว่าเหตุที่เข้าเกณฑ์ได้รับการทบทวนกี่เหตุจากทั้งหมด งานแก้ครบกำหนดกี่ข้อและมีหลักฐานตรวจผลกี่ข้อ รวมถึงมีเหตุซ้ำในกระบวนการเดิมหรือไม่ ถ้าอัตราปิดงานสูงแต่ยังเจอเอกสารซ้ำ ให้กลับไปตรวจว่าชุดทดสอบครอบคลุมจังหวะที่ระบบบันทึกสำเร็จแต่ไม่ได้ตอบกลับจริงหรือเปล่า แนวทางติดตามงานแก้จาก Google SRE Workbook