在当今这个数据驱动的时代，企业要想在激烈的市场竞争中保持领先，就必须不断提升自身的业务洞察力。业务洞察力是企业决策的基石，它能够帮助企业深入理解市场动态、客户行为和内部运营，从而做出更加精准和有效的战略部署。
大家都知道，观测云是一款全面的监控观测平台，提供了非常丰富的能力去描述一个应用系统的全生命周期的健康和观测，那么自然而然，大家也希望观测云能够提供面向业务的监控观测能力。其实作为本质上是一个实时数据平台的观测云，自然可以实现这样的能力，并且甚至可以做得非常强大。如何通过观测云实现面向业务的监控观测呢？
第一步，统一业务表达的数据结构
众所周知，观测云本身的 Datakit 在数据采集的时候，实现了一系列的统一标签（Tag），所以才能够体现出比如一次代码调用到底是发生在哪个主机上的，以及相关的日志，事实上这是通过一系列的 Tag 来完成的，如 service 定义了应用服务，host 定义了主机等等。这些都是观测云定义的，但观测云本身不了解客户的业务，也没办法自动识别和业务相关的字段的实际含义，所以就需要客户自己预先定义一套和自己业务相关的字段规范。如：
- 订单号：order_id
- 金额：amount
- 用户等级：user_class
需要注意的是：
1、需要保证这些字段对应的值是确定的，比如是整型，还是字符串，还是枚举，如果本身数据类型不统一和业务含义不统一，那么当数据再被监控分析的时候所表现出的物理意义可能就会缺失。如 user_class 应该是 vip，却输入错误变成了 vop，那么统计 vip 的时候有可能就漏掉了那个输出成 vop 系统的相关信息了。
2、需要保证所有业务系统都能够按照这一整套的标准来描述自己的业务。如果不同业务系统存在完全不同的定义，那也会导致各个业务系统的联合监控分析这个能力也将缺失。
第二步，将业务模型注入可观测性数据中
定义完标准以后，那么我们就要保证所有的可观测性数据都能够通过这些业务相关的字段进行连接。无论是指标，日志，链路，还是用户访问的行为数据。这些我们就可以通过这些业务字段来快速的构建未来的监控，分析，故障爆炸半径等等能力。
举个例子，如果我们要监控一种类型的订单是否存在问题，我们需要将订单类型（order_class），订单号（order_id）注入到所有的相关数据里。从用户访问（RUM）数据，前端在提交这个订单的 Action 上，就要将这两个字段添加到 Action 上。后端的各个业务 Trace 数据也需要在每一个涉及这个订单的 API 上添加相关的字段，包括涉及到的日志，也需要添加这些字段。只有这样，我们完全可以通过 order_class 设定不同的监控，比如监控某个创建订单接口，针对 order_class 进行分组，最终当某一个分组的订单产生异常的时候，可以快速追踪到对应异常订单和产生异常的原因（通过 RUM 找到用户，通过日志分析业务原因等等），这样快速的观测就不仅仅是针对一些简单的 IT 元素（接口，CPU 等等）而且还可以提升 IT 工程师对于受影响的业务的敏感度，最终真正落实对业务的监控观测和保障。
很显然这个注入过程看起来非常重要，但其实并不复杂。
- 对于用户行为数据，完全可以通过观测云的前端 sdk，让前端工程师进行一些配置，即可实现。
- 对于后端的 Trace，最佳方案是把这些字段放到 HTTP 的请求头上，并配置 tracer 将这些 HTTP 头上的信息添加到每一个 Span 上。
- 对于日志记录，研发工程师有充分的理由在日志输出中添加这些内容（也可以来源于请求的 HTTP Context）。
另外业务也可以主动上报一下计数的指标，也需要添加这些信息，如通过 Prometheus 的 push 协议，或者直接使用 Datakit API 进行指标上报。
另外一个手段就是通过 Func 基于 Webhook 或者定时轮询的方式，从业务系统或者数据库中获取更多业务相关的数据来作为一种数据的输入。
当然如果本身数据存在差异，也可以通过观测云的 Pipeline 进行数据结构的质量和规范，不过如果能在应用层就对齐的情况下，并不推荐这种方式，因为应用系统不断在变化，Pipeline 配置很难有效的跟得上应用的变化，或者将 Pipeline 的配置权力给到业务应用相关的开发工程师，让他们来管理。
第三步，构建可观测性
当所有数据被有效且一致性地记录后，我们就可以利用收集到的数据来构建面向业务的观测。构建可观测性在观测云中主要通过两个手段：
- 第一个手段是 Dashboard（大盘），并可以配置下钻分析，例如从订单号下钻到用户会话，并从会话跟踪整个订单的处理过程。
- 第二个手段是 Explorer（查看器），通过链路、日志和用户访问查看器，可以直接查询对应业务标签的详细数据，针对每条数据详细分析。
在构建可观测性的时候，首先要确定的是业务目标，以上面的例子为例，如果我们已经有了业务字段贯穿了整个可观测性数据，那么我们最关注什么，我们需要分析什么，我们需要做什么样的定位？必须想清楚这个问题。比如：
- 我们是否可以看到相关类型订单的错误分布？
- 相关订单处理在哪个系统中延迟最大？
- 哪些订单超过了正常的处理时间？（可能订单处理存在人工异步的情况）
我们只要把这些问题定义出来，就可以将相关的 Dashboard 定义出来了。同样，我们也可以构建一个 基于订单 id 的查看器，定义好相关的字段，可以通过查看器去追踪每一个订单的全生命周期，包括每一个订单的相关产生的系统日志等等，帮助我们快速确定注入用户投诉时，相关问题的定位。
第四步，面向业务的监控
除了构建可观测性以外，我们还需要针对性的实现面向业务的监控，面向业务的监控需要搞清楚三件事情：
- 第一件事情是什么是当前业务的北极星指标，或者说核心指标，即这些指标出现异常需要提醒。
- 第二件事情是这些问题出现的时候需要通知谁，这个时候可能不一定局限在 IT 相关的人员，甚至可以将问题同步到业务人员，或者同步到一些业务系统，提升业务前线的敏感度。
- 第三件事情是将相关的数据平面绑定到发送的监控告警中，快速让接收到问题的人员能够了解整个业务的全貌，而不仅仅是一个单点的异常，同时提供相关的查看器，方便他来追踪问题。
当然我们也可以通过观测云的自定义巡检算法功能，实现面向业务的一些特性的监控而不是以 IT 视角来监控，如通过异常检测算法分析订单的异常波动，如和过去的日常行为不太一样，通过数据分析风控视角发现一些奇怪的订单，如明显同品类中的价格偏低等等。当然如果业务本身已经上了一些面向业务监控风控的平台，我们也可以将这些风控系统的信号反向订阅到观测云，这样我们可以将这些信号和应用系统，IT 系统的状况管理起来，方便 IT 人员快速分析当发生这些风险信号的时候，整个应用软件和基础设施的状态。