자산 온보딩 가이드

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

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

문제 정의하기

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

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

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

서비스를 시작

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

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

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

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

예: 비즈니스 서비스 분류

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

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

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

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

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

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

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

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

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

Asset Discovery

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

가져오기 도구

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

CSV 가져오기

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

JSON 가져오기

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

유용한 정보와 팁

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

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

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

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

데이터를 하나의 큰 스키마로 만드는 것보다 다른 개체 스키마로 나누는 것이 더 사용자 친화적이며 유지 관리가 쉽습니다. 재무, 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 워크플로에 자산을 빌드할 때는 이슈의 어떤 정보를 자산으로 다시 전달해야 할지 고려하세요. 이상적으로는 자산을 수동으로 업데이트하는 것과 같이 잊어버리기 쉬운 작업을 최소화해야 할 것입니다.