Capordiaカレンダーが守るべきものを定義する
まず、後回しにできない判断から始めましょう。成果のレビュー、他チームへの引き継ぎ、またはレンタル期間の終了です。各プロジェクトについて、その成果を受け入れられる権限を持つ担当者を定めます。納品日は単なる計算の終了日ではありません。レビューとファイルの回収の時間も、あらかじめそこに組み込んでおく必要があります。
次に、マシンの稼働可能時間と人の稼働可能時間を区別します。計算は夜間に進められることもありますが、初回の起動や検証にはチームの立ち会いが必要な場合があります。定額時間のすべてを交換可能な作業時間として数えるのではなく、この制約を明記してください。カレンダーは確認すべき社内の取り決めであり、Capordia による提供の約束ではありません。
出所がわかる、活用可能な見積もりを集める
各作業について、想定される入力、実際に準備が整う時刻、同時使用するカード数、カードあたりのメモリ、転送の必要性を記録します。読み込み開始から解放までのリソース占有の見積もりも加えます。この占有前にできる準備作業は切り分けておきましょう。管理上の待ち時間のあいだカードを予約したままにせずに済みます。
その見積もりが類似の試行によるものか、外挿によるものか、単なる仮定によるものかを明示します。過去の所要時間は、データ、バージョン、設定、使用リソースが十分に近い場合にのみ比較できます。記録がない場合は、検証すべき幅をもった範囲として示し、測定値を思わせる分単位の精度は表示しません。その結果が日程の選択を左右する場合は、小さな検証用の試行を確保しておきます。
総量から実行可能な枠へ落とし込む
予定されている使用時間を合計して明らかな過負荷を見つけ、各作業をタイムラインに配置します。分割できない4時間の処理は、中断と再開が確認されていない限り、2時間の空き2つには収まりません。同じディスクや同じ担当者を同時に必要とする2つの作業も、カードがまだ空いていても互いに妨げになることがあります。
Slurmのドキュメントは、枠の埋まり方が所要時間と要求リソースに依存する理由を示しています。優先度の低いジョブでも、優先度の高いジョブの開始予定を遅らせないなら開始できます。この考え方は計画を読む助けになりますが、Capordiaの提供にSlurmが含まれることを示すものではありません。スケジューラの利用は、その実際の構成とチームが決めたポリシーを前提とします。
架空の例: 2日間に3つのプロジェクト
架空のチーム「Bureau des tracés」は、この演習において、J1とJ2の2日間、9時から17時まで使用できるカードを1枚だけ持っている。どの処理もカードを共有せず、各占有にはロード、計算、エクスポートが含まれる。以下の所要時間は教育上の仮定であり、カタログのGPUやベンチマークから得られたものではない。共通の準備はJ1の開始時に1時間を占める。
Atlasは4時間を要し、J2の13時前に提出しなければならない。Baliseは3時間を要し、その入力はJ1の11時に到着し、提出はJ1の18時に予定されている。Cadastreは5時間を要し、J2の9時に準備完了となり、18時前に提出しなければならない。必要量は4 + 3 + 5 = 12時間である。共通の1時間と自由に残す3時間を加えると、計画は開いている16時間を使用する。
| 枠 | 想定される占有 | 期間 | 条件 |
|---|---|---|---|
| J1 9時～10時 | 共通の準備と確認 | 1時間 | 入力とバージョンが利用可能 |
| J1 10時～14時 | Atlas | 4時間 | 作業は10時に準備完了 |
| J1 14時～17時 | Balise | 3時間 | 入力は11時に受領 |
| J2 9時～14時 | Cadastre | 5時間 | 入力は9時に受領 |
| J2 14時～17時 | 未割り当ての予備 | 3時間 | 余裕はJ2にのみ存在 |
余裕は吸収すべきリスクの前に置く
自由な3時間は、12時間の作業のうち25%に相当します。しかし、この割合だけではBaliseの安全性を確保するには不十分です。その余裕は納品翌日に生まれます。Atlasが4時間ではなく5時間を要した場合、Baliseは許可された時間枠内で17時までに完了できません。計画は紙の上では成り立ちますが、初日は依然として不安定です。この見方は、単純な平均稼働率よりも有用です。
そうなればチームは、Atlasをその制約が許す場合に限り、一部または全部を別の枠へ移すか、追加の枠を確保するか、受け入れた範囲を縮小することができます。カードを追加するのは検討すべき選択肢であり、自動的な結論ではありません。利用可能で、互換性があり、必要なホスト側リソースも伴っている必要があります。有効な解決策がなければ、責任者は「余裕」という名で使えない予備を呼ぶのではなく、開始前にプロジェクトの約束を変更します。
公表したルールで対立を裁定する
同じ時間枠を二人の責任者が同時に求める前に、調整のルールを整えておきましょう。シンプルなルールとして、まず確定済みの外部締め切りを優先し、次に入力が揃っている作業、最後に依頼の古さで判断する方法があります。このルールを例外として破れるのは誰か、そして後ろにずれる作業をどのチームが引き受けるのかを明確にしてください。緊急対応は計画に対して明示的な影響を持つべきであり、依頼者にとって恒久的な新たな優先事項になってはなりません。
基準となるカレンダーと変更理由を保持しておきましょう。入力の到着が遅れた、実測時間が長かった、範囲が拡大した、といった理由です。作業キューのガイドは次に何を起動するかの判断を扱い、カレンダーは複数プロジェクトの締め切りを守ります。この2つを連携させることで、一時的に空いているカードが長い追加処理に必ずしも使えるわけではない理由を説明できます。
計画を確認し、適切なずれで見直す
1日を時間枠ごとに進めながら見直しましょう。各起動には、入力、アクセス、メモリ容量、担当者が揃っている必要があります。提出前の最終転送とレビュー時間も確認します。次に、最も起こりそうな遅延をシミュレーションし、どの余裕が実際にそれを吸収できるかを検証します。単一のずれで重要な締め切りを逃す場合は、計画を条件付きとして提示します。
実際に実行した後は、起動前の待ち時間、カードの占有時間、承認された結果までの時間を区別しましょう。この内訳で次の見積もりを修正します。転送の遅延だけでは、より強力なカードを正当化できません。手動の準備の忘れは、計算の余裕を増やしても解決しません。追跡は、ずれの原因を取り除くために役立つべきであり、単独の合計から責任者を探すためのものではありません。
単位を混同せずにカレンダーとプランを結び付ける
この例における8時間の1日は、組織上の枠であり、8時間の料金ではない。Capordiaのカタログでは、3日、7日、30日の固定期間と、ロット全体ごとの価格を提供している。レンタル期間、ロットのカード数、作業カレンダーを別々に確認すること。カードを追加しても、準備や人による検証がなくなるわけではない。
有用な成果物は、仮定、配置した余裕、差異が生じた場合の判断を伴う承認済みのカレンダーである。実際に提供されるリソースと代表的な試行によって確認する必要が残る。演習の16時間やその予備率を、保証された納期や普遍的なサイジングのルールに変えてはならない。
判断のための質問
予定した時間をGPUの数で割ることはできますか？
作業が並行して進められ、他のリソースがそれを許す場合に限られます。分割できない処理、依存関係、レビュー工程があると、カレンダーが制約されることがあります。合計時間をカード枚数に換算する前に、こうした制約を明らかにしましょう。
どのくらいの余裕を確保すべきですか？
余裕は、起こり得る差異とカレンダー上のその位置によって決まる。例の3時間は架空のものであり、すべての締め切りを守るものではない。確保すべき提出の前に余裕を置き、それを自分の観察に基づいて正当化すること。
計画はマシンの受け入れ確認に代わるものですか？
いいえ。計画は、使用可能なリソースとアプリケーションを前提としています。受け入れ確認は、時間枠を使用可能と見なす前に、この前提を検証する必要があります。不明な条件が残る場合、カレンダーは暫定のステータスと代替の判断を保持すべきです。