​

在当今竞争激烈的商业环境中，企业必须实时掌握业务流程的运行状况，以确保高效运营和优化用户体验。Databuff的业务观测功能能够帮助企业直观理解整体业务流程、识别潜在瓶颈、探索优化空间。这不仅提升了流程效率，还能够实时监控业务健康状况、性能表现和用户体验，从而做出更科学的决策。

本文将介绍如何使用Databuff的业务观测功能来界定关键业务事件，构建能够反映真实用户旅程的业务场景模型，进而以更贴合实际操作需求的方式实现高效精准的业务观测。

1. 定义业务事件

1.1 业务事件概述

业务事件是指与特定业务逻辑相关的操作或事件。为了能够以业务视角进行观测，我们需要先对业务事件进行定义，明确其业务含义。例如，将 web应用服务 中的 POST /user/login 请求定义为“登录”业务。

1.2 创建业务事件

创建业务事件时，需要定义以下信息：

业务事件名称：为业务事件命名，例如“用户登录”。
描述：描述业务事件，方便用户对此业务事件进行补充说明。
业务类型：用于区分不同的业务类型。
业务粒度：选择是以服务为业务粒度还是以接口为业务粒度。不同的粒度在选择具体服务或接口请求时有所差异：
服务级粒度：仅能选择具体的服务名称。
接口级粒度：可以依据具体接口拆分业务，在选择接口请求时需先选择服务，再根据服务选择需要关联的接口请求。
关联服务/请求：当业务粒度选中服务级时，显示为“关联服务”，提供服务选择框供用户筛选；当业务粒度选中接口级时，显示为“关联请求”，提供接口请求选择框。选择接口请求时需要先选择请求类型，请求类型有HTTP请求、RPC请求、MQ消费等。

1.3 示例

假设我们有一个 web应用服务，其中包含 POST /user/login 接口。我们可以创建以下业务事件：

业务事件名称：用户登录
描述：用户通过 POST /user/login 接口进行登录操作。
业务类型：后端业务
业务粒度：接口级
关联请求：POST /user/login

业务事件名称：获取用户资料
描述：用户通过 GET /user/getUserInfo 和POST /user/findRoleByUserName多个接口获取个人资料。
业务类型：后端业务
业务粒度：接口级
关联请求：GET /user/getUserInfo 和POST /user/findRoleByUserName

2. 创建业务场景

2.1 业务场景概述

业务场景是指由多个业务事件组成的业务流程。通过创建业务场景，可以将各个业务事件串联起来，形成一个完整的业务流程进行分析。

2.2 创建业务场景

创建业务场景时，需要定义以下信息：

业务场景名称：定义业务场景的名称，例如“用户登录流程”。
业务分组：选择一个业务分组。业务分组可以帮助用户管理业务场景，将大量的业务场景梳理在不同业务分组中，方便查看和管理。
关联事件：关联绑定业务事件，根据业务事件的先后顺序串联构成业务场景。

2.3 示例

假设我们有一个“用户登录流程”的业务场景，可以包含以下业务事件：
业务事件名称：用户登录
业务事件名称：获取用户资料创建业务场景时，可以选择“用户登录”、“获取用户信息”和“获取用户菜单”三个业务事件，并按顺序串联。

3. 管理业务分组

业务分组可以帮助用户对众多业务场景进行分组管理，以增强管理效率。支持自定义业务分组名称，在管理分组页面中，分组的上下顺序决定了在展示时的自上而下顺序。

3.1 示例

假设我们有两个业务分组：“用户管理”和“订单管理”。在“用户管理”分组中，可以包含“用户登录流程”和“用户注册流程”两个业务场景。

4. 场景地图

场景地图以可视化的方式展示业务场景中各业务事件的关系以及业务事件的状态和关键指标。在场景地图中，业务场景中的各个业务事件单独判断是否正常，当某个业务事件所对应的对象（服务或接口请求）存在告警时，则业务事件标为红色，表示该业务事件异常。而业务场景中的任意一个业务事件存在异常时，在业务场景看板中对应的业务场景也会标为红色，表示业务场景异常。

4.1 关键指标

业务事件会中展示的关键指标有：

请求量：当前业务事件的请求次数。
平均响应时间：当前业务事件的平均响应时间。
错误率：当前业务事件的错误率。

4.2 示例

在“用户下单流程”业务场景中，假设“用户下单”业务事件的请求量为300次，平均响应时间为250毫秒，错误率为0.0%。如果“用户下单”业务事件的某个接口存在告警，则该业务事件在场景地图中会标为红色。右侧也会显示相应的告警数据。

结论

通过定义业务事件和创建业务场景，我们可以从业务视角全面观测系统的运行状态，及时发现和解决问题。业务分组和场景地图的引入，进一步增强了业务观测的可管理性和可视化程度。

​