เคสสมมติ: ธุรกิจขายเครื่องครัวออนไลน์สร้างระบบ 'เฝ้าระวัง' ให้ tracking หลังเจอ Conversion หายเงียบสามครั้งในปีเดียว

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

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

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

จุดเริ่มต้น: ไม่มีอะไรเฝ้าระวังเลยนอกจากตาคน

ก่อนเริ่มโครงการนี้ วิธีเดียวที่ 'ครัวสวย' รู้ว่าระบบ tracking มีปัญหา คือมีคนสังเกตว่ายอดขายในแอดกับยอดขายจริงต่างกันมาก ซึ่งกว่าจะสังเกตได้ก็มักผ่านไปหลายวันแล้ว ทีมตัดสินใจว่าขั้นแรกต้องมีอะไรบางอย่างที่ 'เฝ้าดู' แทนคน ไม่ใช่รอให้คนสังเกตเอง

ขั้นที่ 1: วางแดชบอร์ดสุขภาพ pipeline

สิ่งแรกที่ทีมทำคือวางแดชบอร์ดที่แสดงอัตราส่งสำเร็จ ความลึกของคิว และความสดของข้อมูล ตามหลักการในการเฝ้าระวังสุขภาพ pipeline ใช้เวลาตั้งค่าประมาณหนึ่งสัปดาห์ และเริ่มเห็นผลทันทีตั้งแต่สัปดาห์แรกที่เปิดใช้งาน เพราะจับได้ว่ามี event บางประเภทถูกปฏิเสธเงียบ ๆ อยู่ราว 3% ทุกวัน ซึ่งไม่มีใครเคยรู้มาก่อน

ขั้นที่ 2: เขียน runbook สำหรับเหตุการณ์ที่พบบ่อย

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

ขั้นที่ 3: เปลี่ยนวิธี deploy ให้ปลอดภัยขึ้น

เหตุการณ์ครั้งที่สามที่เกิดจากการเปลี่ยนโครงสร้างข้อมูลกลางคัน ทำให้ทีมตระหนักว่าการ deploy แบบเปลี่ยนทีเดียวทั้งหมดมีความเสี่ยงสูงเกินไป จึงเริ่มปรับมาใช้วิธี canary deploy สำหรับการเปลี่ยนแปลงที่กระทบ logic การประมวลผลข้อมูล Conversion โดยตรง ตามแนวทางที่อธิบายไว้ในการ deploy แบบ canary

ขั้นที่ 4: ปิดช่องว่างที่เหลือ

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

ผลลัพธ์หลังครบหนึ่งปีของการทำเรื่องนี้

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

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

สรุป

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

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

• ปัญหา Conversion หายแบบไม่รู้ตัวซ้ำ ๆ มักมาจากการไม่มีระบบเฝ้าระวังตัวเอง ไม่ใช่แค่บั๊กแยกกันแต่ละครั้ง
• ลำดับที่ใช้ได้ผลคือเริ่มจากแดชบอร์ดเฝ้าระวัง ตามด้วย runbook วิธี deploy ที่ปลอดภัยขึ้น แล้วค่อยปิดช่องว่างที่เหลือ
• ความน่าเชื่อถือของระบบมาจากการเห็นปัญหาเร็วและรู้วิธีรับมือ ไม่ใช่จากการไม่มีปัญหาเลย

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