ランディングページとダッシュボードのビュー

オペレーショナルレジリエンスリリース 21.0.x で導入された柔軟なデータモデルは、ダッシュボードの基盤を提供し、依存サービスのフローを追跡します。失敗したコントロール、インシデント、機能停止などのタイプ別の危険フラグや、フラグの数、重要度、影響許容度などのビジネスサービスメトリクスを含むデータは、柔軟なデータモデルの変更によってダッシュボードで更新されます。

例に示されているデータは、危険フラグの数別のビジネスサービス、重要度別のビジネスサービス、影響許容度別のビジネスサービスなどのビジネスサービス用です。sn_oper_res.top_class_nameプロパティを設定することで、サービスオファリング、ビジネスプロセス、またはアプリケーションサービスを変更できます。その後、最上位クラスを別のオブジェクトに変更すると、その特定の最上位クラスに関するデータが表示されます。

危険フラグの計算とロールアップ

前の例に示したダッシュボードには、1〜30 の範囲の危険フラグが表示されます。選択すると、詳細な内訳が表示され、合計20の危険フラグが表示され、3つは特に「カードと支払い」レベルに起因します。これはロールアップ機能を示しています。ロールアップ機能では、選択した [カードと支払い] ビジネスサービスの下に赤いフラグが集約され、データの階層ビューが提供されます。

[危険フラグの総数] 列に表示される値「24」は、「カードと支払い」ビジネスサービスの下にあるすべてのエンティティの危険フラグのロールアップ値です。

Calculate red flags for CSDM and dependenciesスケジュール済みジョブは、[sn_oper_res_profile] テーブルに新しいレコードを作成しません。代わりに、[sn_grc_m2m_profile_profile] テーブルのデータを使用して、既存の sn_oper_res_profile レコードの影響を受けるオブジェクトを再計算します。

Calculate red flags for CSDM and dependenciesスケジュール済みジョブは、次の条件が満たされた場合にのみ、[sn_oper_res_profile] テーブルのプロファイルの危険フラグをフェッチします。

sn_oper_res_profile.pillarが空でない。
[ sn_oper_res_profile.applies_to] フィールドが空ではない。

危険フラグフェッチメカニズムでは、 sn_oper_res_profile.profile 条件、 sn_oper_res_profile.applies_to 条件、またはその両方の組み合わせを使用できます。

また、危険フラグは、[sn_oper_res_profile] レコードから影響を受けるオブジェクトおよび影響を受けるオブジェクトクラスを継承します。たとえば、アプリケーションサービスの Operational Resilience プロファイルで、影響を受けるオブジェクトとしてビジネスサービス、オファリング、およびビジネスプロセスがリストされている場合 ([影響を受けるオブジェクト] 列に表示されます)、これらのオブジェクトは、アプリケーションサービスとその関連エンティティに関連付けられているすべての危険フラグにコピーされます。

注:

リリース 22.x.x 以降オペレーショナルレジリエンス新規インストールでは、 Calculate red flags for CSDM and dependencies および Update CSDM and other dependencies のスケジュール済みジョブはデフォルトで非アクティブ化されます。既存のインストールの場合、これらのジョブは現在のステータス (アクティブまたは非アクティブ) を保持します。

危険フラグを計算するための条件

このセクションでは、 sn_oper_res_profile.profile 条件と sn_oper_res_profile.applies_to 条件を参照用します。危険フラグを計算するための基準と関連表の詳細については、危険フラグ計算表を参照してください。

