Webhook เงียบไปสามวันแล้วไม่มีใครรู้: วิธี audit การตั้งค่า webhook และ rich menu ก่อนจะเสียลูกค้าฟรี
สรุปสั้น ๆ
webhook ที่หยุดทำงานมักไม่มี alert ใด ๆ แจ้งเตือน เพราะ LINE เห็นแค่ว่าไม่มี response ไม่ได้บอกว่า 'ทำไม' ส่วน rich menu ที่ตั้งค่าผิดจุดก็เงียบเหมือนกันเพราะยังกดได้ แค่พาไปผิดที่ บทความนี้รวมจุดตรวจที่ต้องทำก่อนพังจริง ไม่ใช่หลังพังแล้ว
สมมติร้านขายอุปกรณ์ทำสวนออนไลน์ชื่อ 'สวนสุขใจ' ย้ายเซิร์ฟเวอร์ที่ใช้รับ webhook จาก LINE ไปยังโฮสต์ใหม่เมื่อวันศุกร์ ทีมงานเช็กแล้วว่าเว็บไซต์หลักเข้าได้ปกติ ทุกคนแฮปปี้แล้วแยกย้ายกันพักร้อน แต่สิ่งที่ไม่มีใครเช็กคือ endpoint ที่ผูกกับ webhook ของ LINE OA ยังชี้ไป IP เก่าที่ปิดเซิร์ฟเวอร์ไปแล้ว
ผลคือทั้งสุดสัปดาห์ ลูกค้าที่ทักเข้ามาไม่ได้รับคำตอบจากบอทเลยสักข้อความ ไม่มี error หน้าจอไหนเด้งเตือน ไม่มีอีเมลแจ้ง เพราะฝั่ง LINE แค่เห็นว่า POST request ไปไม่ถึงปลายทาง แล้วก็หยุดพยายามหลังจากลองซ้ำไม่กี่ครั้งเงียบ ๆ กว่าจะรู้ตัวคือวันจันทร์ที่ยอดขายหายไปทั้งสุดสัปดาห์
บทความนี้ไม่ได้พูดเรื่องยอดขายหรือ ROAS แต่พูดเรื่องพื้นฐานที่มาก่อนสิ่งอื่นทั้งหมด คือ ระบบส่งข้อความและเมนูที่ลูกค้าจะใช้ ยังทำงานถูกต้องจริงไหม
ทำไม webhook พังแล้วถึงไม่มีใครรู้ตัวทันที
ธรรมชาติของ webhook คือมันทำงานแบบ 'ยิงแล้วลืม' ฝั่ง LINE ส่ง request ไปหาปลายทางที่ตั้งไว้ ถ้าได้ response 200 กลับมาเร็วพอ ก็ถือว่าจบ ถ้าไม่ได้ก็แค่ retry ตามรอบที่กำหนดแล้วปล่อยผ่าน ไม่มีระบบไหนเด้ง popup มาบอกเจ้าของร้านว่า 'เฮ้ย endpoint ของคุณตายนะ'
จุดที่อันตรายกว่านั้นคือบางกรณี webhook ยัง return 200 ได้ปกติ (เช่น มี load balancer ตอบรับ) แต่ตัว logic ข้างในที่ควรจะประมวลผลข้อความกลับ error เงียบ ๆ ผลคือ LINE คิดว่าส่งสำเร็จ ทั้งที่ความจริงข้อความไม่เคยถูกประมวลผลเลย ต่างจากกรณี server ล่มที่อย่างน้อยยังเห็น error code ชัดเจน
การตรวจจับ webhook ที่ล้มเหลวจึงต้องทำเชิงรุก ไม่ใช่รอให้ลูกค้าโทรมาบ่นว่าทักไปแล้วไม่มีใครตอบ เพราะกว่าจะมีคนบ่น มักผ่านไปแล้วหลายชั่วโมงถึงหลายวัน
5 จุดที่ต้อง audit webhook ทุกเดือน ไม่ใช่แค่ตอนติดตั้งครั้งแรก
- ใบรับรอง SSL ใกล้หมดอายุหรือยัง — LINE บังคับให้ endpoint เป็น HTTPS เท่านั้น ถ้า cert หมดอายุแม้แค่วันเดียว การเชื่อมต่อจะถูกปฏิเสธทันทีโดยไม่มีคำเตือนล่วงหน้าจากฝั่ง LINE
- เวลาตอบสนอง (response time) ของ endpoint — ถ้า server ตอบช้ากว่าที่ LINE กำหนดไว้ในการรอ request จะถูกตัดและนับว่าล้มเหลว ทั้งที่ server อาจกำลังประมวลผลอยู่จริง
- การตรวจสอบลายเซ็น (signature validation) — เช็กว่าโค้ดยังตรวจ x-line-signature ถูกต้องอยู่ไหม บางทีมีการอัปเดต dependency แล้วฟังก์ชันตรวจลายเซ็นพังไปเงียบ ๆ โดยไม่มีใครสังเกต
- Log การ retry จากฝั่ง LINE — ถ้าเปิด log แล้วเห็นว่ามี webhook เดิมถูกยิงซ้ำถี่ผิดปกติ แปลว่าปลายทางตอบช้าหรือตอบผิดสถานะบ่อยกว่าที่คิด
- Endpoint ที่ตั้งไว้ใน Developer Console ตรงกับที่ระบบจริงใช้งานอยู่หรือไม่ — โดยเฉพาะหลังย้ายโฮสต์หรือเปลี่ยนโดเมน จุดนี้เป็นจุดที่ลืมกันบ่อยที่สุด
rich menu ที่ 'ดูปกติ' แต่ area เชื่อม action ผิดจุด
ปัญหาที่พบบ่อยไม่แพ้ webhook คือ rich menu ที่ยังกดได้ ภาพยังโหลดขึ้นปกติ แต่พื้นที่ (area) ที่ผูกกับปุ่มแต่ละอันเชื่อมกับ action ผิดตำแหน่ง เช่น ลูกค้ากดปุ่ม 'สั่งซื้อ' แต่ระบบพาไปหน้า 'ติดต่อเรา' แทน เพราะตอนแก้ไขภาพเมนูใหม่ ทีมงานลืมขยับพิกัด area ให้ตรงกับตำแหน่งปุ่มที่ย้ายไป
ความน่ากลัวของบั๊กแบบนี้คือมันไม่ error ไม่มี log แปลก ระบบทำงานได้ 100% ตามที่ตั้งไว้ แค่ตั้งผิดตั้งแต่ต้น ลูกค้าที่เจอปัญหานี้ส่วนใหญ่ไม่บ่น เขาแค่งงแล้วปิดแชทไปเงียบ ๆ ซึ่งเรื่องนี้ตรงกับที่เคยเขียนไว้ในข้อผิดพลาดที่พบบ่อยของ rich menu
ถ้าตั้ง rich menu แยกตามแหล่งที่มาโฆษณา ต้องเช็กว่ามัน 'สลับ' ให้จริง
ร้านที่ใช้กลยุทธ์แสดงrich menu ต่างกันตามแหล่งที่มาของลูกค้า (เช่น มาจากแคมเปญ A เห็นเมนูโปรโมชั่น A มาจากแคมเปญ B เห็นเมนู B) มีความเสี่ยงเพิ่มอีกชั้น เพราะต้องพึ่งการเรียก API สลับเมนูแบบเรียลไทม์ ถ้า API ตัวนี้ล้มเหลวแบบเงียบ ลูกค้าทุกคนจะเห็นเมนู default แทน โดยไม่มีใครรู้ว่าการสลับหยุดทำงานไปแล้ว
วิธีตรวจที่ทำได้ง่ายคือสุ่มคลิกลิงก์โฆษณาจริงของแต่ละแคมเปญเดือนละครั้ง แล้วดูว่าเมนูที่ขึ้นมาตรงกับที่ตั้งใจไว้จริงหรือไม่ ไม่ใช่แค่เชื่อว่า 'ตั้งไว้แล้วต้องทำงาน'
ตารางเช็คสุขภาพ webhook และ rich menu ที่ทำได้ในสิบนาที
| สิ่งที่เช็ก | วิธีเช็ก | ความถี่ที่แนะนำ |
|---|---|---|
| Endpoint URL ตรงกับระบบจริง | เข้า Developer Console เทียบกับ config จริง | หลังย้ายระบบทุกครั้ง |
| SSL cert อายุคงเหลือ | ดูวันหมดอายุใน browser หรือเครื่องมือเช็ก cert | รายเดือน |
| Rich menu area-action mapping | กดทดสอบทุกปุ่มจริงด้วยมือ | หลังแก้ไขเมนูทุกครั้ง |
| การสลับเมนูตามแหล่งที่มา | คลิกลิงก์แคมเปญจริงแล้วดูเมนูที่ขึ้น | รายเดือน |
ถ้าเพิ่งรู้ตัวว่าพังไปแล้วหลายวัน ควรทำอะไรก่อน
- แก้จุดที่พังให้กลับมาทำงานปกติก่อนเป็นอันดับแรก อย่าเพิ่งไปนั่งสรุปว่าเสียลูกค้าไปกี่คน
- ไล่ดู log ว่าช่วงเวลาที่พังมีลูกค้าพยายามทักเข้ามากี่คน ถ้าระบบเก็บ log การ retry ของ LINE ไว้ จะเห็นร่องรอยได้ระดับหนึ่ง
- ถ้ามีเบอร์โทรหรือช่องทางอื่นของลูกค้าที่ทักเข้ามาช่วงนั้น ให้ลองติดต่อกลับพร้อมคำขอโทษตรง ๆ บางส่วนยังกอบกู้ยอดขายคืนได้
- ตั้งระบบแจ้งเตือนภายนอกที่ยิง request มาเช็ก endpoint ของตัวเองทุกไม่กี่นาที เพื่อไม่ให้ต้องรอฝั่ง LINE บอกซึ่งไม่มีวันเกิดขึ้น
สรุป
ระบบที่เงียบไม่ใช่ระบบที่ปลอดภัยเสมอไป บางครั้งความเงียบคือสัญญาณของสิ่งที่พังไปแล้วโดยไม่มีใครรู้ webhook และ rich menu เป็นจุดที่ธุรกิจพึ่งพาทุกวันแต่มักไม่มีใครแตะต้องจนกว่าจะมีปัญหาชัดเจน
การตั้งรอบตรวจง่าย ๆ แบบในตารางข้างบนใช้เวลาไม่ถึงครึ่งชั่วโมงต่อเดือน แต่ป้องกันความเสียหายที่อาจกินเวลาเป็นสัปดาห์กว่าจะรู้ตัว
- ตั้งเครื่องมือเช็กสุขภาพ endpoint จากภายนอก ไม่พึ่งพาการแจ้งเตือนจาก LINE
- ทดสอบกดทุกปุ่มของ rich menu ด้วยมือหลังแก้ไขทุกครั้ง
- เช็ก SSL cert และ endpoint URL ทันทีหลังย้ายระบบหรือเปลี่ยนโดเมน
คำถามที่พบบ่อย
จะรู้ได้ยังไงว่า webhook หยุดทำงานโดยที่ยังไม่มีลูกค้าบ่น
ควรตั้งเครื่องมือเช็กสุขภาพ endpoint ของตัวเองจากภายนอก (uptime monitoring) ที่ยิง request เข้าไปเช็กเป็นระยะ แทนที่จะพึ่งพาการแจ้งเตือนจากฝั่ง LINE ซึ่งไม่มีระบบแบบนั้นให้
SSL cert หมดอายุแล้วแก้ไขนานไหม
ถ้าใช้ระบบต่ออายุอัตโนมัติ (เช่น Let's Encrypt) มักแก้ได้ในไม่กี่นาที แต่ถ้าต้องซื้อ cert ใหม่ด้วยมือ อาจใช้เวลาหลายชั่วโมง จึงควรตั้งการเตือนล่วงหน้าก่อนหมดอายุอย่างน้อย 2 สัปดาห์
rich menu ที่ตั้งไว้นานแล้วไม่เคยแก้ ยังต้องเช็กไหม
ควรเช็ก เพราะแม้ไม่ได้แก้ไข แต่ URL ปลายทางที่ปุ่มเชื่อมไปอาจเปลี่ยนหรือถูกลบไปแล้วโดยทีมอื่นโดยไม่รู้ตัว ทำให้ปุ่มพาลูกค้าไปหน้าที่ไม่มีอยู่จริง
เปลี่ยนโฮสติ้งแล้วต้องเช็กอะไรเพิ่มเป็นพิเศษ
ต้องอัปเดต endpoint URL ใน Developer Console ให้ตรงกับเซิร์ฟเวอร์ใหม่ทันที และทดสอบส่งข้อความจริงก่อนปิดเซิร์ฟเวอร์เก่า ไม่ควรเชื่อว่าระบบจะสลับให้เองอัตโนมัติ
มีวิธีทดสอบ rich menu แบบ A/B เพื่อลดความเสี่ยงจากการตั้งค่าผิดไหม
มี การทดสอบ<a href="/blog/rich-menu-ab-test-line">เปรียบเทียบเมนูสองแบบ</a>กับกลุ่มลูกค้าเล็ก ๆ ก่อนปล่อยใช้งานเต็มรูปแบบ ช่วยจับความผิดพลาดของการเชื่อม action ได้ก่อนที่จะกระทบลูกค้าวงกว้าง
ถ้าทีมเล็กไม่มีคนดูแลระบบหลังบ้านโดยเฉพาะ ควรทำยังไง
อย่างน้อยควรมีปฏิทินเตือนให้คนคนหนึ่งสุ่มทดสอบกดปุ่มทุกอันของ rich menu และลองทักแชทเข้าไปเองเดือนละครั้ง เป็นวิธีที่ไม่ต้องใช้เครื่องมือซับซ้อนแต่จับปัญหาใหญ่ได้ทัน
บทความที่เกี่ยวข้อง
