无人值守时代，运维怎样保障发布质量？

　　无人值守时代，运维怎样保障发布质量？

　　无人值守发布的时侯须要应用接入到无人值守发布系统，当然大部分情况下这是一个自动化的过程，系统会判定应用是否符合接入标准，如果符合，会手动接入，但是也有一些情况会导致应用难以手动接入，这种情况下，也会告知用户当前应用是否接入了，如果未接入，需要做一些配置或则改建来接入。

　　无人值守发布详情

　　

　　这个是无人值守发布信息展示的详情页面，在这个里面，可以看见愈发明细的一些信息，比如异常数目的发布前后趋势对比，业务监控各个指标的变化情况等。通过这个页面，开发的朋友基本上有足够的信息来判定本次拦截是否有效，是否须要进行回滚等操作。

　　无人值守接入

　　

　　这个是应用接入无人值守发布的一个页面，主要须要配置业务监控指标、日志路径等。

　　无人值守的实战案例

　　

　　这是一个典型的案例，其中一些数据做了隐藏或则处理。发布过程中日志中某个异常出现了大幅度下降，我们可以从左边看见异常的数目，点击异常信息还可以见到愈发明晰的异常堆栈信息，右侧可以见到异常数目出现了显著降低，下面可以看见这个测量被用户判定为确实有问题，最终执行了关掉发布单进行回滚的操作。

　　用户反馈

　　

　　这些是用户的一些反馈。应用接入无人值守发布，对提高发布的稳定性起了立竿见影的疗效。

　　指标

　　上面这种案例都代表了一部分用户的体会和反馈，那么整体疗效怎么样，还是要拿数据来说话。

　　

　　业界对于异常检查这块有两个主要的指标：一个是召回率，一个是准确率。

　　召回率主要拿来反映漏报的情况，准确率主要拿来反馈误报的情况。漏报和误报的概念比较好理解。漏报就是原本有10个故障，系统报了9个，那么漏报了1个，召回率是90%，误报就是只有10个故障，报了20个下来，多下来的10个就属于误报，那么准确率就是50%。

　　目前准确率方面，我们早已做到了60%左右，也就是说差不多每报2次，就有一次确实是有问题的，这种体验应当算还不错。

　　召回率方面，我们早已做到了90%，这个90%是指出现了一次故障我们没有报下来，我们有效拦截了9次，这9次中可能会导致故障，也可能只是有问题，但是不会导致故障，但是由于及时发觉了，都没有导致故障，很难明晰说这9次上面究竟有多少是会导致故障的，所以估算召回率的时侯没有单独估算故障的召回率，而是把故障和异常一起估算进去了。

　　关于先重点抓那个指标，我们也经历过一些坎坷。一开始的目标是拦截尽可能多的故障，所以比较重视召回率，导致常年一段时间内，准确率太低，拦是拦了不少，但是误报相当多，报10次上面可能只有一次是有效的，如果我们是用户，可能几次误报之后，就对这个产品丧失信心了，这个造成我们不敢大面积推广。后来调整策略，优先解决准确率的问题，反正没我们系统之前这种故障也是存在，有了系统，能降低一些就是好的，所以先不追求召回率，把准确率做起来后，可以大面积进行推广了，受益面大了，避免的故障也自然多了。当然，后面还是继续抓了召回率的。

　　无人值守发布实现

　　前面说了不少，但是都没有提及系统的具体实现，接下来我们看是如何去实现无人值守发布的？

　　首先看下我们的产品分层和业务流程。

　　产品构架和业务流程

　　

　　我们的系统大致分了三层，最前面一层是发布系统层，我们的产品叫海狼，主要是发布单的递交、执行以及无人值守信息的展示和反馈，这一层是可以扩充的，除了发布系统外，也可以对接其他的一些变更系统。

　　中间是无人值守的核心系统，根据搜集到的剖析任务，采集对应的数据，进行剖析检查。

　　最下边一层是离线剖析层，主要拿来做一些算法的训练、回放验证等，后面再具体介绍。

　　

