개발 팀을 위한 애플리케이션 및 서비스 자산 관리

Before you start, this guide covers:

  • What does application and service asset management for application development teams mean.

  • Why service context, application dependencies, and configuration data matter for engineering teams.

  • How Service Collection supports developer workflows with Assets, a CMDB, Data Manager, and service relationships.

  • A practical walkthrough example from service modeling to incident and change context.

Service Collection products referenced: Jira Service Management, Assets, Customer Service Management, Rovo

Reading time: 9 minutes

더 나은 서비스 컨텍스트를 바탕으로 애플리케이션을 개발하고 운영

최신 디지털 제품은 복잡하게 연결된 애플리케이션, 서비스, 환경, 인프라 및 타사 구성 요소에 의존하기 때문에 애플리케이션 및 서비스 자산 관리는 애플리케이션 개발 팀에게 중요합니다.

애플리케이션, 종속성, 소유권 및 지원 시스템에 대한 정보가 티켓, 클라우드 콘솔, 스프레드시트 및 암묵적 지식에 분산되어 있으면 팀은 변경 영향, 인시던트 위험 및 서비스 상태에 대한 가시성이 떨어집니다.

이렇게 컨텍스트가 부족하면 제공 속도는 낮아지고 장애 또는 잘못된 문제 해결이 발생할 가능성을 높일 수 있습니다.

개발자 애플리케이션과 서비스 자산 관리는 신뢰할 수 있는 공유 모델로 이러한 컨텍스트를 하나로 통합합니다. Service Collection을 사용하면 팀은 애플리케이션 및 서비스 구성 항목을 추적하고 개발 업무에 연결하며 스택 전반의 관계를 파악하고 소유자를 빠르게 식별할 수 있습니다.

이를 통해 애플리케이션 개발 팀은 더 안전하게 변경 사항을 적용하고 인시던트를 더 빠르게 해결하며 조정 오버헤드를 줄이고 더 큰 자신감을 가지고 안정적인 서비스를 구축 및 운영할 수 있습니다.

애플리케이션 및 서비스 자산 관리란 무엇입니까?

애플리케이션 및 서비스 자산 관리는 운영 가시성을 향상하기 위해 애플리케이션과 서비스의 수명 주기, 소유권 및 종속성을 추적하는 활동입니다. 애플리케이션을 관계형 데이터베이스, 웹 서비스, 마이크로서비스 또는 클라우드 환경과 같은 인프라에 연결하여, 팀은 인시던트 위험을 줄이고 배포 속도를 높이는 데 필요한 서비스 컨텍스트를 확보합니다.

밀접하게 관련된 여러 기능을 결합합니다.

  • 서비스 구성 관리: 서비스, 애플리케이션, 데이터베이스, API, 클라우드 리소스 및 이들 간의 관계에 대한 정확한 정보를 유지 관리합니다.

  • 자산 및 구성 추적: 소프트웨어 애플리케이션 제공 및 프로덕션 운영을 지원하는 시스템과 구성 요소를 체계화합니다.

  • 서비스 관리 워크플로: 해당 컨텍스트를 인시던트, 변경 사항, 요청, 승인 및 보고에 적용합니다.

Service Collection에서 자산은 이 데이터의 구조를 제공합니다. 자산은 시간 경과에 따른 모든 구성 레코드와 그 관계를 저장하는 CMDB로, 팀이 단순히 무엇이 존재하는지 이외에도 구성 요소가 어떻게 연결되어 있는지 이해하도록 돕습니다.

그런 다음 Service Collection의 자산 데이터 매니저는 팀이 운영 업무에 활용하기 전에 여러 소스의 레코드를 통합하고 조정하여 데이터 품질을 향상하는 데 도움을 줍니다.

비즈니스 서비스 및 애플리케이션 매핑: 구성 항목, 종속성, 환경 및 소유권에 대한 신뢰할 수 있는 정보를 사용하여 애플리케이션 서비스 및 애플리케이션 관련 운영 워크플로를 관리합니다.

