คู่มือความน่าเชื่อถือของ Tracking API: วิธีตรวจสอบเวลาพร้อมใช้งาน ความสดใหม่ของข้อมูล และการอัปเดตที่พลาดหลังเปิดใช้งานจริง

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

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

กำหนดความหมายของการอัปเดตการติดตามที่เชื่อถือได้

เริ่มจากเส้นทางการจัดส่งทั้งหมด ได้แก่ การลงทะเบียนการจัดส่ง การเรียกข้อมูลจากผู้ให้บริการ การตอบกลับ API หรือการส่ง webhook การประมวลผลภายใน การบันทึกลงฐานข้อมูล และการแสดงผลแก่ลูกค้า หากคุณส่งการแจ้งเตือน ให้ถือว่านั่นเป็นอีกขั้นตอนหนึ่ง แทนที่จะสมมติว่าการอัปเดตที่บันทึกไว้ถูกส่งถึงผู้ซื้อแล้ว

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

แนวทาง SRE ของ Google อธิบายให้ latency, traffic, errors และ saturation เป็นสัญญาณสำคัญสี่ประการของการตรวจสอบ สัญญาณเหล่านี้มีประโยชน์สำหรับโครงสร้างพื้นฐานการผสานรวมของคุณ แต่การติดตามการจัดส่งยังต้องตรวจสอบความใหม่และความครบถ้วนด้วย เพราะจุดปลายทางที่ดูเหมือนทำงานปกติอาจให้ข้อมูลที่ไม่เปลี่ยนแปลงหรือไม่ครบถ้วน

ติดตั้งการเก็บข้อมูลของการผสานรวมก่อนตั้งค่าการแจ้งเตือน

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

บันทึกขั้นต่ำที่มีประโยชน์ประกอบด้วย:

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

เก็บ payload เดิมไว้ภายใต้การควบคุมสิทธิ์และระยะเวลาการเก็บรักษาที่เหมาะสมเมื่อจำเป็นต่อการตรวจสอบหรือเล่นซ้ำ อย่าบันทึก authorization headers หรือข้อมูลลับ ใช้มิติที่มีขอบเขต เช่น ผู้ให้บริการขนส่งและหมวดหมู่ผลลัพธ์สำหรับเมตริก ส่วนหมายเลขติดตามแต่ละรายการควรอยู่ในระเบียนที่ค้นหาได้ ไม่ใช่ป้ายกำกับเมตริกที่มี cardinality สูง

แยกเวลาของเหตุการณ์ออกจากเวลาที่สังเกต โมเดลข้อมูล logs ของ OpenTelemetry แยกความแตกต่างนี้อย่างชัดเจนผ่าน Timestamp และ ObservedTimestamp การใช้ความแตกต่างเดียวกันกับระเบียนการติดตามช่วยป้องกันไม่ให้เหตุการณ์ของผู้ให้บริการขนส่งที่รายงานล่าช้าถูกเข้าใจผิดว่าเป็นการเขียนฐานข้อมูลที่ช้า

ตรวจสอบเวลาทำงานจากมุมมองของแอปพลิเคชัน

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

ตัวบ่งชี้ความสำเร็จของคำขอที่มีประโยชน์คือ:

Successful eligible operations / All eligible attempted operations

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

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

• Latency: ติดตาม p50, p95 และ p99 เมื่อปริมาณทราฟฟิกรองรับเปอร์เซ็นไทล์ที่มีความหมาย วัด timeout แยกต่างหาก เพื่อไม่ให้ความล้มเหลวที่เกิดขึ้นอย่างรวดเร็วทำให้ latency ดูดีเกินจริง
• Traffic: เปรียบเทียบปริมาณคำขอและ callback กับการลงทะเบียนการจัดส่งและจำนวนการจัดส่งที่กำลังดำเนินการ
• Errors: แยกความล้มเหลวของการส่งข้อมูล ความล้มเหลวระดับแอปพลิเคชัน ข้อผิดพลาดการแยกวิเคราะห์ และความล้มเหลวในการบันทึกข้อมูลปลายทาง
• Saturation: ตรวจสอบ connection pool ความสามารถของ worker ความลึกของคิว รายการที่เก่าแก่ที่สุดในคิว และงบประมาณคำขอที่เหลืออยู่

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

วัดความใหม่โดยไม่สับสนระหว่างความเงียบกับความล้มเหลว

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

ใช้เวลาแยกกันสำหรับความล่าช้าแต่ละประเภท

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

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

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

เปรียบเทียบการจัดส่งที่มีลักษณะใกล้เคียงกัน

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

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

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

ค้นหาการอัปเดตที่ตกหล่นด้วยการกระทบยอด

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

