ตัวเลข Conversion เปลี่ยนไปจากเมื่อวาน แต่ไม่มีใครรู้ว่าทำไม: เก็บ Audit Log แบบ Event Sourcing ให้ย้อนดูได้ทุกจุด

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

ปัญหานี้เกิดจากการออกแบบฐานข้อมูลแบบ 'เก็บสถานะล่าสุด' (state-based) ซึ่งเป็นวิธีที่ง่ายและพบได้ทั่วไป แต่มีจุดอ่อนตรงที่ไม่มีความทรงจำในตัว พอมีคำถามว่า 'ทำไมค่าตอนนี้ถึงต่างจากที่เคยเห็น' ระบบก็ตอบไม่ได้เลย

ทางเลือกที่หลายระบบ tracking ระดับสูงขึ้นเริ่มนำมาใช้คือแนวคิด Event Sourcing ซึ่งเปลี่ยนวิธีคิดจาก 'เก็บสถานะปัจจุบัน' เป็น 'เก็บทุกเหตุการณ์ที่เคยเกิด' แล้วคำนวณสถานะปัจจุบันจากประวัติเหตุการณ์เหล่านั้นทุกครั้ง

เก็บสถานะ vs เก็บเหตุการณ์ ต่างกันตรงไหน

ระบบแบบเก็บสถานะ (state-based) จะมีแถวข้อมูลหนึ่งแถวต่อหนึ่งออเดอร์ พอมีการอัปเดต เช่นลูกค้าขอคืนเงินบางส่วน ระบบจะแก้ไขค่าตรงแถวนั้นเลย ค่าก่อนหน้าจะหายไปทันที เหลือแค่ค่าล่าสุดให้เห็น

ระบบแบบเก็บเหตุการณ์ (event-based) จะไม่แก้ไขแถวเดิม แต่บันทึกเป็นเหตุการณ์ใหม่ต่อท้ายเสมอ เช่น 'สร้างออเดอร์ 1,200 บาท' ตามด้วย 'คืนเงินบางส่วน 300 บาท' สถานะปัจจุบันของออเดอร์นั้นคือผลรวมของทุกเหตุการณ์ที่เกิดกับมัน (1,200 - 300 = 900 บาท) แต่ประวัติทั้งสองเหตุการณ์ยังอยู่ครบ ย้อนดูได้ตลอด

ประโยชน์ที่มากกว่าแค่ 'ย้อนดูได้'

• ตรวจสอบข้อพิพาทได้ชัดเจน เช่นเมื่อลูกค้าหรือทีมการเงินโต้แย้งตัวเลข สามารถดึงประวัติเหตุการณ์ทั้งหมดของออเดอร์นั้นมาอธิบายได้ทันทีโดยไม่ต้องเดา
• สร้างรายงานย้อนหลังที่ถูกต้องได้ เช่นอยากรู้ว่ายอด Conversion ณ วันที่ 15 ของเดือนที่แล้วเป็นเท่าไหร่ (ไม่ใช่ยอดปัจจุบันที่ถูกแก้ไขไปแล้ว) สามารถคำนวณย้อนกลับจากเหตุการณ์ที่เกิดขึ้นถึงวันนั้นได้จริง
• ดีบักบั๊กได้ง่ายขึ้นมาก เพราะเห็นลำดับเหตุการณ์ทั้งหมดที่นำไปสู่ค่าที่ผิดปกติ แทนที่จะเห็นแค่ผลลัพธ์สุดท้ายที่ผิด แล้วต้องเดาว่าอะไรทำให้มันผิด คล้ายกับที่ใช้หลักการนี้ช่วยตามไล่หาสาเหตุคะแนนคุณภาพข้อมูลที่ร่วง และตอบคำถามเรื่องความเป็นเจ้าของข้อมูลได้ชัดเจนขึ้นเมื่อมีข้อพิพาท

จะเริ่มวางระบบนี้ยังไงโดยไม่ต้องรื้อทุกอย่างใหม่

1. ไม่จำเป็นต้องเปลี่ยนทั้งระบบเป็น Event Sourcing เต็มรูปแบบทันที เริ่มจากเพิ่มตาราง audit log แยกต่างหาก ที่บันทึกทุกครั้งที่มีการเปลี่ยนแปลงข้อมูลสำคัญ เช่นยอด Conversion, สถานะออเดอร์, การจับคู่ LINE UID
2. แต่ละแถวใน audit log ควรมีอย่างน้อย เวลาที่เกิดเหตุการณ์ ค่าก่อนเปลี่ยน ค่าหลังเปลี่ยน และแหล่งที่มาของการเปลี่ยนแปลง (ระบบอัตโนมัติหรือคนแก้มือ)
3. ตั้งกฎว่าห้ามลบแถวใน audit log เด็ดขาด ต่อให้ข้อมูลนั้นดูไม่จำเป็นแล้วก็ตาม เพราะจุดประสงค์คือการเก็บประวัติแบบสมบูรณ์ ไม่ใช่แค่ข้อมูลที่ใช้งานอยู่ปัจจุบัน
4. เมื่อระบบโตขึ้นและมีคำถามย้อนหลังบ่อยขึ้น ค่อยพิจารณาย้ายไปใช้สถาปัตยกรรม Event Sourcing เต็มรูปแบบ ซึ่งจะซับซ้อนกว่านี้แต่ให้ความสามารถในการย้อนรอยที่ลึกกว่ามาก

ข้อควรระวังก่อนทำ

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

ทีมที่ไม่คุ้นกับแนวคิดนี้อาจใช้เวลาปรับตัวสักพัก เพราะการเขียนคำสั่งดึงข้อมูลจะซับซ้อนกว่าการดึงค่าจากแถวเดียวตรง ๆ แนะนำให้เริ่มจากส่วนที่สำคัญที่สุดก่อน เช่นข้อมูล Conversion ไม่ต้องทำทั้งระบบพร้อมกัน ควรให้สิทธิ์เข้าถึง audit log ตามหลักการควบคุมการเข้าถึงข้อมูลลูกค้าด้วย ไม่ใช่เปิดให้ทุกคนอ่านได้อย่างอิสระ

สรุป

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

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

• ระบบเก็บสถานะล่าสุดอย่างเดียวตอบไม่ได้ว่าทำไมตัวเลขเปลี่ยน
• Event Sourcing เก็บทุกเหตุการณ์แบบไม่ลบทิ้ง แล้วคำนวณสถานะปัจจุบันจากประวัตินั้น
• เริ่มจาก audit log ง่าย ๆ สำหรับข้อมูลสำคัญก่อน ไม่ต้องรื้อทั้งระบบพร้อมกัน

คำถามที่พบบ่อย