Điều chúng tôi muốn làm rất đơn giản.
Viết một bài mới rồi đăng càng sớm càng tốt.
Chỉ có vậy.
Nhưng không biết từ lúc nào, trước khi đăng đã có một cuộc họp diễn ra.
Lần này ai phụ trách? Workers hay Actions? Ngân sách còn không? Khóa lần trước còn hiệu lực không? Nhãn này là của ai? Đã thử lại mấy lần rồi?
Bài viết đang chờ.
Hệ thống cũng đang chờ.
Bộ phận nào cũng nghĩ: "Việc này không phải của mình."
Ở công ty, bạn có thể gọi mọi người vào phòng họp. Còn hệ thống phân tán thì chỉ lặng lẽ dừng lại.
Đây là địa ngục Live Schedule.
1. Chỉ muốn đăng ngay, vậy mà thành ra bầu chọn người phụ trách
Khi muốn quy trình đăng bài chắc chắn hơn, ta tự nhiên thêm nhiều lớp bảo hiểm.
Workers dừng thì chuyển sang Actions. Actions thiếu ngân sách thì chuyển sang Workers. Đặt khóa để không ai làm một việc hai lần. Đặt nhãn để hai bên không đụng vào cùng một việc. Đếm số lần thử lại. Thêm một người giám sát.
Nhìn từng cái một, cái nào cũng đúng.
Rắc rối bắt đầu khi nối tất cả thành một chuỗi.
Trước câu hỏi "Bài này đăng được chưa?", ta phải trả lời một câu lớn hơn nhiều: "Ai có quyền đăng?"
Nguy hiểm nhất là khi chỉ còn lại nhãn người phụ trách.
Phần việc bên Workers đã dừng. Nhưng bản ghi vẫn ghi "Workers phụ trách". Khi Actions thức dậy, đọc thấy "Workers phụ trách" thì bỏ qua việc đó.
Không có gì hỏng. Cũng không ai làm việc.
Đó là phiên bản hệ thống phân tán của câu "người phụ trách hiện không có ở bàn".
2. Lỗi thật sự là phối hợp, không phải khả năng chạy
Ở một lần chạy, Actions vẫn còn sức xử lý và còn ngân sách.
Dù vậy, việc chính vẫn không chạy.
Lý do rất đơn giản: phép kiểm tra kết luận "việc đó thuộc về Workers".
Chỗ này quan trọng.
Không phải thiếu CPU. Không phải mọi API đều chết. Không phải Actions không khởi động được.
Vấn đề nằm ở phối hợp, không phải ở việc chạy.
Thứ cản đường là việc quyết định ai làm, không phải sức để làm.
Như vậy, sửa từng lỗi riêng lẻ khó mà xong.
Sửa lượng dữ liệu lấy về. Sửa lỗi lưu vào main thất bại. Sửa việc thử lại. Sửa việc chuyển người phụ trách. Rồi nhãn cũ còn sót lại. Rồi khóa cũ còn sót lại. Người giám sát phát hiện ra vấn đề nhưng không có quyền đăng bài.
Trông như trò đập chuột chũi, nhưng mọi con chuột đều chui ra từ cùng một cái hang.
Tầng điều khiển quá thông minh.
3. Schedule là chiếc đồng hồ, không phải danh sách việc cần làm
Schedule của GitHub Actions rất tiện, nhưng tài liệu chính thức cũng nói rằng nó có thể bị trễ khi tải cao, và khi tải đủ cao, một phần việc đang xếp hàng có thể bị bỏ.
Vì vậy schedule hợp với yêu cầu "gọi tôi dậy khoảng giờ này".
Nhưng không hợp với yêu cầu "bản thảo này nhất định phải có người nhận và giữ đến khi thành công".
Đồng hồ thì reo.
Đồng hồ không cầm giữ bản thảo cho bạn.
Còn hàng đợi tin nhắn thì giữ chính công việc. Nó cũng xử lý được thất bại: thử lại, trì hoãn, và "hàng đợi việc lỗi" (dead-letter queue), nơi riêng cho những việc cứ thất bại mãi.
Ý ở đây không phải là "nhất định phải thêm dịch vụ mới".
Ý là chia vai trò cho rõ:
- schedule = thứ gọi dậy theo giờ
- danh sách việc chờ = bản ghi chính của việc chưa xong
- bên thực hiện = bên làm việc thật
- khóa ngắn = chìa khóa để hai bên không làm cùng lúc
- thử lại và hàng đợi việc lỗi = nơi việc thất bại được đưa đến
Nếu bắt chiếc đồng hồ kiêm luôn phòng nhân sự, nhà kho và nơi giữ đồ thất lạc, chiếc đồng hồ sẽ khổ.
4. Hãy lấy "việc gì chưa xong" làm gốc, đừng lấy "ai sở hữu"
Trong cách phân công phức tạp, trung tâm của bản ghi dễ biến thành "người phụ trách".
Nhưng điều ta thật sự cần biết trong quy trình đăng bài là:
Bài này đã đăng hay chưa.
Gần như chỉ có vậy.
Nên lấy danh sách việc chờ làm bản ghi chính là đủ.
Bản thảo mới vào thì cho vào danh sách chờ. Khi bắt đầu đăng, đặt một khóa ngắn. Thành công thì đánh dấu đã đăng. Thất bại thì trả về danh sách chờ. Thất bại đủ số lần quy định thì chuyển sang hàng đợi việc lỗi và gửi cảnh báo.
"Việc của Workers" hay "việc của Actions" chỉ là thông tin phụ. Đừng để nó thành quyền phủ quyết vĩnh viễn.
Dù ghi "việc của Workers", nếu một thời gian không có tiến triển thì bên thực hiện khác có thể nhận lại.
Như vậy, một nhãn người phụ trách đã "chết" không thể bắt công việc làm con tin.
5. Tuyến chính bắt đầu khi có sự kiện; schedule chỉ nhặt những gì bị sót
Muốn đăng ngay mà còn chờ đến lần hẹn giờ kế tiếp thì thật ngược đời.
Hãy đánh thức bên thực hiện ngay khi bản thảo mới đến.
Lấy đó làm tuyến chính.
Còn schedule thì nhặt những mục chờ cũ vẫn còn nằm đó sau vài phút đến vài chục phút.
Nói gọn lại:
Sự kiện là tuyến chính. Schedule là bảo hiểm.
Như vậy ngày thường sẽ nhanh.
Nếu lỡ mất một thông báo, schedule sẽ nhặt lại sau.
Nếu lấy schedule làm tuyến chính, cứ trễ là việc đăng bài bị trễ theo. Thêm bước kiểm tra ai phụ trách nữa thì sẽ có chuyện "đã thức dậy mà chẳng làm gì".
Đồng hồ đã reo.
Kiểm tra cũng đã qua.
Rồi nói "hôm nay không phải việc của tôi" và về nhà.
Vậy đến để làm gì?
6. Phương án dự phòng là "nhặt lại việc cũ chưa xong", không phải "đổi người phụ trách"
Cái bẫy hay gặp khi thiết kế dự phòng là chính thức chuyển việc từ A sang B.
Việc chuyển giao cần cập nhật bản ghi.
Nếu bước cập nhật đó thất bại, chính việc chuyển giao lại thành sự cố.
Có thể làm đơn giản hơn nhiều.
Bình thường Workers xử lý. Thành công thì xong. Thất bại thì mục đó vẫn nằm trong danh sách chờ.
Bên thực hiện dự phòng, như Actions, kiểm tra định kỳ. Nếu
- có mục đang chờ
- mục đó cũ hơn một khoảng thời gian đã định
- không có khóa còn hiệu lực
- mình chạy được
thì nhận việc đó.
Không cần "giấy chứng nhận chuyển giao" từ Workers.
Điều cần nhìn là sự thật rằng việc vẫn chưa xong.
Theo cách này, có kết quả hay chưa quan trọng hơn bảng phân công có gọn gàng hay không.
Với hệ thống đăng bài, đó là cách tự nhiên.
7. Không cần bỏ Live Schedule, nhưng đừng biến nó thành máy trợ sinh
Bản thân Live Schedule không có lỗi.
Nó rất mạnh khi có người đang theo dõi:
Đổi thứ tự ưu tiên. Tìm hiểu bất thường. Đề xuất cải tiến. Đẩy nhanh việc sửa chữa. Đưa kế hoạch mới vào.
Vấn đề là khi nó dừng thì cả nhà máy bài viết cũng dừng.
Live nên là bộ tăng tốc, không phải điểm duy nhất mà hỏng là tất cả dừng.
Dù không có Live,
bản thảo mới → danh sách chờ → bên thực hiện → kiểm tra → đăng
vẫn phải tự chạy.
Có Live thì nhanh hơn.
Không có cũng không chết.
Giống như ta không nên nối trái tim của một người vào việc "có ai trả lời Slack chưa".
8. Đưa đích đến từ "hệ thống thông minh hoàn thành" về "bỏ vào một bài, ra một bài"
Hệ thống kiểu này có thể cải tiến mãi mãi.
Phân công công bằng. Dùng gói miễn phí tối ưu. Chống trùng lặp. Dự báo ngân sách. Thứ tự ưu tiên. Giám sát. Tự phục hồi. Phân tích.
Cái nào cũng thú vị.
Và nếu làm hết, bài sẽ không được đăng.
Vì vậy đích đầu tiên có thể thô hơn nhiều.
Bỏ vào một bản thảo mới, không cần thao tác đặc biệt, thì một bài được đăng.
Thất bại thì vẫn nằm trong danh sách chờ. Bên thực hiện khác sẽ nhận lại. Chỉ những việc thất bại nhiều lần mới chuyển cho con người.
Khi đường thẳng đơn giản này đã ổn định, hãy đưa các bước tối ưu quay lại.
Chúng tôi chỉ muốn đăng bài mới thật nhanh, vậy mà không hay biết đã tự dựng một thứ giống hệ thống đồng thuận phân tán.
Có những ngày như vậy.
Nhưng vẫn có cách thoát ra.
Cắt bớt sự phức tạp.
Giá trị của hệ thống đăng bài không nằm ở việc cuộc bầu chọn người phụ trách đẹp đến đâu.
Giá trị là bài viết đến được với người đọc.
Kết luận
Gốc rễ của địa ngục Live Schedule không phải bản thân schedule.
Mà là đã để trạng thái "ai phụ trách" mạnh hơn trạng thái "việc nào chưa xong".
Nếu quay lại thiết kế đơn giản, chỉ cần thế này:
- Lấy danh sách việc chờ làm bản ghi chính của việc chưa xong
- Bắt đầu ngay khi có sự kiện
- Giữ khóa ngắn
- Để bên thực hiện dự phòng nhặt lại các mục chờ đã cũ
- Dùng schedule làm bảo hiểm
- Tách những việc thất bại đủ số lần quy định vào hàng đợi việc lỗi
- Xem Live là bộ tăng tốc tùy chọn
Một nhà máy không ngừng tốt hơn một nhà máy thông minh.
Hãy bắt đầu từ đó.
- GitHub Docs: Events that trigger workflows — schedule https://docs.github.com/actions/reference/workflows-and-actions/events-that-trigger-workflows
- Cloudflare Workers Docs: Cron Triggers https://developers.cloudflare.com/workers/configuration/cron-triggers/
- Cloudflare Queues Docs: Overview https://developers.cloudflare.com/queues/
- Cloudflare Queues Docs: Dead Letter Queues https://developers.cloudflare.com/queues/configuration/dead-letter-queues/
