Chọn chính sách bù lịch phù hợp cho các tác vụ cron bị bỏ lỡ

Một máy chủ khởi động lại để vá kernel lúc 01:55 và hoạt động trở lại lúc 02:10 đã khiến một công việc sao lưu quan trọng được lên lịch vào lúc 02:00 biến mất không dấu vết. Do các daemon cron tiêu chuẩn không nhìn ngược về quá khứ, hệ thống đã bỏ qua việc thực thi mà không báo lỗi, khiến tổ chức không có bản sao lưu nào trong suốt cả ngày. Sự cố này làm nổi bật một chế độ lỗi phổ biến nhưng thường bị bỏ qua trong hạ tầng tự quản lý (self-hosted), nơi hành vi mặc định của các công cụ lập lịch không đáp ứng yêu cầu về tính liên tục kinh doanh.

Chuyện gì đã xảy ra

Vấn đề cốt lõi nằm ở cách các hệ thống lập lịch khác nhau diễn giải những khoảng trống thời gian do downtime gây ra. Trong sự cố được báo cáo, daemon cron cổ điển chỉ kiểm tra các công việc khớp với phút hiện tại. Vì máy ngoại tuyến (offline) vào lúc 02:00, phút đó hoàn toàn không tồn tại dưới góc nhìn của daemon. Kết quả là, không có lỗi nào được ghi log, không có cảnh báo nào được gửi đi, và lần chạy thành công tiếp theo chỉ diễn ra vào ngày hôm sau. Hành vi "bỏ qua âm thầm" này là mặc định của nhiều công cụ lập lịch Unix truyền thống, khiến nó trở nên nguy hiểm đối với các tác vụ quan trọng như dump cơ sở dữ liệu hoặc quét bảo mật.

Ngược lại, một đội ngũ khác gặp phải cực đoan trái chiều. Bộ lập lịch của họ bị ngừng hoạt động trong sáu giờ, và khi khôi phục, nó cố gắng "bù lịch" bằng cách kích hoạt đồng thời 72 phiên bản của một công việc đồng bộ hóa cứ năm phút một lần. Làn sóng hoạt động này đã làm nghẽn một API đối tác, kích hoạt giới hạn tốc độ (rate limits) và làm gián đoạn dịch vụ trong phần còn lại của ngày. Cả hai đội đều chịu thiệt hại vì họ chưa định nghĩa rõ ràng một chính sách bù lịch cho các công việc của mình. Hành vi mặc định của bộ lập lịch, thay vì một lựa chọn kỹ thuật có chủ đích, đã quyết định kết cục.

Chi tiết chính

• Ba chính sách chính: Khi một thời điểm được lên lịch bị bỏ lỡ, các hệ thống thường sẽ hoặc bỏ qua lần chạy, hoặc thực hiện nó một lần muộn, hoặc cố gắng chạy tất cả các khung thời gian bị bỏ lỡ.
• Cron cổ điển: Mặc định bỏ qua hoàn toàn các lần chạy bị lỡ, không cung cấp cơ chế bù lịch hay ghi log cho sự kiện bị bỏ lỡ.
• systemd timers: Sử dụng Persistent=true cho phép timer kích hoạt một lần ngay sau khi khởi động nếu một lần chạy bị bỏ lỡ, lý tưởng cho các bản sao lưu hàng ngày.
• Kubernetes CronJobs: Có thể được cấu hình với startingDeadlineSeconds để cho phép bắt đầu muộn trong một cửa sổ thời gian nhất định, và concurrencyPolicy: Forbid để ngăn chặn các lần thực thi chồng chéo.
• Công việc theo chu kỳ (Per-period jobs): Các tác vụ như tính phí cần xử lý từng khoảng thời gian bị bỏ lỡ theo thứ tự, điều này nên được xử lý bởi logic của chính công việc, không phải bởi bộ lập lịch.
• Phát hiện là yếu tố then chốt: Bất kể chính sách nào, các đội ngũ phải triển khai giám sát để phát hiện khi một công việc bị bỏ qua hoặc chạy muộn đáng kể.

Bối cảnh

