Deploy một phiên bản mới không nên biến các tác vụ đang chạy thành việc thất lạc. Nhưng giữ worker sống mãi để đợi mọi việc xong cũng có thể làm lần phát hành treo. Dừng worker an toàn cần một thời hạn, một trạng thái ngừng nhận việc và cách bàn giao phần chưa hoàn tất.
Deploy dừng tiến trình, không hủy ý định nghiệp vụ
Phân biệt yêu cầu vận hành “thay worker này” với yêu cầu khách hàng “hủy đơn này”. Khi thay tiến trình, công việc thường vẫn cần hoàn tất bởi worker hiện tại hoặc một worker khác. Không tự đặt trạng thái canceled cho tất cả job vì container nhận tín hiệu dừng. Những tác động đã xảy ra vẫn cần được ghi nhận theo quy trình nghiệp vụ.
Mỗi loại việc nên có ranh giới hoàn thành riêng: đã ghi kết quả bền vững, đã xác nhận với hàng đợi hay chỉ đang có dữ liệu trong bộ nhớ. Nếu một bước tạo tác động ngoài hệ thống, trạng thái mơ hồ phải được giữ để đối chiếu. Tắt máy không làm API bên ngoài quên yêu cầu đã nhận.
Drain bắt đầu bằng việc ngừng lấy thêm
Worker cần ngừng nhận tác vụ mới trước, rồi xử lý phần đang giữ. Ngừng readiness của dịch vụ HTTP không mặc định ngừng consumer hàng đợi; đó là hai đường nhận việc khác nhau. Tương tự, chỉ đóng cổng HTTP không bảo đảm timer nền đã dừng. Sổ nguồn việc cần liệt kê message broker, lịch nội bộ, request và các tiến trình con nếu có.
Kubernetes mô tả quá trình kết thúc Pod với thời gian ân hạn và tín hiệu dừng; đây là cơ chế nền tảng, không tự định nghĩa nghiệp vụ của worker. Handler phải phù hợp cách ứng dụng chạy và tín hiệu thực tế được chuyển đến tiến trình. Không lấy một con số thời gian trong ví dụ tài liệu làm cam kết cho mọi job.
Thời hạn dừng cần một sổ việc, không chỉ đồng hồ đếm
Ví dụ giả định có ba tác vụ khi deploy: A đã ghi kết quả, B đang đọc file, C đã gọi dịch vụ vận chuyển nhưng chưa nhận phản hồi. A có thể hoàn tất xác nhận theo hợp đồng hàng đợi. B có thể tiếp tục nếu đủ thời gian hoặc nhường lại nếu hỗ trợ khôi phục. C cần trạng thái chưa rõ tác động; không phát lại một lệnh tạo vận đơn mới chỉ vì worker cũ sắp thoát.
| Việc | Điểm đã biết | Bàn giao đề xuất |
|---|---|---|
| A | Kết quả đã lưu | Xác nhận đúng message theo hợp đồng |
| B | Chưa tạo tác động ngoài | Lưu checkpoint hoặc nhường lại nếu được hỗ trợ |
| C | Đã gửi, chưa rõ kết quả | Giữ mã đối chiếu và người xác minh |
Bảng là mô phỏng quyết định, chưa phải log hệ thống hay thử nghiệm của Onter. “Nhường lại” có an toàn không phụ thuộc broker, visibility timeout, lease và cách lưu checkpoint. Tài liệu của stack cụ thể mới quyết định API cần gọi; bài này không cung cấp một lệnh chung chạy trên production.
Đặt thứ tự đóng tài nguyên
Khi công việc còn cần ghi kết quả, đóng pool dữ liệu quá sớm có thể khiến nó không hoàn tất được. Khi chưa ngừng nguồn nhận việc, drain pool có thể chạy đua với request mới. Kế hoạch thường bắt đầu từ chặn đầu vào, đợi phần đang xử lý theo thời hạn, lưu hoặc bàn giao trạng thái rồi đóng tài nguyên; thứ tự cần được kiểm trên kiến trúc thật.
Cũng cần xét tác vụ sinh thêm tác vụ con. Nếu parent báo xong trước khi child ghi trạng thái, bản bàn giao có thể bỏ sót phần còn chạy. Dùng định danh và quan hệ parent–child trong sổ việc thay vì chỉ đếm số promise hoặc thread. Tên trạng thái nên diễn tả điều đã xác nhận, không mô tả một mong muốn “đã dừng sạch”.
Thử ở ranh giới có khả năng mất việc
Trong môi trường được phép, chuẩn bị ca dừng trước nhận việc, trong khi xử lý, sau khi lưu kết quả nhưng trước xác nhận và khi hết thời hạn drain. Quan sát số tác vụ có kết quả, số được giao lại và số phải đối chiếu. Bộ ca này là kế hoạch kiểm tra; chỉ có receipt lần chạy và dữ liệu sau chạy mới là bằng chứng đạt.
Đội vận hành cần biết có thể quay về phiên bản trước không và job mới có tương thích với worker cũ không. Nếu format hoặc nghĩa của job đã đổi, rollback tiến trình có thể tạo một lỗi khác. Không dùng khả năng bật lại container làm bằng chứng rollback nghiệp vụ đã sẵn sàng.
Việc hủy workflow và bù trừ chỉ mở khi có yêu cầu nghiệp vụ phù hợp, không phải hệ quả tự động của deploy. Với bước ngoài đã gửi rồi timeout, tham khảo cách giữ kết quả chưa xác định. Khi trao đổi phạm vi phần mềm với Onter, một sổ nguồn việc và ba ranh giới bàn giao quan trọng hữu ích hơn yêu cầu “deploy không bao giờ mất job”.