개발자에게 애플리케이션 및 서비스 자산 관리가 중요한 이유

애플리케이션 및 구성 요소 정보가 스프레드시트와 사일로화된 시스템에 분산되어 있으면, 회사에서 어떤 애플리케이션을 실행하고 어떻게 사용하며 특히 변경 사항이 있는 경우 어떤 문제가 발생하는지 명확하게 파악하기 어렵습니다.

Service Collection 자산은 모든 애플리케이션 및 구성 요소 데이터를 한곳으로 모아주는 구조화되고 쿼리 가능한 CMDB를 제공하여, 흩어져 있는 스프레드시트를 실시간으로 연결된 레지스트리로 대체합니다.

  • Atlassian 자산은 애플리케이션 및 서비스 카탈로그를 구조화되고 검색 가능한 단일 CMDB에 중앙 집중화하여, 분산된 스프레드시트와 사일로화된 도구를 동적이며 연결된 레코드로 대체합니다. 앱, 구성 요소 및 인프라 간의 종속성을 매핑하고 Jira Service Management 워크플로에 직접 연결하므로, 팀은 보유한 자산, 소유자 및 변경 사항이 있는 경우 영향을 받는 항목을 항상 파악할 수 있습니다.

  • 변경 영향을 더 빠르게 평가: 팀은 변경 사항을 배포하기 전에 어떤 애플리케이션, 환경 또는 종속된 서비스가 영향을 받을 수 있는지 파악할 수 있습니다.

  • 인시던트 대응 개선: 대응자는 서비스 소유자, 업스트림 및 다운스트림 종속성, 영향을 받을 수 있는 인프라를 빠르게 식별할 수 있습니다.

  • 컨텍스트 전환을 줄이기: 개발자와 운영자는 Jira Service Management 워크플로에서 직접 서비스 및 자산 컨텍스트에 액세스할 수 있습니다.

  • 서비스 소유권 강화: 팀은 소유권, 지원 책임 및 종속성 데이터를 더 쉽게 찾고 유지 관리할 수 있습니다.

  • 애플리케이션 서비스 및 운영 데이터에 대한 높은 신뢰: 자산 데이터 매니저는 클라우드 도구, 검색 도구 및 내부 시스템의 레코드를 더 깔끔한 정보 출처로 조정하도록 지원합니다.

  • 운영 팀과 더 나은 공동 작업을 지원: 공통의 구성 컨텍스트는 변경 및 인시던트 중에 엔지니어링 및 운영 팀이 동일한 이해를 바탕으로 작업하는 데 도움이 됩니다.

신뢰할 수 있는 CMDB: 모든 애플리케이션과 컴포넌트 데이터를 한곳으로 모아주는 구조화되고 쿼리 가능한 CMDB입니다.

Service Collection이 앱 및 서비스 인식 개발을 지원하는 방법

Service Collection은 개발 및 운영 팀이 구성 데이터를 중요한 워크플로로 가져올 수 있도록 지원합니다. 서비스 모델을 일상적인 업무와 분리하는 대신에 팀은 앱, 서비스 및 종속성을 요청, 인시던트 및 변경 사항에 직접 연결할 수 있습니다.

자산으로 서비스 중심의 CMDB를 구축

자산을 통해 팀은 소프트웨어 및 애플리케이션의 제공과 운영에 중요한 구성 요소의 개체 스키마를 정의한 다음 인프라와 관계형 데이터베이스를 매핑할 수 있습니다. 여기에는 비즈니스 서비스, 애플리케이션, 환경, API, 데이터베이스, 큐, 클라우드 리소스, 리포지토리 및 지원 팀이 포함될 수 있습니다.

CMDB 내에서 이러한 구성 항목은 서비스가 실제로 실행하는 방식을 반영하는 관계를 통해 연결될 수 있습니다. 예를 들어, 고객 대상 애플리케이션은 API 게이트웨이, 데이터베이스 클러스터, 클라우드 인프라 및 소유 팀에 종속될 수 있습니다. 팀이 영향을 빠르게 파악해야 하는 경우 그 연결된 모델이 유용합니다.