1. กำหนดประชากรที่เข้าเกณฑ์ รวมการจัดส่งที่ลงทะเบียนและกำลังได้รับการตรวจสอบ แยกการลงทะเบียนที่ถูกปฏิเสธและการตรวจสอบที่หยุดชั่วคราวไว้ต่างหาก เพื่อไม่ให้หายไปจากรายงานการปฏิบัติงาน
2. เลือกแหล่งอ้างอิง หาก API ที่มีเอกสารกำกับอนุญาต ให้เรียกรายละเอียดการติดตามปัจจุบันโดยอิสระจากการรับ webhook หน้าติดตามของผู้ให้บริการขนส่งอาจช่วยตรวจสอบกรณีเฉพาะรายได้ แต่ไม่ควรกลายเป็นการพึ่งพาการดึงข้อมูลอัตโนมัติโดยไม่ได้รับอนุญาต
3. ใช้ระยะเวลาผ่อนผัน เผื่อเวลาสำหรับความล่าช้าในการส่งและการประมวลผลตามปกติก่อนจัดประเภทความแตกต่างเป็นช่องว่างที่สงสัย
4. เปรียบเทียบสิ่งที่เหมือนกัน จับคู่ด้วยตัวระบุเหตุการณ์ที่รองรับ หรือใช้กฎการทำให้เป็นมาตรฐานที่มีเอกสารกำกับสำหรับ timestamp สถานะ สถานที่ และคำอธิบาย
5. กู้คืนอย่างปลอดภัย เล่นข้อความที่เก็บรักษาไว้ซ้ำ หรือเรียกการอัปเดตที่ได้รับอนุญาตผ่านเส้นทางการประมวลผลแบบ idempotent ตามปกติ
6. ยืนยันปลายทาง ตรวจสอบว่าฐานข้อมูลและมุมมองที่ลูกค้าเห็นได้รับการแก้ไขแล้ว ไม่ใช่เพียงยืนยันว่า recovery job ทำงาน

ตัวบ่งชี้ภายในสามารถเขียนได้ดังนี้:

Eligible reconciled shipments with unresolved differences / All eligible reconciled shipments

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

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

ทำให้การรับ webhook สามารถกู้คืนได้

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

ตรวจสอบกฎการผสานรวมจริงแทนการคาดเดา ได้แก่ การยืนยันตัวตนหรือการตรวจสอบลายเซ็น ข้อกำหนดการตอบรับ timeout ของคำขอ เงื่อนไขการลองใหม่ ระยะเวลาการลองใหม่ ลำดับ และความสามารถในการเล่นซ้ำ รายละเอียดเหล่านี้กำหนดว่าระบบของคุณต้องจัดเตรียมการกู้คืนแบบใด

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

หากการผสานรวมของคุณใช้ 17TRACK ให้ใช้ เอกสาร Tracking API อย่างเป็นทางการ เป็นข้อมูลอ้างอิงในการพัฒนา และตรวจสอบข้อกำหนดที่ใช้กับการผสานรวมของคุณ หน้าผลิตภัณฑ์ Tracking API ให้บริบทเกี่ยวกับผลิตภัณฑ์ แต่เกณฑ์การตรวจสอบและสมมติฐานการกู้คืนควรมาจากพฤติกรรมที่มีเอกสารกำกับ ข้อตกลงการให้บริการ และการวัดผลจากระบบจริง ไม่ใช่คำอธิบายผลิตภัณฑ์

เปลี่ยนแดชบอร์ดให้เป็นการแจ้งเตือนที่ดำเนินการได้

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

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

ใช้คู่มือการกู้คืนที่พิสูจน์การเสร็จสมบูรณ์

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

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

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

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

API สามารถตอบกลับสำเร็จในขณะที่ข้อมูลการติดตามล้าสมัยได้หรือไม่

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

ควรกระทบยอดการจัดส่งบ่อยเพียงใด

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

การไม่มี webhook หมายความว่าการผสานรวมเสียหรือไม่

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

ควร polling อย่างต่อเนื่องเพื่อสำรองหรือไม่

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

ควรส่งข้อมูลใดเมื่อยกระดับปัญหาที่สงสัยว่าเกิดจากผู้ให้บริการ

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

แหล่งข้อมูล

• Google SRE: Monitoring Distributed Systems — สัญญาณสำคัญสี่ประการและหลักการตรวจสอบ
• OpenTelemetry: Logs Data Model — ความแตกต่างระหว่าง timestamp ของเหตุการณ์และ timestamp ที่สังเกต
• เอกสาร 17TRACK Tracking API — ข้อมูลอ้างอิงในการพัฒนาการผสานรวม 17TRACK
• 17TRACK Tracking API — บริบทผลิตภัณฑ์อย่างเป็นทางการ