Cron job (chạy theo lịch)

Cron job là gì?

Cron job là một việc được hẹn giờ chạy tự động theo lịch: mỗi 5 phút một lần, 2 giờ sáng mỗi ngày, hoặc 1 giờ sáng thứ Hai hằng tuần. Không ai bấm nút — đến giờ là nó chạy.

Rất nhiều thứ trong sản phẩm chạy theo lịch mà người dùng không nhìn thấy: tổng hợp báo cáo doanh thu, cộng điểm thưởng cho các đơn đã giao, gửi email nhắc giỏ hàng bỏ quên, đối soát với đơn vị vận chuyển, dọn dữ liệu tạm, xuất file cho kế toán.

Hệ quả quan trọng nhất với BA/PO: mọi con số do một job tạo ra chỉ mới bằng lần chạy gần nhất. Câu hỏi "vì sao báo cáo hôm nay chưa có đơn của sáng nay" gần như luôn có câu trả lời là lịch chạy, không phải bug. Và ngược lại: khi một job lỗi, không ai biết cho tới khi có người tình cờ nhìn vào số — trừ khi bạn đã spec sẵn ai được cảnh báo.

Baseline — bạn hiểu

• Nhiều thứ chạy theo lịch (tính điểm thưởng, tổng hợp báo cáo, gửi email nhắc) — dữ liệu chỉ mới bằng lần chạy gần nhất.
• Giữa hai lần chạy, con số không đổi dù nghiệp vụ bên dưới vẫn đang diễn ra.
• Job có thể chạy trễ, chạy lỗi, hoặc chạy hai lần — và mỗi khả năng đó cần một dòng trong spec.

Working — bạn làm được

• Biết lịch chạy của các job trong khu vực của mình mà không phải hỏi lại mỗi lần.
• Spec độ trễ chấp nhận được cho số tổng hợp thay vì đòi "tính liên tục".
• Với mọi job động tới tiền hoặc điểm, viết đủ ba thứ: ai được cảnh báo, chạy lại bằng cách nào, và khoá chống trùng là gì.

Cơ chế hoạt động

Ví dụ theo cấp độ

Cơ bản — Báo cáo hôm nay hiện số của hôm qua

Tình huống: 9 giờ sáng, trưởng phòng nhắn: "Dashboard doanh thu chưa có đơn nào của sáng nay, hỏng rồi à?"

Điều đang thực sự xảy ra: bảng số trên dashboard không được tính lúc bạn mở trang. Nó được một job tính sẵn từ đêm và ghi kết quả xuống. Cả ngày hôm nay, ai mở dashboard cũng đọc đúng kết quả của lần chạy đó.

1. 02:00 hôm nay: job cộng dồn toàn bộ đơn từ 00:00 tới 23:59 hôm qua, ghi ra một dòng cho mỗi tỉnh.
2. 09:00: trưởng phòng mở dashboard. Hệ thống chỉ đọc các dòng đã tính sẵn đó nên trang hiện gần như tức thời.
3. 14:00 và 20:00: vẫn đúng những dòng đó, không đổi một chữ số nào.
4. 02:00 ngày mai: job chạy lại, số của hôm nay mới xuất hiện.

Việc phải làm: không tạo ticket bug. Tạo một ticket cải tiến rất nhỏ: "Hiện dòng 'Số liệu tính đến 02:00 ngày 12/08' ngay dưới tiêu đề dashboard."

Học được: phần lớn "bug số liệu" thực ra là câu hỏi về lịch chạy. Một dòng mốc dữ liệu hiển thị ngay trên màn hình xoá được gần hết loại câu hỏi này — và đó là thứ BA nghĩ ra được, không cần chờ dev đề xuất.

Trung bình — "Gửi email nhắc lúc 9h sáng"

Tình huống: marketing yêu cầu: "Khách để hàng trong giỏ quá 24 tiếng thì 9h sáng hôm sau gửi email nhắc." Nghe như một dòng spec. Thực tế nó giấu bốn quyết định mà dev không được phép tự chọn.

1. 9h sáng theo giờ nào? Máy chủ thường chạy theo UTC. Đặt lịch 09:00 UTC nghĩa là email tới lúc 16:00 giờ Việt Nam. Viết vào spec: "chạy lúc 09:00 giờ Việt Nam (UTC+7)".
2. Job quét những giỏ nào? "Quét các giỏ có ít nhất một sản phẩm, chưa đặt hàng, và lần cập nhật cuối cách đây từ 24 đến 48 giờ." Cái chặn trên là phần quan trọng: thiếu nó thì ngay lần chạy đầu tiên, mọi giỏ hàng bỏ quên từ hai năm trước cũng nhận được email.
3. Một khách nhận tối đa mấy email? "Mỗi giỏ chỉ nhắc một lần. Nếu khách thêm sản phẩm mới thì tính là giỏ đã cập nhật và có thể được nhắc lại sau 24 giờ, nhưng tối đa 2 email mỗi tuần cho một khách."
4. Nếu job chạy trễ thì sao? "Job bắt đầu 09:00, có 40.000 email, gửi hết mất khoảng 25 phút — chấp nhận email tới rải rác từ 09:00 tới 09:30. Nếu job không chạy được đúng giờ và mãi 11:30 mới chạy thì vẫn gửi. Nhưng nếu quá 12:00 thì bỏ lượt hôm đó, vì email nhắc mua hàng gửi vào buổi tối gây phiền và tỉ lệ huỷ đăng ký tăng."

Học được: một câu yêu cầu về thời gian luôn giấu ít nhất bốn quyết định — múi giờ, phạm vi quét, giới hạn số lần, và hành vi khi chạy trễ. Không viết ra thì dev sẽ tự chọn, và bạn sẽ biết họ chọn gì vào đúng ngày có sự cố.