Best practice: start with one or two critical application services and the dependencies that matter most for incidents and changes. A lean, service-centric CMDB is usually more useful than a large model nobody maintains.

자산 데이터 매니저를 사용하여 데이터 품질을 개선

애플리케이션 및 서비스 데이터는 많은 경우 클라우드 플랫폼, 검색 도구, 스프레드시트, 내부 설명서, 엔지니어링 시스템 등 다양한 곳에서 나옵니다. 이런 출처들이 일치하지 않으면 팀은 모델에 대한 신뢰를 잃게 됩니다.

자산 데이터 매니저는 여러 출처의 데이터를 통합, 정제 및 조정하여 더욱 신뢰할 수 있는 운영 기록으로 만들 수 있도록 지원합니다. 이를 통해 명명 규칙을 정규화하고 중복을 줄이며 인시던트, 감사 또는 승인에 영향을 주기 전에 공백을 식별하기가 더 쉬워집니다.

엔지니어링 및 플랫폼 팀은 이를 통해 서비스 소유권, 환경 레코드 및 종속성 데이터에 대해 더 큰 확신을 얻을 수 있습니다.

데이터 매니저: 여러 애플리케이션 데이터 소스의 데이터를 수집, 변환, 정제, 정규화 및 조정합니다.

인시던트 및 변경 사항의 영향을 파악할 수 있도록 비즈니스 서비스를 애플리케이션 서비스 및 자산과 매핑

Jira Service Management를 사용하면 팀은 티켓 보기에서 직접 요청 또는 변경 사항을 자산 개체와 연결할 수 있습니다. 인시던트를 영향을 받는 애플리케이션 또는 서비스에 연결할 수 있으며, 변경 사항에서는 영향을 미치는 환경 또는 인프라를 참조할 수 있음을 의미합니다.

연결되면 응답자와 승인자가 컨텍스트를 더 잘 파악할 수 있습니다. 어떤 서비스가 관련되어 있으며 소유자는 누구이며 어떤 다른 구성 요소가 영향을 받을 수 있으며 관련 업무가 이미 진행 중에 있는지 확인할 수 있습니다.

관계 컨텍스트를 통해 더 빠른 문제 해결을 지원

서비스 기록은 그 자체로도 도움이 됩니다. 종속성에 연결된 서비스 레코드는 훨씬 더 강력합니다. 관계 데이터는 팀이 '무언가 작동하지 않는다'에서 '이 특정 종속성이 원인일 수 있다'로 더 빠르게 전환할 수 있도록 도와줍니다.

예를 들어, 웹 애플리케이션의 성능이 저하된 경우 팀은 조사 범위를 좁히기 위해 연결된 데이터베이스, 인증 공급자, 큐 및 클라우드 환경을 검토할 수 있습니다. 이 공유 보기는 또한 개발 및 운영 팀에 서비스의 공통 맵을 제공하여 인시던트 스워밍을 지원할 수도 있습니다.

자동화를 사용하여 운영 워크플로를 원활하게 유지

자동화를 통해 팀은 추가적인 수동 업무 없이 서비스 및 구성 컨텍스트에 따라 조치할 수 있습니다. 팀은 상태 또는 연결된 개체의 변경 사항을 기반으로 알림을 트리거하거나 티켓을 라우팅하거나 후속 작업을 만들거나 레코드를 업데이트할 수 있습니다.

일반적인 예시는 다음과 같습니다.

  • 선택한 서비스 또는 소유 팀을 기반으로 인시던트 라우팅

  • 중요 종속성이 변경되는 경우 후속 작업 만들기

  • 인시던트가 우선 순위가 높은 서비스에 영향을 주는 경우 이해 관계자에게 알리기

  • 특정 환경 또는 구성 요소에 표준 운영 검사를 연결

AI 변경 위험 평가: 릴리스 전에 애플리케이션 변경이 미치는 영향을 파악하여 비즈니스 중단을 방지합니다.

