Close

자산 온보딩 가이드

개요

이 가이드는 Jira Service Management Cloud Premium 또는 Enterprise 에디션에서 자산을 시작하는 모든 사용자를 위한 가이드입니다. 자산을 통해 팀은 자산, 구성 항목 및 리소스를 추적하여 애플리케이션, 서비스, 기본 인프라 및 기타 주요 자산 간 핵심 관계를 파악할 수 있습니다. 자산은 Jira를 기반으로 구축되어 자산 및 구성 항목에 대한 서비스 요청, 인시던트, 문제, 변경 및 기타 이슈에 연결하는 간단하고 빠른 방법을 팀에 제공하여 가치 있는 컨텍스트를 얻을 수 있습니다.


1단계 - 자산에 액세스

Jira Service Management Premium 또는 Enterprise 라이선스가 있는 버전 또는 평가판을 사용하는 경우 모두 상단 메뉴에서 자산을 선택하여 액세스할 수 있습니다.

Jira Service Management Premium 또는 Enterprise의 상단 메뉴를 통해 자산에 액세스합니다

2단계 - 자산 구조화 방법 이해

이 섹션에서는 자산 데이터베이스 구성 방법에 대한 개요를 제시합니다.

개체가 가운데에 있고 그 위 수준에 개체 유형, 맨 위 수준에 개체 스키마가 있는 다이어그램

개체

개체는 노트북, 서버, 장비, 계약서 또는 차량과 같이 하나의 고유한 모든 것입니다. 개체는 실제 자산 또는 구성 항목(CI)입니다.

개체를 Jira 이슈에 연결할 수 있으므로 이슈가 발생하는 즉시 이슈는 더 많은 컨텍스트를 갖게 됩니다. 또한 개체가 서로 어떻게 종속하는지 보여주기 위해 개체 참조를 사용하여 서로 연결할 수 있습니다.

개체 유형

비슷한 개체는 개체 유형으로 그룹화됩니다. 개체 유형은 실제 개체의 컨테이너 역할을 합니다. 개체 유형은 스키마 내에서 사용되여 스키마에 포함된 개체를 정의합니다. 개체를 직접 정의하거나 사용자 지정할 수 있는 특정 개체 유형으로 미리 채워지는 개체 스키마 템플릿을 사용할 수 있습니다. 일반적인 개체 유형에는 다음이 포함됩니다.

  • 비즈니스 서비스
  • 서버
  • 노트북
  • 소프트웨어

하지만 반드시 IT 자산일 필요는 없습니다. 예를 들어, 많은 사용자가 다음과 같은 유용한 정보를 추가합니다.

  • 판매자
  • 위치
  • 직원
  • 비즈니스 우선 순위

계층 구조 트리에서 적절한 방식으로 개체 유형을 구성할 수 있습니다. 이 트리는 주로 탐색 및 가독성을 위한 것이며 그런 목적으로 빈 개체 유형이 있을 수 있지만, 개체 유형 만들기를 용이하게 하기 위해 특성의 상속을 제공하도록 설정할 수 있습니다.

계층 구조 트리에서 개체 유형 구성

개체 스키마

개체 스키마는 개체 유형과 개체를 포함하는 실제 구성 관리 데이터베이스(CMDB)입니다. 여러 목적으로 유용한 다양한 개체 스키마를 자산에서 만들 수 있습니다.

  • 데이터를 작은 뭉치로 나누는 것은 데이터를 감사하고 정확하게 유지하는 데 유용합니다.
  • 직원 정보와 같은 중요한 정보가 포함된 경우, 제한된 액세스 권한을 가진 하나의 개체 스키마에 모든 데이터를 함께 보관하는 것이 더 간편할 수 있습니다.

데이터를 자산에 넣는 방법을 결정할 때 데이터의 용도와 업데이트 주체를 고려하여 데이터를 논리적 개체 스키마로 그룹화해야 합니다. 하나의 사용 사례에 여러 개체 스키마를 쉽게 사용할 수 있으며, 서로 다른 개체 스키마의 개체 사이에 링크를 만들 수 있습니다.

