网站建设有什么专业术语,wordpress新闻列表如何制作,wordpress首页是哪个,如何做响应式网站设计摘要#xff1a; 阿里巴巴千亿交易背后#xff0c;如何尽量避免发布故障#xff1f;在面对实际运维过程中遇到的问题该如何解决#xff1f;近日#xff0c;在刚刚结束的 GOPS深圳站大会上#xff0c;阿里巴巴运维技术专家少荃#xff0c;给我们带来了解决方案和思路。前…摘要 阿里巴巴千亿交易背后如何尽量避免发布故障在面对实际运维过程中遇到的问题该如何解决近日在刚刚结束的 GOPS·深圳站大会上阿里巴巴运维技术专家少荃给我们带来了解决方案和思路。
前言近几年我们在发布效率和稳定性方面做了不少工作其中效率简单的说就是发布耗时一个是发布的速度比如一个应用是1个小时发布完成还是5分钟发布完成另一个是人员介入开发在发布过程中是否需要介入处理各种发布过程中出现的问题这两者都做好了才能说是发布效率提升了。稳定性最基础的是系统的稳定性保障系统的可用而最关键的是要保障通过系统来进行发布的应用的稳定性不会因为发布而导致服务不可用等故障出现。效率这块我们在集团内比较受好评的产品是SP2P的文件分发系统叫做蜻蜓我们根据阿里自身的一些特点实现了一套安全高效的P2P分发同时在P2P的协议上引入了超级节点就是S提升了P2P网络的启动速度目前已经开源。稳定性这块我们去年做了一个产品叫做无人值守发布对发布进行检测看看发布是否会引起问题来提升发布的可靠性今天就和大家一起交流下这方面的心得。线上发布之痛我们为什么要在稳定性方面投入大量精力呢先让我们来看一个笑话。变更故障这个笑话可能没那么好笑但是它真真切切的说明了一个问题理想和现实的差异你以为是有四个单身狗陪你但是实际却是另外两对情侣。这个和我们做生产环境的发布是一样的我们以为凭借我们出色的逻辑思维能力已经把所有场景都想到了测试也做的很充分了但是发布上线后经常会遇到实际结果和预期不一致故障发生了。我们针对阿里的故障产生原因做了统计其中很大一部分都是线上变更引起的相信在座各位也会遇到或者制造过故障开发和运维的同学对故障都是很敬畏的。故障大家都遇到过但是故障的影响差异会比较大。有些故障可能是故障发现后处理了一会就恢复了有些故障则可能会导致严重的后果。所以我们需要尽量避免变更带来的故障。业务挑战阿里的特殊业务场景回到阿里我们都知道去年双11的成交额已经达到了1682亿想象下这么大的交易额下如果出现了故障那会怎么样阿里现在的业务多样化发展新零售、线下支付等一些新的业务场景要求我们对故障更加敏感要能够更好地避免故障更快地发现和处理故障。想一下如果是线下场景比如用支付宝坐地铁如果出现几分钟的服务不可用那会怎么样如何才能有效的避免故障发生呢那么如何才能在发布的时候有效的避免故障发生呢靠“蒙”大家知道肯定不行。可是细想一下很多时候确实或多或少在“蒙”。我个人是有过类似感受的。我们虽然不会随便到不经过测试就进行线上发布但是虽然已经经过了多轮测试肯定还是没有办法覆盖线上各种复杂多样的场景的而这些没有办法覆盖的场景就只能靠运气去蒙了运气好的这些场景没有问题运气不好刚好就其中一个场景出问题出现故障了。通常来讲为了尽可能不要去“蒙”我们会对上线流程加入各种验证环节来保证发布尽可能可靠。例如发布前我们会通过各种测试来验证功能是否ok包括单元测试、集成测试等发布过程中我们会通过一些发布策略例如先预发(预发布是一种特殊的线上环境和线上使用同样的资源比如数据库等但是不会有用户流量进来)、然后灰度、然后分批滚动发布等方式逐步将变更更新到线上发布完成后又会借助一些故障预警系统例如像阿里有GOC来尽早的发现故障进行处理这些环节的这些手段都已经有成熟的系统来进行支持但是发布的时候我们常常还是心里没有底。人工智能的解决方案那么还有什么办法能够帮助我们尽可能地保障发布质量呢大家可能都已经在做了就是人工智能的发布保障。在发布过程中盯着各种屏幕去看各种数据来人肉的判断本次发布有没有问题。在阿里这些屏幕包括监控、发布单、机器、GOC故障预警等。监控能够反映出来当前系统的一些状况例如机器的负载是否上去了接口的成功率是否下降了发布单则能让我们了解当前的发布情况有多少机器已经更新到新版本了有多少还在跑旧版本有多少机器启动又遇到异常了等等盯着机器则可以看一些日志信息是否有一些新的异常出现了异常的量是否很大等等GOC让我们在故障发生的第一时间就能知道结合自己发布的内容判断是否是本次发布引起需要进行处理。这种方式相比之前让人放心多了是因为现在我们看到的是最真实的线上环境的情况而不是单单的测试数据。但是这种人肉盯屏的方式也存在着很大的问题首先是成本太高了发布过程中需要有熟练工盯着各种屏幕去看片刻不离其次是人的因素太大了同样的发布情况不同的人分析出来的结果可能完全是不一样的即使是同一个人因为状态或者其他方面的原因针对同样的一些数据可能分析出来的结果也不一样另外人也有局限性各种数据刷新很快肉眼分析的方式根本都来不及看。既然这种盯屏的方式被证明是有效的但是存在一些问题那么我们就考虑通过系统化来解决这些问题所以就有了无人值守发布。无人值守发布无人值守发布主要是把上述过程自动化、智能化。通过自动化采集这些实时的线上核心数据进行智能化分析迅速对发布状况进行判断是否有故障发生有的话则立即终止当前发布。无人值守发布的两大核心能力一个是故障检测一个是异常推荐。故障检测主要是发现现在的问题。异常推荐主要是防范于未然是指发布出现了问题但是不一定会引起故障这些异常给开发的同学透明出来需要开发注意比较常见的是出现了一些异常这些异常从绝对数量或者涨幅来看没有非常明显但可能是需要处理的。什么是无人值守发布首先是发布单详情页面中的无人值守信息展示发布单详情页面是发布过程中最常会去看的页面所以我们选择把无人值守检测出来的一些信息展示到这个页面在一个页面中把可以做的事情都做掉。当然并不是说开发同学一定要自己去刷这个页面才能够知道当前发布是否有异常当发布出现异常的情况下系统会先自动暂停当前的发布然后通过钉钉等一些通知方式告知开发的同学你的某个发布出现了异常需要你去看下。这些展示的信息包括了左侧的当前发布是否有异常的概要信息通过概要信息可以知道当前发布有没有问题如果有问题可以看右侧的问题分类是基础监控指标出问题了还是业务指标出问题了或者是日志出问题了日志出问题具体是哪个日志有问题了在这里都可以看到。如果这里的信息还不够来判断是否发布有问题那么点击查看详情可以看到更加详细明确的异常信息来进行判断。无人值守发布的时候需要应用接入到无人值守发布系统当然大部分情况下这是一个自动化的过程系统会判断应用是否符合接入标准如果符合会自动接入但是也有一些情况会导致应用无法自动接入这种情况下也会告知用户当前应用是否接入了如果未接入需要做一些配置或者改造来接入。无人值守发布详情这个是无人值守发布信息展示的详情页面在这个上面可以看到更加明细的一些信息比如异常数量的发布前后趋势对比业务监控各个指标的变化情况等。通过这个页面开发的同学基本上有足够的信息来判断本次拦截是否有效是否需要进行回滚等操作。无人值守接入这个是应用接入无人值守发布的一个页面主要需要配置业务监控指标、日志路径等。无人值守的实战案例这是一个典型的案例其中一些数据做了隐藏或者处理。发布过程中日志中某个异常出现了大幅度增长我们可以从左侧看到异常的数量点击异常信息还可以看到更加明确的异常堆栈信息右侧可以看到异常数量出现了明显增加下面可以看到这个检测被用户判断为确实有问题最终执行了关闭发布单进行回滚的操作。用户反馈这些是用户的一些反馈。应用接入无人值守发布对提升发布的稳定性起了立竿见影的效果。指标上面这些案例都代表了一部分用户的感受和反馈那么整体效果怎么样还是要拿数据来说话。业界对于异常检测这块有两个主要的指标一个是召回率一个是准确率。召回率主要用来反映漏报的情况准确率主要用来反馈误报的情况。漏报和误报的概念比较好理解。漏报就是本来有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同学比较谨慎可能就会反馈认为确实是有问题如何去平衡这两个特点也是比较棘手的。这个就是刚才提到的用户反馈数据通过这个反馈数据我们可以明确的知道某个指标虽然异常了但是对这个应用来说可能是完全没有用的根本不需要作为检测的依据那么下次检测的时候就可以忽略掉该指标。这个反馈数据的采集看似很容易但是据我所知在不少公司里采集这个数据阻力都是比较大的开发同学不愿意去填写反馈这些信息比较幸运的是我们通过一系列方式优化尽可能地减少这个反馈对开发的干扰把这个反馈给强制开启来了采集到的数据对我们的帮助确实相当大。算法样本数据有了接下来就要根据样本数据计算出应用的发布特征了我们采用的是简单的分类的方法最初的想法是分成正常、异常、未分类三大类正常比较好理解异常是指每次出现都会导致故障的未分类则是一些新增的或者之前出现过没有变化的一些指标后面考虑到上面说的异常样本非常小的问题就把这三类统一成一类了就是只计算应用发布时候各个指标的一个正常阈值如果下次发布的时候指标的值超过了这个阈值那么可能就是有问题。具体学习的过程比较简单总结起来一句话就是找到正常发布单中指标的最大值作为应用的正常指标阈值。具体过程是首先是发布过程中如果出现了异常指标那么会去看这次发布最终是否是有问题的发布(通过发布单的行为是否回滚以及用户的反馈等)如果是正常发布那么和之前的正常阈值进行比较如果比之前的正常阈值要小那么忽略如果比之前的阈值大那么就更新正常阈值而如果这次发布是异常发布那么理论上应该去判断这次的指标是否比正常阈值小如果小那么要更新正常阈值但是实际上这次发布的问题可能并不一定是这个指标引起的而且如果确实是这个指标引起的话那么之前指标比这个值更大的发布应该也是异常的考虑到这两点我们现阶段采取的是忽略异常发布单的方式只针对正常的发布单进行阈值计算。指标使用正常阈值的使用也比较简单。发布过程中如果发现了异常指标那么会找到该指标对应的正常阈值做比较如果小于正常阈值那么忽略掉如果超过了正常阈值那么作为可疑指标在一个窗口期内进行多轮检测窗口期会根据检测的结果做一些动态调整如果在窗口期内多次被判定为可疑指标并且达到了一定比例那么最终会被判定为异常指标对发布进行拦截。整个机器学习的改进过程大致就是这样通过这个改进我们一方面解决了之前遇到的一些问题提升了召回率和准确率尤其是准确率方面有了显著提升。另外一方面也释放了大量精力出来可以更好的优化这个学习的算法。GOPS 2018 深圳站精彩PPT持续更新中链接: https://pan.baidu.com/s/1zgOGm7CabpO6lIquNVcNkg 密码: sp76另一位阿里技术专家即将出现在 6月的北京6.29-30 DevOps 国际峰会将在北京与您见面DOIS 大会为您呈现互联网公司与海外企业的实践经验与工具技术聚焦 DevOps 在金融、通信、零售等行业的系统性实践不空谈不务虚专注 DevOps 落地原文发布时间为2018-04-20本文作者陆叶平少荃原文链接干货好文请关注扫描以下二维码
