Một công việc theo lịch chạy mà không có VPN trông vẫn ổn

Trạng thái công việc báo thành công, nhật ký cho thấy một lần chạy đã hoàn tất, và dữ liệu thì cũ hoặc không có. Sự kết hợp đó thường có nghĩa là công việc theo lịch đã khởi động mà không có đường đi nó cần, và có thứ gì đó ở phía sau đã nuốt mất lỗi. Một lịch trình kích hoạt đúng giờ không nói gì về việc mạng đã sẵn sàng hay chưa. Khoảng trống giữa hai sự thật đó chính là nơi lỗi này tồn tại.

Việc cho phép thuộc về lần chạy, không thuộc về sự tồn tại của tệp cron.

Một lần chạy xanh không phải là công việc đã hoàn tất

Bộ lập lịch ghi nhận rằng một tiến trình đã bắt đầu và sau đó thoát ra; nó không biết tiến trình đó có đến được tài nguyên mà nó tồn tại vì nó hay không. Một tập lệnh coi kết nối thất bại là kết quả rỗng, hoặc bắt lỗi và thoát với số không, sẽ trông khỏe mạnh mãi mãi. Triệu chứng không phải là trạng thái đỏ; đó là một trạng thái hợp lý gắn với công việc bị thiếu.

Hãy nêu rõ lần chạy thực sự cần gì trước khi quyết định cách kiểm tra nó. Một bản sao lưu có thể cần DNS riêng và một điểm cuối đã xác thực, không chỉ một tiến trình đường hầm.

Kiểm tra kết nối, không phải tên giao diện

Một giao diện tên tun0 có thể tồn tại mà không có phiên quan trọng, và một kết nối khác có thể sở hữu cái tên đó. Hãy kiểm tra đối tượng cụ thể mà công việc phụ thuộc vào: một danh tính hồ sơ, một phiên bản dịch vụ, hoặc một thao tác nhỏ đã được phê duyệt đối với tài nguyên. Giữ việc kiểm tra có giới hạn thời gian, và giữ thông tin xác thực ngoài các đối số tiến trình và nhật ký chẩn đoán.

Cũng hãy định nghĩa kết quả khi mất kết nối. Một lần bỏ qua thông thường, một lần thử lại trong cửa sổ ngắn và một thời hạn bị bỏ lỡ mà người vận hành nhìn thấy là ba câu trả lời khác nhau, và một lịch trình định kỳ không chọn giữa chúng.

Bỏ qua và thất bại là những kết quả khác nhau

[Service]
Type=oneshot
User=worker
ExecCondition=/usr/local/libexec/check-office-path
ExecStart=/usr/local/bin/private-task

Trong một triển khai systemd, ExecCondition= chạy bộ kiểm tra đó trước khối lượng công việc. Hành vi thoát của nó rất cụ thể: số không tiếp tục, các mã từ một đến 254 bỏ qua các lệnh khởi động còn lại mà không đánh dấu đơn vị là thất bại, còn 255 hoặc kết thúc bất thường làm nó thất bại. Điều đó cho ba tín hiệu khác biệt, chỉ hữu ích nếu hợp đồng của bộ kiểm tra được ánh xạ tới chúng một cách có chủ đích. Các cài đặt định nghĩa lại thành công có thể thay đổi bức tranh, vì vậy hãy ghi lại ánh xạ.

Chính việc ghi lại các lần bỏ qua làm cho thiết kế trung thực. Một lần chạy bị bỏ qua mà không xuất hiện ở đâu cả thì không thể phân biệt với một lần chạy thành công, và coi mọi lỗi của bộ kiểm tra là một lần bỏ qua im lặng sẽ che giấu một triển khai hỏng vô thời hạn.

Bảo vệ toàn bộ lần chạy, không chỉ lúc khởi động

Một kiểm tra mức sẵn sàng quan sát thế giới trước khi khởi chạy; nó không giám sát từng ổ cắm sau đó. Khi một đường đi trực tiếp không bao giờ chấp nhận được cho công việc này, hãy gắn một chính sách ra ngoài đã được phê duyệt, được thực thi liên tục và bao phủ DNS, IPv6 cùng phương tiện vận chuyển của chính đường hầm. Việc chuyển trạng thái IPv6 toàn cục của máy chủ không thay thế một chính sách giới hạn cho công việc.

Quyết định xem một sự kiện mới có thể chồng lấn với một công việc vẫn đang chạy hay không, giữ quy tắc đó ở chủ sở hữu khối lượng công việc, và làm cho việc thử lại an toàn cho thao tác dữ liệu. Dừng một công việc khi mất kết nối sẽ giới hạn công việc mà không bảo đảm gì về lưu lượng dự phòng.

Chấp nhận quy trình làm việc trong ba trường hợp: đường đi sẵn sàng, đường đi không khả dụng và mất mát giữa chừng. Bất cứ điều gì ít hơn sẽ kiểm tra lịch trình, không phải công việc.