　　大致的业务过程是，用户在发布系统中递交了一个发布计划，这个时侯会通过Normandy(诺曼底)这个平台进行发布(海狼是诺曼底平台的一部分，负责发布的执行)，海狼开始执行发布单后，无人值守系统都会收到发布单执行的风波，然后开始剖析，分析的时侯会借助离线算下来的一些特点集，然后和当前的指标进行比较测量，如果有异常，那么会通过海狼的插口进行暂停发布单的操作，用户可以在发布单页面见到对应信息，然后进行一些判别后递交反馈，是有效拦截，还是误报等。

　　两个阶段

　　上述是一个大致的过程，具体实现方面，我们经过了两个大的版本迭代，下面针对两个版本分别介绍下。

　　1.0实现

　　

　　通过上面的介绍，应该大致了解，无人值守发布就是剖析发布过程中各类指标数据，来判定发布是否有异常，那么具体有什么指标数据可以拿来剖析呢？大致总结了下，有以下几类：

　　首先是业务指标，这个最直接反应当前发布有没有问题，如果影响到了业务，那么基本上就是有问题的。如果业务指标才能覆盖所有的故障场景，那么理论上只要剖析业务指标就行了，但是现实常常是好多业务指标的建立都跟不上业务发展的，业务起来了，指标还没上，这是太现实的事情。

　　其次是一些基础指标，例如机器的显存使用情况，cpu使用率，load情况，磁盘io等，这些指标通常在发布过程中不太会发生显著的变化，但是一旦发生了显著变化，就可能有问题了。

　　还有些中间件的指标，阿里内部广泛使用的hsf、tair、metaq等，都有相应的qps、rt、成功率等指标，如果发布后成功率忽然涨的比较显著或则qps涨0等，那么也很有可能是有问题了。

　　还有一个比较关键的是日志，阿里比较多的应用是java的，我们会在日志中把一些异常的堆栈信息都复印下来，这些异常信息反映了代码运行过程中的一个不正常状态，所以是一个太宝贵的指标数据。通过剖析这种异常的出现情况、涨幅情况、或者是否出现了一些常见的容易导致故障的异常，例如ClassNotFound等，我们可以作出足够有用的判别。

　　指标和算法选定

　　指标这么多，我们一开始应当从哪入手呢？

　　第一个版本的时侯，我们选择了基础监控和日志这两方面入手。原因比较简单，基础监控的覆盖率够高，有足够多的数据可以使我们剖析，而日志依据经验则十分重要。至于业务监控和中间件指标，由于数据方面等一些问题，第一个版本我们没有去考虑。

　　那如何对基础监控和日志的指标进行剖析呢？我们采用的是使用一些简单的规则加上复杂的算法共用的方法，针对一些情况，例如出现了上面提及的危险异常等，采用规则的形式，直接进行拦截，针对异常的升幅变化等，则采用算法来衡量这个跌幅是否在合理范围内。

　　如何实现

　　确定好了指标和剖析思路，我们再瞧瞧须要做什么事情。首先要做的是数据采集，我们面临的问题是须要采集哪些数据，怎么尽早地采集这些数据。其次是对数据进行处理，原创的数据中会有一些干扰的数据，干扰的来源可能是多方面的，可能是数据采集系统本身的问题，也可能是与业务自身的特性有关，需要把这种干扰的数据才能剔除掉。然后就是针对采集和处理后的那些数据，制定什么样的规则，使用什么样的算法，来对它们进行剖析，尽可能确切的判别出发布后的数据是否有问题。

　　数据怎么采集

　　首先我们来瞧瞧数据如何采集？

　　采集之前，先明晰测量的大致思路：发布前和发布后的指标进行对比，已发布和未发布的机器进行对比。所以，我们要采集的是时间序列的数据，也就是每位时间点某个指标是什么样的一个数据，例如某个时间点，系统的load是多少，某个时间点，某类异常出现了多少次等。

　　具体要采集哪些指标，上面早已明晰了，只要把这种指标再做一个剖析，把最重要最能反映故障情况的一些指标选购下来，采集过来就行。