템플릿은 IT 자산 관리, 직원 및 시설과 같은 핵심 사용 사례에도 사용할 수 있습니다. 이러한 템플릿에는 필요에 따라 사용할 수 있는 다양한 관련 개체 유형이 포함되어 있어 효과적인 데이터베이스를 구축하고 개체를 가져오기 위한 초기 구조를 제공할 때 빠르게 시작할 수 있습니다. 여기에서 템플릿에 대해 자세히 알아보세요.

자산은 Jira Service Management 내의 서비스 기능과 자동으로 동기화되며, 서비스 레지스트리 내에 문서화된 각 서비스에 대해 입력한 개체를 사용하여 자산 데이터베이스 내에 읽기 전용 개체 스키마를 만듭니다. 즉, Jira Service Management 서비스를 다양한 자산 및 CI에 연결하여 변경 사항, 인시던트 및 문제를 지원하는 서비스 맵을 구축할 수 있습니다.

개체 특성

특성은 개체에 연결된 특정한 정보(예: 해당 개체에 대한 설명, 모델 번호, 연결된 다른 개체 또는 개체의 소유자로 지정된 사용자)를 나타냅니다.

각 개체 유형에는 고유한 특성 집합이 있습니다. 예를 들어 "노트북" 개체 유형은 모델, 일련 번호, 사용자, 보증 만료 날짜 등의 특성을 포함할 수 있습니다.

특성에 대한 실제 값을 입력하면 개체가 정의됩니다. 이 작업은 수동 또는 자동으로 수행할 수 있습니다(4단계 참조).

모든 개체 유형에는 다음과 같은 네 가지 필수 특성이 있습니다.

  1. 이름
  2. 만든 날짜
  3. 최근 업데이트 날짜

마지막 세 개는 자동으로 설정됩니다. 다른 모든 특성은 관리자가 정의할 수 있습니다. 또한 고유 키 특성이 있기 때문에 각 개체에 대해 고유한 이름을 부여하지 않아도 됩니다.

개체 레퍼런스

참조는 자산에서 서로 다른 두 개체를 연결합니다. 각 개체는 직접적으로 연결하지 않고 다른 개체에 대한 참조를 포함하는 특성을 통해 다른 여러 개체에 연결될 수 있습니다.

예를 들어, 위치가 자체 개체 유형인 경우 각 위치 개체는 귀하의 지사들 중 하나일 수 있습니다. 예를 들어, '스톡홀름'을 선택하여 모든 노트북의 위치를 신속하게 설정할 수 있습니다.

Jira Service Management 개체 참조의 스크린샷 예시

개체 참조는 수동으로 설정할 필요가 없습니다. 네트워크 스캐너, 가져오기 도구, 자동화 규칙 등에서 자동으로 추가할 수 있습니다.

개체 간 레퍼런스에는 두 가지 주요 이점이 있습니다.

  1. 개체 간 종속성을 매핑할 수 있습니다. 예를 들어, ITSM 애플리케이션을 종속하고 있는 비즈니스 서비스 및 다른 호스트, 운영 체제 및 파일에 매핑할 수 있습니다. 이 맵은 변경의 다운스트림 효과(OS를 변경할 경우 어떤 영향이 있는지)를 이해하는 데 매우 유용하며, 인시던트와 문제의 원인을 찾을 수도 있습니다. 또한 각 개체는 Jira 이슈에 연결될 수 있기 때문에 시간이 지나면서 인프라 또는 기타 비즈니스 자산에 대한 종합적인 기록을 만들어서 이슈 및 문제 해결에 더 도움이 됩니다.
  2. 관리하기 용이합니다. 사무실을 몬트리올에서 토론토로 옮기는 경우, 모든 노트북에서 몬트리올을 토론토로 변경하는 것이 아니라 몬트리올이라는 개체만 업데이트하면 됩니다.

개체 레퍼런스에는 다음 두 가지 유형이 있습니다.

  1. 아웃바운드 참조는 현재 개체에서 다른 개체로의 참조입니다.
  2. 인바운드 참조는 다른 개체에서 현재 개체를 가리킵니다.

