一、了解可观测性
1.1 什么是可观测性
维基百科定义:
OpenTelemetry组织提出了可观测性依赖的三大“支柱”:

注:图片来源于网络
可观测性运作模式可看作是:观察-判断-优化-再观察
1.2 可观测性和监控的区别
•监控(Monitoring):收集、分析和使用信息来观察一段时间内的运行进度,并且进行相应的决策管理的过程,监控侧重于观察特定指标。

1.3 可观测性和监控的联系

二、质量保障目的
三、质量保障思路
上边提到了监控和可观测性的区别和联系,本文提到的质量保障思路是以业务监控作为基础底座,拓展数据可观测性的能力,旨在解决传统监控被动防御的缺点,结合可观测性下的采集、聚合、追踪提供问题定位、风险预测、系统决策的能力。
1. 监控基础底座
1.1 监控维度思考
-
对硬件、网络带宽等资源使用层面的监控。通常由运维侧主导。
-
服务或接口的可用性等,例如UMP监控。通常由研发侧主导。
-
重点关注系统对外提供的功能是否正常,测试需重点关注的部分
-
重点关注跟业务特性强相关的数据,根据数据正确性、数据走向趋势能间接的反映出系统健康度是否有下降或存在潜在风险
-
统计学监控的思维,从日志聚合角度计算出系统整体、分接口的可用性。可用性低于预期或存在环比内大幅下降则可能是系统出现异常
1.2 测试团队重点建设监控项
1.2.1 业务功能监控
写接口:由于写接口可能会产生脏数据,在保险侧业务上禁止此种操作,而且即使使用测试账号也会产生于生产环境差异巨大的不真实数据,所以我们无法使用直接在生产环境直接操作写接口。这里想到的一个方案是【测试反哺】,具体思路为:用预发环境反哺生产验证。理论上预发环境版本号一定 >= 生产环境,预发环境由于新提测的内容导致监控探测失败,可看作是对历史功能的回归验证不通过,其中有两种情况:
1. 预期内失败:功能变更对接口产生的影响,这时需要同步修改监控内容
2. 非预期内失败:新提测内容,影响了原有的功能,可看作是提测的需求bug

按照传统的接口监控方式,通常会写一个监控case然后周期性执行。这样写的弊端是高度依赖测试人员对业务的了解程度,也很难保障业务场景覆盖的完整性,而随着系统的迭代一个接口的功能场景可能会被扩展出很多,如果测试人员只了解其中的一个或某几个场景,按照习惯会添加这几个场景的监控case,但是不熟悉的场景可能就会一直缺少对应的监控。
这种思路比较像黑盒测试,即不关注具体的数据、业务处理流程,更贴近用户的真实操作,把自己想像成一个真实的用户,用户在使用产品的时候能看到什么,能操作哪些页面、按钮?这些操作背后对应的功能是什么,从视角上的可见反推到不可见的应用背后。
1.2.2 业务数据监控
业务数据是产品最终的价值体现,数据的有消息、正确性、健康性最终能反应出系统的稳定性。针对保险业务,我们其实可以做很多业务数据层面的监控,例如:
1.2.3 日志聚类监控
跟业务数据的重要性一样,通过日志也能间接的反应出系统运行的稳定性状况,由于对日志进行聚类监控本身依赖应用日志的规范性,所以这里非为短期内可落地和长期改造的两个思路。
短期:
所以需要一段时间的试错,前期阈值设定的保守一些,用一段时间的数据评估出一个相对合理的阈值,同时由于数据的积累,后续的报警策略也可以摆脱单独的固定阈值方式,使用阈值+趋势分析的策略进行报警。
引申价值:近一周或一个月内报错数量统计对比,如果某天报错突然增多,则预示可能存在风险(百分比上涨监控)。
报警Demo:【警告】10min内 {投保年龄错误} 类型报错数量超过100,大于设定阈值90,请排查系统是否有异常!
长期:
应用可用性 = (时间段内的全量流量 - 时间段内的报错流量) / 时间段内的全量流量

集团的PFinder (problem finder) 是UMP团队打造的新一代APM(应用性能追踪)系统,非常贴合可观测性的概念,目前研发团队也在陆续的将应用接入到PFinder。
避免重复造轮子!作为测试人员应该对系统的功能是否可用、业务数据是否正确有高度的敏感性。测试团队的可观测行建设与监控紧密结合。通过配合监控建设,结合可观测性给出系统诊断、分析、定位的能力。

2.2 系统级可观测性
联动报警
可观测性具有系统及观测的特点,也就是说它能更全局的看到到整个系统不同模块的状态,所以应该具备很强的模块联动性。
通常在一个业务系统中,叶子节点的异常会导致上游服务的异常。例如应用A 调用 应用B完成业务处理,当应用B发送异常时,会影响到应用A,传统的监控方式是对各自的应用做监控,此时如果应用B本身的监控不完善,很难第一时间排查出问题的根因,甚至在应用B监控完善的情况下,如果AB信息没有及时共享,也很难第一时间定位问题。在这种情况下建设联动报警的能力,除了能发现上游服务的问题,还能引申联动探测出子模块的异常,可以有效缩短问题定位和修复的时间。
具体思路为:当上游应用发生异常时,可尝试向下游子模块进行探测,在报警信息中汇总出所有发现异常的模块信息,给问题定位人员提供直观的排查方向。
联动报警不止能应用在系统及可观测性中,针对传统的监控方式也可以根据模块间的关闭进行联动报警。
故障定位
数据分析
多系统之间的业务交互最终表现在数据流上,在具备了系统应用间的联动能力以后,可以对关键数据进行核对或者分析转化率
数据核对可以提供不同系统间数据一致性的校验
数据转化可以看出同一笔数据在不同系统间的流动,可以引申出一些业务敏感数据的对比等
2.3 感知及展示
扫一扫,加入技术交流群
本篇文章来源于微信公众号: 京东云开发者
本文来自投稿,不代表TakinTalks稳定性技术交流平台立场,如若转载,请联系原作者。