Capordia要求の最小契約を書く
実行可能な要求には、オーナー、プロジェクト、利用可能な入力、特定されたコマンドまたは手順、期待される結果を明記します。同時に使うカードの枚数、カードごとのメモリ、推定所要時間、出力の保存先も示します。さらに、期限、その期限の理由、遅延やスコープ縮小を承認できる担当者を明記します。
これらの情報の欠如を、高い優先度で覆い隠してはなりません。入力が準備できていないタスクは、プロジェクトが重要であっても受付不可のままです。何が不足しているかを確認し、再検討の時点を定めます。そうすればキューは意思決定の道具となり、誰もが自発的に処理されることを期待する、起動不可能な要求の倉庫にはなりません。
受付、予約、通行権を区別する
受け入れでは、タスクを検討できるかどうかを確認します。権限、データ、互換性、容量、および手順が揃っていることです。次に予約が、決定された時間枠またはリソースを保護します。優先度は、利用可能なリソースを巡って競合する受け入れ可能な要求間の順序を選択します。これら3つの決定は、異なる担当者に依存する場合があります。技術的な必要性が暗黙のうちに承認されることを避けるため、この役割分担を明示してください。
カードが空いていても、すべてのタスクが受付可能になるわけではありません。必要なディスクが足りない、ライセンスが同時実行を制限する、前の結果が必要といったことがあります。逆に、技術的には準備ができた要求が、スケジュールの決定を待つこともあります。誰にも解釈できない単なる数値順位ではなく、理解できる理由と次のアクションを示しましょう。
特権にならない優先度を定義する
読みやすいクラスをいくつか選びます。たとえば、確認済みの外部期限、通常業務、確定日のない探索などです。誰がクラスを割り当てられるか、どの証拠がそれを正当化するかを定めてください。クラス内では、先着順やローテーションのルールによって選択が予測可能になります。100件の小さな申請に分割された要求が、別のチームの1件の要求よりも機械的に100倍のチャンスを得てはなりません。
Slurm は特に、許容される待機時間の長さと、割り当てられたリソースおよび消費されたリソースに基づく公平な共有を区別します。これは二つの異なる問いを示しています。いつから待っているのか、そしてすでにどれだけの割り当てを使ったのか。ルールは手動のままでも構いません。パラメータを理解せずにスコア計算式を流用しないでください。特定のスケジューラの重み付けは、普遍的な公平性の基準ではありません。
架空の例：他のジョブを追い出さずに緊急案件を通す
架空のチーム「 Plans et repères 」は1枚のカードを使用しています。9時に、プロジェクトPlansのタスクが11時まで確定した時間枠を確保しており、中断はできません。完全な要求が2件待っています。Repèresが40分、Esquissesが80分です。9時30分に、Repèresから正午のレビューのために30分の緊急対応が要求されます。これらの時間はすべて教育用の仮定であり、実測値ではありません。
ローカルルールでは、承認された緊急案件は、すでに開始された作業を中断することなく、次の解放時点で割り込めます。したがって緊急案件は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 のドキュメントでは、ジョブとそのステップ、およびシグナルの送信とジョブのキャンセルを区別しています。同等のツールを使用する前に、対象となる識別子と範囲を確認してください。便宜上、全体を一括選択することは避けてください。その後、プロセスの終了と部分的な出力の保存先を確認します。データ復旧計画は移行のドシエで扱い、この優先順位ルールとは別にします。
試行回数を制限し、不具合のあるタスクを隔離する
同じ原因に対して何回の自動試行が許容されるかを実行前に決めてください。無効な入力は再実行しても正しくなりません。一時的に到達できない依存関係は、確認後の再試行を正当化する場合があります。ルールには、最大回数、必要に応じた遅延、再検討の責任者を明記する必要があります。新しい投入ごとにリセットされるカウンターはこの保護を無効にします。連続する要求を同じ問題に結び付けてください。
決定した上限に達したら、不具合のあるタスクを通常の競合から外し、読み取り可能な理由を付けて論理的に隔離します。残りの受付可能なジョブは継続できます。復帰には、修正または検証済みの説明、小規模な的を絞った確認、および所有者の判断が必要です。以前の緊急度の優先順位を自動的に取り戻すことはありません。この手順は失敗後の受け入れを扱います。出力の保持とその復旧は移行のドシエに残し、ここで新たな状態レジストリをでっち上げないでください。
4つの単純な状況でポリシーをテストする
プロジェクト責任者に4つのケースでルールを再確認してもらいます。同一の要求2件、中断不可能なジョブ中の緊急案件、短い要求に囲まれた長時間タスク、および緊急として分類された不完全な要求です。各ケースについて、別の担当者が同じ次の開始に到達するか、必要な裁定を明示的に特定できる必要があります。作成者だけが理解できるルールは、適用できる状態ではありません。
また、キャンセルが同じ容量を二重に付与しないこと、およびブロックされたジョブが他の受付可能なジョブを不必要に妨げないことを確認してください。これらの検証は紙の上で始められますが、スケジューラの実装を証明するものではありません。その後自動化する場合は、プロジェクトのコミットを依存させる前に、構成されたツールで同じシナリオを再現してください。
キューが提供するサービスを測定する
クラス別およびプロジェクト別に、受理可能なリクエストの待ち状況とブロックの理由を追跡します。待ち時間、稼働、受理された結果までの所要時間を分けて把握してください。完了した作業の合計だけでは、常に後回しにされているチームや、緊急タスクの蓄積が見えなくなることがあります。推定稼働と実稼働の乖離も確認してください。これは将来の予約に直接影響します。
チームと合意した期限で、または不足しているルールが判明したインシデントの後に、ポリシーを見直します。一度に変更するルールは1つにし、既存のリクエストへの影響を告知してください。期待される結果は、説明可能な処理順序、追跡可能な例外、整合性のあるスケジュールです。これはCapordiaアカウントの認証やマシンの権限に代わるものではなく、サポートのコミットメントを生じさせるものでもありません。
判断のための質問
緊急の案件は常に最優先にすべきですか？
緊急案件は、受理可能で、正当化され、共通ルールに従って承認される必要があります。進行中の作業を中断可能にするものではありません。通過ポイント、移動されるリクエスト、およびそれらの期限への影響を引き受ける担当者を定義してください。
特定のチームが枠を独占するのを防ぐにはどうすればよいですか？
すでに獲得したリソースと他プロジェクトの待ち状況を確認し、ローテーションまたは明示的な配分ルールを用います。リクエストの生の件数は公平性の指標にはなりません。長時間の作業の処理も計画してください。
この方法ではSlurmのインストールが必須ですか？
いいえ。Slurmのドキュメントはいくつかの区別を明確にする参考になりますが、ポリシーはまずチームの調整ツール内で適用できます。将来的な自動化には独自の設定と制御が必要であり、スケジューラが提供されていることは前提としていません。