개체 간 참조는 그래픽 뷰어를 사용하여 볼 수 있습니다. 가지고 있는 참조 유형(예: 설치 위치, 소유자, 판매자)을 결정하고 개체 스키마 설정에서 색상 코드를 지정할 수 있습니다.

개체 그래프에서 개체 간 참조 보기

자산 권한

자산에는 두 가지 유형의 권한이 있습니다.

  • 개체 스키마 권한 - 개체 스키마 설정에서 특정 개체 스키마에 대한 관리 권한이 있는 사용자, 개체 스키마 데이터를 업데이트할 수 있는 사용자 또는 데이터를 볼 수만 있는 사용자를 정의할 수 있습니다.
  • 개체 유형 권한 - 때로는 Jira Service Management 고객에게 전체 개체 스키마의 모든 데이터를 볼 수 있는 액세스 권한을 부여하지 않고 특정 정보만 볼 수 있도록 하려는 경우도 있습니다. 개체 유형 권한은 여기서 사용할 수 있습니다.

3단계 - 포함할 데이터 선택

회사마다 다른 정보를 추적해야 하므로 자산의 모든 인스턴스는 고유합니다. 자산은 귀하와 귀하의 비즈니스가 알아두면 유용한 모든 정보를 저장할 수 있습니다. 포함해야 할 특정 자산 및 구성 항목은 수행하려는 작업에 따라 다릅니다. 이 섹션에는 어떤 데이터를 포함할지 결정하는 방법에 대한 조언이 포함되어 있습니다.

문제 정의하기

대부분의 도구는 문제를 해결하기 위해 구현하며 자산 역시 그렇습니다. 인시던트 해결 시간이 충분히 빠르지 않거나 특정 서비스를 변경하면 서비스 종속성을 쉽게 확인할 수 없기 때문에 예기치 않은 결과가 발생할 수 있습니다.

문제를 찾아 이를 통해 해당 사용자로부터 데이터베이스에 포함시킬 자산과 정보에 이르기까지 그 밖의 모든 것을 정의합니다. 문제를 살펴보고 문제를 극복하기 위해 어떤 추가 정보가 필요한지 이해하세요. 이 정보가 개체 유형을 정의합니다.

한 번에 너무 많은 정보를 추가하면 정확성을 확인하기 어려울 수 있으므로 한 번에 한 가지 문제에 집중하세요. 첫 번째 문제를 해결했으면 자산이 확장하여 다른 문제를 해결할 수 있습니다.

서비스를 시작

구성 관리에 자산을 사용하려는 경우 서비스부터 시작하여 하향식 접근 방식을 사용하는 것이 좋습니다. 그런 다음 해당 서비스가 종속되는 서비스(예: 애플리케이션 및 호스트)를 매핑합니다. 또 다시 이 종속성이 종속하는 서비스를 매핑합니다. 이렇게 하면 인시던트 및 변경 요청이 들어올 때 사용할 수 있는 서비스 맵을 빠르게 구축할 수 있습니다. 필요에 따라 다른 영역을 문서화하도록 확장할 수 있습니다.

물리적 항목 이상을 생각하기

자산을 사용하면 필요한 개체를 정의할 수 있어 기존 자산이나 물리적 자산에 국한되지 않습니다. 예를 들어, 비즈니스 서비스는 물리적 자산이 아니지만 사용자가 자세히 이해하는 데 중요한 경우가 많습니다. 서비스의 모든 물리적 및 추상적 종속성을 해당 서비스에 연결할 수 있으므로 비즈니스 서비스 개체를 살펴보면 서비스가 어떻게 실행되는지 완전히 이해할 수 있습니다.

얼마든지 추상적으로 사용해도 됩니다. 일반적인 예에는 비즈니스적 중요성 개체, 환경 유형, 부서/팀, 위치 등이 포함될 수 있습니다.

예: 비즈니스 서비스 분류

