สรุปสั้น ๆ
Webhook ที่ตอบ error ต่อเนื่องคือหนึ่งในจุดเสียหายที่สุดของระบบ tracking เพราะ LINE จะพยายามส่งซ้ำในกรอบเวลาจำกัดแล้วเลิกส่ง ถ้าไม่มีระบบแจ้งเตือนอัตโนมัติ กว่าจะรู้ตัวมักผ่านไปหลายชั่วโมงหรือเป็นวัน สิ่งที่ป้องกันได้คือ health check และ alert ที่แยกจากดวงตาคน
เหตุการณ์นี้เกิดกับทีมพัฒนาที่ผมเคยช่วยดูระบบให้ วันหนึ่งมีการอัปเดต dependency บนเซิร์ฟเวอร์ตอนตีสอง แล้วบริการที่รับ webhook จาก LINE ก็เริ่มตอบ error 500 ตั้งแต่ตอนนั้นโดยไม่มีใครรู้ กว่าจะมีคนสังเกตเห็นว่ายอด conversion หายก็ปาไปช่วงบ่ายของวันถัดมา รวมเวลาที่ webhook ล่มไปแล้วเกือบ 14 ชั่วโมง
สิ่งที่น่ากลัวที่สุดไม่ใช่การล่ม เพราะระบบไหนก็มีโอกาสล่มได้ สิ่งที่น่ากลัวกว่าคือ ‘ไม่มีใครรู้ตัวจนกว่าจะมีคนมาถาม’ นั่นแปลว่าตลอด 14 ชั่วโมงนั้น ทุกการปิดการขายในแชทไม่ถูกส่งไปที่ไหนเลย และไม่มีใครในทีมรู้เลยจนกระทั่งมันสายไปแล้ว
LINE ส่ง Webhook ซ้ำยังไงตอนปลายทางล่ม แล้วมันเลิกส่งเมื่อไหร่
เมื่อ LINE ยิง webhook ไปแล้วปลายทางไม่ตอบสำเร็จ (ไม่ใช่ 200 หรือใช้เวลานานเกินไป) ระบบจะพยายามส่งซ้ำในช่วงเวลาถัดมาตามกลไกของมันเอง แต่การ retry นี้ไม่ได้ทำไปเรื่อย ๆ ตลอดกาล มีกรอบเวลาจำกัดที่ถ้าปลายทางยังล่มอยู่ ระบบจะหยุดพยายามส่ง event นั้นไปเลย
นั่นแปลว่าถ้าปลายทางล่มนานพอ event ในช่วงนั้นจะหายไปถาวร ไม่ใช่แค่ ‘ดีเลย์’ แล้วค่อยตามมาทีหลังเหมือนกรณีevent ที่แค่ส่งช้า นี่คือความต่างสำคัญที่ทำให้ webhook ล่มอันตรายกว่าความล่าช้าธรรมดา
สาเหตุที่พบบ่อยว่าทำไม Webhook ถึงล่ม
- อัปเดต dependency หรือ deploy โค้ดใหม่ที่มีบั๊กแอบแฝง แล้วไม่มีการทดสอบก่อนขึ้น production
- เซิร์ฟเวอร์รับ traffic เกินกำลังในช่วงเวลาที่มีผู้ใช้เข้ามาพร้อมกันเยอะผิดปกติ
- Certificate SSL หมดอายุโดยไม่มีใครต่ออายุล่วงหน้า ทำให้การเชื่อมต่อล้มเหลวทั้งหมด (คล้ายกับกรณีtoken หมดอายุแบบไม่มีเตือน)
- Database หรือ service ที่ webhook endpoint พึ่งพาอยู่ล่มไปก่อน ทำให้ endpoint ตอบ error แม้ตัวเซิร์ฟเวอร์เองยังทำงานอยู่
ตั้งระบบเฝ้าระวังที่ไม่ต้องพึ่งดวงตาคน
- ตั้ง health check ที่ยิงเข้า endpoint รับ webhook เป็นระยะ (เช่นทุก 1-5 นาที) แล้วแจ้งเตือนทันทีถ้าไม่ได้ response ที่คาดหวัง
- ผูกการแจ้งเตือนเข้ากับช่องทางที่มีคนเห็นจริง เช่นแอปแชทของทีม ไม่ใช่แค่ส่งอีเมลที่อาจไม่มีใครเปิดจนกว่าจะสาย
- แยก alert สำหรับ ‘endpoint ไม่ตอบสนอง’ ออกจาก alert สำหรับ ‘ยอด conversion ต่ำกว่าปกติ’ เพราะสองอย่างนี้บอกจุดปัญหาต่างกัน
- ทำ runbook สั้น ๆ ไว้ล่วงหน้าว่าเมื่อ webhook ล่ม ใครต้องรับผิดชอบตรวจอะไรก่อน เพื่อลดเวลาตัดสินใจตอนเกิดเหตุจริง
หลังเหตุการณ์ผ่านไป ต้องทำอะไรต่อ
สิ่งแรกที่ควรทำหลังแก้ปัญหาเสร็จคือประเมินว่ามี event กี่ตัวที่หายไปถาวรในช่วงเวลาที่ webhook ล่ม แล้วถ้าเป็นไปได้ให้ส่งข้อมูลย้อนหลังเข้าไปแบบ manual ให้กับแพลตฟอร์มที่รองรับการรับข้อมูลย้อนหลัง ระวังอย่าส่งซ้ำจนเกิดปัญหานับซ้ำตามมาอีกชั้น
ขั้นต่อมาคือทำ post-mortem สั้น ๆ ไม่ต้องซับซ้อน แค่บันทึกว่าเกิดอะไรขึ้น รู้ตัวช้าไปกี่ชั่วโมงเพราะอะไร แล้วจะป้องกันไม่ให้เกิดซ้ำแบบเดียวกันได้อย่างไร เอกสารสั้น ๆ แบบนี้มีค่ามากตอนเหตุการณ์คล้ายกันเกิดขึ้นอีกในอนาคต
สรุป
เหตุการณ์ webhook ล่มไม่ได้อันตรายเพราะมันเกิดขึ้น แต่อันตรายเพราะมันเกิดขึ้นแบบเงียบ ไม่มีใครรู้จนกว่าจะมีคนมาถามหรือสังเกตยอดผิดปกติเอง
มี monitoring ก่อนเกิดปัญหาย่อมดีกว่าไล่แก้หลังลูกค้าโวย เพราะทุกชั่วโมงที่ webhook ล่มโดยไม่มีใครรู้ตัว คือข้อมูลที่หายไปถาวรและกู้คืนไม่ได้เต็มร้อย
- webhook ที่ล่มนานเกินกรอบ retry จะทำให้ event หายถาวร ไม่ใช่แค่ล่าช้า
- ตั้ง health check และ alert แยกจากการดูตัวเลขยอดขายด้วยตา
- เตรียม runbook ล่วงหน้าเพื่อลดเวลาตัดสินใจตอนเกิดเหตุจริง
- ทำ post-mortem สั้น ๆ ทุกครั้งหลังเหตุการณ์ เพื่อป้องกันไม่ให้เกิดซ้ำแบบเดิม
คำถามที่พบบ่อย
webhook ล่มกี่นาทีถึงเริ่มเสียหายจริงจัง
ไม่มีตัวเลขตายตัว ขึ้นอยู่กับปริมาณออเดอร์ต่อชั่วโมงของธุรกิจนั้น ธุรกิจที่มีออเดอร์ถี่จะเสียหายเร็วกว่าธุรกิจที่มีออเดอร์น้อย แต่หลักการคือยิ่งรู้ตัวเร็วเท่าไหร่ ยิ่งจำกัดความเสียหายได้มากเท่านั้น ไม่ว่าปริมาณออเดอร์จะเป็นเท่าไหร่ก็ตาม
ทำไมต้องแยก alert เรื่อง webhook ล่ม กับ alert เรื่องยอดต่ำ ทั้งที่ดูจะเป็นปัญหาเดียวกัน
เพราะสาเหตุที่ต้องแก้ต่างกันโดยสิ้นเชิง ยอดต่ำอาจมาจากยอดขายจริงลดลงซึ่งเป็นปัญหาธุรกิจ ส่วน webhook ล่มเป็นปัญหาทางเทคนิคล้วน ๆ ถ้ารวม alert ไว้ด้วยกันทีมจะเสียเวลาวินิจฉัยผิดทางตั้งแต่ต้น
จำเป็นต้องมี health check เฉพาะทางไหม หรือใช้เครื่องมือทั่วไปก็พอ
เครื่องมือ uptime monitoring ทั่วไปที่ยิง request เข้า endpoint เป็นระยะใช้ได้ผลดีพอสำหรับกรณีส่วนใหญ่ ไม่จำเป็นต้องสร้างระบบเฉพาะทางที่ซับซ้อน สิ่งสำคัญกว่าคือมันต้องแจ้งเตือนไปยังช่องทางที่มีคนเห็นจริงและเร็ว
certificate SSL หมดอายุ ป้องกันไม่ให้เกิดซ้ำได้ยังไง
ตั้งระบบต่ออายุอัตโนมัติถ้าเป็นไปได้ และตั้งการแจ้งเตือนล่วงหน้าอย่างน้อย 2-4 สัปดาห์ก่อนวันหมดอายุ เพื่อให้มีเวลาจัดการก่อนที่จะกลายเป็นปัญหาฉุกเฉิน
ถ้าไม่มีทีมเทคนิคเฝ้าระบบตลอด 24 ชั่วโมง ควรทำยังไง
อย่างน้อยควรมี alert อัตโนมัติที่ส่งแจ้งเตือนได้ตลอดเวลาแม้ไม่มีคนเฝ้าหน้าจอ แล้วกำหนดว่าใครเป็นผู้รับผิดชอบตอบสนองนอกเวลางาน แม้จะไม่ใช่ real-time เต็มรูปแบบ อย่างน้อยก็ลดเวลาจากหลักวันเหลือหลักชั่วโมงได้
บทความที่เกี่ยวข้อง
