测试右移：线上监控实践

前言

大家可能了解过关于“测试左移”、“测试右移”的思想。产品研发周期随手就能画出来，以前，测试基本都在开发阶段完成之后和产品上线之前完成。目前，很多测试团队的部分测试活动已经左移：测试在开发阶段之前设计，比如对于BDD行为驱动开发、单元测试、CodeReview的实践。而测试右移，即是往产品发布之后移，最常见的，我们可以理解为：在生产环境中监控，并且实时获取用户反馈。今天，我们就来谈谈线上监控吧~~

为什么要做线上监控

先给大家讲一个故事。某日某广告业务，晚上7点半，由于程序故障，大量渠道被误封禁，但因因该低峰时段收入占比较少，全天收入报警阈值是20%，没有触发报警。第二天，产品同学发现高峰期收入和请求降低一半，立刻告知技术排查。2小时后，相关程序回滚完成，问题处理完毕，请求数和收入恢复正常。至此，从问题出现到问题解决已经过去了16小时，造成了大量损失。

故事讲完了，不知道你有何感想？

笔者所在的DSP业务线每日接收近百亿广告请求，线上服务在高峰期哪怕异常1分钟也会造成可观的损失，对于这样的关键收入业务，如果没有足够有效的监控，将会是一个定时炸弹般巨大的隐患，因为谁都不能保证系统永远工作正常，也无法实现每时每刻都有人肉眼监控。所以，线上监控自然非常迫切。

基于上面的背景，我们开始了“测试右移”的监控之旅，具体做了哪些呢？

我们做了哪些监控

1.接口级监控

我们首先做的，就是依托现有的三剑客Ialert监控系统（http://www.jiekouceshi.com/ialert/），将所有服务器都做了单独的接口级监控，并设置了合理的业务逻辑断言，一旦接口经过断言不满足超过3次，则触发短信报警。接口本身的监控能够确保我们随时获知自身的每台服务器的异常情况。下图为Ialert系统中对于某接口的监控概览。

但是，DSP业务上下游链路长，最终还要将素材返回ADX（即广告交易平台）去竞价，如果上游出了问题，那么接口级的监控是无感知的。怎么解决这个问题呢？

2.UI级监控

那么问题又来了，这种监控只是针对特定渠道号（或者叫广告位）的监控，对于全局的程序异常是有效的，但对于开篇提到的渠道误封禁的事故，却依然存在无法发现问题的可能。

3.收入监控

在广告业务中，收入往往是最直观的考量指标，如果某个时间点收入突降，一定要引起警觉。调研到公司的BA系统（下图）能够以5分钟的频率产出该时间段的收入，所以自然而然就拿到了接口，每5分钟自动请求一次，并判断当前时间点同比上周和环比昨日是否超过所设定的阈值，一旦超过即短信报警。

4.关键指标每日监控

除此之外，熟悉广告业务的同学都知道还有很多衡量指标，比如请求数、竞价成功数、点击数、CPM、CPC等关键指标，这些都集中在业务方开发的监控平台中，但为了方面查看每日数据波动，我们依然基于该监控平台提供的接口，做了关键指标的每日监控邮件提醒，可以清楚看到昨日数据相比上周、前天的同环比情况，便于及时发现问题。

监控效果如何

搭建起这四层监控体系之后，还是解决了不少业务问题，举两个栗子来说明。

1.某工作日接口上线时因流程操作错误，导致部分服务器状态异常，几分钟后，短信报警频繁触发，RD在15分钟内进行了迅速修复；

2.某周六，由于大量异常流量请求服务器，导致资源被耗尽，大量接口请求无法正常返回，报警后及时进行了修复。如果没有监控，可能在周末这样的时间点更不容易尽快发现问题。

写在最后

以上是DSP业务在线上监控上的一些实践。诚然，监控本身肯定存在误报，服务器抖动也好，依赖的上游数据有问题都会产生误报，我们努力的方向是在减少误报的同时尽量提高灵敏度，缩短问题发现时间，能真正做到在测试右移后，业务的线上可靠性得到大幅提升。

Qtest是360旗下的专业测试团队！

是WEB平台部测试技术平台化、效率化的先锋力量！