ดูแลระบบ webhook: หยุด worker ปิดใช้งาน หรือลบ endpoint?

หากบำรุงรักษาเฉพาะระบบปลายทาง ควรให้ตัวรับ webhook ตรวจสอบและบันทึกเหตุการณ์ลงที่เก็บถาวรต่อไป แล้วหยุด worker ที่นำเหตุการณ์ไปประมวลผล การปิดใช้งาน endpoint ของ UnifyPort จะเปลี่ยนสถานะเป็น inactive โดยยังเก็บการตั้งค่าไว้ ส่วนการลบจะนำทรัพยากร endpoint ออก ทั้งสองอย่างไม่ได้มีสัญญาว่าจะ “พักแล้วส่งเหตุการณ์ที่พลาดย้อนหลัง” จึงควรเลือกตามชั้นของระบบที่ต้องหยุดจริง ๆ

ประเด็นสำคัญ

• หากดูแล CRM เวิร์กโฟลว์ AI หรือ worker ให้หยุดงานธุรกิจหลังจากรับและบันทึกเหตุการณ์อย่างถาวรแล้ว
• ปิดใช้งาน endpoint เมื่อมีเจตนาเช่นนั้น พร้อมแผนรับมือช่วงที่อาจขาดการนำส่ง
• ใช้การลบเมื่อต้องเลิกใช้ endpoint ไม่ใช่เป็นสวิตช์ชั่วคราวระหว่าง deploy
• การตอบ 503 ไม่ได้สร้างเวลารอสำหรับบำรุงรักษา เพราะ UnifyPort ลองใหม่ทันทีโดยไม่มี backoff

เปรียบเทียบการควบคุมทั้งสามแบบ

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

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

เอกสารปิดใช้งาน endpoint ระบุ POST /v1/webhook-endpoints/{endpoint_id}/deactivate ส่วนเอกสารลบ endpoint ระบุ DELETE /v1/webhook-endpoints/{endpoint_id} ซึ่งตอบ 204 No Content เมื่อสำเร็จ

การควบคุมเหล่านี้มีขอบเขตที่ webhook endpoint ไม่ใช่การออกจากระบบบัญชี การหยุด runtime หรือการยกเลิกงานที่แอปรับไปแล้ว worker ที่รับงานไปก่อนอาจทำงานจนจบได้ หากต้องหยุดผลข้างเคียงเหล่านั้น ต้องมีกลไกควบคุมในแอปเอง

เมื่อใดควรหยุด worker แทน

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

แยกเส้นทางรับเหตุการณ์ออกจาก CRM ดังนี้

1. ตรวจลายเซ็นและ timestamp จากไบต์ต้นฉบับของคำขอ
2. ตรวจเหตุการณ์และบันทึกลงที่เก็บถาวรให้สำเร็จ
3. ส่งการตอบรับว่าสำเร็จ
4. ให้ worker แยกต่างหากเขียนข้อมูลลง CRM เรียก AI หรือส่งการแจ้งเตือน

ก่อนหยุด consumer ต้องยืนยันว่าที่เก็บข้อมูลฝั่งรับยังพร้อมใช้งานตลอดช่วงบำรุงรักษา กำหนดขีดจำกัดการเติบโตของคิวและอายุข้อมูล พร้อมระบุผู้รับผิดชอบหากบันทึกไม่สำเร็จ อาร์เรย์ในหน่วยความจำไม่ใช่บัฟเฟอร์ที่ทนต่อการเริ่ม process ใหม่

หลัง deploy ให้ทำงานต่อจากสถานะที่บันทึกไว้แล้ว อย่าถือว่างานค้างทั้งหมดเสร็จเพียงเพราะฝั่งรับเคยตอบ 2xx เช็กลิสต์เชื่อมต่อแบบ webhook-first อธิบายขอบเขตการเก็บข้อมูลตั้งแต่แรก ส่วนแผนบำรุงรักษาต้องควบคุมเพิ่มเติมว่า consumer จะเริ่มทำงานได้เมื่อใด

แนวทางนี้ไม่แก้ปัญหาการบำรุงรักษาที่เก็บข้อมูลฝั่งรับเอง หากทั้งตัวรับและที่เก็บต้องหยุด ต้องเตรียมเส้นทางรับสำรองที่ตรวจสอบแล้ว หรือยอมรับและบันทึกช่วงหยุดอย่างชัดเจน อย่ารับรองการเก็บข้อมูลต่อเนื่องหากยังไม่มีการออกแบบที่ยืนยันได้

ทำไมการตอบข้อผิดพลาดจึงไม่ใช่การพักระบบ

