金融领域业务监控体系的构建（上篇）

字数 4786阅读 3796评论 0赞 4

> 本文为云原生应用创新实践联盟——容器云自动化运维课题组生产内容，相关专家如下所示，更多内容可 [**点击此处进入云原生应用创新实践联盟**](https://cnaipa.talkwithtrend.com/?action-topic-id-403) 进行查看。  
① 已通过课题组专家审核  
② 待课题用户组织评议（欢迎各位在下方评论区提出您的宝贵意见）

> **执笔专家：**  
[**顾黄亮 容器云自动化运维用户委员会委员**](https://www.talkwithtrend.com/home/space.php?uid=1225551 "** 顾黄亮 容器云自动化运维用户委员会委员**")  
twt社区云原生应用创新实践联盟——容器云自动化运维方向课题组组长。 畅销书《DevOps权威指南》和《技术赋能 数字化转型的基石》作者，中国商联专家智库入库专家、国家互联网数据中心产业技术创新战略联盟(NIISA)智库专家委员会副主任委员、江苏银行业和保险业金融科技专家委员会候选专家、工信部企业数字化转型IOMM委员会特聘专家、财联社鲸平台智库入库专家、中国信通院可信云标准特聘专家、中国信通院低代码/无代码推进中心特聘专家，《研发运营一体化（DEVOPS）能力成熟度模型》和《企业IT运维发展白皮书》核心作者，容器云技能大赛课程出品人，多个技术峰会演讲嘉宾，拥有丰富的企业级DevOps实战经验，专注企业IT数字化的转型和落地，致力于企业智慧运维体系的打造。

> **顾问专家：**  
[**毛天明 容器云自动化运维用户委员会委员**](https://www.talkwithtrend.com/home/space.php?uid=1225435 "**毛天明 容器云自动化运维用户委员会委员**")  
twt社区云原生应用创新实践联盟—— 容器云自动化运维方向课题组专家。 5年大型保险公司容器云建设与推广经验，覆盖服务器规模超万台。工作主要从事devops流程设计、云原生架构建设、应用容器化改造。2020 容器云职业技能大赛百位专家委员会成员。

# 导读：
随着企业规模不断变大，系统也呈现爆发式增长，大型业务系统的监控复杂性也日益显现。笔者发现：监控遗漏导致业务受损的黑天鹅现象频繁发生；出现故障时很难从海量监控指标中迅速找到故障根因；报警风暴极大地干扰IT组织定位问题的速度；故障恢复速度基本依赖于IT团队的操作速度。因此，为解决以上问题，需要构建面向“终端”的业务监控体系，需要具备三种特征，确保业务数据的传递和一致性，具备业务事件监控和分析，基于业务数据和业务事件的端到端流程监控。

本话题分为两个部分：第一部分为方法论，主要涵盖传统监控体系的难点和业务监控体系的特征；第二部分为技术实践部分，包括请求传递技术和数据关联技术。

**通常，我们都会遇到一些熟悉的场景，当业务团队反馈系统可能存在异常，技术团队的反应是这样的：**

运营：授信系统出问题了？
技术：不可能吧，应用请求一切正常，而且最近没有上线和发布。
运营：可是近一小时授信通过率同比下降了40%？
技术：什么意思？听不懂，要不我们内部先查查。
运营：查到问题了吗：
技术：还没有，关联系统特别多，技术团队都在查。

# 一、现有监控体系难以解决的一些问题

## 1、系统呈现爆发式的增长

在运维人员的认知中，传统的监控体系是跟运维岗职相匹配的，只需要关注基础网络、服务器、数据库以及各类中间件的状态。然而，随着金融领域的业务拓展，系统数量越来越多，微服务、云原生等新技术的大量运用，系统架构越来越复杂，规模也越来越大。单体架构，逐步演变为分布式架构，再到现在的微服务架构，导致业务体系映射到系统体系的过程中，层级越来越多，匹配的业务场景也越来越复杂。

## 2、传统监控的场景越来越封闭
传统的监控场景仅开放给运维人员，能力稍强的，会开放给IT组织，笔者认为，这是故障驱动的一个典型方式，并非业务连续性驱动或用户体验驱动的方式。传统监控缺少业务视角的监控，以及业务与 IT 系统之间的联系。这导致用户、业务人员和技术人员之间无法形成统一视角。

无论运维监控、业务监控，都面临“面向终端”的转型，为业务负责，为客户负责，监控场景的封闭，业务级的故障往往需要用户的反馈，或者业务已经受损，技术人员依然无法确定是哪个系统的问题，恢复时间被大大拉长。

## 3、传统监控的数据或指标不具备业务价值
笔者调研过大量的案例，发现传统的监控体系由网络监控、主机存储监控、系统监控、中间件组件监控等构成，不同的监控系统之间无法共享数据，数据缺乏流动，这就导致传统的监控体系所采集的数据无法进行统一的分析，无法和业务场景结合，无法形成完善的指标集群，更无法具备科学的度量手段。

当出现问题时候，更多的从基础架构向上进行倒推，依靠技术人员的经验，在多个工具之间不断地切换和逐步排查，大大增加了故障恢复时长。除此之外，也无法和业务人员进行衔接，给公司造成舆情风险和客诉风险。

其次，传统的监控体系缺乏自动化协作，需要大量的人力进行配置的准入和准出，这种方式造成各系统的监控能力参差不齐，一旦有新的系统或新的业务投产，又需要进行梳理和监控项的配置，此外，业务的上下线需要不断调整监控指标和告警规则。

# 二、构建业务监控体系的一些关键要素

## 1、业务监控一定需要面向业务
监控和运维岗职是强相关的，我们需要每天通过监控系统查看系统的状态、资源的使用情况、告警的信息，而这一切都是为了企业的业务能够正常的开展，客户能够正常接受服务，因此业务监控一定需要面向业务。

业务监控需要同时面向业务的生产者和使用者，关注系统的功能点，关注承载使用者的业务场景，将二者进行数据的打通和流通，因此需要将业务监控体系内的角色进行业务属性的视觉统一。传统监控体系的最大问题，你关注你的点，我关注我的点，大家在业务监控的理解上是不一致的。

本文开头的案例是一个很好的例子，如果所有的业务监控可以抽象三个核心指标，分别是请求量、成功率、耗时。这三个关键指标来判断我们服务的可靠性，通过可靠性可以推算出业务的可用性，并且可以间接反映用户使用产品的的体验，如图1所示。
![图1](/home/attachment/202212/13/1225551_167091220298494.png)

## 2、业务监控体系一定是分层的
笔者认为，业务监控并不是孤立的，一个合理的业务监控体系可以分为三层，分别是业务监控层、应用监控层、基础架构层，如图2所示。

其中业务监控是整个监控体系的最上层，能够反映用户使用业务的真实情况，可以与业务结果直接挂钩，能够被不同部门、不同角色的人员所理解。

应用监控提供应用中服务和系统层监控能力，能够直接反应系统运行状态，帮助研发人员全面了解应用中服务和中间件的健康状态，快速定位系统问题。

基础架构层覆盖各类资源的监控，如网络、主机、存储和中间件，在故障排查中能够为研发人员提供实例级别的明细监控数据，快速确定是应用系统的问题，还是基础架构的问题。
![图2](/home/attachment/202212/13/1225551_167091224240089.png)

另外，还有一种分层方式，如图3所示，将应用监控进行了展开，分为用户端监控、客户端监控、WEB端监控和服务端监控。多端的分离，可以保证监控对象的广度，监控点的覆盖率，其中，服务端一般指后台服务，如金融领域中的信贷核心、会员核心；客户度一般指业务APP，通过埋点的方式发现APP的奔溃率，以及用户轨迹；用户端通常采集用户的舆情信息，和第三方舆情平台进行打通；WEB端一般对域名、IP地址的拨测。
![图3](/home/attachment/202212/13/1225551_167091227051675.png)

## 3、监控指标集群一定是体系的
传统的监控体系，通常将监控指标和报警规则按重要程度分成严重、警告、普通等多个等级，不同层次、不同级别的监控报警会被分派给不同的角色来处理。运维组织会关注基础架构的监控指标，研发组织会关注应用系统的监控指标，产品组织和业务组织会关注业务指标，这种按照级别的指标集群区分，可以解决绝大部分告警风暴的问题。

笔者认为，还有一种更体系化的监控指标集群，更好的匹配服务对象的定位，分为可预警集群、可报警集群、有效监控集群和有效优化集群。

其中可预警集群的指标可以通过可视化的方式反映系统和业务的健康状况，用于日常的巡检和查看；可报警集群通过一定的数据阈值，对业务的开展、系统的压力、资源的承载进行监控，需要多组织的协同，对问题进行有效处理；有效监控集群重点面向业务人员，从上而下进行驱动，可以通过用户端和客户端的数据反馈及时发现业务异常，并根据业务异常识别告警级别和触发应急处理机制；有效优化集群可以理解为公共指标集群，可以统一进行编排和配置，减少技术在运营支撑上的投入成本。

确定体系的监控指标集群需要相应的数据支撑，如信息的采集、信息的清洗、信息的加工、信息的编排、信息的有效利用，不同的阶段会有对应的技术选型，但把握一个原则，不过度设计，规避简单事情复杂化。

## 4、数据一定是全流程的，且一定是闭环的
无论什么形式的监控体系，都离不开数据，笔者举一个简单的例子，描述账务核心系统的故障排查。

首先，业务人员收到代收渠道发生切换的告警通知，同时账务核心系统的负责人也收到调用延时报警，此时线上问题已经达到故障等级的标准。

业务人员确认代收渠道发生切换后，业务可以正常运行。研发人员通过报警信息中的链接直接打开对应业务监控页面查看交易总调用量、延时、成功率等黄金指标数据，发现延时大幅升高，成功率有所下降，调用量没有明细下跌，排除上游流量徒增造成系统容量问题的情况。

通过业务监控的数据关联，查看切换前的数据，发现超时错误码存在同环比的增加，可以排除业务逻辑的问题，通过应用监控的监控，可以发现资金方的回调接口异常，调用成功率大幅下降，调用延时增加。

研发人员将信息反馈给业务人员，业务人员联系资金方，确认资金方出现资源瓶颈，基础架构的资源不足导致数据库出现慢查询的情况，经过资金方确认，此问题由于内部资源隔离造成，增加资源后解决。

从以上的问题解决过程，我们可以发现，无论是业务团队还是技术团队，协同路径和数据传递路径是一致的，围绕数据生产到数据增值，再到数据消费，可以配合业务场景勾勒出不同的用户故事，用户故事就是针对具体的角色，会有什么具体的活动，以及这个活动所产生的价值，如图4所示。
![图4](/home/attachment/202212/13/1225551_167091230954019.png)

传统监控体系的数据传递是自下而上的，从数据生产到数据消费，这是一个小的闭环。业务监控体系的数据传递是环状的，从数据采集到数据生产，到数据消费，再到最后的数据增值，围绕着业务场景不停的进行优化迭代。

笔者在此进行一定的延伸，例如对若干承载 CPU 计算型业务的服务器所产生的 CPU 使用率告警时间进行分析统计，可以推导出该业务的服务高峰期是大概在那个时间范围，这是典型的从资源容量管理上升到业务的容量管理。

# 三、业务监控体系的技术路径
业务监控体系的技术路径本质上和应用监控体系没有区别，需要关注的是，在应用监控体系的基础上，对链路追踪和数据关联赋予了业务属性，基于篇幅的考虑，笔者后续逐步进行展开。

监控体系规划业务监控应用监控

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

金融领域业务监控体系的构建（上篇）

添加新评论0 条评论

作者其他文章

相关文章

相关问题