모든 비즈니스 서비스가 자산에 "비즈니스 서비스" 개체 유형 아래에 추가되었다고 가정해보겠습니다. 비즈니스 서비스를 "재무", "물류", "영업", "인프라" 등으로 분류할 수 있습니다. 비즈니스 서비스 개체 유형의 특성을 사용하여 이 작업을 수행하거나 이 범주를 "서비스 범주"라는 고유한 개체 유형으로 만들 수 있습니다.

개체 유형 분류의 "비즈니스 서비스" 예시

비즈니스 서비스 범주에 특정한 세부 정보(특성)를 추가할 수 있다는 이점이 있습니다. 모든 재무 비즈니스 서비스에 대한 책임이 있는 사용자가 있을 수도 있습니다. 유지 관리가 어려워지기 때문에 이 사용자를 모든 재무 "비즈니스 서비스" 개체에 직접 추가하기를 원하지는 않을 것입니다. 대신 "서비스 범주" 개체 유형의 "재무" 개체에 한 번만 추가하여 한 곳에서 업데이트하면 데이터를 중복할 필요가 없습니다.

또한 개별 재무 비즈니스 서비스의 운영 상태를 가져와 재무 범주의 전체 상태로 롤업하는 규칙을 만들 수 있습니다. 이렇게 하면 범주 개체를 확인하여 각 서비스 범주에 대해 서비스 문제가 있는지 빠르게 확인할 수 있습니다.

이러한 유형의 개체를 자산에 추가할 필요 는 없지만 기존 자산/구성 항목에 의해 제한되지 않는다는 점이 중요합니다. 이는 사용자가 무엇을 하고 싶은지에 달려있습니다. 따라서 목표와 목표를 달성하는 데 필요한 정보를 이해하는 것이 핵심이라 할 수 있습니다.

앞을 보고 끊임없이 성장하십시오.

향후에 포함할수도 있는 확장을 염두에 두세요. 포함하려는 데이터뿐 아니라 데이터를 구성하는 방법까지에도 영향을 줄 것입니다.

원하는 최종 상태를 염두에 두고 자산을 점진적으로 구축하는 것이 좋습니다. 1,000개의 개체에 대해 100% 정확한 데이터로 대형 릴리스를 시도하는 것은 매우 어렵습니다. 작게 만들고 새 특성, 개체 및 개체 스키마를 추가하는 것이 훨씬 간단할 수 있습니다.

문제를 찾고 자산을 빌드하여 문제를 해결한 다음 문제로 넘어가는 것이 좋습니다.

정확성에 대한 현실적 기대치 설정

항상 100% 정확도를 목표로 해야 하지만 실제로는 가능하지 않을 수 있습니다. 데이터가 처음부터 없는 것보다 더 많은 비즈니스 가치를 제공할 정도로 정확하다면 성공적인 것입니다. 많은 CMDB 프로젝트가 진행하기도 전에 "완벽"을 추구하여 지연되거나 심지어 실패할 수 있습니다.


4단계 - 데이터를 자산으로 가져오기

수동으로 모든 것을 입력하면 대규모 조직에서의 업무가 번거로울 수 있습니다. 거기에 도움이 될 몇 가지 도구가 있습니다.

Asset Discovery

Asset Discovery(Atlassian Marketplace에서 무료로 사용 가능)는 네트워크 자산을 검색하는 에이전트 없는 스캐너입니다. 개체 스키마로 끌어올 자산과 특성을 선택할 수 있을 뿐 아니라 고유한 검사 패턴을 만들어 더 많은 틈새 자산을 찾을 수 있습니다. 일정에 따라 실행하는 경우 변경 사항을 선택하고 데이터를 업데이트한 상태로 유지하면 됩니다. 자동화 규칙을 사용하여 감지된 변경 사항에 따라 Jira 이슈, 이메일 알림 등을 트리거할 수도 있습니다.

가져오기 도구

다른 소스로부터 데이터를 가져올 때 가져오기를 사용할 수 있습니다. 이러한 가져오기 규칙은 일정에 따라 동기화가 가능하므로 필요한 경우 데이터를 업데이트할 수 있습니다. 각 가져오기 유형에 대해 데이터가 저장되는 위치와 자산에서 이동해야 하는 위치를 정의합니다.

