チケットポリシー階層は、衝突するチケットポリシーの一部のケースを解決する手段を提供します。チケットポリシー間の衝突の解決は、特に保留中のジョブに関係します。
そのようなケースは、共有ベースポリシーおよび機能ポリシーと結び付いて発生する場合があります。どちらのポリシーでも、同じリーフレベルのエンティティーに属するジョブへの優先順位への割り当ては、先着順で行われます。リーフレベルのエンティティーには、次のものが該当します。
共有ツリーのユーザーリーフ
共有ツリーのプロジェクトリーフ
機能ポリシーの、ユーザー、プロジェクト、部署、またはキューなどのカテゴリのすべてのメンバー
ジョブカテゴリーのメンバーは、リーフレベルのエンティティーには含まれません。そのため、同じユーザーの最初のジョブが最大量を受け取り、2 番目のジョブが 2 番目に多い量を受け取り、3 番目がそれに続く、となります。
別のポリシーが異なる順序を指定した場合に、衝突が発生する可能性があります。そのため、たとえば、優先ポリシーが 3 番目のジョブをもっとも重要なものとして定義し、発行される最初のジョブが最後に来る場合があります。
ポリシー階層は、共有ツリーポリシーや機能ポリシーよりも、優先ポリシーにより高い優先順位を与える場合があります。このようなポリシー階層により、優先ポリシーの高優先順位ジョブが、ほかの 2 つのポリシーのジョブよりも多くのエンタイトルメントを獲得します。このようなジョブは、共有ツリーで同じリーフレベルのエンティティー (ユーザーまたはプロジェクト) に属する必要があります。
チケットポリシー階層は、3 文字までの組み合わせから構成できます。これらの文字は、次の 3 つのチケットポリシーの名前の最初の文字です。
S – Share-based (共有ベース)
F – Functional (機能)
O – Override (優先)
これらの文字を使用しててチケットポリシーの階層を作成します。最初の文字で、最上位のポリシーを定義します。最後の文字で、階層の最下位を定義します。ポリシー階層に存在しないポリシーは、階層に影響を与えません。ただし、階層に存在しないポリシーも、ジョブのチケットのソースとなる場合があります。ただし、これらのチケットはそのほかのポリシーにおけるチケット計算には影響しません。各ジョブが全エンタイトルメントを定義できるように、すべてのポリシーのすべてのチケットは合計されます。
次の例では、2 つの設定と、これらの設定が保留中のジョブの順序にどのように影響するかを説明します。
policy_hierarchy=OS |
優先ポリシーは、保留中の各ジョブに適切な数のチケットを割り当てます。
2 つのジョブが同じユーザーまたは同じリーフレベルのプロジェクトに属する場合、チケットの数は共有ツリーでのエンタイトルメントの割り当てを決定します。続いて共有ツリーのチケットは、保留中のジョブに対して計算されます。
優先ポリシー、および共有ツリーポリシーからのチケットは、階層内にないそのほかのアクティブなポリシーとともに合算されます。結果のチケット数が最高であるジョブは、最高のエンタイトルメントを獲得します。
policy_hierarchy=OF |
優先ポリシーは、保留中の各ジョブに適切な数のチケットを割り当てます。続いて優先ポリシーからのチケットが合算されます。
2 つのジョブが同じ機能カテゴリメンバーに属している場合、結果のチケット数は機能ポリシーのエンタイトルメントの割り当てに影響します。このエンタイトルメントの割り当てに基づいて、保留中のジョブに対する機能チケットが計算されます。
結果の値は、優先ポリシーのチケット量に加算されます。結果のチケット数が最高であるジョブは、最高のエンタイトルメントを獲得します。
3 つの文字は理論上どのように組み合わせることもできますが、意味がある、あるいは現実的に妥当なのは一部の組み合わせだけです。最後の文字は常に S または F にする必要があります。これは、上記の例で説明した特徴があるため、影響を受ける可能性があるポリシーは、この 2 つしかないためです。
policy_hierarchy の設定には次の形式を推奨します。
[O][S|F] |
優先ポリシーが存在する場合、影響を与える可能性があるポリシーは優先ポリシーのみであるため、O は最初の文字としてのみ使用する必要があります。影響を受ける可能性があるポリシーは、共有ベースポリシーと機能ポリシーのみです。そのため、S または F を最後の文字として使用する必要があります。