面向开发团队的应用与服务资产管理
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，团队可跟踪应用与服务配置项，将其与开发工作联系起来，了解整个技术栈中的各种关系，并快速识别负责人。
这有助于应用开发团队执行更安全的更改、更快地解决事件、减少协调开销，并更有信心地构建和运营可靠的服务。
什么是应用与服务资产管理？
应用与服务资产管理是指跟踪应用与服务的生命周期、权责归属和依赖关系，以提高运营可见性的实践。通过将应用连接到关系型数据库、Web 服务、微服务或云环境等基础设施，团队可获得所需的服务上下文，从而降低事件风险并加快部署速度。
它结合了多项密切相关的功能：
服务配置管理：维护有关服务、应用、数据库、API、云资源及其相互关系的准确信息。
资产与配置跟踪：组织用于支持软件应用交付和生产运营的各种系统和组件。
服务管理工作流：将该上下文应用于事件、变更、请求、审批和报告。
在 Service Collection 中，Assets 可为这些数据提供一个结构。Assets 是您的 CMDB，可用于存储所有配置记录及其随时间推移的关系，从而帮助团队不仅了解存在哪些内容，还能了解各组件之间的关联方式。
然后，Service Collection 的 Assets 数据管理器可通过整合并核对来自多个来源的记录，在团队将其运用于运营之前帮助提升数据质量。
为什么应用与服务资产管理对开发人员很重要
当应用与组件信息分散在不同电子表格和孤立系统中时，便难以清晰地了解公司运行了哪些应用、这些应用的使用情况，以及更重要的一点—发生变更时哪些部分会受到影响。
Service Collection Assets 可为您提供了一个结构化、可查询的 CMDB，它可将您的所有应用与组件数据集中在一处，从而用实时、互连的注册表取代零散的电子表格。
Atlassian Assets 可将您的应用与服务目录集中在一个结构化、可搜索的单一 CMDB 中，从而用实时、互联的记录取代分散的电子表格和孤立的工具。它会对应用、组件和基础设施之间的依赖关系绘制地图，并直接与 Jira Service Management 工作流关联；如此一来，团队便可始终了解自己拥有的资产、相关负责人是谁，以及发生变更时会受到什么影响。
更快地评估变更影响：团队可在发布变更之前了解哪些应用、环境或依赖服务可能会受到影响。
改善事件响应：响应者可以快速识别服务负责人、上游与下游依赖关系，以及可能受影响的基础设施。
减少上下文切换：开发人员和运营人员可直接在 Jira Service Management 工作流中访问服务与资产上下文。
强化服务权责归属：团队可让权责归属、支持责任与依赖关系数据更易于查找和维护。
提高对应用服务和运营数据的信任：Assets 数据管理器可帮助核对来自云工具、发现工具和内部系统的记录并将其转化为一个更纯净的事实来源。
支持与运营团队更好地开展协作：共享的配置上下文有助于工程与运营团队在变更和事件期间基于相同的理解开展工作。
Service Collection 如何支持应用与服务感知开发
Service Collection 可帮助开发与运营团队将配置数据引入此类数据在其内具有关键作用的工作流中。团队可将应用、服务和依赖关系直接与请求、事件和变更关联起来，而不是将服务模型与日常工作分离开来。
使用 Assets 构建以服务为中心的 CMDB
Assets 有助于团队为对软件与应用的交付和运营至关重要的组件定义对象架构，然后为基础设施和关系数据库绘制地图。其中可能包括业务服务、应用、环境、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.
使用 Assets 数据管理器提高数据质量
应用与服务数据通常来自多个来源：云平台、发现工具、电子表格、内部文档和工程系统。如果这些来源不一致，团队便会对模型失去信心。
Assets 数据管理器有助于整合、清理和核对来自多个来源的数据，从而形成更可靠的运营记录。这有助于更轻松地规范命名约定、减少重复项，并在缺漏影响事件、审计或审批之前对其加以识别。
对于工程与平台团队，这意味着更加信赖服务权责归属、环境记录与依赖关系数据。
为业务服务和应用服务与资产绘制地图，以评估事件和变更的影响
Jira Service Management 允许团队直接从工作单视图将请求或变更与资产对象关联起来。这意味着事件可以关联到受影响的应用或服务，而变更则可引用其涉及的环境或基础设施。
关联后，响应者和审批者便可掌握更好的上下文。他们可以查看涉及的服务、相关负责人、可能受影响的其他组件，以及相关工作是否已在进行。
借助关系上下文支持实现更快的故障排除
服务记录本身便很有帮助。连接到其依赖关系的服务记录要有用得多。关系数据可帮助团队更快地从“某一对象出现故障”推进到“该特定依赖关系可能就是原因”。
例如，如果某一 Web 应用出现降级，团队便可检查关联的数据库、身份验证提供程序、队列和云环境，以缩小调查范围。该共享视图还可通过为开发与运营团队提供该服务的通用地图来支持开展事件群集协作。
使用自动化保持运营工作流的运转
自动化可以帮助团队根据服务与配置上下文来采取行动，而无需额外的手动工作。团队可以根据状态或链接对象的变更来触发通知、路由工作单、创建后续任务或更新记录。
常见示例包括：
根据所选服务或所属团队路由事件
当关键依赖关系发生变化时创建后续任务
当事件影响高优先级服务时通知利益相关者
将标准运营检查与特定环境或组件相关联
演示示例：从服务模型到更快的事件分类、根本原因定位和解决
以下实际示例说明了应用与服务资产管理如何结合 Jira Service Management 和 Assets 在 Service Collection 中开展工作。
场景
平台工程团队负责支持一个内部开发者门户和多个面向客户的应用。服务权责归属已部分记录，但依赖关系信息却存在不一致，且分散在不同图表、云工具和团队知识中。
发生事件时，响应者需花费过多时间来弄清更改了什么以及涉及哪些组件。
第 1 步：定义服务模型
该团队创建了一个 Assets 架构，用于表示其 CMDB 中的关键配置项，其中包括业务服务、应用、环境、数据库、API 和所属团队。它们先从一个高价值的应用服务开始，并对其最重要的依赖关系绘制地图。
它们定义了以下关系（例如）：
应用依赖于 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 工作流
该团队将 Assets 字段添加到事件与变更工作流中，以便工程师和运营人员能选择受影响的服务或配置项。创建新事件时，响应者可立即看到关联的应用、负责人、环境和相关依赖关系。
此举可减少询问基本分类问题所花费的时间，并帮助团队更早地让合适的人员参与进来。
第 4 步：在事件期间使用模型
由于面向客户的应用中出现上报的错误，因而报告了一起事件。响应者在 Jira Service Management 中关联受影响的服务，并查看相关的配置项。他们发现，该应用依赖于一个共享的身份验证 API 和一个数据库集群。
近期变更已与身份验证 API 关联。该线索有助于团队快速缩小调查范围，并引入合适的负责人，而无需进行猜测。
第 5 步：改进未来的变更规划
此事件发生后，团队开始在变更审查期间使用相同的服务关系。在推出更新之前，它们可查看哪些依赖服务可能会受到影响，并提前与相关团队进行协调。
实际应用情况
阶段 | 团队的工作内容 | 运营价值 |
为服务建模 | 在 Assets 中创建服务、应用、环境与依赖关系对象 | 为工程与运营团队构建可用的 CMDB |
提高数据质量 | 使用数据管理器整理来自多个系统的数据 | 提升对责权归属数据与依赖关系数据的信任度 |
连接工作流程 | 将服务和配置项关联到事件和变更 | 在团队现有的工作环境中为其提供上下文 |
更快地进行分类 | 在事件期间使用依赖关系 | 缩短调查与上报时间 |
更好地规划变更 | 实施前审查受影响的服务和组件 | 提高风险意识并改善协调 |
如何着手实施
如果您正在为工程或应用开发团队构建此功能，分阶段推出通常效果最好。
从一个经常出现在事件或变更中的关键应用或服务开始。
定义配置项和关系的最小有用集合。
在大范围扩展之前，使用数据管理器提高源数据的质量。
首先将 Assets 上下文添加到事件与变更工作流中，从而创造直接运营价值。
随着团队证明该模型足够实用且可维护，逐步扩展 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
[Assets 是]我们 Jira 基础设施中相当关键的一部分。坦白来说，如果不在此空间中同时跟踪硬件，我不知道该如何使用 Jira 开展硬件工程。因为当我们尝试使用零散的硬件跟踪工具来做这件事时……我们的系统本身并不具备可追溯性。而且，如果尝试在其他那些工具中完成所有工作，那也谈不上有什么敏捷性。所以，我们确实找到了适合我们的方法。
Felipe Luisi，Lucid Motors 高级产品经理
常见问题
什么是应用与服务资产管理？
应用与服务资产管理是一种在关联模型中跟踪应用、服务、依赖关系、环境、配置项和责权归属的实践。它可为开发与运营团队提供有关事件、变更、请求和服务规划的可靠背景信息。
Assets 如何为应用开发团队提供支持？
Assets 提供了一个结构化的 CMDB，可用于对应用、API、数据库、环境、云资源及其所属团队进行建模。团队可将此上下文链接到 Jira Service Management 事件和变更，以评估影响、分配工作并更快地进行故障排除。
CMDB 和资产清单有什么区别？
资产清单记录了现有的内容，而 CMDB 还记录了配置项之间如何相互关联以及如何支持服务。Assets 可将应用与服务记录连同其依赖关系、责权归属和运营上下文一起存储，从而兼具两者的作用。
团队如何提高应用与服务数据的质量？
使用 Assets 数据管理器对来自多个来源的记录进行整合、清理、规范化和核对，然后再将其发布到工作模型中。从重大事件与变更所需的数据开始，然后在服务模型证明其足够有用且可维护时进行扩展。