CSV 가져오기

모든 자산이 포함된 Excel, Sheets와 같은 스프레드시트를 사용하는 경우 CSV 가져오기 기능을 사용하여 데이터를 자산으로 가져올 수 있습니다. 이를 통해 자산을 이슈에 링크하여 영향을 분석하는 통합적이고 투명한 시스템을 확보할 수 있습니다.

JSON 가져오기

데이터가 들어있는 JSON 파일을 사용하여 개체를 자산으로 가져올 수 있습니다.

유용한 정보와 팁

사용량이 낮을 때 가능하면 Asset Discovery와 가져오기 도구를 자주 실행하는 것이 좋습니다. 예상되는 데이터 변경 빈도와 데이터의 중요성을 확인하여 예약된 실행 빈도를 결정합니다. 데이터가 변하는 속도보다 좀 더 빨리 알아야 합니다.

Asset Discovery를 사용하면 자산을 최대한 최신 상태로 유지하는 데 필요한 리소스를 절약하기 위해 서로 다른 검색 패턴을 다양한 빈도로 실행할 수 있습니다.


5단계 - 데이터 구조화 방법의 결정

데이터를 논리적 개체 스키마로 분할하기

데이터 사용 또는 데이터 소유자에 따라 여러 개체 스키마를 사용하는 것이 좋습니다.

데이터를 하나의 큰 스키마로 만드는 것보다 다른 개체 스키마로 나누는 것이 더 사용자 친화적이며 유지 관리가 쉽습니다. 재무, HR 부서와 같은 팀은 자산의 일부 정보가 필요할 수 있지만 불필요한 정보까지 함께 받을 필요는 없습니다. 하나의 큰 개체 스키마의 특정 부분만 확인하도록 요청하는 것보다 한 팀에 하나의 개체 스키마에서 데이터 품질을 정기적으로 확인하도록 요청하는 것이 더 용이합니다.

데이터 통합

완벽하게 사용할 수 있는 데이터베이스 또는 정보 소스가 어딘가에 있고 업데이트 상태를 유지하는 프로세스가 이미 있는 경우 데이터를 자산으로 옮길 필요가 없습니다. 대신 통합을 사용하여 관련 데이터의 복사본을 만들고 자산 정보를 업데이트하기 위해 일정에 따라 해당 통합을 실행하는 편이 좋습니다.

자산은 다양한 가져오기 도구를 함께 제공합니다(이전 섹션 참조). 가져오기 도구를 사용하면 결정을 내리는 데 필요한 정보를 Jira 이슈/자산 자체에서 사용할 수 있지만, 두 개의 복사본을 별도로 관리하지는 않습니다.

가져온 데이터에 대해 별도의 개체 스키마를 만들거나 다른 경우에는 보다 큰 개체 스키마에 통합합니다. 데이터를 다양한 용도(예: IT 지원, HR 등)로 사용하는 경우, IT 개체 스키마와 직접 연결하지 않고 별도의 개체 스키마로 유지하고 HR 팀에 이 스키마에도 액세스할 수 있게 하는 것이 좋습니다.

가져오기 도구를 사용할 수 없는 경우, 개체를 만들고 추가 정보를 찾을 수 있는 다른 데이터베이스에 연결하는 URL 특성을 부여할 수도 있습니다. 이 옵션은 에이전트가 정보를 직접 볼 수 있지만 이를 기반으로 검색 또는 보고하는 것을 원하지 않는 경우 적합합니다.

동일한 특성을 모든 곳에서 재사용하지 마십시오.

특성이 여러 곳에서 사용되고 같은 값이 반복된다면 자체 개체 유형으로 만드는 것이 더 좋은 경우가 많습니다. 예를 들어 노트북, 전화기, 프린터, 모니터 등의 개체 유형에 대해 공급업체라는 특성이 있을 수 있습니다. 또한 각 개체에 대해 특정 노트북 또는 전화기의 공급업체 이름을 입력하거나 가져와야 합니다.