表 : 1. 危険フラグの計算
危険フラグ	テーブル	条件	メモ
高リスク:高度なリスク	[sn_risk_advanced_risk_assessment_instance]	条件: entity_1=プロファイルステータス = 30 summary_residual_risk_scoreは、risk_assessment_methodologyで定義された最大基準より大きい値にする必要があります sn_risk_advanced_risk_assessment_instanceにリンクされたオープンアセスメントを含めることはできません	これらすべてのリスクについて、[sn_oper_res_risk] テーブルにステージングレコードが作成されます。
失敗したコントロール:ステップ 1 (オプション)	[sn_compliance_m2m_control_entity](sn_compliance_control ← → sn_grc_profile)	条件: エンティティ = プロファイル control.status=non_compliant control.exempt=false control.state=monitor control.active=true	コントロールのリストが抽出されます。これは有効な危険フラグです。
失敗したコントロール:ステップ 2	[sn_compliance_control]	条件: entity=profile または sys_id コントロールのリストで control.status=non_compliant control.exempt=false control.state=monitor control.active=true	これらすべてのコントロールについて、ステージングレコードは [sn_oper_res_failed_control] テーブルに作成されます。
問題:ステップ 1 (オプション)	[sn_grc_m2m_issue_to_entity](sn_grc_issue ←→ sn_grc_profile)	条件: エンティティ = プロファイル sn_grc_issue.active=true	問題のリストが抽出されます。有効な危険フラグです。
問題:ステップ 2 (オプション) 次のいずれかのピラーが使用されている場合は、このステップが考慮されます。サービスビジネスサービスオファリング	[sn_oper_res_m2m_scenario_event_issue](scenario_event ←→ sn_grc_issue) [sn_oper_res_m2m_scenario_event_service](scenario_event ←→サービス)	2 つのテーブルを使用して共同クエリが実行され、サービス、ビジネスサービス、およびオファリングの [sn_grc_issue] がフェッチされます。	これらは、ステップ 1 の問題のリストに追加されます。
問題:ステップ 3	[sn_grc_issue]	条件: entity=profile または sys_id コントロールのリストでアクティブ = true さらに、問題に例外ポリシーを含めることはできません。例外ポリシーは、次の 2 つの条件を使用して [sn_compliance_policy_exception] テーブルで確認できます。 validity>now ステータス = 8	これらすべての問題について、[sn_oper_res_issue] テーブルにステージングレコードが作成されます。
インシデント:ステップ 1	インシデント	条件: cmdb_ci=profile.applies_to 状態 IN [1,2]	これらすべてのインシデントについて、[sn_oper_res_incident] テーブルにステージングレコードが作成されます。
インシデント:ステップ 2 (オプション)	[task_ci]	条件: ci_item=profile.applies_to task.sys_class_name=incident task.state IN [1,2]
インシデント:ステップ 3	[task_cmdb_ci_service]	条件: cmdb_ci_service=profile.applies_to task.sys_class_name=incident task.state IN [1,2]
変更要求:ステップ 1	[change_request]	条件: cmdb_ci=profile.applies_to アクティブ = true	これらすべての変更要求について、[sn_oper_res_change_request] テーブルにステージングレコードが作成されます。
変更要求:ステップ 2 (オプション)	[task_ci]	条件: ci_item=profile.applies_to task.sys_class_name=change_request task.active=true
変更要求:ステップ 3	[task_cmdb_ci_service]	条件: cmdb_ci_service=profile.applies_to task.sys_class_name=change_request task.state IN [1,2]
機能停止	[cmdb_outage_ci_mtom](cmdb_ci ←→ cmdb_ci_outage) [cmdb_ci_outage](cmdb_ci) [cmdb_ci_outage] のレコードごとに、[cmdb_ci_outage_ci_mtom] テーブルに 1 つのレコードが作成されます。[cmdb_ci_outage] では、影響を受ける CI ごとにレコードが [cmdb_ci_outage_ci_mtom] テーブルに挿入されます。	条件: ci_item=profile.applies_to outage.type IN [デグレード、機能停止] outage.end が空であるか、outage.end >	これらすべての機能停止について、[sn_oper_res_outage] テーブルにステージングレコードが作成されます。
タスク	[task]	条件: cmdb_ci=profile.applies_to アクティブ = true sys_class_name IN <プロパティ sn_oper_res.allowed_task_tables からフェッチされたクラスのリストベースシステムの一部として、問題レコードのみが考慮されます。	これらすべてのタスクについて、[sn_oper_res_task] テーブルにステージングレコードが作成されます。
運用上の脆弱性:ステップ 1 (オプション)	[sn_grc_case_mgmt_related_area]	条件: related_area=profile または related_area=profile.applies_to core_case.sys_class_name=sn_oper_res_vulnerability core_case.active=true	これらすべての脆弱性について、[sn_oper_res_vulnerability_profile] テーブルにステージングレコードが作成されます。
運用上の脆弱性:ステップ 2 (オプション)	[sn_grc_case_mgmt_impacted_area]	条件: impacted_area=profile または impacted_area=profile.applies_to core_case.sys_class_name=sn_oper_res_vulnerability core_case.active=true
サードパーティのリスクアセスメント	[sn_vdr_risk_asmt_assessment]	条件: applies_to [core_company, sn_vdr_risk_asmt_vendor_engagement] 状態 IN [5, 8, 9] 今すぐrisk_rating_valid_to > risk_rating = highestRiskRating ベンダー = profile.applies_to (注意:この条件は、[sn_vdr_risk_asmt_assessment] テーブルの applies_to フィールドとは異なります。) エンゲージメント = profile.applies_to (注:この条件は、[sn_vdr_risk_asmt_assessment] テーブルの applies_to フィールドとは異なります。)	これらすべてのアセスメントについて、[sn_oper_res_tprm] テーブルにステージングレコードが作成されます。