测试技术篇之认识线上监控
题记今天我跟大家聊一聊监控，包括为什么要做线上监控，如何评估监控效果做的怎么样，常用的监控方向都有哪些等这些常见问题。
一、为什么要做线上监控？
首先，我们聊下为什么要做线上监控。
在传统的测试认知里，测试是指产品上线前进行的线下测试。但是随着互联网产品越来越复杂，线下测试已经不能满足质量保障的诉求，所以，如果你仍然只会线下测试，而没有线上测试的意识、没有掌握线上测试的方法，已经不能满足当前互联网产品对测试人员的工作要求。
今天要讲解的线上监控就是线上测试的一种测试手段。
请注意，本文以互联网产品为背景进行线上监控的讲解，当然，监控的设计思想是通用的，即使是非互联网业务也可以参考。
我会通过回答问题的方式来完成本小节的讲解，三个问题分别是：
·到底什么是线上监控？
·为什么要做线上监控？
·线上监控与测试有什么关系？
1.什么是线上监控？
首先，我先回答第一问题：什么是线上监控？
线上监控，就是通过技术手段，实时探测线上产品的运行状态。目的是为了及时发现产品的线上问题，助力问题及时解决，避免产生更多的用户体验损失。
注意，这里面提到了一个词叫“实时探测”，怎么探测呢？我们会有个探测周期。这个周期可以是分钟、小时等任意级别，具体需要根据产品功能的重要程度来定。
2.为什么要做线上监控？
好，接下来，我来回答第二个问题：为什么要做线上监控？
首先，了解互联网产品的人都知道，互联网产品更新迭代的速度太快了，一个产品从需求到上线往往时间很短，留给研发、测试同学的时间更是非常有限。并且，最终，历经千辛万苦上线的产品，还很有可能因为功能设计不符合市场需求等原因被废弃掉。这时候，如果我们从开始就精益求精，每一步都要非常完美，这就需要公司投入很多的人力。考虑到投入产出比，在一开始，无论研发还是测试环节，都会做一定程度的质量容忍。
其次，互联网产品很多都是to C的。这样的话，用户的使用场景就会千差万别。在实际操作中，我们其实也很难在产品上线之前发现所有的缺陷。
最后，即使投入非常大的精力去做质量控制，线上服务突发异常也是不可避免的。这一点其实可以从两方面来说。
一方面，由于产品迭代过于快速，很难在有限的时间发现所有的问题，尤其当服务本身非常复杂时，这里我给你举个真实的案例：复杂的搜索系统升级带来的线上服务故障。
大家经常使用的搜索产品，看似简单的搜索框和搜索结果，后面其实有很多团队和产品线在研发和运维。下图所示是搜索产品某数据通路经过的系统或者模块，类似这样的数据通路有很多，每个系统都是不同的人员负责（数据进行脱敏处理）。
http://www.51testing.com/attachments/2021/04/15326825_202104191513511mBvt.png
每个团队只负责开发自己的模块，每个功能的上线，需要依赖其他很多团队的服务，在这么复杂的系统下，如果要确保每次上线的功能不影响其他服务，就需要跟其他服务做大量的联调工作。
但是由于系统太复杂了，我们一般只会跟直接的上下游进行联调。如果需要做更充分的联调工作，就特别依赖测试人员对整个系统的了解，测试人员需要清楚的知道整个功能流会经过哪些服务，可能存在哪些问题。
有经验的人都清楚，这其实是非常难的事情，即使是开发人员也很难做到，因为大家负责的事情太螺丝钉了，而每个服务又在快速迭代，几乎不可能完全考虑到所有的风险点。
实际上，由于某次升级导致线上服务故障的情况非常常见。
另一方面，即使服务没有进行升级，服务在线上运行的过程中，也会由于某种原因出现故障。
比如服务的某些数据也许来自于第三方服务，如果第三方突发故障，我们的服务就会出现问题。
下图给出了我曾经负责过的一个产品的第三方引起的问题占比情况，高达56%。
http://www.51testing.com/attachments/2021/04/15326825_2021041915135121z5t.png
这里我再给你举个真实的案例：线上突发计算资源受限导致的服务异常。
我曾经负责过一个产品，这个产品其中的一个功能就是在web端天级别展示给用户最近一天的成长数据，这个成长数据关系到用户可以获得哪些产品功能，因此用户非常关注。
这个功能曾经发生过一次故障，导致所有用户的成长数据降低为0，当时引起了疯狂的用户反馈。
故障出现后，我们首先排查有没有服务升级，排查后确定没有服务升级。
后来定位出来原因是，成长数据产出的过程中经过的其中一个服务由于计算资源受限导致计算失败 ，最终导致最新的成长数据全部降低为0。
事后，我们做了复盘，对于这种不是服务升级引发的故障，也就不能经过线下测试环节来进行质量控制，只能通过监控线上服务的运行状态，争取在用户使用之前，快速的发现服务的问题。
说到这里，我跟你讲解下，线下测试主要解决的问题。
线下测试主要解决的问题是：在产品的某个版本正式上线前，测试同学在给定的时间和人力成本的情况下，对产品进行测试，只有测试通过，该版本才会正式发布。并且传统的测试一般指的就是线下测试。
因此，结合上述三点，也就是考虑到人力投入产出比、to C产品丰富的使用场景带来的很难挖掘到全量的产品缺陷、以及无法避免的的线上服务突发异常，我们都不可能只通过线下测试，就能完全确保产品的质量问题。
为了解决这个问题，我们引入了线上测试的概念，线上测试主要解决的问题是：在产品的某个版本正式上线后，测试同学对上线后的产品进行测试，目的是为了发现产品上线后的问题，当然，这个过程是漫长的，只要产品在线上运行，就需要投入时间和人力成本。
线上测试其实是线下测试的一种补充，也是一种测试手段。
刚才我们提到，只要产品在线上运行，就需要投入时间和人力成本来开展线上测试，这种成本是随着时间线性增长的，因此，如果能够建立一种机制，这种机制可以自动监测产品的运行状态，一旦服务故障，就能够主动通知我们，而当服务正常运行的时候，我们可以安心的开展其他工作，这样的话，将会大大降低线上测试的成本。
这种机制就是线上监控。
3.线上监控与测试有什么关系？
好，讲到这里，刚才提到的第三个问题：线上监控与测试有什么关系？ 我想你已经非常清楚了。一句话总结就是：线上监控其实就是线上测试的一种实现方式。当然需要监控的内容有很多，并非所有的监控点都是测试人员负责的范畴，比如机器相关的监控通常都是运维或者研发自己负责，测试人员偏重于业务功能的监控。
通过上述内容，期望帮大家建立线上测试的意识，打破传统测试即线下测试的边界，知晓线上监控的概念、以及为什么要开展线上监控。
二、如何评估监控效果做的怎么样？
为什么要分享这个话题呢，因为，只有知道什么样的监控效果是好的，才能够更好的开展监控。并且监控的开发不是一次性可以完成的，它需要在不断的运行过程中逐渐完善，而完善的过程就需要一些指标作为指引。比如，监控发现问题的情况如何？监控发现问题后解决速度如何？明确衡量这些问题的指标，根据这些指标，采取以终为始的思维方式倒推出工作开展的详细路径。
其实不单是监控，我们在做任何一件事情的时候，都可以按照这个思路来展开。
为了方便你理解，我会以自己曾经负责过的一个实际产品为例，来进行讲解。这个产品的业务效果如下图所示，是搜索引擎的一个产品，具体产品形态是当用户输入一个关键词，比如“天气”时，搜索出来的第一个结果是一张卡片，卡片里面有详细的天气相关的信息，同时输入其他关键词，也会得到类似的搜索结果，并且每个卡片的内容样式都是不一样的。
我们是这个产品效果的负责人，但是我们直接负责并开发的是一个后端服务，也就是说，产品最终的效果依赖于很多其他产品线的能力。
http://www.51testing.com/attachments/2021/04/15326825_202104191513513Ua0Q.png
对于这个产品，我们是如何评估监控效果做的怎么样的呢？好，接下来，我会跟你详细讲解。
常见的衡量指标主要有三个：监控召回率、报警准确率、故障召回周期。
1.监控召回率
我们先来看下第一个衡量指标，监控召回率。
在解释监控召回率之前，我先给你讲下什么是“召回”。
举个例子，当我们在搜索框中输入“天气”，如果没有出现预期的天气卡片，那么，我们认为搜索服务肯定出现故障了，这时候，如果事先开发好的监控服务报警了，那么，我们就认为监控召回了该问题，相反，监控服务没有报警，我们是通过人工巡查或者用户反馈的方式发现的该故障，那么，我们就认为监控没有召回这个问题。
那么，假如上述类似的故障出现了M次，其中监控召回了N次，那么监控召回率就是N/M。
因此，监控召回率是指在线上发生的所有的产品故障中，其中有多少故障是通过监控的手段发现的。用公式表示的话，分子是：监控发现的产品故障，分母是：线上发生的所有的产品故障。
监控召回率越高，说明监控做的越好。如果线上发生的所有的产品故障，监控都能够发现，这时候N=M，监控召回率等于100%，这就说明监控做的非常好，但是实际上，召回率很难达到100%，我们在设置目标的时候几乎不会设置召回率100%的目标。
你可能会说，线上出现了多少次故障，我怎么知道？的确，统计这个数字，不是那么容易。
因为，我们平常都在忙自己的工作，不可能时时刻刻去使用产品，大部分时候都是收到用户的反馈或者监控报警了才知道服务出现问题了。
线上发生的所有的产品故障，细分的话，包含两部分：监控发现的问题、人工发现的问题。
监控发现的问题能够很准确的统计到，人工发现的问题就不可能做到很精准了。
通常，为了最大化收集到线上问题，就需要建立良好的人工反馈渠道，并安排人力定期去做用户反馈分析。
2.报警准确率
接下来，我们先来看下第二个衡量指标，报警准确率。
同样的，在介绍报警准确率之前，我先给你介绍下什么是报警。
前面我们提到，监控是这样一种机制，这种机制可以自动监测产品的运行状态，一旦服务故障，就能够主动通知我们，而当服务正常运行的时候，我们可以安心的开展其他工作，这样的话，将会大大降低线上测试的成本。
这里的“通知我们”，就是指的“报警”，准确来讲，报警是指当线上服务出现故障的时候，监控系统以某种形式，比如短信、电话，来提醒我们，服务出现故障了，需要赶紧处理故障。下图所示是邮件报警实例（数据进行脱敏处理）。
http://www.51testing.com/attachments/2021/04/15326825_202104191513514zjvw.png
http://www.51testing.com/attachments/2021/04/15326825_202104191513515R5Di.png
假如报警出现了M次，其中报警准确N次，那么报警准确率就是N/M。
因此，报警准确率是指在监控系统发出的所有报警中，其中有多少条报警是准确的。用公式表示的话，分子是：报警准确的数量，分母是：监控系统发出的所有报警。
报警准确率越高，说明监控做的越好。这时候，我们就会非常信任报警，当报警出现的时候，也会更加积极主动的去分析报警原因。
反之，假如报警准确率越低，我们对报警就失去了信任，当报警再次出现的时候，我们不但不会去积极主动的追查原因，还会觉的这是一种无用的骚扰信息。 这其实是监控工作遇到的常见问题：误报率太高。
实际工作中，想要获得高准确率，低误报率的监控并非易事，原因有很多了，比如：监控升级引入缺陷，监控未及时升级，监控服务本身不稳定等等。
为了尽可能降低误报的影响，可以采取的方法有很多，比如建立监控开发维护机制、架构设计的时候考虑到各种异常处理能力等等。
比如，我们可以建立一种线上测试机制，监控上线后，首先默认是报警关闭的状态，这里请注意，报警开启与关闭可以在GUI界面上自行配置，同时，后台监控服务正常启动，这时候如果出现报警，会默认发送给我们几个监控开发同学，当测试没问题后，直接在GUI界面上，开启报警即可。这样，在不需要手工修改任何报警收件人和代码的情况下，就可以完成线上测试。
下图所示为报警开启与关闭的GUI界面，可以设置整体的关闭、开启按钮，也可以针对不同的业务进行开启关闭（数据进行脱敏处理）。
http://www.51testing.com/attachments/2021/04/15326825_202104191513516ZSh7.png
再比如，正常情况下，我们监控100个关键词的搜索结果，报警阈值是90%，也就是当出现10个关键词搜索失败后，就会触发报警。假如由于抓取或者解析不稳定，导致最终只有20个有效关键词监控，这时候，假如出现2个关键词搜索失败后，就会触发报警，显然，很大程度上，这属于误报。
为了规避掉这种情况导致的误报，我们设置了有效关键词最小量策略，当低于这个数量时，即使触发报警阈值，仍然不会触发报警逻辑。
下图是有效关键词最小量策略的代码实现：在发送报警的时候，除了判断是否触发阈值，还会判断是否满足关键词最小量策略。
http://www.51testing.com/attachments/2021/04/15326825_202104191513517Qqzw.png
http://www.51testing.com/attachments/2021/04/15326825_202104191513518e0Uz.png
总之，监控系统的目标是要么不报警，只要报警就一定是真正发生了服务故障。下图是一个实际的召回率、准确率变化趋势图，正确情况下，我们很难做到监控的召回率、准确率均达到100%，但是整体来看一定是逐渐提升的一个状态。
http://www.51testing.com/attachments/2021/04/15326825_2021041915135191SlE.png
3.故障召回周期
最后，我们来看下第三个衡量指标，故障召回周期。
为了方便你理解，这里我举个例子，假如一个线上服务故障：用户在搜索框中输入“天气”，没有出现天气卡片，这个故障在1个月前就已经发生了，但是监控系统在1个月后才发现这个问题，那么故障召回周期就是1个月。
虽然故障也最终被监控召回，但是这个故障已经在线上持续了1个月，已经给用户带来了严重的用户体验损失。这时候监控效果其实是大打折扣的。
因此，故障召回周期是指故障发生后，经过多长时间，才被监控召回。
故障召回周期越短，产生的用户体验损失越低。理想的情况是，当故障发生后，监控就能立即召回，在实际工作中，考虑到监控成本，最快的故障召回周期一般也就是分钟级。
好了，到这里，三个衡量指标就讲解完了。
页:
[1]
