Một quy trình có thể dừng khi nhà cung cấp AI phản hồi chậm, API CRM hết hạn mức hoặc hệ thống lưu trữ không truy cập được. Dịch vụ nào cũng có lúc gián đoạn. Sản phẩm vì thế phải xác định hành vi khi lỗi xảy ra.
Phương án dự phòng có thể là đưa yêu cầu vào hàng chờ, dùng quy tắc cố định, chuyển cho nhân sự hoặc dừng một hành động có rủi ro. Không phải lúc nào cũng cần thêm nhà cung cấp.
Bắt đầu từ tác vụ nghiệp vụ, không bắt đầu từ nhà cung cấp
Giả sử một luồng nhận yêu cầu báo giá từ form, dùng AI để đọc nội dung, gọi CRM rồi tạo bản nháp cho sales. Nếu AI không phản hồi, hệ thống vẫn có thể lưu yêu cầu để người đọc. Nếu CRM lỗi, hệ thống chưa nên tạo khách hàng bằng dữ liệu phỏng đoán. Nếu gửi email lỗi, bản nháp phải được giữ để gửi lại mà không tạo báo giá khác.
Cùng là lỗi API nhưng mỗi bước có hậu quả khác nhau. Đội sản phẩm cần liệt kê từng điểm phụ thuộc, đầu vào, đầu ra và hành động tiếp theo. Câu hỏi cần trả lời là: khi dịch vụ tạm thời không thực hiện được yêu cầu, quy trình chuyển sang trạng thái nào?
Chọn một trong bốn chế độ xử lý khi dịch vụ lỗi
Chờ và thử lại phù hợp khi kết quả vẫn có giá trị sau một khoảng chờ, chẳng hạn đồng bộ ghi chú. Yêu cầu cần có mã riêng, số lần thử và giới hạn dừng.
Tiếp tục với chức năng tối thiểu cho phép form vẫn nhận yêu cầu nhưng bỏ qua bước phân loại AI, sau đó đánh dấu để nhân sự xem.
Chuyển sang xử lý thủ công phù hợp với việc có thời hạn nhưng cần phán đoán. Hệ thống phải chuyển đủ ngữ cảnh cho người nhận.
Dừng an toàn áp dụng khi hành động có thể gây hậu quả khó sửa, như gửi cam kết, cập nhật giá hoặc ghi đè dữ liệu.
Quy trình thiết kế phương án dự phòng cho một luồng AI hoặc API
Bước 1: Lập bản đồ điểm phụ thuộc
Ghi từng lần gọi dịch vụ, dữ liệu gửi đi, dữ liệu nhận về và bước đang chờ kết quả. Bao gồm xác thực, lưu tệp và đồng bộ CRM.
Bước 2: Phân loại lỗi có thể xảy ra
Tách lỗi tạm thời như timeout khỏi lỗi cần can thiệp như hết quyền, sai cấu trúc dữ liệu hoặc tài khoản bị khóa.
Bước 3: Gán chế độ xử lý thay thế
Với từng điểm phụ thuộc, chọn chế độ thay thế. Ghi rõ trạng thái mới và dữ liệu bắt buộc phải lưu.
Bước 4: Xác định điều kiện khôi phục
Nêu cách kiểm tra dịch vụ, chọn yêu cầu cần chạy lại và tránh thực hiện trùng.
Cơ chế thử lại cần đi cùng tính lặp an toàn. Nếu cùng một yêu cầu được gửi hai lần, hệ thống không được tạo hai đơn hoặc gửi hai email. Bài retry và idempotency trong quy trình tự động giải thích kỹ phần này. Nếu luồng nhận dữ liệu từ nhiều hệ thống, đội cũng nên quyết định khi nào dùng webhook, khi nào đồng bộ theo lịch để có đường lấy bù dữ liệu sau gián đoạn.
Dữ liệu nào phải được giữ để khôi phục đúng
Muốn xử lý lại, đội phải biết yêu cầu đang ở đâu. Bản ghi nên có mã yêu cầu, thời điểm nhận, nguồn gửi, trạng thái, bước thất bại, số lần đã thử và tham chiếu tới đầu vào gốc. Với dữ liệu nhạy cảm, chỉ lưu phần cần thiết.
Thông báo cho nhân sự cần nêu hồ sơ bị ảnh hưởng, việc chưa được thực hiện và hành động tiếp theo. Engineering cần thêm mã lỗi, thời điểm, dịch vụ liên quan và thông tin truy vết.
Hệ thống tự xử lý đến đâu khi có gián đoạn
Hệ thống có thể tự xử lý
- Lưu yêu cầu hợp lệ và gán mã tham chiếu.
- Thử lại lỗi tạm thời trong giới hạn đã đặt.
- Chuyển sang chức năng tối thiểu đã được duyệt trước.
- Thông báo đúng nhóm kèm trạng thái và dữ liệu cần thiết.
Con người cần xác nhận
- Có chạy lại hàng loạt yêu cầu đang chờ hay không.
- Dữ liệu đã phát sinh trong thời gian lỗi có cần đối soát không.
- Khi nào được mở lại hành động gửi, cập nhật hoặc thanh toán.
- Lỗi lặp lại có cần đổi thiết kế hoặc nhà cung cấp không.
Kiểm tra phương án dự phòng bằng lỗi có chủ đích
Trong môi trường thử nghiệm, đội nên mô phỏng timeout, phản hồi sai định dạng, lỗi xác thực và hết hạn mức. Mỗi lần thử phải kiểm tra cả trải nghiệm người dùng lẫn dữ liệu.
Kiểm tra yêu cầu có bị mất không, trạng thái có đúng không, thông báo có đến đúng người không và thao tác chạy lại có tạo bản ghi trùng không. Khi dịch vụ hoạt động trở lại, chọn một nhóm nhỏ để khôi phục trước. Cách làm này nối trực tiếp với việc giám sát chất lượng quy trình AI, vì cả lỗi hạ tầng lẫn kết quả kém đều cần ngưỡng dừng và người xử lý.
Khi nào cần nhà cung cấp dự phòng
Nhà cung cấp thứ hai hữu ích khi tác vụ phải tiếp tục và hai dịch vụ trả về đầu ra tương thích. Lựa chọn này làm tăng chi phí tích hợp, kiểm thử và theo dõi chất lượng. Đổi mô hình AI cũng có thể làm đầu ra thay đổi dù cùng một prompt.
Trước khi thêm nhà cung cấp, hãy xem hàng chờ hoặc xử lý thủ công có đáp ứng yêu cầu không. Nếu có thể chờ, kiến trúc đơn giản thường dễ kiểm soát hơn. Với giao tiếp khách hàng hoặc thay đổi dữ liệu quan trọng, vẫn cần bước xác nhận của con người.
Đội ngũ muốn đưa AI vào quy trình thật có thể bắt đầu với Coaching triển khai hệ thống AI. Phạm vi làm việc nên bao gồm điểm phụ thuộc, trạng thái lỗi, lựa chọn xử lý thay thế và bài kiểm tra khôi phục, chứ không dừng ở việc kết nối thành công một API.