ポリシーは、ポリシー定義に基づいて処理されます。特に、単一の展開に適用される可能性のあるポリシーが複数ある場合は、有効なポリシーは範囲と適用レベルに基づいて決定されます。
この記事では、ポリシーの処理に関する一般的な情報を紹介しますが、さまざまなタイプのポリシーの詳細についても説明します。
組織レベルと適用タイプに基づいたポリシーのランク付け方法
プロジェクトのメンバーであるユーザーが展開を作成した場合、展開に適用されるポリシーは複数存在する可能性があります。
ポリシーを評価するには、まずシステムでポリシーを特定してからランク付けします。
|
組織レベルと適用タイプに基づいたポリシーの処理方法
ポリシーは評価され、ランク付けされてから、必要に応じてマージされ、有効なポリシーを生成します。有効なポリシーによって意図された結果が生成されますが、常に特定の名前が付いたポリシーになるわけではありません。
このセクションには、以下の例が含まれます。
- リース ポリシー
- Day 2 アクション ポリシー
次のリース ポリシーの例を確認してください。
考慮するポリシーを特定してランク付けすると、ポリシーが評価され、マージの順序が特定されます。
|
|
1 つのポリシーを適用してそれより高いすべてのポリシーを除外するのではなく、ポリシーをマージして複数の個別のポリシーの値を含めることができます。 この例では、ポリシー 2 の値がポリシー 1 よりも大きいため、ポリシー 2 がマージ プロセスで考慮対象から除外されます。 次に、ポリシー 3 がポリシー 1 に対して評価されます。ポリシー 3 のリースおよびリース合計の値がポリシー 1 よりも低いため、これらの値は猶予期間とともに有効なポリシーに含まれるようになります。 |
次の Day 2 アクション ポリシーの例を確認してください。
考慮するポリシーを特定してランク付けすると、ポリシーが評価され、マージの順序が特定されます。
|
リース ポリシー管理の目標に関する考慮事項
リース ポリシーの処理方法について理解したら、ポリシー管理の目標を特定します。ポリシーの処理方法を理解することで、管理不能になるような過剰な数のポリシーを作成することなく、管理目標を達成できるようになります。
ポリシーの実装方法を決定するときは、次のシナリオを考慮してください。
- リース ポリシーの目標と適用例
- Day 2 ポリシーの目標と適用例
管理目標 | 構成の例 | 動作 |
---|---|---|
プロジェクトレベルのポリシー値が適用される値に影響を与えることを引き続き許可する、デフォルトの有意な組織レベルのポリシー。 | 組織ポリシー = ソフト
プロジェクト 1 のポリシー 1 = ソフト
プロジェクト 2 のポリシー 1 = ソフト
|
プロジェクト 1 のメンバーがカタログ アイテムを申請します。 プロジェクト 2 は、プロジェクト 1 の展開には適用できないため、考慮されません。 マージされた有効なポリシー:
|
常に、組織レベルのポリシーのデフォルトになります。 | 組織ポリシー = ハード
プロジェクト 1 のポリシー 1 = ソフト
|
プロジェクト 1 のメンバーがカタログ アイテムを申請します。 プロジェクト 1 のポリシー 1 は、ハード組織レベルのプロジェクトが高いランクになり、ソフト ポリシーが考慮されないため、考慮されません。 有効なポリシー:
|
すべてのポリシーが組織レベルのデフォルト ポリシーを使用せずにプロジェクトレベルで定義されます。 | プロジェクト 1 のポリシー 1 = ソフト
プロジェクト 1 のポリシー 2 = ソフト
|
プロジェクト 1 のメンバーがカタログ アイテムを申請します。 これらは両方ともソフト ポリシーであり、どちらもプロジェクト 1 用に使用されます。値はマージされます。 有効なポリシー:
|
これらの例では、Day 2 アクション ポリシーが使用されています。
管理目標 | 構成の例 | 動作 |
---|---|---|
プロジェクトレベルのポリシー値が適用される値に影響を与えることを引き続き許可する、デフォルトの有意な組織レベルのポリシー。 |
組織ポリシー = ソフト
プロジェクト 1 のポリシー 1 = ソフト
プロジェクト 2 のポリシー 1 = ソフト
|
プロジェクト 1 のメンバーがカタログ アイテムを申請します。 プロジェクト 2 は、プロジェクト 1 の展開には適用できないため、考慮されません。
マージされた有効なポリシー:
|
常に、組織レベルのポリシーのデフォルトになります。 |
組織ポリシー = ハード
プロジェクト 1 のポリシー 1 = ソフト
|
プロジェクト 1 のメンバーがカタログ アイテムを申請します。 プロジェクト 1 のポリシー 1 は、ハード組織レベルのプロジェクトが高いランクになり、ソフト ポリシーが考慮されないため、考慮されません。
有効なポリシー:
|
すべてのポリシーが組織レベルのデフォルト ポリシーを使用せずにプロジェクトレベルで定義されます。 |
プロジェクト 1 のポリシー 1 = ソフト
プロジェクト 1 のポリシー 2 = ソフト
|
プロジェクト 1 のメンバーがカタログ アイテムを申請します。 これらは両方ともソフト ポリシーであり、どちらもプロジェクト 1 用に使用されます。値はマージされます。
有効なポリシー:
|
承認ポリシーの目標と適用例
承認ポリシーの評価は、以下のプロセスに従って行われます。
- 展開または Day 2 アクションの申請が送信されます。
- 承認サービスは、カタログ アイテムの申請や展開済みアイテムの変更を行うプロジェクトに適用されるポリシーを照会します。
- 適用可能なすべてのプロジェクト レベルおよび組織レベルの範囲ポリシーが返されます。
- 承認ポリシーは、展開条件に基づいてフィルタリングされます。展開基準は、展開および Day 2 アクションに適用されます。
- 一致するポリシーが見つからない場合、承認の必要はなく、展開プロセスは続行されます。
- 一致するポリシーがあった場合(たとえば、AP1、AP2、APn)、承認アイテムは以下のように作成されます。
- 適用されるポリシー = AP1、AP2、APn
- 承認者 = 適用されるすべてのポリシーのすべての承認者の和集合
- 自動有効期限 = ポリシーの値が 1 つでも拒否の場合は拒否、すべて承認の場合は承認
- 有効期限 = 適用されているすべてのポリシーの中で最小の日数
次の表は、複数のポリシーがある場合の例です。ポリシーがどのように処理されるかについては、表の下で説明します。
ポリシー | 構成の例 |
---|---|
AP1 | 範囲 = 組織 自動有効期限 = 承認 有効期間 = 7 日 |
AP2 | 範囲 = プロジェクト 1 自動有効期限 = 承認 有効期間 = 3 日 |
AP3 | 範囲 = プロジェクト 1 自動有効期限 = 拒否 有効期間 = 4 日 |
AP4 | 範囲 = プロジェクト 2 自動有効期限 = 承認 有効期間 = 5 日 |
上記のようなポリシーと構成例の場合、プロジェクト 1 の申請は、以下のように処理されます。
- 範囲の評価は、AP1、AP2、および AP3 を返します。AP4 はプロジェクト 2 のポリシーであるため、除外されます。
- AP1、AP2、および AP3 が展開とアクションの条件を満たしている場合、承認アイテムには次の値が含まれます。
- 承認者 = AP1、AP2、および AP3 の中から、任意の組み合わせまたはそのすべてが承認者として追加されます。
- 自動有効期限 = 拒否。AP3 の値によって動作が限定されます。
- 有効期間 = 3 日。AP2 が最小の値を提示しています。