Để hiểu các chế độ lỗi này, cần phân biệt giữa các đồng bộ hóa stateless (không trạng thái) và các thao tác stateful (có trạng thái). Một đồng bộ hóa stateless, chẳng hạn như lấy dữ liệu thời tiết công khai, thường không cần khôi phục dữ liệu quá khứ; lần chạy tiếp theo sẽ đơn giản lấy trạng thái hiện tại. Đối với những trường hợp này, việc bỏ qua thường chấp nhận được. Tuy nhiên, các thao tác stateful như sao lưu hoặc tính phí tài chính tích lũy "nợ" khi chúng bỏ lỡ một chu kỳ. Một bản sao lưu bị lỡ có nghĩa là dữ liệu không được bảo vệ lâu hơn, và một chu kỳ tính phí bị lỡ có nghĩa là rò rỉ doanh thu.

Cron truyền thống được thiết kế cho sự đơn giản, không phải cho khả năng chống chịu lỗi. Nó giả định rằng máy luôn hoạt động. Các giải pháp thay thế hiện đại như systemd timers và anacron được xây dựng để xử lý các máy ngủ hoặc khởi động lại thường xuyên. Ví dụ, Anacron theo dõi thời gian thực thi cuối cùng trên đĩa và chạy các công việc nếu chu kỳ của chúng (hàng ngày, hàng tuần) đã trôi qua kể từ lần chạy trước. Hiểu được công cụ nào phù hợp với nhu cầu độ tin cậy của khối lượng công việc là điều cần thiết cho thiết kế hạ tầng vững chắc.

Tại sao điều này quan trọng

Đối với các đội ngũ vận hành phần mềm riêng, hành vi mặc định của bộ lập lịch là một rủi ro ẩn. Nếu bạn dựa vào cron tiêu chuẩn cho các bản sao lưu cơ sở dữ liệu hàng ngày, một lần khởi động lại đơn giản trong cửa sổ bảo trì có thể khiến bạn dễ bị tổn thương trong 24 giờ mà không có bất kỳ cảnh báo nào. Sự im lặng này đặc biệt nguy hiểm vì nó tạo ra cảm giác an toàn giả tạo. Các đội vận hành có thể thấy đèn xanh trên dashboard vì daemon cron đang chạy, mà không biết rằng payload công việc thực tế đã bị bỏ qua.

Ngược lại, các cơ chế bù lịch quá mạnh mẽ có thể gây ra từ chối dịch vụ (DoS) do chính mình gây ra. Như thấy trong ví dụ về giới hạn tốc độ API, việc phát lại mù quáng các công việc bị lỡ có thể làm quá tải các dịch vụ downstream hoặc cạn kiệt tài nguyên cục bộ. Điều này đặc biệt liên quan đến kiến trúc microservices, nơi backlog của một dịch vụ có thể lan rộng thành các lỗi trên toàn hệ thống. Việc định nghĩa rõ ràng cách mỗi công việc xử lý downtime giúp ngăn ngừa những bất ngờ này và đảm bảo rằng các hành động khôi phục tương xứng với tầm quan trọng của tác vụ.

Bạn có thể làm gì

• Kiểm toán các công việc cron của bạn: Xác định những công việc nào là quan trọng (sao lưu, tính phí) và những công việc nào là tạm thời (đồng bộ hóa, log). Ghi chép lại hành vi mong muốn cho từng công việc nếu một lần chạy bị bỏ lỡ.
• Di chuyển các công việc quan trọng sang systemd timers: Sử dụng Persistent=true cho các tác vụ hàng ngày hoặc hàng tuần để đảm bảo chúng chạy một lần sau khi khởi động lại nếu chúng bị bỏ lỡ.
• Cấu hình deadline cho Kubernetes: Đặt startingDeadlineSeconds trên CronJobs để xác định một cửa sổ hợp lệ cho việc thực thi muộn, ngăn chặn các lần thử lại vô hạn hoặc bỏ qua hoàn toàn.
• Triển khai logic bù lịch idempotent: Đối với các tác vụ theo chu kỳ như tính phí, hãy viết công việc để tính toán các khoảng thời gian bị thiếu từ một bản ghi cơ sở dữ liệu thay vì dựa vào bộ lập lịch để kích hoạt nhiều lần chạy.
• Thêm giám sát heartbeat: Sử dụng các công cụ giám sát bên ngoài để cảnh báo nếu một công việc không báo cáo thành công trong khoảng thời gian dự kiến cộng thêm biên độ gia hạn (grace margin).
• Ghi log thời gian dự kiến vs. thực tế: Đảm bảo ứng dụng của bạn ghi log phân biệt giữa thời điểm công việc dự kiến chạy và thời điểm nó thực sự bắt đầu để hỗ trợ gỡ lỗi các vấn đề về độ trễ.