Capordia编写请求的最小契约
一个可用的请求会指明负责人、项目、可用的输入、已识别的命令或流程以及预期结果。它说明同时使用的显卡数量、每张显卡的内存、预计时长以及输出目标。最后，它还说明截止时间、该截止时间的理由，以及有权接受延迟或缩减范围的人。
缺少这些信息不应被高优先级所掩盖。即使项目很重要，输入尚未就绪的任务仍然不具备准入资格。请询问缺失的内容并确定重新审查的时间点。这样队列便成为决策工具：它不会变成一个堆满无法启动的请求、人人都盼着它们能被自发处理的仓库。
区分准入、预留和通行权
准入检查任务是否可以被审查：权限、数据、兼容性、容量和流程是否齐备。预留随后保护一个已确定的时段或资源。优先级在争夺同一可用资源的多个具备准入资格的请求之间选择顺序。这三项决策可能由不同的人负责；请明确这种分工，以免技术需求的批准被默认通过。
一张空闲的显卡并不会让所有任务都具备准入资格。所需的磁盘空间可能不足，许可证可能限制并发数量，或者前一个结果可能是必需的。反过来，一个技术上已就绪的请求也可能在等待日程决策。请展示一个可以理解的原因和下一步行动，而不是一个没人看得懂的单纯数字排序。
定义不会变成特权的优先级
请选择少数几类清晰易懂的类别，例如已确认的外部截止时间、日常工作，以及没有确定日期的探索性工作。确定谁可以指定类别以及依据什么来指定。在同一类别内，采用按等待时长或轮换的规则可以让选择变得可预测。一个被拆分成一百份小提交的请求，不应机械地获得比另一个团队的请求多一百倍的机会。
Slurm 尤其区分具备准入资格的等待时长和基于已分配与已消耗资源的公平份额。这体现了两个不同的问题：已经等了多久，以及已经用掉了多少份额？你的规则可以保持手动。不要在不理解其参数的情况下照搬某种评分公式；某个特定调度器的权重并不构成普适的公平标准。
虚构示例：让一个紧急任务进来而不挤走其他任务
虚构团队“Plans et repères”只使用一张显卡。上午 9 点，一个“Plans”项目的任务已确认占用时段至 11 点；该任务不可中断。两个完整的请求在等待：“Repères”，四十分钟，以及“Esquisses”，八十分钟。9 点 30 分，一个三十分钟的紧急任务到来，由“Repères”为中午的一场评审提出。以上所有时长均为教学假设，而非实测数据。
本地规则允许已批准的紧急任务在下一个释放点插队，而不中断已经开始的工作。因此该紧急任务于 11 点开始，理论上于 11 点 30 分结束。随后团队让“Esquisses”优先通行，以免已通过紧急任务得到服务的“Repères”独占队列。这一例外情况以及“Repères”新的预计开始时间均已通知相关责任人。
| 假设时段 | 项目 | 通行原因 |
|---|---|---|
| 9 点–11 点 | Plans | 时段已占用，不可中断 |
| 11 点–11 点 30 分 | Repères，紧急任务 | 中午之前已确认的外部截止时间 |
| 11 点 30 分–12 点 50 分 | Esquisses | 在“Repères”的紧急任务得到服务后轮换 |
| 12 点 50 分–13 点 30 分 | Repères，日常请求 | 下一个可受理的请求 |
防止长任务饿死
始终优先处理最短的请求，队列看起来会更流畅，但可能让长任务被无限期推后。应预留专用时间窗口，或根据公示的等待时长阈值触发重新审查。该阈值是内部定义的规则，而非有保证的服务时限。如果长任务确实超出可用时段，其受理应导向新的排期，而不是让其陷入无望的等待。
短空档可以承接那些不会推迟已预约离场时间的任务。这一决定需要有可靠的估算、真正兼容的资源，以及在窗口内完成任务的可行性。不要用新的承诺填满日程表的所有余量。用于吸收偏差的预留并不是免费时段；动用它必须有明确的责任人和已知的后果。
规划范围明确的取消操作
指定谁可以取消自己的请求、某个项目的请求，或对其它任务已构成危险的执行。对于仍在等待的请求，确认其已从排队顺序中移除。对于已启动的任务，先确认哪些部分可以中断、哪些必须保留、谁在等待其输出。一条“已请求取消”的消息尚不能证明资源已经空闲。
实际使用的工具决定了技术效果。scancel 的文档区分了作业与其步骤，以及发送信号与取消作业。在使用同类工具前，应确认涉及的标识符和范围；不要为图方便而进行全局选择。随后检查进程是否结束以及部分输出的去向。数据恢复方案在迁移文档中处理，与这条优先级规则分开。
限定重试次数并隔离故障任务
在执行前决定同一原因可接受多少次自动重试。无效的输入不会因为重新运行就变得正确；暂时无法访问的依赖可以在核实后成为重试的理由。规则应说明最大次数、可能的延迟以及复核负责人。每次重新提交都清零的计数器会抵消这种保护：请将后续请求与同一问题关联起来。
达到所决定的界限时，将故障任务从正常竞争中移除，并置于逻辑隔离区，附上可读的原因。其余可受理的作业可以继续。重新纳入需要经过修正或获批的说明、一次小范围针对性检查以及所有者的决定；它不会自动恢复旧有紧急事项的优先级。该流程解决失败后的准入问题。输出的保存及其恢复仍属于迁移档案，不要在此臆造新的状态登记表。
用四种简单情形检验策略
让项目负责人用四个案例复读该规则：两个相同的请求、一个不可中断工作期间的紧急事项、一项被短请求包围的长任务，以及一个被归类为紧急的不完整请求。对于每个案例，不同的人都必须得出相同的下一步走向，或明确指认所需的裁决。只有作者自己才理解的规则尚不具备可执行的条件。
还要检查取消操作是否不会重复授予同一份容量，以及被阻塞的任务是否不会无谓地阻碍另一个符合条件的任务。这些检查可以先用纸面方式进行；它们并不能证明调度器已经实现。如果之后将其自动化，请在所配置的工具上复现同样的场景，再据此作出项目承诺。
衡量队列所提供的服务
按类别和项目跟踪合格请求的等待情况以及受阻原因。将等待、占用和直到获得可接受结果所需的时间分开来看。仅统计已完成的作业总数，可能会掩盖某个始终被推后的团队或紧急任务的持续积压。还要检查预估占用与实际占用之间的差异：它们会直接影响未来的预订。
在团队选定的时间节点，或在暴露出缺失规则的事故之后，重新审视该策略。每次只更改一条规则，并说明其对已有请求的影响。预期结果是可解释的排序、可追溯的例外情况以及一致的日程安排。它既不能替代 Capordia 账户的身份验证，也不能替代机器的权限，并且不构成任何支持承诺。
决策要点
紧急任务是否总应优先处理？
紧急任务必须合格、理由充分，并按共同规则获得批准。它不会使正在进行的工作变得可中断。请明确其通过节点、被调整的请求以及由谁承担对其截止时间的影响。
如何避免某个团队垄断时段？
查看已获得的资源和其它项目的等待情况，然后采用轮换或明确的共享规则。请求的原始数量并不是公平性的衡量标准。还要预先考虑长时作业的处理方式。
这种方法是否要求安装 Slurm？
不要求。Slurm 文档阐明了一些区分，但该策略可以先在团队的协调工具中实施。后续的自动化需要其自身的配置和检查；并不假定已提供任何调度器。