　　而从什么机器上采集指标呢？前面提及，我们测量思路中有一条是已发布和未发布的机器进行对比，所以我们为每位应用设置了两组机器，一个是发布组，一个是参照组，只采集这两组机器的数据，而不是所有机器的数据都采集。至于采集时间，也不用采集所有数据，只要采集发布前后一段时间内的数据就可以。

　　采集到数据之后，接下来就须要对数据进行一些处理，除了上面提及的一些干扰数据剔除外，我们还须要进行一些维度的聚合，因为领到的是一些单机数据，所以须要针对已发布未发布等一些维度进行数据聚合合并，最终生成了可以剖析的数据。

　　数据剖析方式

　　数据剖析的方式，我们采用的是改进型的funnel测量模型，它有这种优点：可以满足针对不同的指标，采用不同的算法的需求，不同的指标有各自的特性，使用同一个算法其实不大合适；其次它的估算须要的资源少，同时测量的速率又够快，还支持好多指标一起剖析。

　　

　　通过上述这种工作，我们大致就把一个测量系统构建run上去了，这第一个版本在准确率方面表现不是挺好，离线跑的时侯才能有30%、40%，但是线上实际跑的时侯只有10%上下的准确率，所以我们须要去提高准确率，那如何提高呢？

　　答案是不断的剖析误报和漏报数据，然后对算法做一些微调。不停的微调算法又带来了一个新的问题，针对那些误报的数据，可能新的算法不会报下来了，但是之前的这些没报的数据呢，用新的算法会不会又报下来了？之前这些报下来的有效拦截，会不会新的算法中就不报下来了？

　　于是我们又搭建了之前产品构架中提及的离线回放系统，用来对算法进行回放验证，从之前的误报、有效拦截、未拦截等数据中抽取部份数据，每次算法调整后，通过回放系统对这种数据重新进行测量剖析，看看准确率和召回率是如何变化的，误报的是否还在误报，有效拦截的是否漏报了等等。

　　无人值守回放系统

　　

　　整个无人值守回放系统大致过程如下：录制模块会将线上检查过的发布单的相关数据录制到回放db，然后须要回放的时侯，通过回放触发插口，触发无人值守进行检查，检测时侯会调用回放系统提供的指标mock插口，从回放db获取数据，而不是从实际的数据源获取数据，将回放检查的结果进行保存，产出回放结果报表。

　　算法的窘境

　　通过无人值守回放系统，我们构建了可靠的算法验证机制，通过不断的微调算法来提高召回率和准确率。但是，还是遇见了一些问题。

　　首先是须要不断的去剖析检查数据，然后调整算法，这个过程是相当花费精力的，并且不一定就能有相应的回报。还有很重要的一点是，在实践过程中，我们发觉一些显著的误报信息在重复的误报。

　　所以我们须要去探求一个才能解决这种问题的方案。于是，第二个版本，我们就采用了基于机器学习的形式在原先的基础上做了一些改进。

　　机器学习的大约过程

　　

　　首先会有一个离线学习的过程，通过一些历史的发布单的指标数据和拦截数据，以及用户反馈的一些数据，计算下来应用发布时侯的一个特点库，发布的时侯，会首先采用一些算法来测量出可疑指标，然后对可疑指标和特点库进行比较，如果发觉这个可疑指标落在正常的特点库里，那么忽视掉，否则，就觉得发布出现了异常进行拦截，拦截完成后，会依据发布单最终的结果和用户的反馈行为将此次拦截是否有效等数据保存上去，作为上次离线估算的一个输入数据。

　　三大要素

　　机器学习也面临几个问题须要去解决，首先是去学习什么样的数据，其次是要通过什么样的方式去学习产出什么样的结果，还有一个就是怎么样把这个学习的结果用到前面的发布监测中去。

　　样本

　　我们首先看下样本问题，就是学哪些数据。我们有的数据大致有这种：发布单数据、发布过程中的指标数据、拦截是否有效的数据、用户反馈的一些数据。

　　这些数据看起来好多，每天的发布单有好几万，每个发布单又有大量的指标数据，但是实际上，每个应用的特点都是不一样的，所以学习的时侯一定是基于应用的维度去学习的，而每位应用的发布数据就极少了，如何从这不多的数据去估算应用的发布特点呢？

