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

  • リリースバージョン: Zurich
  • 更新日 2025年07月31日
  • 所要時間：16分

    • オペレーショナルレジリエンスワークスペースのランディングページには、組織内のサービス、ビジネスサービス、およびピラーの概要が 1 つのペインに表示されます。ダッシュボードには、運用ステータス、完了したアクティビティ、危険フラグ、改善のための提案など、レジリエンスメトリクスが表示されます。

    オペレーショナルレジリエンス リリース 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 プロファイルで、影響を受けるオブジェクトとしてビジネスサービス、オファリング、およびビジネスプロセスがリストされている場合 ([影響を受けるオブジェクト] 列に表示されます)、これらのオブジェクトは、アプリケーションサービスとその関連エンティティに関連付けられているすべての危険フラグにコピーされます。

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

    このセクションでは、 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) 条件:
    • entity=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) 条件:
    • entity=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 コントロールのリストで
    • active=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
    • active=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
    • active=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] テーブルにステージングレコードが作成されます。

    ピラーを持つエンティティの危険フラグを計算できます。脆弱性一致アイテムの場合、ピラーはテクノロジーである必要があります。その他の危険フラグの場合、エンティティにはタイプに制限のないピラーが必要です。

    オペレーショナルレジリエンス 統合のサンプルクエリ条件

    オペレーショナルレジリエンス アプリケーションは、エンティティを使用して リスク管理、高度なリスク、およびポリシーとコンプライアンス管理と統合します。オペレーショナルレジリエンス はエンティティのapplies_to値を使用して他のテーブルと統合します。これらの統合がどのように機能するかを説明するために、次の表に、さまざまな統合タイプのクエリ条件の例を示し、これらの接続を容易にするエンティティと applies_to の役割を示します。

    表 : 2. サンプル条件
    テーブル 条件 関数 統合アプリケーション
    task_ci
    • task.sys_class_name=incident
    • task.state IN 新規、進行中
    • ci_item = Applies_to
    		 _createIncidentAndChangeRequestsWithImpactedAndAffectedCis インシデント
    task_ci
    • task.sys_class_name=change_request
    • task.active=true
    • ci_item = Applies_to
    		 _createIncidentAndChangeRequestsWithImpactedAndAffectedCis 変更要求
    task_cmdb_ci_service
    • task.sys_class_name=incident
    • cmdb_ci_service= Applies_to
    		 _createIncidentWithCriticalService インシデント
    task_cmdb_ci_service
    • task.sys_class_name=change_request
    • cmdb_ci_service= Applies_to
    		 _createIncidentWithCriticalService 変更要求
    cmdb_outage_ci_mtom
    • ci_item = Applies_to
    • outage.type = デグレードまたは機能停止
    • outage.end が空か、次の値より後
    		 _createOpresOutageWithAffectedCis 機能停止
    sn_grc_case_mgmt_impacted_area
    • Impacted_area=エンティティまたはApplies_to
    • Core_case.sys_class_name = sn_oper_res_vulnerability
    • Core_case.active=true
    		 _createOpresVulProfileForImpactedAreas 運用上の脆弱性
    sn_grc_case_mgmt_related_area
    • Related_area=エンティティまたはApplies_to
    • Core_case.sys_class_name = sn_oper_res_vulnerability
    • Core_case.active=true
    		 _createOpresVulProfileForRelatedAreas 運用上の脆弱性
    sn_grc_m2m_issue_to_entity
    • 問題のアクティブ = true
    • エンティティ = エンティティ
    		 _createServiceWithOpenIssue 問題
    sn_grc_issue
    • 問題のアクティブ = true
    • エンティティ = エンティティ
    		 _createServiceWithOpenIssue 問題
    • Cmdb_ci = Applies_to
    • アクティブ = true
    • Sys_class_name IN プロパティ「sn_oper_res.allowed_task_tables」
    タスク タスク
    Sn_risk_risk
    • プロファイル = エンティティ
    • ステータス = モニター
    • Residual_score=highest_residual_score
    • コンテンツが空でない
    • アクティブ = true

    __serviceWithHighRisk

    		 リスク
    sn_risk_advanced_risk_assessment_instance
    • entity_1= エンティティ
    • ステータス = 完了
    • summary_residual_risk_score=最高評価
    		 _advancedServiceWithHighRisk 高度なリスク
    sn_compliance_m2m_control_entity
    • Control.Status=non_compliant
    • Control.Exempt=false
    • Control.State=monitor
    • Control.active=true
    • プロファイル = エンティティ
    		 _createServiceWithFailedControl ポリシーとコンプライアンス
    sn_compliance_control
    • ステータス = non_compliant
    • 免除 = false
    • ステータス = モニター
    • プロファイル = エンティティ
    		 createServiceWithFailedControl ポリシーとコンプライアンス
    sn_bcp_plan_asset #1
    • アイテム = Applies_to
    • タイプは「次の値を含む」で、「primary_scope」です
    • Plan.expires after
    • Plan.state=approved
    		 _createServiceWithBCMPlan それ以外の場合は、Applies_toを「計画なし」としてマークします 事業継続性管理
    sn_recovery_activated_plan #2
    • アクティブ = false
    • Plan=#1 から 1 つ
    		 それ以外の場合は、Applies_toを「演習なし」としてマークします
    sn_recovery_event_asset #3
    • asset_name= Applies_to
    • event=one from #2
    		 イベント資産のステータスが「未復旧」の場合は、Applies_toを「未復旧」としてマークします。それ以外の場合は、Applies_toを「復旧済み」としてマークします
    sn_vul_vulnerable_item
    • risk_rating=重大または高
    • ステータスが「クローズ済み、解決済み、保留」ではない
    • プロファイルとの結合クエリ
    • Profile.pillar にテクノロジーを含む
    • Profile.active=true
    		 _computeVulnerabilityEntities Vulnerability Response (脆弱性対応)
    sn_oper_res_tprm
    • applies_toIN「ベンダー、エンゲージメント」
    • stateIN'submitted,response
    • 受信、フォローアップ」
    • 後にrisk_rating_valid_to
    • risk_rating = 最高評価
    • ベンダー = Applies_to またはエンゲージメント = Applies_to
    		 _createServiceWithThirdPartyRiskAsmt サードパーティのリスクアセスメント