Trên trang này
Xét một tác vụ trình duyệt minh họa gồm một trăm bước. Giả sử mỗi bước thành công 99% số lần, độc lập với các bước khác. Khả năng tất cả bước đều thành công là 0.99^100, tức khoảng 36,6%.
Chín mươi chín phần trăm nghe rất tốt. Ba mươi sáu phần trăm thì không.
Cuộc thảo luận nguồn về giao dịch qua trình duyệt dùng phép tính này cho một ý hẹp: khách hàng nhận giá trị khi tác vụ hoàn tất, còn chi phí và nguy cơ lỗi tích lũy qua từng bước. Đây là số học theo giả định, không phải tỷ lệ thành công công bố của tác nhân trình duyệt hay đồng bộ Tajo. Lỗi thực có thể liên quan nhau. Một phiên đăng nhập hết hạn có thể làm hỏng nhiều thao tác phía sau cùng lúc.
Vì vậy, câu hỏi hữu ích không phải “Cú nhấp cuối của mô hình chính xác đến đâu?” mà là “Trạng thái người dùng yêu cầu đã xuất hiện chưa?”
Giao dịch là đơn vị quan trọng
Hình dung tác nhân mở cổng bảo hiểm, tìm tài liệu, tải xuống và xác nhận nó thuộc đúng tài khoản. Nó có thể đi đúng qua 99 màn hình rồi tải nhầm tệp ở màn hình thứ 100. Nhật ký đầy những cú nhấp thành công không sửa được kết quả.
Điều tương tự đúng với tích hợp. Tác nhân có thể tìm API, đề xuất ánh xạ trường và lưu bản nháp. Không hành động nào chứng tỏ liên hệ ở hệ thống đích hiện có trạng thái đồng ý như dự định. Công việc chỉ hoàn tất khi thao tác được duyệt đã chạy và hậu điều kiện liên quan được kiểm tra.
Đó là khác biệt giữa hoạt động và hoàn tất. Hoạt động dễ đếm. Hoàn tất cần định nghĩa.
Với tải tệp, đó có thể là hiện vật có số tài khoản khớp yêu cầu. Với đồng bộ liên hệ, đó có thể là bản ghi đích đúng định danh, các trường và trạng thái cho phép gửi tin. Phép kiểm tra phải nhìn vào điều người dùng quan tâm. Phản hồi màu xanh từ lệnh trước chứng minh lệnh đã trả lời; chưa chắc chứng minh hệ thống đích thay đổi như ý.
Hướng dẫn kết nối công cụ kinh doanh của Tajo bắt đầu từ quy trình và nguồn dữ liệu chuẩn cho từng đối tượng. Những lựa chọn đó tạo ý nghĩa cho phép kiểm tra cuối. Nếu hai hệ thống đều nhận là chủ một trường, ngay cả lượt ghi thực thi hoàn hảo cũng có thể tạo trạng thái sai về lâu dài.
Chi phí của một quyết định nữa
Vẫn theo giả định 99% minh họa, mười quyết định độc lập cho tỷ lệ thành công cả chuỗi khoảng 90,4%. Năm mươi quyết định cho khoảng 60,5%. Một trăm cho khoảng 36,6%.
Xác suất thành công toàn chuỗi (%)
Số bước độc lập
- Giả định thành công 99% mỗi bước
Xem các giá trị tính toán
| Số bước | Thành công toàn chuỗi (%) |
|---|---|
| 0 | 100,0 |
| 10 | 90,4 |
| 25 | 77,8 |
| 50 | 60,5 |
| 75 | 47,1 |
| 100 | 36,6 |
Đường cong dốc vì phép nhân không ưu ái một mức trung bình tốt. Mỗi quyết định thêm vào phải chứng minh nó cần thiết.
Điều đó không có nghĩa gộp mọi lệnh API thành một thao tác khổng lồ. Một số lệnh mang tính xác định: lấy trang theo con trỏ đã biết, so định danh hoặc ghi trường theo ánh xạ đã duyệt. Mô hình không cần quyết định lại trên từng bản ghi. Lệnh khác có sự mơ hồ thật: trường mới của nhà cung cấp, thông báo lỗi thay đổi hoặc yêu cầu chưa rõ ai sở hữu. Chúng có thể cần phán đoán.
Cách chia thực tế là dùng phán đoán để thiết kế hoặc sửa quy tắc, rồi để mã thông thường áp dụng quy tắc ổn định. Reverse ETL là ví dụ về di chuyển dữ liệu lặp lại: đường ống, không phải cuộc trò chuyện, nên thực hiện thao tác thường lệ trên từng hàng. Tác nhân vẫn có thể giúp quyết định đường ống phải làm gì.
Đây là ranh giới, không phải khẩu hiệu. Nếu nhà cung cấp đổi nghĩa một trường, quy tắc xác định có thể lặp lại hành động sai một cách hoàn hảo. Hệ thống cần cách phát hiện giả định đã đổi và đưa trường hợp về khâu xem xét.
Một công cụ lớn không phải lời giải
Phản biện hợp lý là: “Chuỗi dài dễ lỗi thì đặt toàn tác vụ sau một lệnh công cụ.” Cách đó giúp nếu công cụ là giao dịch được định nghĩa rõ và kết quả kiểm tra được. Nó thất bại nếu chỉ giấu một quá trình dài, nhiều bất định.
Giả sử syncCustomer() trả success: true sau khi gửi cập nhật. Nếu hệ thống đích xử lý cập nhật sau đó, lệnh chưa thể chứng minh trạng thái liên hệ cuối. Công cụ giảm số bước nhìn thấy, không giảm bất định.
Giao diện tốt hơn bộc lộ trạng thái quan trọng: đã nhận, đã áp dụng, đã kiểm tra hoặc thất bại. Mỗi từ cần tương ứng với bằng chứng. Lượt ghi được nhận có thể đủ cho bản xem trước ít hệ quả. Thay đổi đối tượng chiến dịch hoặc đồng ý nhận tin cần kiểm tra hệ thống đích trước khi gọi là hoàn tất.
Trong giao diện Tajo đề xuất này, yêu cầu được nhận và cập nhật được áp dụng là hai bước khác với trạng thái đích đã xác minh. Bước kiểm tra cuối vẫn đang chờ. Hành động tiếp theo rất cụ thể: xem đích đã lưu gì. Đếm thêm một lệnh gọi công cụ thành công không trả lời câu hỏi ban đầu.
Ghi xong vẫn cần bằng chứng
Đồng bộ khách hàng đã xong chưa?
Đã áp dụng lượt ghi. Còn chờ xác minh.
Chưa kiểm tra trạng thái ở đích.
Hoạt động đồng bộ
- Đã nhận yêu cầu
- Đã áp dụng cập nhật
- Chờ kiểm tra đích
Lượt chạy mẫu · 14:32 UTC
Điều đã biết
- Phản hồi từ nhà cung cấp
- Đã nhận
- Kết quả ghi
- Đã áp dụng
- Đọc lại từ đích
- Đang chờ
Lệnh gọi thành công không chứng minh trạng thái cuối.
Bố cục đề xuất dựa trên bảng hoạt động của Tajo. Hình này thêm trạng thái xác minh; không khẳng định tính năng đọc lại từ đích đã được triển khai.
Cách đo cũng thay đổi. Ghi số lần thử nếu giúp chẩn đoán chi phí. Ghi lỗi trung gian nếu chỉ ra bước hỏng. Nhưng đánh giá quy trình bằng giao dịch hoàn tất đã xác minh, kèm cách xác minh bên cạnh con số. Nhóm báo “99% lệnh thành công” chưa trả lời khách hàng đã xong việc hay chưa.
Bài giải thích máy chủ MCP cho thấy công cụ giúp trợ lý gọi hệ thống khác. Tiếp cận công cụ mới là bước mở đầu. Hợp đồng thật là trạng thái còn lại.
Một trăm cú nhấp tốt vẫn có thể không để lại gì. Hãy đếm kết quả.
Câu hỏi Thường gặp
Vì sao quy trình dài thất bại dù từng bước thường đúng?
Nếu mỗi bước thành công độc lập với xác suất p, chuỗi n bước thành công với xác suất p mũ n. Giả sử mỗi bước đạt 99%, chuỗi một trăm bước hoàn tất khoảng 36,6% số lần. Lỗi thực tế có thể phụ thuộc nhau, nên phép tính là ví dụ, không phải tỷ lệ tác nhân đã đo.
Giảm số lần gọi công cụ có bảo đảm độ tin cậy không?
Không. Ít lệnh chỉ giúp khi thao tác gộp vẫn có các điểm kiểm tra và khôi phục cần thiết. Một lệnh khó quan sát có thể giấu lượt ghi thất bại như chuỗi dài có thể đánh mất trạng thái.
Nhóm nên đo gì trong quy trình tác nhân?
Đo việc giao dịch người dùng yêu cầu đã hoàn tất và được xác minh, không chỉ các lệnh mô hình thành công. Xác định hiện vật hoặc trạng thái ở hệ thống đích chứng minh công việc xong, rồi ghi tỷ lệ xuất hiện sau toàn quy trình.