이 것도 괜찮은 방법이지만 여러모로 '판매자' 개체 유형을 가지고 각 판매자를 개체로 설정하는 것이 보다 효율적입니다.

  • 공급업체 이름 외의 정보를 원할 수 있습니다. 지원 연락처 또는 계약 링크와 같이 공급업체와 관련된 다른 정보를 원할 수 있습니다. 모든 노트북과 휴대폰에 해당 작업을 반복하고 싶지 않을 수 있습니다. 이 경우 한 번만 실행한 후 공급업체 개체에 연결하세요. Jira Service Management 내에서 공급업체 관리 요소를 수행하려는 경우에도 도움이 됩니다.
  • 이 방법으로 공급자를 표준화하여 보고서를 더 쉽게 실행할 수 있습니다. 공급자별 지원 요청 수를 보고하려는 경우, 어딘가에 Microsoft 또는 Apple이라고 쓰여 있기 때문에 누락되지 않은 것을 확신할 수 있습니다.
  • 판매자가 어떤 식으로든 다시 브랜딩하거나 변경해야 하는 경우 한 곳에서 업데이트하면 됩니다.

공급업체는 하나의 예시일 뿐이며, 다른 특성에는 비즈니스 중요도 수준, 배포 환경, 부서 및 위치 등이 포함됩니다.


6단계 - Jira 이슈에 대한 자산 사용자 지정 필드 구성

이 섹션에서는 Jira 이슈를 개체에 연결하도록 구성하는 방법을 설명합니다. 영향을 받는 비즈니스 서비스를 인시던트 이슈에 추가하거나, 컴퓨터를 하드웨어 요청 이슈에 추가하거나, 잠재적으로 영향을 받을 수 있는 호스트 집합을 변경 요청 이슈에 추가하는 것 등이 될 수 있습니다.

자산을 사용하여 새로운 특정 사용자 지정 필드에 액세스할 수 있습니다. 사용자 지정 필드는 특정 개체 집합을 가리키도록 구성해야 합니다.


7단계 - 자동화 설정

자산에 다양한 작업을 자동화하는 데 사용할 수 있는 새로운 여러 개체 관련 자동화 트리거 및 작업을 도입했습니다.

예는 다음을 포함합니다.

  • 서비스 요청 워크플로 중에 노트북의 소유자 또는 상태 업데이트
  • 인시던트 이슈가 발생할 때 인프라의 일부 상태를 "인시던트 진행 중"으로 업데이트
  • 연결된 개체를 기반으로 특정 직원에게 Jira 이슈를 자동으로 라우팅
  • 라이선스, 계약 또는 보증이 만료될 예정인 경우 주요 담당자에게 알림

8단계 - 데이터를 정확하게 유지하는 방법 결정

데이터를 최신 상태로 유지하는 것은 아주 중요합니다. 그렇지 않으면, 팀이 잘못된 가정 하에 작업하게 되어 인시던트 해결이 지연되거나 서비스 요청 후 잘못된 결과가 발생할 수 있습니다.

자산에서는 데이터를 최신 상태로 유지하는 다양한 방법이 있으며 많은 경우 자동화에 의존하여 대부분의 작업을 수행합니다.

  1. 데이터에 대한 정기 감사 수행하기
    일정에 따라 데이터 감사를 수행하도록 알리기 위해 자산 자동화 규칙을 설정할 수 있습니다. 이를 통해 신속한 온전성 검사를 수행하여 핵심 자산이 최신 상태인지 확인할 수 있습니다.
  2. 정기적으로 Asset Discovery, 관련 가져오기 도구 및 통합 동기화
    데이터를 최신 상태로 유지하지 못하는 큰 원인은 자산을 외부 데이터 소스와 자주 동기화하지 않기 때문입니다. 외부 소스의 데이터를 변경하는 빈도와 알맞은 균형을 확보하기 위해 Jira Service Management에서 사용하는 빈도를 생각해 보세요. 변경이 잦고 정기적으로 이슈와 연결되어 있으면 24시간 주기의 동기화가 필요할 수 있습니다. 다른 통합은 몇 주 또는 몇 달 후에 해도 무방합니다.
  3. 자동화 규칙 사용
    자산/구성 데이터를 변경하는 Jira 이슈에서 결정이 내려지면 자산에서 이것을 캡처하는 것이 중요합니다.