Nâng cao — Job cộng điểm thưởng lỗi lúc 2 giờ sáng

Tình huống: job "cộng điểm thưởng" chạy 02:00 mỗi ngày, đọc các đơn đã giao thành công hôm trước và cộng điểm vào ví của khách. Đêm nay job chạy được nửa chừng thì database bận, job dừng. 40.000 khách đã được cộng, 60.000 khách chưa.

Ba câu hỏi, theo đúng thứ tự này:

1. Ai biết? Nếu câu trả lời là "sáng ra có khách khiếu nại mới biết" thì đó là lỗ hổng lớn hơn cả bản thân sự cố. Spec: "Job thất bại, hoặc chạy quá 30 phút, thì gửi cảnh báo ngay vào kênh trực của đội vận hành, kèm số bản ghi đã xử lý và bản ghi cuối cùng."
2. Chạy lại thế nào? Chạy lại toàn bộ hay chỉ phần còn thiếu? Muốn trả lời được, job phải ghi nhật ký nó đã xử lý tới đâu.
3. Chạy lại có cộng điểm hai lần không? Đây là chỗ hầu hết spec sụp.

Cái bẫy, gọi tên thẳng: nếu job chỉ có logic "đọc đơn đã giao hôm qua, cộng điểm", thì lần chạy lại sẽ cộng thêm một lần nữa cho 40.000 khách đã được cộng ở lần đầu. Không ai phát hiện ngay, vì được nhiều điểm thì khách không khiếu nại. Nó chỉ lộ ra ở kỳ đối soát vài tuần sau, hoặc không bao giờ lộ ra. Nói cách khác: chạy lại một job không chống trùng còn nguy hiểm hơn chính sự cố ban đầu.

Những dòng phải có trong spec để job được phép chạy lại:

• "Mỗi lần cộng điểm ghi kèm khoá duy nhất theo cặp (mã đơn hàng, loại thưởng). Nếu khoá đã tồn tại thì bỏ qua, không cộng lần hai." Đây là điều kiện bắt buộc, không phải tuỳ chọn.
• "Job ghi nhật ký từng lần chạy: giờ bắt đầu, giờ kết thúc, số bản ghi đã xử lý, số bỏ qua vì trùng, số lỗi."
• "Chạy lại được thực hiện bằng một nút trong trang quản trị, có ghi lại ai bấm và lúc nào — không sửa tay trực tiếp vào database."
• "Quá 12:00 mà điểm vẫn chưa cộng xong: đội vận hành nhận cảnh báo thứ hai và chăm sóc khách hàng được báo trước, vì khách sẽ bắt đầu hỏi."
• "Trong lúc điểm chưa về, màn hình ví hiện 'Điểm của đơn ngày 11/08 đang được tính', không hiện số 0."

Học được: câu hỏi thật cho một job không phải "nó chạy khi nào" mà "nó hỏng thì chuyện gì xảy ra". Ba thứ phải có trong spec của bất kỳ job nào động tới tiền hoặc điểm: có người được cảnh báo, chạy lại được, và chạy lại không làm hai lần. Thiếu cái thứ ba thì cái thứ hai trở thành vũ khí.

Áp dụng khi viết spec

Với mỗi con số tổng hợp hoặc việc chạy tự động, ticket của bạn phải trả lời được bốn câu:

1. Việc này chạy theo lịch nào, theo múi giờ nào?
2. Số do nó tạo ra mới đến thời điểm nào, và mốc đó có hiển thị cho người xem không?
3. Job lỗi thì ai được báo, qua kênh nào, trong bao lâu?
4. Chạy lại có làm cùng một việc hai lần không? Khoá chống trùng là gì?

Câu hỏi nên hỏi dev

• "Con số này được tính lúc mở trang hay do một job chạy sẵn? Job chạy lúc mấy giờ?"
• "Lịch chạy theo múi giờ nào — giờ Việt Nam hay UTC?"
• "Job này thường chạy mất bao lâu? Nếu lần trước chưa xong mà tới giờ chạy tiếp thì sao?"
• "Job lỗi thì ai nhận cảnh báo, và cảnh báo đi vào đâu?"
• "Chạy lại job này có an toàn không, hay có nguy cơ xử lý trùng?"
• "Có bảng nhật ký các lần chạy để đội vận hành tự kiểm tra không?"

Sai lầm thường gặp

• Viết "cập nhật liên tục" cho một con số do job chạy đêm tạo ra.
• Không hiện mốc dữ liệu trên báo cáo, rồi mất cả buổi họp để giải thích một độ trễ vốn là thiết kế.
• Ghi "9h sáng" mà không ghi múi giờ.
• Quên chặn trên khi quét dữ liệu, khiến lần chạy đầu tiên đụng vào cả dữ liệu rất cũ.
• Coi "chạy lại là xong" trong khi job không có khoá chống trùng.
• Không chỉ định ai nhận cảnh báo — sự cố được phát hiện bởi khách hàng.
• Spec một job mới mà không nói nó chạy trong bao lâu và có được phép chạy chồng lần không.

Definition of done — dấu hiệu bạn đã đạt

• Bạn kể được lịch chạy của các job ảnh hưởng tới màn hình trong khu vực của mình.
• Mọi báo cáo bạn spec đều hiển thị mốc "số liệu tính đến".
• Mọi job động tới tiền hoặc điểm mà bạn spec đều có đủ: người nhận cảnh báo, cách chạy lại, và khoá chống trùng.

Đi sâu hơn

• Database (Lưu trữ dữ liệu) — vì sao số tổng hợp phải tính sẵn thay vì tính lại mỗi lần mở trang.
• Webhook vs polling — khi độ trễ đến từ cách truyền tin thay vì từ lịch chạy.