CapordiaViết bản hợp đồng tối thiểu của một yêu cầu
Một yêu cầu có thể xử lý được phải nêu rõ chủ sở hữu, dự án, đầu vào sẵn có, một lệnh hoặc quy trình đã được xác định và kết quả mong đợi. Yêu cầu đó ghi rõ số lượng card đồ họa chạy đồng thời, dung lượng bộ nhớ trên mỗi card, thời lượng ước tính và nơi lưu kết quả đầu ra. Cuối cùng, yêu cầu nêu rõ hạn chót, lý do của hạn chót đó và người có thẩm quyền chấp nhận việc trễ hạn hoặc giảm bớt phạm vi.
Việc thiếu những thông tin này không được che giấu bằng một mức ưu tiên cao. Một tác vụ chưa sẵn sàng đầu vào vẫn không đủ điều kiện được chấp nhận, kể cả khi dự án quan trọng. Hãy hỏi xem còn thiếu gì và ấn định thời điểm xem xét lại. Khi đó hàng đợi trở thành một công cụ ra quyết định: nó không biến thành kho chứa những yêu cầu không thể khởi chạy mà ai cũng hy vọng sẽ được xử lý tự phát.
Phân biệt chấp nhận, đặt trước và quyền được ưu tiên
Việc chấp nhận kiểm tra xem tác vụ có thể được xem xét hay không: quyền, dữ liệu, khả năng tương thích, năng lực và quy trình đều đã có. Sau đó, việc đặt trước bảo vệ một khung giờ hoặc một tài nguyên đã được quyết định. Mức ưu tiên chọn thứ tự giữa các yêu cầu đủ điều kiện đang tranh nhau một tài nguyên sẵn có. Ba quyết định này có thể thuộc về những người khác nhau; hãy nêu rõ sự phân chia đó để tránh việc vô tình hợp thức hóa nhu cầu kỹ thuật.
Một card đồ họa rảnh không làm cho mọi tác vụ đều đủ điều kiện. Có thể thiếu dung lượng đĩa cần thiết, một giấy phép có thể giới hạn số chạy đồng thời, hoặc kết quả trước đó có thể là bắt buộc. Ngược lại, một yêu cầu đã sẵn sàng về mặt kỹ thuật vẫn có thể chờ một quyết định về lịch. Hãy hiển thị một lý do dễ hiểu và một hành động tiếp theo, thay vì chỉ một con số thứ hạng mà không ai hiểu được.
Định nghĩa mức ưu tiên không trở thành đặc quyền
Hãy chọn một vài hạng mục dễ hiểu, chẳng hạn hạn chót bên ngoài đã xác nhận, công việc thường ngày và hoạt động khám phá không có ngày cố định. Hãy xác định ai có thể gán một hạng mục và căn cứ nào để biện minh cho hạng mục đó. Trong cùng một hạng mục, một quy tắc dựa trên thời gian chờ hoặc luân phiên có thể khiến việc lựa chọn trở nên dễ đoán. Một yêu cầu bị chia thành một trăm bài nộp nhỏ không được tự động có cơ hội gấp trăm lần so với một yêu cầu của nhóm khác.
Slurm phân biệt cụ thể giữa thời gian chờ đủ điều kiện và việc chia sẻ công bằng dựa trên tài nguyên được cấp và đã tiêu thụ. Điều này minh họa hai câu hỏi khác nhau: đã chờ từ bao giờ, và đã sử dụng bao nhiêu phần? Quy tắc của bạn có thể vẫn thủ công. Đừng bê nguyên một công thức tính điểm mà không hiểu các tham số của nó; trọng số của một bộ lập lịch cụ thể không tạo thành một chuẩn mực công bằng phổ quát.
Ví dụ giả định: đưa một trường hợp khẩn cấp vào mà không đuổi những trường hợp khác
Nhóm giả định «Plans và Repères» sử dụng một card đồ họa duy nhất. Lúc 9 giờ, một tác vụ của dự án Plans đã có khung giờ được xác nhận đến 11 giờ; nó không thể bị ngắt. Hai yêu cầu đầy đủ đang chờ: Repères, bốn mươi phút, và Esquisses, tám mươi phút. Lúc 9 giờ 30 xuất hiện một trường hợp khẩn cấp ba mươi phút, do Repères yêu cầu cho một buổi đánh giá lúc giữa trưa. Tất cả những khoảng thời gian này là giả định minh họa, không phải số đo thực tế.
Quy tắc cục bộ cho phép một trường hợp khẩn cấp đã được xác nhận được chen vào ngay điểm giải phóng kế tiếp, mà không ngắt một công việc đã bắt đầu. Vì vậy, trường hợp khẩn cấp bắt đầu lúc 11 giờ và kết thúc theo lý thuyết lúc 11 giờ 30. Sau đó nhóm dành lượt cho Esquisses để tránh việc Repères, đã được phục vụ nhờ trường hợp khẩn cấp, chiếm độc quyền hàng đợi. Ngoại lệ này và thời điểm bắt đầu mới dự kiến của Repères được thông báo cho những người phụ trách liên quan.
| Khung giờ giả định | Dự án | Lý do được ưu tiên |
|---|---|---|
| 9 giờ–11 giờ | Plans | Khung giờ đã bắt đầu, không thể ngắt |
| 11 giờ–11 giờ 30 | Repères, khẩn cấp | Hạn chót bên ngoài đã xác nhận trước giữa trưa |
| 11 giờ 30–12 giờ 50 | Esquisses | Luân phiên sau khi phục vụ trường hợp khẩn cấp cho Repères |
| 12 giờ 50–13 giờ 30 | Repères, yêu cầu thường ngày | Yêu cầu được chấp nhận tiếp theo |
Ngăn chặn tình trạng đói của các tác vụ dài
Luôn phục vụ yêu cầu ngắn nhất tạo ra một hàng đợi có vẻ trôi chảy nhưng có thể đẩy lùi vô thời hạn một tác vụ dài. Hãy dự phòng các khung giờ dành riêng hoặc xem xét lại từ một ngưỡng tuổi chờ đã công bố. Ngưỡng này là một quy tắc nội bộ cần định nghĩa, không phải một thời hạn phục vụ được đảm bảo. Nếu tác vụ dài thực sự vượt quá khoảng thời gian khả dụng, việc chấp nhận nó phải dẫn đến một lịch trình mới thay vì chờ đợi vô vọng.
Các khoảng trống ngắn có thể tiếp nhận những tác vụ không đẩy lùi một khởi hành đã dành riêng. Quyết định này giả định một ước lượng đáng tin cậy, một tài nguyên thực sự tương thích và khả năng hoàn thành trong khung giờ đó. Đừng lấp đầy mọi khoảng dư của lịch trình bằng những cam kết mới. Một khoản dự phòng nhằm hấp thụ sai lệch không phải là một khung giờ miễn phí; việc sử dụng nó phải có người chịu trách nhiệm và hậu quả đã biết.
Dự liệu một việc hủy bỏ có phạm vi rõ ràng
Hãy chỉ định ai có thể hủy yêu cầu của chính mình, yêu cầu của một dự án hoặc một lượt thực thi đã trở nên nguy hiểm cho các tác vụ khác. Đối với một yêu cầu còn đang chờ, hãy xác nhận việc rút nó khỏi thứ tự lượt. Đối với một tác vụ đã khởi chạy, trước tiên hãy kiểm tra phần nào có thể ngắt, phần nào phải được giữ lại và ai đang chờ kết quả đầu ra của nó. Một thông báo “đã yêu cầu hủy” chưa chứng minh rằng tài nguyên đã được giải phóng.
Công cụ thực tế quyết định các tác động kỹ thuật. Tài liệu scancel phân biệt một tác vụ với các bước của nó, cũng như việc gửi một tín hiệu và việc hủy tác vụ. Trước khi dùng một công cụ tương đương, hãy kiểm tra mã định danh và phạm vi liên quan; tránh chọn toàn bộ cho tiện. Sau đó kiểm tra việc kết thúc các tiến trình và nơi lưu các kết quả đầu ra một phần. Kế hoạch khôi phục dữ liệu được xử lý trong hồ sơ di chuyển, tách biệt với quy tắc ưu tiên này.
Giới hạn số lần thử và cô lập một tác vụ lỗi
Hãy quyết định trước khi thực thi xem bao nhiêu lần thử tự động là chấp nhận được cho cùng một nguyên nhân. Một đầu vào không hợp lệ không trở nên đúng chỉ vì ta khởi chạy lại; một phụ thuộc tạm thời không truy cập được có thể biện minh cho một lần thử mới sau khi kiểm tra. Quy tắc phải nêu rõ số lần tối đa, thời gian chờ nếu có và người chịu trách nhiệm xem xét lại. Một bộ đếm được đặt lại về không ở mỗi lần gửi mới sẽ vô hiệu hóa biện pháp bảo vệ này: hãy gắn các yêu cầu liên tiếp vào cùng một vấn đề.
Khi đạt đến giới hạn đã định, hãy loại tác vụ lỗi khỏi luồng cạnh tranh thông thường và đưa nó vào vùng cách ly logic, kèm một lý do dễ đọc. Phần còn lại của các tác vụ được chấp nhận có thể tiếp tục. Việc tái tích hợp đòi hỏi một sửa chữa hoặc một giải thích đã được xác nhận, một kiểm tra nhỏ có mục tiêu và một quyết định của chủ sở hữu; nó không tự động lấy lại mức ưu tiên của một tình huống khẩn cấp cũ. Thủ tục này giải quyết việc chấp nhận sau thất bại. Việc lưu giữ các kết quả đầu ra và khôi phục chúng vẫn thuộc hồ sơ di chuyển, không tạo ra ở đây một sổ đăng ký trạng thái mới.
Kiểm thử chính sách bằng bốn tình huống đơn giản
Hãy để các quản lý dự án đọc lại quy tắc với bốn trường hợp: hai yêu cầu giống hệt nhau, một tình huống khẩn cấp trong lúc một tác vụ không thể ngắt đang chạy, một tác vụ dài được bao quanh bởi các yêu cầu ngắn và một yêu cầu chưa đầy đủ được xếp vào loại khẩn cấp. Với mỗi trường hợp, một người khác nhau phải đi đến cùng một lượt khởi hành tiếp theo hoặc chỉ rõ ràng sự phân xử cần thiết. Một quy tắc mà chỉ tác giả của nó hiểu thì chưa sẵn sàng để áp dụng.
Cũng hãy kiểm tra rằng một việc hủy bỏ không cấp hai lần cùng một năng lực và rằng một tác vụ bị kẹt không ngăn cản vô ích một tác vụ được chấp nhận khác. Những kiểm tra này có thể bắt đầu trên giấy; chúng không chứng minh việc triển khai một bộ lập lịch. Nếu sau đó bạn tự động hóa, hãy tái tạo các kịch bản tương tự trên công cụ đã cấu hình trước khi để một cam kết dự án phụ thuộc vào nó.
Đo lường mức phục vụ mà hàng đợi mang lại
Theo dõi mức chờ của các yêu cầu đủ điều kiện theo lớp và theo dự án, cùng với lý do bị chặn. Tách biệt thời gian chờ, thời gian chiếm dụng và thời gian đến khi có kết quả được chấp nhận. Một con số tổng công việc đã hoàn thành có thể che giấu một nhóm luôn bị đẩy lùi hoặc sự tích tụ các tác vụ khẩn cấp. Hãy xem cả chênh lệch giữa mức chiếm dụng ước tính và thực tế: chúng ảnh hưởng trực tiếp đến các lượt đặt trước trong tương lai.
Xem xét lại chính sách theo một mốc thời gian đã chọn cùng với nhóm, hoặc sau một sự cố cho thấy thiếu một quy tắc. Mỗi lần chỉ thay đổi một quy tắc và thông báo ảnh hưởng của nó lên các yêu cầu đã có. Kết quả mong đợi là một thứ tự ưu tiên có thể giải thích được, các ngoại lệ có thể truy vết và một lịch trình nhất quán. Nó không thay thế việc xác thực tài khoản Capordia cũng như các quyền trên máy, và không tạo ra bất kỳ cam kết hỗ trợ nào.
Câu hỏi để quyết định
Có phải lúc nào cũng ưu tiên một việc khẩn cấp trước không?
Một việc khẩn cấp phải đủ điều kiện, có lý do chính đáng và được phê duyệt theo quy tắc chung. Nó không làm cho một công việc đang chạy trở nên có thể ngắt. Hãy xác định điểm ưu tiên của nó, các yêu cầu bị dịch chuyển và người chịu trách nhiệm về ảnh hưởng lên thời hạn của chúng.
Làm thế nào để tránh việc một nhóm độc chiếm các khung giờ?
Hãy xem các tài nguyên đã được cấp và mức chờ của các dự án khác, sau đó dùng luân phiên hoặc một quy tắc chia sẻ rõ ràng. Số lượng yêu cầu thô không phải là thước đo công bằng. Hãy dự liệu cả việc xử lý các công việc dài.
Phương pháp này có bắt buộc phải cài Slurm không?
Không. Các tài liệu Slurm làm rõ một số phân biệt, nhưng chính sách trước hết có thể được áp dụng trong công cụ phối hợp của nhóm. Việc tự động hóa sau này cần cấu hình và các kiểm soát riêng; không có bộ lập lịch nào được giả định là có sẵn.