　　计算的思路也有两个，一个是算异常的，比较自然的看法，找出异常的特点，下次假如匹配了异常特点，那么就可以判定发布有问题，一个是算正常的，而应用维度异常的发布常常远多于正常发布，甚至可能都从来没有过异常发布，所以基于异常的维度去估算，也不大靠谱，相对比较靠谱点的，只能是通过正常的发布单数据去估算出应用发布的正常发布特点。

　　样本中的一个挑战是怎样来判定一个发布真正是有问题的，我们采取的是发布单行为和用户反馈相结合的形式，如果发布单被回滚了，那么就觉得是异常的，如果用户反馈说有异常，那么也觉得是异常的。

　　关键和不靠谱是拿来描述用户反馈数据的两个特性的，关键是指用户反馈数据十分重要，是最就能帮助我们去了解应用的各个指标对异常检查是否有帮助的，但是用户反馈数据又具有主观性，发布过程中出现了某个异常，A开发朋友可能会反馈觉得没有问题，而B朋友比较慎重可能还会反馈觉得确实是有问题，如何去平衡这两个特征也是比较棘手的。

　　

　　这个就是刚刚提及的用户反馈数据，通过这个反馈数据，我们可以明晰的晓得某个指标尽管异常了，但是对这个应用来说，可能是完全没有用的，根本不需要作为测量的根据，那么上次测量的时侯就可以忽视掉该指标。

　　这个反馈数据的采集看似很容易，但是据我所知，在不少公司里，采集这个数据阻力都是比较大的，开发朋友不乐意去填写反馈这种信息，比较辛运的是，我们通过一系列方法优化，尽可能地降低这个反馈对开发的干扰，把这个反馈给强制开启来了，采集到的数据对我们的帮助确实相当大。

　　算法

　　样本数据有了，接下来就要按照样本数据估算出应用的发布特点了，我们采用的是简单的分类的方式，最初的看法是分成正常、异常、未分类三大类，正常比较好理解，异常是指每次出现就会造成故障的，未分类则是一些新增的或则之前出现过没有变化的一些指标，后面考虑到前面说的异常样本特别小的问题，就把这三类统一成一类了，就是只估算应用发布时侯各个指标的一个正常阀值，如果上次发布的时侯，指标的值超过了这个阀值，那么可能就是有问题。

　　具体学习的过程比较简单，总结上去一句话就是：找到正常发布单中指标的最大值，作为应用的正常指标阀值。具体过程是：首先是发布过程中若果出现了异常指标，那么会去看此次发布最终是否是有问题的发布(通过发布单的行为是否回滚以及用户的反馈等)，如果是正常发布，那么和之前的正常阀值进行比较，如果比之前的正常阀值要小，那么忽视，如果比之前的阀值大，那么就更新正常阀值，而假如此次发布是异常发布，那么理论上应当去判定此次的指标是否比正常阀值小，如果小，那么要更新正常阀值，但是实际上，这次发布的问题可能并不一定是这个指标引发的，而且假如确实是这个指标引发的话，那么之前指标比这个值更大的发布应当也是异常的，考虑到这两点，我们现阶段采取的是忽视异常发布单的形式，只针对正常的发布单进行阀值估算。

　　指标使用

　　正常阀值的使用也比较简单。发布过程中，如果发觉了异常指标，那么会找到该指标对应的正常阀值做比较，如果大于正常阀值，那么忽视掉，如果超过了正常阀值，那么作为可疑指标，在一个窗口期内进行多轮检查，窗口期会依据测量的结果做一些动态调整，如果在窗口期内多次被判断为可疑指标，并且达到了一定比列，那么最终会被判断为异常指标，对发布进行拦截。

　　整个机器学习的改进过程大致就是这样，通过这个改进，我们一方面解决了之前碰到的一些问题，提升了召回率和准确率，尤其是准确率方面有了明显提高。另外一方面，也释放了大量精力下来，可以更好的优化这个学习的算法。

　　原文链接