예를 들어, 노트북이 손상되어 에이전트가 사용자에게 새 노트북을 제공하기로 결정한 경우 자산에서 캡처해야 하는 정보가 있습니다.

  • 새 노트북은 소유자를 요청자로 업데이트하고, 상태를 "서비스 중"으로 업데이트해야 합니다.
  • 이전 노트북에서 소유자를 제거하고 상태를 "고장"으로 업데이트해야 합니다.

에이전트가 요청자에게 이를 전달하면 전환 화면과 자산 전환 후 작동을 사용하여 이 유형의 정보를 캡처하고 자동화를 통해 자산에서 새로운 상태 및 소유자를 설정할 수 있습니다.

위의 사례는 한 가지 예로, 실제 Jira 워크플로에 자산을 빌드할 때는 이슈의 어떤 정보를 자산으로 다시 전달해야 할지 고려하세요. 이상적으로는 자산을 수동으로 업데이트하는 것과 같이 잊어버리기 쉬운 작업을 최소화해야 할 것입니다.


9단계 - 개선을 보여 주는 메트릭 추적

자산을 설정한 후에는 즉시 사용할 수 있는 보고서를 사용하여 가치 증명을 시작할 수 있습니다. 이렇게 하면 자산 및 구성 데이터를 비판적으로 분석하고 더 효과적인 의사 결정을 내리고 간편하게 보고할 수 있습니다. 자산에서 무엇을 추적하는지에 따라 이 보고서를 인벤토리 관리, 수명 주기 관리, 직원 생산성 측정 등에 사용할 수 있습니다. 보고서는 개체 유형, 특성별 개체 또는 시간 경과에 따른 개체를 보여 줍니다. 예를 들어 현재 사용 중인 직원 노트북 수, 유지 관리가 필요한 노트북 수, 노트북 소유자 및 비용에 대한 데이터를 확인할 수 있습니다.


10단계 - Confluence Cloud에서 자산 데이터 표시하기

에이전트는 Confluence 자산 매크로를 사용해 Confluence에서 바로 자산의 개체에 관한 스마트 목록을 만들 수 있습니다. 중요한 자산의 상태에 관한 보고서 작업을 하는 공간으로 자산 데이터를 가져와 관련 팀원들과 함께 확인하며 팀 전체의 가시성을 향상하세요.

이 목록은 개체 스키마에서 데이터를 끌어오며, 특정한 특성이나 데이터에 맞게 사용자 지정하는 것도 가능합니다.

이 기능은 다음 3단계에 따라 시작할 수 있습니다.

  1. 키보드에서 슬래시 키(/)를 누릅니다.
  2. 입력한 후 드롭다운에서 '자산'을 선택합니다.
  3. 원하는 자산 개체를 선택해 표시합니다.

이 기능을 사용하면 Jira Service Management 액세스 권한과 관계없이 모든 Confluence 라이선스 사용자가 자산 목록을 볼 수 있습니다. Jira 관리자가 자산에서 '개체 조회자' 역할을 할당하면 자산 목록 조회가 가능합니다. Confluence에서 이러한 목록을 구성하고 관련 권한을 추가하려면 Jira 관리자이거나 Jira Service Management의 자산에서 관련 개체 스키마를 볼 수 있는 권한이 있어야 합니다.


기타 주제

자산 쿼리 언어- AQL

자산 쿼리 언어(AQL)는 자산 쿼리에 사용되는 언어를 말합니다. AQL은 검색 보기, 자동화 규칙, 자산 간의 고급 참조를 만들거나 가져오기를 지시하는 경우에 유용합니다.


기타 주제

자산 쿼리 언어- AQL

자산 쿼리 언어(AQL)는 자산 쿼리에 사용되는 언어를 말합니다. AQL은 검색 보기, 자동화 규칙, 자산 간의 고급 참조를 만들거나 가져오기를 지시하는 경우에 유용합니다.


유용한 정보와 팁

양식 디자인