Post-Incident Review: คุยเรื่องที่พลาดโดยไม่หาคนผิด
หลังระบบกลับมาใช้ได้ ทีมเล็กควรทบทวนเหตุอย่างไรให้เห็นลำดับจริง ปัจจัยที่ทำให้งานสะดุด และงานแก้ที่มีคนรับต่อ โดยไม่เปลี่ยนวงคุยเป็นการโทษกัน
ระบบรับออเดอร์กลับมาใช้งานได้แล้ว แต่ระหว่างที่ระบบสะดุด มีบางคนเห็นข้อความผิดพลาด บางคนรู้จากลูกค้า และคนที่แก้ระบบก็ทำหลายอย่างพร้อมกัน ถ้าพรุ่งนี้ทีมจะคุยกันว่าเกิดอะไรขึ้น ผมอยากให้เปิดจากบันทึกเหตุและสิ่งที่แต่ละคนรู้ในตอนนั้น มากกว่าเปิดด้วยคำถามว่า “ใครทำพัง”
Post-Incident Review คือการทบทวนหลังเหตุสงบ เพื่อให้ครั้งหน้าเรารู้เร็วขึ้น ตัดสินใจดีขึ้น หรือทำให้ผลกระทบเล็กลง มันมีประโยชน์กับทีมเล็กเป็นพิเศษ เพราะคนหนึ่งคนอาจรับทั้งแจ้งเตือน แก้ระบบ และตอบลูกค้า หากจำเหตุจากความรู้สึกอย่างเดียว เราอาจซ่อมเฉพาะส่วนที่ดังที่สุดในวันนั้น แล้วปล่อยช่องว่างเดิมไว้
ตัวอย่างระบบรับออเดอร์นี้เป็นสถานการณ์สมมติสำหรับเดินตามวิธีคิด ไม่ใช่เหตุที่ผมอ้างว่าเคยเจอ คำถามที่อยากได้จากวงคุยคือ “ตรงไหนที่ทีมมองไม่เห็นหรือทำต่อไม่ทัน และจะแก้จุดไหนก่อน” ไม่จำเป็นต้องได้รายงานหนา ๆ หากกลับไปทำงานต่อได้ชัดกว่าเดิม
เอาเหตุการณ์มาวางเรียง ก่อนอธิบายสาเหตุ
ผมจะเริ่มจากสิ่งที่หาได้จริง: เวลาแจ้งเตือนจากระบบ เวลาแชตที่ทีมพบปัญหา รายการเปลี่ยนแปลงระบบ ข้อความที่ส่งให้ลูกค้า และเวลาที่ออเดอร์เริ่มกลับมาวิ่ง แต่ละรายการควรแยกว่าเป็นหลักฐานจากระบบ เป็นคำบอกเล่าของคนในเหตุ หรือยังเป็นข้อสันนิษฐาน ไม่ต้องฝืนเติมช่องว่างให้ timeline ดูสวย
ในตัวอย่างนี้ สมมติว่ามีการเปลี่ยนค่าบางอย่างก่อนระบบสะดุด และทีมรู้ผลกระทบจากลูกค้าก่อน alert การเปลี่ยนค่าอาจเกี่ยวหรือไม่เกี่ยวก็ได้ ต้องดูหลักฐานเพิ่ม ส่วนการรู้จากลูกค้าก่อนบอกได้แล้วว่าเส้นทางแจ้งเตือนของเรามีช่องว่าง การแยกสองเรื่องนี้ช่วยให้ไม่รีบสรุปว่าคนที่กดเปลี่ยนค่าเป็นต้นเหตุทั้งหมด
ผมชอบถามด้วยว่า ณ เวลานั้นแต่ละคนเห็นหน้าจออะไร มีข้อมูลอะไร และกำลังรับงานอื่นอยู่หรือเปล่า การตัดสินใจที่ดูแปลกเมื่อมองย้อนหลังอาจสมเหตุสมผลภายใต้ข้อมูลที่มีตอนนั้น ถ้าข้ามคำถามนี้ วงทบทวนจะกลายเป็นการให้คะแนนคนด้วยคำตอบที่เราเพิ่งรู้หลังเหตุจบ ซึ่งไม่ค่อยยุติธรรมและไม่ได้ช่วยแก้ระบบ
อย่าหยุดที่ประโยค “คนลืมเช็ก”
เมื่อ timeline พอใช้ได้ ค่อยถามว่ามีอะไรทำให้เหตุลุกลามหรือกู้กลับช้า เช่น alert ส่งไปยังบัญชีที่ไม่มีคนดู ขั้นตอนย้อนการเปลี่ยนค่าอยู่ในหัวคนเดียว หรือคนตอบลูกค้าไม่รู้ว่าทีมเทคนิคยืนยันอะไรแล้ว ปัจจัยเหล่านี้ไม่ได้ลบความรับผิดชอบของใคร แต่ทำให้เห็นจุดที่แก้แล้วช่วยคนถัดไปด้วย
คำว่า no-blame ไม่ได้หมายถึงห้ามพูดถึงการตัดสินใจผิด เราควรพูดตรง ๆ ว่าทำอะไรไปและผลเป็นอย่างไร เพียงแต่ถามต่อว่าทำไมทางเลือกนั้นจึงดูเหมาะในขณะนั้น มีสัญญาณอะไรที่ขาด และระบบงานเปิดทางให้ตรวจทานหรือถอยกลับได้แค่ไหน ถ้ามีเรื่องวินัย การละเมิดเจตนา หรือข้อกฎหมายจริง ก็ต้องจัดการในช่องทางที่เหมาะ ไม่ควรใช้วงเรียนรู้เป็นเวทีตัดสินโดยไม่มีข้อมูลครบ
สำหรับทีมเล็ก ผมจะไม่บังคับหาสาเหตุเดียวเสมอไป เหตุอาจเริ่มจากค่าที่เปลี่ยน แต่ผลกระทบยาวเพราะ alert ไม่ถึงคน และออเดอร์ที่ค้างไม่ถูกตรวจหลังระบบกลับมา การเห็นปัจจัยร่วมทำให้เลือกงานแก้ได้ดีกว่าเขียนท้ายเอกสารว่า “ระวังให้มากขึ้น” NCSC แนะนำ ให้ทบทวนสิ่งที่ทำระหว่างตอบสนองเหตุ ทั้งส่วนที่ทำได้ดีและส่วนที่ควรปรับ แล้วนำบทเรียนไปแก้แผนรับมือ
ปิดวงด้วยงานที่กลับมาตรวจได้
ผมจะเลือกงานแก้เพียงไม่กี่ชิ้นที่เปลี่ยนผลลัพธ์จริงในตัวอย่างนี้: ตรวจว่า alert ไปถึงคนที่รับช่วงได้, ทำวิธีถอยค่าที่เปลี่ยนให้ค้นเจอ, และตรวจออเดอร์ค้างหลังระบบเปิดอีกครั้ง งานแต่ละชิ้นควรมีคนรับ วันกลับมาดู และวิธีพิสูจน์ว่าใช้ได้ การเขียนว่า “ปรับ monitoring” โดยไม่มีใครลองรับ alert ยังไม่ช่วยมากนัก
บางงานอาจยังตอบไม่ได้ทันที เช่น log เก็บไม่พอจะยืนยันว่าค่าที่เปลี่ยนเป็นต้นเหตุหรือไม่ ก็ระบุความไม่แน่ใจไว้และตัดสินใจว่าคุ้มจะสืบต่อไหม ไม่ต้องสร้างข้อเท็จจริงใหม่เพื่อปิดรายงาน หากผลกระทบกว้าง มีข้อมูลอ่อนไหว หรือมีหน้าที่ต้องแจ้งผู้เกี่ยวข้อง วงทบทวนสั้น ๆ นี้ก็ไม่ทดแทนการสืบสวนและขั้นตอนตามข้อกำหนด
เอกสารที่ผมอยากเก็บหลังคุยจบจึงสั้นได้: เกิดอะไรและกระทบงานไหน, เรารู้อะไรจากหลักฐานและยังไม่รู้อะไร, อะไรช่วยหรือขวางการตอบสนอง, และงานแก้ที่มีเจ้าของพร้อมวันตรวจ ผลที่ดีไม่ใช่ทุกคนเห็นตรงกันหมด แต่ครั้งหน้าทีมมีทางสังเกตเหตุ ตัดสินใจ และกู้บริการที่ชัดกว่าเดิม แนวทาง NCSC เรื่อง lessons learned ก็เน้นให้บทเรียนครอบคลุมทั้งด้านเทคนิค กระบวนการ และคน รวมถึงมีการนำสิ่งที่พบไปปรับจริง
ถ้าเพิ่งผ่านเหตุมา ลองหยิบ timeline ที่มีอยู่มาดูก่อนว่าช่วงใดทีมต้องเดา แล้วเลือกแก้ช่องว่างนั้นหนึ่งจุดให้ตรวจซ้ำได้ วงคุยจะคุ้มเวลามากกว่าการพยายามเขียนรายงานให้ดูสมบูรณ์ตั้งแต่รอบแรกครับ
อ่านต่อที่เกี่ยวข้อง
- Incident Response สำหรับ SME ที่ไม่มี SOC สำหรับการเตรียมบทบาทและทางติดต่อก่อนเกิดเหตุ
- ทำไม Log ถึงสำคัญตอนเกิด Incident สำหรับหลักฐานที่ช่วยต่อ timeline