Xử lý tác vụ nền với giới hạn retry rõ ràng

Tác vụ nền không nên biến mất khỏi góc nhìn nghiệp vụ chỉ vì nó chạy ngoài yêu cầu khách hàng. Khi xử lý lỗi, cần có người biết công việc có được thử lại không, tác động có thể đã xảy ra chưa và khi nào con người phải quyết định. Thiết kế các trạng thái đó trước khi dùng vòng lặp thử lại vô hạn để thay cho trách nhiệm vận hành.

Tách lỗi tạm thời khỏi công việc không hợp lệ

Phân loại lỗi theo khả năng lần thử tiếp có thể thành công hợp lý hay không. Gián đoạn thành phần phụ thuộc tạm thời khác tài liệu sai vĩnh viễn. Định nghĩa trạng thái chờ, thành công và kết thúc cần rà soát. Cho nhân viên hỗ trợ thấy trạng thái mà không lộ nội dung nhạy cảm của tác vụ.

AWS giải thích rằng hết thời gian chờ hoặc thất bại không nhất thiết có nghĩa tác động phụ chưa xảy ra.[7] Vì thế, kết quả chưa chắc chắn cần thận trọng hơn việc chỉ gửi lại. Hỏi thao tác phía nhận nhận diện công việc lặp thế nào và nhóm đối soát kết quả mơ hồ ra sao.

Đặt thời gian hữu ích cho thử lại

Đặt giới hạn số lần, tổng thời gian đã trôi qua và hạn nghiệp vụ. Nên dừng thử lại tự động khi chạm bất kỳ giới hạn áp dụng nào. Thông báo giao hàng tới sau khi đã giao có thể không còn phục vụ mục đích ban đầu, dù hạ tầng cuối cùng phục hồi.

AWS mô tả backoff và jitter là cách giãn lần thử lại, tránh các đợt dồn đồng thời.[7] Backoff tăng khoảng chờ giữa các lần thử. Jitter thêm tính ngẫu nhiên vào thời điểm thử.[7] Áp dụng cùng giới hạn rõ ràng, không mặc định chỉ chờ là giải quyết được quá tải. Ghi lần thử tiếp theo đến hạn khi nào và thành phần nào điều khiển, để các tầng thử lại không bị khuất.

Cho người vận hành thấy ranh giới

Rà soát thiết kế tác vụ với chủ nghiệp vụ cần kết quả. Yêu cầu thử cả tình huống lỗi và cách giải quyết thủ công.

• Định nghĩa nhóm lỗi đủ điều kiện thử lại tự động.
• Đặt giới hạn số lần, thời gian trôi qua và tính hữu ích.
• Ghi cách tránh tác động nghiệp vụ trùng khi công việc lặp.
• Hiển thị lúc thử tiếp và trạng thái chưa giải quyết cuối cùng.
• Nêu người được đối soát, hủy hoặc chạy lại công việc.

Ví dụ giả định: xuất dữ liệu kế toán

Trong ví dụ giả định này, tác vụ xuất ban đêm gửi bản ghi hóa đơn tới bộ kết nối kế toán. Bộ kết nối hết thời gian chờ sau khi đã nhận lô, khiến tác vụ gửi không chắc kết quả. Tác vụ giữ tham chiếu ổn định và chuyển sang đối soát thay vì tự tạo định danh lô mới.

Người rà soát có thẩm quyền kiểm tra kết quả phía nhận trước khi quyết định thử lại. Ví dụ minh họa tránh trùng và trách nhiệm. Nó không khẳng định mọi hệ thống bên ngoài hỗ trợ cùng cơ chế tham chiếu hoặc bảo đảm chỉ có đúng một tác động nghiệp vụ.

Kiểm soát phục hồi thủ công

Giới hạn quá ngắn có thể đẩy quá nhiều việc sang rà soát thủ công. Giới hạn quá dài có thể che vấn đề và tiêu tốn năng lực khi kết quả không còn giá trị. Chọn ranh giới theo thao tác nghiệp vụ, không dùng một con số chung cho mọi hàng đợi.

Giữ dấu vết kiểm toán khi có người hủy hoặc chạy lại. Yêu cầu nêu lý do và kiểm tra tác động có thể đã xảy ra. Hàng đợi tác vụ chưa giải quyết không phải thất bại của tự động hóa nếu đó là ranh giới quyết định có chủ ý. Vấn đề xuất hiện khi không ai phụ trách ranh giới ấy.