설명 예제: 서비스 모델부터 더 빠른 인시던트 분류, 근본 원인 파악 및 해결까지

다음은 Jira Service Management 및 자산과 함께 Service Collection에서 애플리케이션 및 서비스 자산 관리 업무가 어떻게 진행될 수 있는지에 대한 실용적인 예제입니다.

시나리오

플랫폼 엔지니어링 팀은 내부 개발자 포털과 여러 고객 대상 애플리케이션을 지원합니다. 서비스 소유권은 부분적으로 문서화되어 있지만 종속성 정보는 일관성이 없으며 다이어그램, 클라우드 도구 및 팀 참조 자료에 분산되어 있습니다.

인시던트가 발생하면 대응자는 무엇이 변경되었고 어떤 구성 요소가 관련되어 있는지 파악하는 데 너무 많은 시간을 소비합니다.

1단계: 서비스 모델 정의

팀은 비즈니스 서비스, 애플리케이션, 환경, 데이터베이스, API 및 소유 팀을 포함하여 CMDB의 키 구성 항목을 나타내는 자산 스키마를 만듭니다. 가치가 높은 하나의 애플리케이션 서비스로 시작하여 가장 중요한 종속성을 매핑합니다.

다음과 같은 관계를 정의합니다.

  • 애플리케이션이 API 서비스에 종속

  • API 서비스는 데이터베이스 클러스터에 종속

  • 애플리케이션은 프로덕션 환경에서 실행

  • 플랫폼 팀은 런타임 인프라를 소유

2단계: 데이터 매니저로 소스 데이터 통합

팀은 클라우드 인벤토리, 내부 스프레드시트 및 기존 서비스 설명서의 레코드를 통합하기 위해 데이터 매니저를 사용합니다. 작업 모델에 게시하기 전에 중복된 애플리케이션 이름을 조정하고 누락된 소유자에 플래그를 지정하며 오래된 레코드를 정리합니다.

Outcome: the team now has a cleaner, more trustworthy service model rather than relying on competing versions of the truth.

3단계: 모델을 Jira Service Management 워크플로에 연결

엔지니어와 운영자가 영향을 받는 서비스 또는 구성 항목을 선택할 수 있도록 팀은 인시던트 및 변경 워크플로에 자산 필드를 추가합니다. 새로운 인시던트가 만들어지면 대응자는 즉시 연결된 애플리케이션, 소유자, 환경 및 관련 종속성을 즉시 확인할 수 있습니다.

기본적인 분류 질문에 소요되는 시간을 줄이고 팀이 적절한 담당자를 더 일찍 참여시킬 수 있도록 돕습니다.

4단계: 인시던트 중에 모델을 사용

고객 대상 애플리케이션의 오류 증가로 인해 인시던트가 보고되었습니다. 대응자는 Jira Service Management에서 영향을 받는 서비스를 연결하고 관련 구성 항목을 검토합니다. 애플리케이션이 공통의 인증 API와 데이터베이스 클러스터에 종속된다는 것을 확인합니다.

최근 변경 사항이 이미 인증 API와 연결되어 있습니다. 그 단서는 팀이 신속하게 조사 범위를 좁히고 추측 없이 적절한 담당자를 참여시키는 데 도움이 됩니다.

5단계: 향후 변경 계획 개선

인시던트 이후, 팀은 변경 검토 중에 동일한 서비스 관계를 사용하기 시작합니다. 업데이트를 배포하기 전에 영향을 받을 수 있는 종속된 서비스를 확인하고 미리 적절한 팀과 조율할 수 있습니다.

실제 적용 모습

스테이지

팀이 하는 일

운영 가치

서비스를 모델링

자산에서 서비스, 앱, 환경 및 종속성 개체 만들기

엔지니어링 및 운영에서 사용할 수 있는 CMDB를 구축

데이터 품질 개선

데이터 매니저를 사용하여 여러 시스템의 데이터를 조정

소유권 및 종속성 데이터에 대한 더 높은 신뢰를 구축

워크플로에 연결

