之前应该有写文章探讨过测试左右移的问题。

左移大致就是在设计的时候，写代码之前先把问题考虑清楚，尽量减少一些伪需求和自相矛盾的需求，要求测试同学有较大的业务能力。

右移就是上线之后通过监控等手段去提前感知线上的问题，争取在大部分用户发现问题之前就感知到问题并且快速修复和发布，没有被用户抓住的问题其实影响范围是有限的，可以想办法消化掉。

从软件测试的生命周期上看，大部分项目可能都会经历发布上线和线上运行/运营的阶段，从绩效层面上看，线上问题对绩效的影响是很大的，起码从感觉上来说是这样的。比如某测试同学工作兢兢业业勤勤恳恳，但是由于某天线上出了一个很严重的问题，造成了经济损失，通过回溯和复盘，发现该测试人员应该负主要责任，如果你是他的上级，你会怎么评估他的绩效呢？是采取人非圣贤孰能无过，知错能改善莫大焉的态度，还是因为严重的线上问题全盘否定他的付出呢？一般来说，你可能会采取比较中庸的做法，事故责任是要承担的，但瑕不掩瑜，还是会有值得肯定的地方。这时候往往就是把大锅分成一个一个的小锅，找人一起背。不过测试是甩锅链中比较弱势的一环，也是背锅链中首当其冲的一环，还是要有比较强的求生欲以及良好的心理素质才可以。

把线上监控做完备是求生欲强的表现之一。

简单起见，我们把线上监控分为3种类型，分别是业务级，服务级和硬件级的监控。

• 业务级。业务级的监控需要大家去定义一些核心的业务指标，然后对指标进行监控，如果指标有异常那么争取迅速定位问题，将业务重新推上正轨。拿电商业务举例，核心指标可能是订单量，假如平时下午2点到3点左右的平均单量是1000，但今天只有100，那么应该是哪里出了问题，需要迅速去定位和排查。如果订单数直接掉到0，那么可能是订单服务不可用或者整站都挂掉了。

• 服务级。比如订单服务一共有10个接口，那么每个接口的调用次数，成功率，返回速度等。服务级的指标可以分的很细，每个团队每种业务都有不同的服务级指标的着重点。

• 硬件级。这个比较好理解。比如可以看到某台服务器的cpu内存网卡等指标。

谁来做

监控谁来做是个老生常谈的问题。一般来业务级监控需要测试+产品+运维的同学一起来做，运维可以主导，测试同学可以辅助验证或验收。服务级的监控可以由开发+运维+测试来做。硬件级可以由运维同学主导。

3层是不是都要做

一般来说3层都做的话是比较好的。比如业务级监控发现了订单量异常，然后通过服务级监控发现订单服务的库存接口调用失败率很高，导致订单无法正常创建，最后通过硬件层监控发现库存服务的硬件服务器磁盘io异常，从而可以快速定位到问题，迅速修复。

如果没有精力把3层都做全的话，可以先做业务级，至上而下把3层逐步建设好。因为业务级的监控往往非常直观，有锅自远方来可以一目了然，做好业务层监控可以提高一些存活率，不过如果想把线上问题的影响降到最低，另2层也是需要建设完备的。

并不是所有的问题都可以监控到

有时候我们并不是所有的问题都可以监控到，或者有一些监控的指标由于跨部门，或调用第三方服务的关系，我们没办法拿到我们想要的核心指标或数据。这时候我们可能需要模拟线上用户的一些具体操作去感知问题。举个例子，目前订单系统支持微信支付和支付宝支付，默认情况下展示的是微信支付的链接。我们可以通过在线上真实下单的方式(自动化测试的手段)去调用微信支付接口，如果可以正常走完流程，那么微信支付应该是没有问题的，如果走不通流程，那么微信支付可能暂时不可用，我们可以迅速把默认支付方式切成支付宝，这样可能对订单量不会造成特别大的影响。

告警

监控往往跟告警结合起来，比如我们可以设置高峰期每十分钟的订单量如果小于100就通知相关人员进行故障排查。告警往往需要非常精准，因为如果老是误报，那么大家可能会习惯性的忽略告警信息，导致告警形同虚设，那就是狼来了的故事了。

综上希望对大家有所帮助，另外作者水平有限能力一般，有问题还请斧正。