ในหน้านี้
ลองพิจารณางานในเบราว์เซอร์แบบสมมติที่มี 100 ขั้น สมมติว่าแต่ละขั้นสำเร็จ 99% ของเวลาโดยเป็นอิสระจากขั้นอื่น โอกาสที่ ทุก ขั้นทำงานได้คือ 0.99^100 หรือราว 36.6%
เก้าสิบเก้าเปอร์เซ็นต์ฟังดูยอดเยี่ยม แต่สามสิบหกเปอร์เซ็นต์ไม่ใช่
การอภิปรายต้นทางเกี่ยวกับงานธุรกรรมในเบราว์เซอร์ ใช้การคำนวณนี้เพื่อชี้ประเด็นเฉพาะ: ลูกค้าได้รับคุณค่าเมื่องานเสร็จ ขณะที่ต้นทุนและความเสี่ยงสะสมทุกขั้น นี่คือเลขคณิตภายใต้สมมติฐาน ไม่ใช่อัตราความสำเร็จที่เผยแพร่สำหรับเอเจนต์เบราว์เซอร์หรือการซิงค์ของ Tajo ข้อผิดพลาดจริงอาจพึ่งพากัน การเข้าสู่ระบบหมดอายุเพียงครั้งเดียวอาจทำให้หลายขั้นถัดไปล้มเหลว
คำถามที่มีประโยชน์จึงไม่ใช่ “โมเดลคลิกครั้งล่าสุดแม่นแค่ไหน” แต่เป็น “สถานะที่ผู้ใช้ขอปรากฏแล้วหรือยัง”
หน่วยที่สำคัญคือธุรกรรม
นึกถึงเอเจนต์เปิดพอร์ทัลประกัน ค้นเอกสาร ดาวน์โหลด และยืนยันว่าเป็นของบัญชีที่ถูกต้อง มันอาจผ่าน 99 หน้าจอได้ถูกต้อง แต่ดาวน์โหลดไฟล์ผิดที่หน้าจอที่ 100 บันทึกการคลิกสำเร็จจำนวนมากไม่ได้แก้ผลลัพธ์
การเชื่อมต่อระบบก็เช่นกัน เอเจนต์อาจค้นพบ API เสนอการแมปฟิลด์ และบันทึกร่าง ไม่มีการกระทำใดแปลว่ารายชื่อผู้ติดต่อปลายทางมีสถานะความยินยอมตามที่ต้องการ งานจะเสร็จเมื่อการดำเนินการที่อนุมัติแล้วเกิดขึ้นและตรวจเงื่อนไขปลายทางที่เกี่ยวข้อง
นี่คือความต่างระหว่าง กิจกรรม กับ การเสร็จงาน กิจกรรมนับง่าย ส่วนการเสร็จงานต้องมีนิยาม
สำหรับการดาวน์โหลดไฟล์ นิยามอาจเป็นไฟล์ที่เลขบัญชีตรงกับคำขอ สำหรับการซิงค์รายชื่อ อาจเป็นระเบียนปลายทางที่มีตัวระบุ ฟิลด์ และสถานะการส่งข้อความที่ได้รับอนุญาตอย่างถูกต้อง การตรวจต้องดูสิ่งที่ผู้ใช้สนใจ การตอบกลับสีเขียวจากการเรียกก่อนหน้าเป็นหลักฐานว่าการเรียกตอบกลับ แต่อาจไม่พิสูจน์ว่าปลายทางเปลี่ยนตามต้องการ
คู่มือเชื่อมต่อเครื่องมือธุรกิจของ Tajo เริ่มจากเวิร์กโฟลว์และแหล่งข้อมูลที่เป็นหลักสำหรับแต่ละออบเจ็กต์ การเลือกเหล่านั้นทำให้การตรวจครั้งสุดท้ายมีความหมาย หากสองระบบต่างอ้างเป็นเจ้าของฟิลด์เดียวกัน แม้เขียนข้อมูลถูกต้องก็อาจเกิดสถานะระยะยาวที่ผิด
ต้นทุนของการตัดสินใจเพิ่มอีกครั้ง
ภายใต้สมมติฐาน 99% เดียวกัน การตัดสินใจอิสระ 10 ครั้งให้โอกาสสำเร็จทั้งสายประมาณ 90.4% จำนวน 50 ครั้งเหลือ 60.5% และ 100 ครั้งเหลือ 36.6%
โอกาสสำเร็จทั้งสาย (%)
จำนวนขั้นอิสระ
- สมมติว่าสำเร็จ 99% ต่อขั้น
อ่านค่าที่คำนวณได้
| จำนวนขั้น | สำเร็จทั้งสาย (%) |
|---|---|
| 0 | 100.0 |
| 10 | 90.4 |
| 25 | 77.8 |
| 50 | 60.5 |
| 75 | 47.1 |
| 100 | 36.6 |
เส้นโค้งลดเร็วเพราะการคูณไม่สนใจค่าเฉลี่ยที่ดูดี การตัดสินใจเพิ่มแต่ละครั้งต้องมีเหตุผล
นั่นไม่ได้หมายความว่าควรรวมทุกการเรียก API เป็นการดำเนินการก้อนเดียว บางการเรียกเป็นแบบกำหนดแน่นอน เช่น ดึงหน้าด้วยเคอร์เซอร์ที่ทราบ เปรียบเทียบตัวระบุ หรือเขียนฟิลด์ตามการแมปที่อนุมัติ โมเดลไม่จำเป็นต้องตัดสินเรื่องเหล่านี้ซ้ำในทุกระเบียน การเรียกอื่นมีความกำกวมจริง เช่น ฟิลด์ใหม่ของผู้ให้บริการ ข้อผิดพลาดที่เปลี่ยนไป หรือคำขอที่ไม่ชัดว่าใครเป็นเจ้าของ สิ่งเหล่านี้อาจต้องใช้วิจารณญาณ
แนวทางคือให้วิจารณญาณออกแบบหรือซ่อมกฎ แล้วให้โค้ดทั่วไปใช้กฎที่เสถียร Reverse ETL เป็นตัวอย่างการย้ายข้อมูลซ้ำ ๆ: ไปป์ไลน์ควรทำงานประจำกับแต่ละแถว ไม่ใช่บทสนทนา เอเจนต์ยังช่วยตัดสินว่าไปป์ไลน์ควรทำอะไรได้
นี่คือขอบเขต ไม่ใช่คำขวัญ หากผู้ให้บริการเปลี่ยนความหมายของฟิลด์ กฎแบบกำหนดแน่นอนจะทำสิ่งผิดซ้ำได้อย่างสมบูรณ์ ระบบต้องตรวจได้ว่าสมมติฐานเปลี่ยนและส่งกรณีนั้นกลับให้ตรวจ
ทำไมเครื่องมือก้อนเดียวไม่ใช่คำตอบ
ข้อโต้แย้งที่สมเหตุผลคือ “ถ้าสายงานยาวล้มเหลว ก็ใส่งานทั้งหมดไว้หลังการเรียกเครื่องมือเดียว” วิธีนี้ช่วยเมื่อเครื่องมือเป็นธุรกรรมที่นิยามชัดและตรวจผลได้ แต่ล้มเหลวเมื่อมันเพียงซ่อนกระบวนการยาวและไม่แน่นอน
สมมติว่า syncCustomer() คืน success: true หลังส่งอัปเดต หากปลายทางประมวลผลภายหลัง การเรียกนั้นยังพิสูจน์สถานะรายชื่อสุดท้ายไม่ได้ เครื่องมือลดจำนวนขั้นที่มองเห็น ไม่ได้ลดความไม่แน่นอน
อินเทอร์เฟซที่ดีกว่าเผยสถานะที่สำคัญ: รับคำขอแล้ว ใช้การเปลี่ยนแปลงแล้ว ตรวจแล้ว หรือไม่สำเร็จ คำเหล่านี้ต้องผูกกับหลักฐาน การรับคำขออาจพอสำหรับตัวอย่างก่อนเผยแพร่ที่ผลกระทบต่ำ แต่กลุ่มเป้าหมายแคมเปญหรือสถานะความยินยอมควรตรวจที่ปลายทางก่อนเรียกว่าเสร็จ
ในมุมมอง Tajo ที่เสนอนี้ การรับคำขอและการใช้การอัปเดตแยกจากสถานะปลายทางที่ยืนยันแล้ว การตรวจขั้นสุดท้ายยังรออยู่ ขั้นถัดไปจึงชัด: ตรวจว่าปลายทางบันทึกอะไร การนับการเรียกเครื่องมือที่สำเร็จอีกครั้งไม่ตอบคำถามเดิม
เขียนเสร็จก็ยังต้องมีหลักฐาน
การซิงค์ลูกค้าเสร็จหรือยัง
ใช้การเขียนแล้ว รอการตรวจยืนยัน
ยังไม่ได้ตรวจสถานะที่ปลายทาง
กิจกรรมการซิงค์
- รับคำขอแล้ว
- ใช้การอัปเดตแล้ว
- รอตรวจปลายทาง
การทำงานตัวอย่าง · 14:32 UTC
สิ่งที่ทราบ
- คำตอบจากผู้ให้บริการ
- รับแล้ว
- ผลการเขียน
- ใช้แล้ว
- อ่านกลับจากปลายทาง
- รอดำเนินการ
การเรียกสำเร็จไม่ได้พิสูจน์สถานะสุดท้าย
เค้าโครงที่เสนออิงฟีดกิจกรรมของ Tajo ภาพนี้เพิ่มสถานะการตรวจยืนยัน แต่ไม่ได้อ้างว่าการอ่านกลับจากปลายทางมีให้ใช้งานแล้ว
วิธีวัดก็เปลี่ยนตาม บันทึกจำนวนครั้งที่พยายามหากช่วยวิเคราะห์ต้นทุน บันทึกข้อผิดพลาดระหว่างทางหากชี้ขั้นที่เสีย แต่ตัดสินเวิร์กโฟลว์จากธุรกรรมที่เสร็จและตรวจแล้ว พร้อมระบุวิธีตรวจข้างตัวเลข ทีมที่รายงานว่า “99% ของการเรียกสำเร็จ” ยังไม่ได้ตอบว่าลูกค้าได้งานเสร็จหรือไม่
คำอธิบายเซิร์ฟเวอร์ MCP แสดงว่าเครื่องมือให้ผู้ช่วยเรียกระบบอื่นได้อย่างไร การเข้าถึงเครื่องมือเป็นเพียงจุดเริ่ม เกณฑ์สำเร็จที่แท้จริงคือสถานะที่เหลืออยู่
คลิกดี ๆ หนึ่งร้อยครั้งก็อาจไม่เหลือผลงาน จงนับผลลัพธ์
คำถามที่พบบ่อย
ทำไมเวิร์กโฟลว์ยาวจึงล้มเหลวทั้งที่แต่ละขั้นมักถูกต้อง?
หากแต่ละขั้นสำเร็จอย่างเป็นอิสระด้วยความน่าจะเป็น p สายงาน n ขั้นจะสำเร็จด้วยความน่าจะเป็น p ยกกำลัง n เมื่อสมมติว่าแต่ละขั้นสำเร็จ 99% สายงาน 100 ขั้นจะเสร็จประมาณ 36.6% ความล้มเหลวจริงอาจสัมพันธ์กัน จึงเป็นตัวอย่างคำนวณ ไม่ใช่อัตราที่วัดจากเอเจนต์
ลดจำนวนการเรียกเครื่องมือรับประกันความเชื่อถือได้ไหม?
ไม่ การเรียกน้อยลงช่วยได้ก็ต่อเมื่อการดำเนินการรวมยังมีจุดตรวจและกู้คืนที่เหมาะสม การเรียกเดียวที่มองไม่เห็นข้างในก็ซ่อนการเขียนข้อมูลล้มเหลวได้เหมือนสายงานยาวหลงทาง
ทีมควรวัดอะไรในเวิร์กโฟลว์เอเจนต์?
วัดการทำธุรกรรมของผู้ใช้จนเสร็จและตรวจสอบแล้ว ไม่ใช่เพียงการเรียกโมเดลที่สำเร็จ กำหนดไฟล์หรือสถานะปลายทางที่พิสูจน์ว่างานเสร็จ แล้วบันทึกว่าเกิดขึ้นบ่อยเพียงใดหลังทั้งเวิร์กโฟลว์