방문 페이지 및 대시보드 뷰

  • 릴리스 버전: Australia
  • 업데이트 날짜 2026년 03월 12일
  • 소요 시간: 9분

    • 의 운영 복원성 작업 공간 방문 페이지에서는 조직의 서비스, 비즈니스 서비스 및 필라에 대한 단일 창 개요를 제공합니다. 대시보드에는 운영 상태, 완료된 활동, 빨간색 플래그 및 개선 제안을 포함한 복원성 메트릭이 표시됩니다.

    와 함께 운영 복원성도입된 유연한 데이터 모델, 릴리스 21.0.x는 대시보드의 기반을 제공하고 종속 서비스의 플로우를 추적합니다. 실패한 통제, 인시던트 및 중단과 같은 유형별 빨간 플래그와 플래그 수, 중요도 및 영향 허용 범위와 같은 비즈니스 서비스 메트릭을 포함한 데이터는 유연한 데이터 모델을 변경하여 대시보드에서 업데이트됩니다.

    대시보드 데이터입니다.

    이 예시에 표시된 데이터는 빨간 플래그 수별 비즈니스 서비스, 중요도별 비즈니스 서비스, 영향 공차별 비즈니스 서비스와 같은 비즈니스 서비스에 대한 것입니다. 속성을 구성하여 IT 서비스 오퍼링, 비즈니스 프로세스 또는 애플리케이션 서비스를 변경할 수 있습니다 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] 기록에서 영향을 받는 객체 및 영향을 받는 객체 클래스를 상속합니다. 예를 들어 애플리케이션 서비스의 운영 복원성 프로파일에 비즈니스 서비스, 오퍼링, 비즈니스 프로세스가 영향을 받은 객체로 나열되어 있는 경우(영향을 받는 객체 열에 표시됨) 이러한 객체는 애플리케이션 서비스 및 관련 엔터티에 대해 연관된 모든 빨간 플래그에 복사됩니다.

    주:
    릴리스 22.x.x부터 운영 복원성 는 Calculate red flags for CSDM and dependenciesUpdate CSDM and other dependencies 새 설치에 대해 예약된 작업이 기본적으로 비활성화됩니다. 기존 설치의 경우 이러한 작업은 현재 상태(활성 또는 비활성)를 유지합니다.

    적색 플래그 계산 조건

    이 섹션에서는 및 sn_oper_res_profile.applies_to 조건을 참조로 sn_oper_res_profile.profile 사용합니다. 적색 플래그 계산 기준과 관련 테이블은 적색 플래그 계산 테이블에 자세히 설명되어 있습니다.

    표 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=아니오
    • control.state=모니터
    • control.active=참
    		 통제 목록이 추출되며 유효한 빨간 플래그입니다.
    실패한 통제: 2단계 [sn_compliance_control] 조건:
    • entity=profile 또는 통제 목록의 sys_id
    • control.status=non_compliant
    • control.exempt=아니오
    • control.state=모니터
    • control.active=참
    		 이러한 모든 통제에 대해 스테이징 기록은 [sn_oper_res_failed_control] 테이블에 생성됩니다.
    문제: 1단계(선택 사항) [sn_grc_m2m_issue_to_entity] (sn_grc_issue ←→ sn_grc_profile) 조건:
    • 엔터티=프로파일
    • sn_grc_issue.active=참
    		 문제 목록이 추출되며 유효한 위험 신호입니다.
    문제: 2단계(선택 사항)
    다음 필라 중 하나를 사용하는 경우 이 단계가 고려됩니다.
    • 서비스
    • 비즈니스 서비스
    • 제공
    • [sn_oper_res_m2m_scenario_event_issue] (scenario_event ←→ sn_grc_issue)
    • [sn_oper_res_m2m_scenario_event_service] (scenario_event ←→ 서비스)
    		 두 테이블을 사용하여 공동 쿼리가 수행되고 서비스, 비즈니스 서비스 및 오퍼링에 대해 [sn_grc_issue]을(를) 가져옵니다. 이는 1단계의 문제 목록에 추가됩니다.
    문제: 3단계 [sn_grc_issue] 조건:
    • entity=profile 또는 통제 목록의 sys_id
    • 활성=예
    • 또한 문제에는 예외 정책이 없어야 합니다.
    • 예외 정책은 다음 두 가지 조건으로 [sn_compliance_policy_exception] 테이블에서 확인할 수 있습니다.
      • 유효성>현재
      • 상태=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=인시던트
    • [1,2]의 task.state
    인시던트: 3단계 [task_cmdb_ci_service] 조건:
    • cmdb_ci_service=profile.applies_to
    • task.sys_class_name=인시던트
    • [1,2]의 task.state
    변경 요청: 1단계 [change_request] 조건:
    • cmdb_ci=profile.applies_to
    • 활성=예
    		 이러한 모든 변경 요청에 대해 스테이징 기록은 [sn_oper_res_change_request] 테이블에 생성됩니다.
    변경 요청: 2단계(선택 사항) [task_ci] 조건:
    • ci_item=profile.applies_to
    • task.sys_class_name=change_request
    • task.active=참
    변경 요청: 3단계 [task_cmdb_ci_service] 조건:
    • cmdb_ci_service=profile.applies_to
    • task.sys_class_name=change_request
    • [1,2]의 task.state
    중단
    • [cmdb_outage_ci_mtom] (cmdb_ci ←→ cmdb_ci_outage)
    • [cmdb_ci_outage] (cmdb_ci)

    [cmdb_ci_outage]의 각 레코드에 대해 [cmdb_ci_outage_ci_mtom] 테이블에 하나의 레코드가 만들어집니다. [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] 테이블에 생성됩니다.
    작업 [작업] 조건:
    • cmdb_ci=profile.applies_to
    • 활성=예
    • sys_class_name <.allowed_task_tables 속성에서 가져온 클래스 목록 sn_oper_res.allowed_task_tables
    • 기본 시스템의 일부로 문제 기록만 고려합니다.
    		 이러한 모든 작업에 대해 스테이징 기록이 [sn_oper_res_task] 테이블에 생성됩니다.
    운영 취약성: 1단계(선택 사항) [sn_grc_case_mgmt_related_area] 조건:
    • related_area=프로필 또는 related_area=profile.applies_to
    • core_case.sys_class_name=sn_oper_res_vulnerability
    • core_case.active=참
    		 이러한 모든 취약성에 대해 스테이징 기록은 [sn_oper_res_vulnerability_profile] 테이블에 생성됩니다.
    운영 취약성: 2단계(선택 사항) [sn_grc_case_mgmt_impacted_area] 조건:
    • impacted_area=프로필 또는 impacted_area=profile.applies_to
    • core_case.sys_class_name=sn_oper_res_vulnerability
    • core_case.active=참
    외부 공급업체 위험 평가 [sn_vdr_risk_asmt_assessment] 조건:
    • [core_company, sn_vdr_risk_asmt_vendor_engagement]에서 applies_to
    • 상태 IN [5, 8, 9]
    • 지금 risk_rating_valid_to >
    • risk_rating = highestRiskRating
    • 공급업체 = profile.applies_to(참고: 이 조건은 [sn_vdr_risk_asmt_assessment] 테이블의 applies_to 필드와 다릅니다.)
    • engagement = profile.applies_to (참고: 이 조건은 [sn_vdr_risk_asmt_assessment] 테이블의 applies_to 필드와 다릅니다.)
    		 이러한 모든 평가에 대해 스테이징 기록은 [sn_oper_res_tprm] 테이블에 생성됩니다.