서비스 및 구성 항목을 인시던트 및 변경 사항에 연결

팀이 이미 작업하는 도구에서 컨텍스트를 제공

더 빠르게 분류

인시던트 중에 종속성 관계를 사용

조사 및 에스컬레이션 시간을 단축

변경 사항을 더 효과적으로 계획

구현하기 전에 영향을 받는 서비스 및 구성 요소를 검토

위험 인식 및 조율을 향상

구현 접근 방법

엔지니어링 또는 애플리케이션 개발 팀을 위해 이 기능을 구축하는 경우, 단계적 롤아웃이 일반적으로 가장 효과적입니다.

  1. 인시던트 또는 변경 사항에 자주 등장하는 하나의 중요 애플리케이션 또는 서비스에서 시작하세요.

  2. 최소한의 유용한 구성 항목 및 관계 세트를 정의하세요.

  3. 광범위하게 확장하기 전에 데이터 매니저를 사용하여 소스 데이터의 품질을 개선하세요.

  4. 즉각적인 운영 가치를 창출하는 인시던트 및 변경 워크플로에 먼저 자산 컨텍스트를 추가하세요.

  5. 팀이 모델이 유용하고 유지 관리 가능하다는 것을 입증함에 따라 CMDB를 점진적으로 확장하세요.

Good first milestone: make it easy for a responder or approver to answer what service is affected, what supports it, who owns it, and what else may be impacted.


고객 스포트라이트: Lucid Motors

[자산은] 우리의 Jira 인프라에서 절대적으로 중요한 부분이며, 동일한 도구에서 하드웨어를 추적하지 않고 Jira로 하드웨어 엔지니어링을 어떻게 수행할 수 있을지 솔직히 모르겠습니다. 파편화된 하드웨어 추적 도구로 시도했을 때... 우리 시스템에 내재된 추적성이 없었기 때문입니다. 그리고 다른 도구에서 모든 것을 수행하려고 시도한다면, 그 방식에도 민첩성은 없습니다. 그래서 우리에게 정말 잘 맞는 것을 찾았습니다.

Felipe Luisi, 선임 제품 관리자, Lucid Motors


FAQ

애플리케이션 및 서비스 자산 관리란 무엇입니까?

애플리케이션 및 서비스 자산 관리는 연결된 모델에서 애플리케이션, 서비스, 종속성, 환경, 구성 항목 및 소유권을 추적하는 방식입니다. 개발 및 운영 팀에 인시던트, 변경 사항, 요청 및 서비스 계획에 대한 신뢰할 수 있는 컨텍스트를 제공합니다.

자산은 애플리케이션 개발 팀을 어떻게 지원합니까?

자산은 애플리케이션, API, 데이터베이스, 환경, 클라우드 리소스 및 이들을 소유한 팀을 모델링하기 위한 구조화된 CMDB를 제공합니다. 팀은 이 컨텍스트를 Jira Service Management 인시던트 및 변경 사항에 연결하여 영향을 평가하고 업무를 라우팅하며 더 빠르게 문제를 해결할 수 있습니다.

CMDB와 자산 인벤토리의 차이점은 무엇입니까?

자산 인벤토리는 존재하는 항목을 기록하는 반면, CMDB는 구성 항목이 서로 어떻게 연관되어 있고 서비스를 어떻게 지원하는지도 기록합니다. 자산은 애플리케이션 및 서비스 레코드를 종속성, 소유권 및 운영 컨텍스트와 함께 저장하여 두 가지 역할을 모두 수행할 수 있습니다.

팀은 애플리케이션 및 서비스 데이터의 품질을 어떻게 개선할 수 있습니까?

작업 모델에 게시하기 전에 자산 데이터 매니저를 사용하여 여러 소스의 레코드를 통합, 정제, 정규화 및 조정하세요. 중요 인시던트 및 변경 사항에 필요한 데이터로 시작한 다음, 서비스 모델이 유용하고 유지 관리 가능한 것으로 확인되면 확장하세요.

Discover all Service Collection has to offer