ข้อกำหนดการนำส่ง ระบุว่าข้อผิดพลาดการเชื่อมต่อและสถานะ 408, 429, 5xx จะถูกลองใหม่ทันที retry_policy.max_attempts คือจำนวนครั้งที่ลองใหม่หลังคำขอแรก โดยค่าเริ่มต้นคือสามครั้ง ไม่มี backoff และไม่ใช้ค่า Retry-After ส่วน 4xx อื่นจะหยุดการนำส่งอัตโนมัติและทำเครื่องหมายเหตุการณ์เป็น dead-lettered

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

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

หากตั้งใจปิดใช้งาน ต้องมีเงื่อนไขเปิดกลับที่ชัดเจน

ก่อนเปลี่ยน ใช้อ่านการตั้งค่า endpoint เพื่อบันทึก ID, URL, สถานะ, รายการเหตุการณ์ที่สมัคร, สถานะการลงลายเซ็น และนโยบายลองใหม่ เก็บ secret จริงไว้ในการตั้งค่าที่ป้องกัน ไม่ใช่ในบันทึกการเปลี่ยนแปลง พร้อมระบุเวิร์กโฟลว์ที่พึ่งพา endpoint นี้

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

เมื่อต้องการเปิดกลับ ใช้อัปเดต endpoint โดยกำหนด status: active พร้อมการตั้งค่าที่ทบทวนแล้ว รักษา URL, การสมัครเหตุการณ์, นโยบายลองใหม่ และ signing secret ที่ไม่ว่าง อย่าคัดลอกตัวอย่างที่ปิดใช้งานหรือไม่มีลายเซ็นไปใช้กับ production โดยตรง

อ่านผลกลับ ยืนยัน signing_enabled: true แล้วส่งข้อความทดสอบที่ควบคุมได้ไปยังบัญชีรับส่งข้อความที่เชื่อมต่อ ติดตาม message.received ผ่านการตรวจลายเซ็น การบันทึกถาวร และ worker ที่ต้องการ สิ่งนี้พิสูจน์ว่าเส้นทางใหม่ทำงาน แต่ไม่ได้พิสูจน์ว่าข้อมูลในช่วง inactive ถูกกู้คืนแล้ว

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

ขอบเขตของการลบและการกู้คืน

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

อินเทอร์เฟซที่ไม่เป็นทางการของ UnifyPort ทำให้เหตุการณ์จากบัญชีรับส่งข้อความที่รองรับมีรูปแบบร่วมกัน แต่ไม่มี REST API ทั่วไปสำหรับอ่านประวัติข้อความ และไม่รับรองการส่ง payload ที่พลาดย้อนหลัง กลไกประวัติ WhatsApp ที่มีขอบเขตจำกัดไม่ใช่การรับประกันกู้คืนหลังบำรุงรักษาสำหรับทุกช่องทาง

เมื่อนำงานที่เก็บไว้กลับมาทำต่อ ให้ใช้ขอบเขตการป้องกันข้อมูลซ้ำตามเอกสาร เหตุการณ์ทั่วไปที่ลองใหม่ใช้ X-Device-Event-Id เดิม แต่ชุด conversation.history ต้องรวมข้อมูลระดับข้อความ ไม่ใช่ตัดทั้งชุดด้วย header นี้เพียงอย่างเดียว การส่งข้อความหรือผลข้างเคียงทางธุรกิจยังต้องป้องกันการทำซ้ำแยกต่างหาก

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

ปิดใช้งานแล้วยังเก็บ endpoint ไว้หรือไม่?

ใช่ สถานะจะเป็น inactive โดยไม่ลบ endpoint แต่ไม่ได้รับรองการเก็บเหตุการณ์ค้างหรือการส่งย้อนหลัง

หยุดเฉพาะเวิร์กโฟลว์ AI ได้หรือไม่?

ได้ในระดับการออกแบบแอป โดยหยุด consumer นั้นและให้ตัวรับยังตรวจสอบกับบันทึกถาวรต่อไป นี่ไม่ใช่ตัวเลือก API เพิ่มเติมของ UnifyPort

ควรลบแล้วสร้าง endpoint ใหม่ทุกครั้งที่ deploy หรือไม่?

โดยทั่วไปไม่ควร งานบำรุงรักษาปลายทางควรหยุด consumer หากต้องหยุด endpoint จริงให้วางแผนช่วงหยุด ส่วนการลบคือการตัดสินใจเลิกใช้งาน

ขั้นตอนถัดไปและแหล่งข้อมูล

อ่านข้อกำหนดการนำส่ง webhook และเขียนให้ชัดว่าการบำรุงรักษาหยุดระบบชั้นใด ก่อนแก้การตั้งค่า production

ตรวจเอกสารผลิตภัณฑ์เมื่อ 2026-10-06:

• ปิดใช้งาน webhook endpoint
• อัปเดต webhook endpoint
• ลบ webhook endpoint
• การนำส่ง การตอบรับ และการลองใหม่