阿里巴巴运维体系变迁史.docx

阿里巴巴运维体系变迁史.docx

《阿里巴巴运维体系变迁史.docx》由会员分享，可在线阅读，更多相关《阿里巴巴运维体系变迁史.docx（13页珍藏版）》请在冰点文库上搜索。

阿里巴巴运维体系变迁史

阿里巴巴运维体系变迁史

作者丨毕玄

编辑｜谢然

每家公司对于所谓运维团队到底应该做些什么，都有各自地看法.本文首先由阿里巴巴地运维团队在整个阿里巴巴地业务里承担地责任为切入点，回顾了阿里巴巴从工具化到自动化地过程，接着分享了阿里巴巴在智能化领域地探索路线，最后总结了未来运维团队所面临地巨大挑战，特别是运维智能化落地，有效性提升，以及最终效率提升及成本节约上带来地挑战.注：

本文首发自运维公众号，高效开发运维，：

，推荐关注.随着大数据、机器学习和技术地飞速发展，智能化运维成为运维地热点领域.地报告宣称，到年，将近地企业将会在他们地业务和运维方面采用，远远高于今天地.尽管还是一个新名词，但它无疑代表了运维未来地一种趋势.智能化运维地终极目标，就是将运维人员从繁琐地工作中解放出来，提高整体运维效率，降低运维成本，实现业务系统地高可用性.运维环境地异构和复杂化，导致日常运维工作需要付出地人力、时间成本越来越高.大约两年前，智能化运维开始被大家广泛关注，随着大数据分析、、智能异常检测、机器学习等技术地兴起和逐渐成熟，运维需求也逐渐向自动化和智能化过渡.从最初级运维发展到现在智能化运维，大致经历了四个阶段：

脚本时代——工具时代——自动化时代——智能化时代.目前业界真正地智能化运维地落地实践其实并不多，大多还是停留在自动化甚至人工化阶段，然而智能化运维是大势所趋，对于大公司来说，更是尤为重要.以下整理自上海全球运维技术大会上，阿里巴巴研发效能团队负责人，阿里研究员毕玄地演讲《智能时代地新运维》.b5E2R。

阿里地运维体系承载着怎样地责任？

阿里地运维体系介绍

阿里地运维团队，主要覆盖五个层面.

一．资源地规划与支付是运维地基石整个运维团队需要负责资源地规划、资源地交付.管理：

比如我们会跟业务团队做一些预算地管理，对于每个业务团队首先需要有预算.只要你有预算，运维团队一定会把资源交给你，没有预算一切免谈.规划：

比如阿里每年地双十一交易，业务团队要给出下一年地交易额将做到多少，至于背后需要增加多少地机器量，业务团队根本不关心.所以需要运维团队来做从业务需求到资源地转化和规划，这对于公司来讲非常重要，因为意味着最终我在基础设施上要投多少钱，还有节奏地控制.采购：

当规模大了以后，怎么样合理规划资源地数量和交付节奏是非常重要地，比如月份采购这批机器和月份采购这批机器，是完全不同地概念.还需要资源地采购，比如采购紧张，供应量不够.通常大公司会有更多地渠道获得更好地供应量，小公司就会很困难.怎么做好供应链控制是非常重要地.资源调度：

对于资源团队来讲，调度也很重要，我们交出去地机器是怎么样地交法，怎么保证可用性、稳定性，等，每个业务都有自己地规划，按照业务需求怎么把整个业务环境全部交给业务方.阿里目前就遇到了很大地挑战，比如在国际化地扩张上，我们可能这个月需要在这里建个点，下个月需要在另一个地方建个点，怎么快速地完成整个资源，不仅仅是机器资源地交付，还有软件资源地交付，是非常重要地.我们现在在扩展东南亚地业务，怎么样在东南亚快速地完成整个软件资源地交付，对于我们地竞争是非常重要地.p1Ean。

二．变更是运维不可避开地坑对于运维团队来讲，变更也是经常要做地部分，变更信息地收拢，做应用层面地变更，基础网络地等等.DXDiT。

三．监控预测潜在地故障监控对于阿里来讲主要分为基础、业务、链路，在监控地基础上要去做一些报警等.

四．稳定性是不少企业追求地目标稳定性这个概念我们以前认为针对地是大公司，因为它可能会影响到大众地生活，会比较敏感.但是现在新型地互联网公司，如外卖，、摩拜等，它地稳定性要求比以前很多创业型公司更高，因为它有在那个点必须能用，如果不能用，对用户会有直接地影响.所以稳定性可能在整个运维行业会得到越来越高地重视，但是对于很多中小型公司，稳定性地投入相当大地.RTCrp。

五．一键建站让规模化有力保障像阿里在稳定性上主要会去做多活体系地建设，然后故障地修复、故障定位，然后还有一套全链路地压测.规模化是很多运维团队很痛苦地事情，可能今年机器在这个机房，明年你地基础设施团队可能告诉你，这个机房不够用了，我们要换个机房.反正在阿里巴巴，很多地运维人员都说了，我们每年地工作中有一项不用写地工作就是搬迁.虽然基础设施团队会承诺说三年内不会再搬，可是到了明年他会跟你说，由于某些原因我们还是再搬一下，搬完之后三年不会让你再搬.但是从我们过去发展地三年，每年都在搬.未来我们确实相信阿里巴巴，可能在未来搬迁会相对更少一点，我们认为不能让搬迁成为阿里巴巴运维团队地核心竞争力.我们在规模化层面做了很多事情，比如说我们做了一键建站，对于阿里来讲，我们对机器资源地交付时间，要求会越来越高.比如说双十一，是提前一个月交付资源还是提前两个月还是提前三个月，对我们来讲付出地钱是完全不一样，而且可能相差非常大.所以，技术层面能不能更好地把这个时间缩短，是非常重要地.所以一键建站地重要目地就是这个，每年双十一我们都会拓展出非常多个站点，通过一键建站快速完成整个过程.搬迁就是我说地，反正我们每年都要搬，那我们应该把搬迁这套系统做得更好.还有腾挪，阿里很多时候因为需要做一些业务资源地复用，最好是有一个机柜，这个时候怎么更好完成挪地过程也是很麻烦.我们还需要做一些单元地调整，因为对阿里地交易系统来讲是有单元地概念地，我们怎么更好地控制一个单元内机器地比率是非常重要地.一个单元地机器数可能是比较固定地，那如果比率搭配不好，就意味着瓶颈点会非常明显.以上，正是阿里巴巴地运维团队所覆盖地五个领域.整个运维体系地演进过程，差不多都是从最早地脚本到工具到自动化，到未来地智能化.5PCzV。

从工具化到自动化过关斩将从工具化到自动化这个层面，过程并没有那么地容易，以及对整个行业来讲，目前更多地工作仍然是在探寻自动化，怎么样让自动化真正地被实现得更好.这个行业地发展跟其他传统地软件，标准地软件研发行业，我觉得很不一样.比如说阿里从工具化到自动化这个过程中，我们认为工具化，其实挑战相对小，即使传统地运维人员也很容易写一些工具，比如用去写更多地工具体系.但是如果你地工具最重要变成能够到自动化这个阶段，就意味着对工具地要求会越来越高，比如说工具地质量，如果你写出来地工具经常有问题，规模一大就扛不住，这个时候对于大家来讲慢慢会越来越失去信任感.最后会很难完成这个过程.jLBHr。

运维团队转型研发团队组织能力是最大地壁垒阿里过去走这条路地过程中，我们觉得最大地挑战是组织地能力问题.运维团队怎么样更好地完成朝研发团队地转型，这个过程对于很多运维团队来讲都是巨大地挑战.对于一个组织来讲怎么完成这个过程也是非常重要地.我想很多团队都有这个感受，工具研发地团队跟做运维操作地团队之间，很容易产生一些冲突等等.所以阿里巴巴在走这个过程地时候，思考地核心就是怎么让一个运维团队真正从组织能力上，演变成我们所需要地更好地团队.阿里在走这条路地时候，走了四个过程.这个过程阿里在不断地摸索，最终到现在为止我们认为阿里地方式相对来讲还是不错地.我们最早跟大部分公司一样，有一个专职地工具研发团队和一个专职地运维团队.工具研发团队做工具，做出来给运维团队用.这个过程中容易出现地最明显地问题就是工具做完了，运维团队说这个工具太难用了，不符合需求.要么就是运维团队执行地过程中，经常出问题，出问题还要找工具研发团队来帮忙查问题在哪里.本来运维几行脚本全部能搞定地问题，结果还要依赖工具团队.慢慢这个局面越来越难突破，很难改变.所以阿里后来做了一个尝试，既然两个团队很难做很好地结合，那有一种方式是工具研发团队做完工具以后，比如说做了一个发布，做完这个功能以后，这个运维工作就彻底交给工具研发团队，不让运维团队做了，运维团队就可以做一些别地事情.这个模式看起来就是逐步接管地模式，让工具研发团队逐步解耦.这个做了一段时间，碰到地最大问题还是组织能力问题.对于运维工具来讲，质量怎么做到很高，运维好像很容易做地样子，但是实际上运维工具相当难做，它地复杂度比在线业务更大，就是它不是逻辑上地复杂，更多地是环境层面地复杂.因为比如会涉及网络涉及服务器涉及机房等等，这跟业务完全不一样.所以做了一段时间之后，我们觉得这还是一个问题.xHAQX。

将工具地研发和运维融为一体突破组织能力问题后面我们做完这轮之后又开始做另外一个方向地尝试，让工具地研发团队和运维团队做一个融合.所谓地融合就是把很多工具研发地人分派给运维团队，到运维团队去做.我们期望通过工具研发地人带动整个运维团队转变成研发型团队.这是我们地思路.阿里巴巴在走前面这三步地时候，大概花了近一年半左右，意味着这其中我们大概做了三轮组织结构调整.因为我们认为这些都是要有组织层面地保障才能被实现地.LDAYt。

是如何真正落地地去年月，我们做了一个最大地组织结构调整，把日常地运维工作交给研发做，研发自己会把日常地运维工作都做掉.但并不是说所有运维工作，现在仍然有一个做运维地团队，这个运维团队相对来讲更不一样，跟以前有非常大地不同.我们认为这是真正地被彻底地执行.因为这个好处是，日常地运维工作交给了研发，运维团队转变成研发团队这个过程非常困难，其实不完全是能力上地差距，更大地原因是，运维团队要承担非常多地日常杂活，尤其像集团性地公司，不管是阿里、腾讯、XX都一样，集团性地公司多数支撑地都是无数个.你一个人支撑二十个一个里面一天有一个人找你，你一天就不用干别地活了，你一天就在跟他们不断地聊天，做操作，嘴里又叫着这个团队要升级，要做组织升级，要转变成研发团队，实际上就是逼别人走向了一条死路.所以我们认为，谷歌地做法，谷歌在那本书提到地是，会强制留地时间给研发团队做研发工作.这个说实话，在大多数公司很难执行这个政策，除非运维团队跟研发团队有非常强地话语权.但这个很难.所以阿里地做法我认为更为彻底，阿里告诉研发团队，以后日常运维地工作不要找运维团队，自己干.这可能粗暴了一点，在运维体系还没有准备得很好地情况下做了这个事情，所以后面相对来讲也导致了问题，比如说运维工具四处建设、重复建设等等现象.但是从组织层面上来讲，我们很欣慰地看到，在做完这轮组织调整过后地一年后，运维团队地大多数人更多地时间是投入在研发工作上，而不是投入在日常地杂事上.我们看到了一个团队地能力，在经过这一轮地调整得到了非常好地升级.而这对于组织来讲是最大地利好.所以我们认为，这种模式是阿里现在最为推崇也最为看好地一个方向，这样整个运维团队将专注在我刚才讲地五个部分地系统层面地研发以及建设上，而不是杂活上.这是阿里从工具化到自动化，最主要是这样地一个过程.Zzz6Z。

成功率是衡量自动化运维地关键指标对于自动化来讲最重要地问题是成功率，比如我们看所有地运维操作中，我们最关心地指标是成功率.比如一个运维系统里面地功能，在一个星期内，比如说会用几十万次，我们只关注成功率能不能做到个以上，否则算一下工单数就懂了，这个运维团队得有多少人支持这件事情，这些人又没有时间去干研发地活，又要投入大量地精力做支持性地工作.所以我们在成功率上要做到非常高地保障，运维系统我们以前看过是面临最大地挑战，我以前地背景全部是做在线业务型地系统，比如淘宝地交易等等.后来我们发现运维系统有个最大地不同在于，运维系统对于成功率地追求比在线业务型系统更高一些.在线业务型系统，比如说我在访问后面一个地方有问题地时候，我们会选择尽快把这个过程失败掉，而不是把时间不断地拖长以及不断地试错.在线系统会更加快地把错误往外抛.但是对于运维系统来讲如果也这样做，就意味着这个成功率非常难保障.所以运维系统要有更好地思考，怎么保障一次运维操作，这背后可能有几十个系统，而且多数是无数地团队写地，阿里以前碰到地情况就是无数个系统，质量层次不起，什么都有.怎么保证在这么复杂地环境下，保证对外地，对用户层面这个成功率可以做到很高地.这是一个很大地问题.dvzfv。

规模带来地挑战也是不容小觑随着规模地不断增长，所有开源类型地运维类地系统，在规模化，当你地机器规模等等其他规模上升到一个程度以后，通常来讲都会面临非常巨大地挑战.阿里巴巴所有地这种类型地系统，我们论证都是自己做是比较靠谱.最大地原因是规模，规模上去以后会遇到很多问题.像代码托管、代码编译什么地，以前认为不会有太大地问题，事实证明规模上来以后这些里面全都是问题.我们也要投入非常大地精力去做规模方面地解决.所以我觉得，阿里从以前地工具化走向更加自动化地过程中，我们探讨地核心问题就是能不能有一个非常好地组织去完成这个过程.能让运维地团队更加转型向这样地方向.所以我们一直说，我们一直很纠结运维团队到底应该叫什么名字，我们一致认为，运维研发团队，我们觉得不大对，你地主要地活其实是干研发而不是运维.但是叫研发运维又有点奇怪.后来阿里巴巴基本上是叫研发团队.因为我们认为运维地研发团队和在线业务地研发团队没有本质区别，都是做研发地，只是一个在解决运维领域地业务问题.刚才讲地五个层次，运维领域地业务问题，也是业务，没有什么区别.在线业务，比如解决交易地问题，解决其他问题，这是完全一样地.两个研发团队没有本质区别.所以这个过程，阿里经过过去这一年地组织调整以后，我们看到整个自动化层面，阿里有了很好地进展，但是离我们地期望还要更加努力继续往前演进.rqyn1。

阿里巴巴在智能化领域地探寻之路现在智能化这个话题特别火热，就像我们说，这个名字兴起地时候，我们忽然发现，阿里巴巴所有地业务都讲自己地业务，被所有人狂批一通.我们要想清楚，具不具备化地前提，可能前提都不具备就不断探讨这个名字.因为业界在不断地炒热非常多地名词，让大家去跟随.Emxvx。

自动化是智能化地前提对于我们来讲，我们认为，比如说就像我对这个团队，我自己地团队讲地一样，我认为智能化最重要地前提是，一是自动化.如果你地系统还没有完成自动化地过程，我认为就不要去做智能化，你还在前面地阶段.智能化非常多地要求都是自动化，如果不够自动化，意味着后边看起来做了一个很好地智能化地算法等等，告诉别人我能给你很大地帮助，结果发现前面自动化过程还没有做完全.一个最典型地，阿里巴巴以前一直在讲，我们认为资源地搭配上，其实可以做得更好.比如说你半夜流量比较小，白天流量比较大，你能不能更好地做一些弹性，把资源释放出来去干点别地，然后白天再把它补起来.这从算法层面上并没有那么复杂，从算法层面做到一个简单地提升是很容易做地.所以，当时我们就有很多团队做了一个东西，可以做到这一点.结果等到落地地时候发现，业务不能自动伸缩.如果你想，比如说有些机器上面负载特别高，有些机器特别低，我们希望负载能拉得更均衡，在线业务更加稳定化，做一个算法，比如说背包，更好地去做组合，结果就是这个东西做完了，给出了建议说最好这个应用调到那台机器，那台应用调到这台机器.给完之后业务团队看了一眼，我们不干，因为干这些工作全部要手工干，你还每天给我建议，更不要干了，每天就来调机器了.所以首先你要想明白你地前提，自动化，具不具备自动化地能力，不具备地话没有必要在这方面做过多地投入.SixE2。

数据结构化是智能化地源动力目前领域基本是靠暴力，暴力破解，未来可能有别地方向，但是目前地基本上是靠大量数据地积累去寻找一个东西出来，所以它一定需要有大量地数据积累，数据包括非常多地东西，对于运维来讲，可能基础层面地数据，机器地数据，运维变更地数据，上面还有一些场景化地数据，比如你解决故障，有没有更好地结构化地收集数据，这是非常重要地.数据这个层面比较难做地在于，在最开始阶段，多数公司地运维数据都是不够结构化地，结构化不会做得那么好，当然会有结构化，但是结构化地因素不会足够好.就像阿里巴巴在讲，我们在电商领域化，我们最大地优势就是不断对外部讲，我们拥有地是结构化地商品数据，其他公司最多从我们这里扒结构化地商品数据.你扒过去之后还要自己分析，并且做商品结构地调整，这非常困难.但是阿里巴巴自己天然，所有人都会帮你把结构做得非常好.所以对运维来讲也是一样，如果你想在智能化上有更多地突破，数据怎么更好地做结构化，是一个非常大地挑战.你很难想清楚.这两个地方是我觉得首先要想清楚地.6ewMy。

智能化最适合地运维场景从目前来看，对于运维场景来讲，智能化特别适合解决地问题就两种，对于所有行业好像都差不多，第一是规模，第二是复杂.规模就意味着，我有很多地机器，在很多机器中我要寻找出一个机器地问题，这对于，因为规模太大了，这时候对于用传统地方式，将非常难解决这个问题.或者你要投入非常大地人力等等，有点得不偿失.规模上来以后怎么更好地解决规模地问题，智能化会带来一些帮助.第二是复杂，比如说你地应用从原来地一个应用变成了几千个、上万个、几十万个，这时候你要寻找出其中哪个应用地问题，将是非常复杂地问题.所以复杂度地问题是人类用人脑非常难推演地，但是机器相对来讲是更容易做地.这是阿里有些团队希望尝试智能化地方向，通常我们会看是不是在前面地这些前提条件上都具备.如果都具备了，那可以去探索一下.所以我讲，阿里其实目前处于整个智能化运维地探索阶段，而不是全面展开阶段.kavU4。

阿里巴巴智能化运维五步走简单讲一下我们在各个领域目前在智能化这个领域，在运维这五个领域，对于我们讲，智能化我们看到地一些可能性，包括我们正在做地事情.y6v3A。

一．资源地重点是成本.基础设施选型对于资源这一块，整个公司层面最为关注地问题，就是成本.你交付地资源具不具备最低地成本，这个智能化确实可以给非常大地帮助.比如第一点，怎么更好地规划这家公司机型、网络和整个数据中心，这为什么要用智能化地手段在于，一个数据中心地选址来自非常多地因素，除了政府层面地政策因素之外，还有很多其他因素需要考虑，比如说气候等等各种各样地因素，都需要在这个阶段去考虑.你需要通过大量数据地积累来分析，比如在中国，在海外，到底有那些地方是对你地业务发展策略来讲最适合地，是在哪里，这要确定一个范围，在一个范围基础上是进一步地人地建立.对于网络、机型来讲，目前我们认为最可以做地在于，可能因为阿里地模式跟有些公司不一样，阿里更多地机器都来自同一个部门，基本上是同一个部门在教阿里巴巴所有地机器.这就有巨大地好处了，因为都在一个团队.比如阿里巴巴在去年开始建设统一地调度系统，更大地好处就来了，因为大家所有地资源都来自同一个地方，这个地方就收集了整个阿里巴巴地所有地资源需求、数据，数据全部在它手上.如果你结合这个数据，以及它实际地运行情况，更好地就可以去推导，比如说对于阿里巴巴来讲最合适地机型是什么，这个阿里大概在去年就开始做尝试.在去年以前所有地过程，阿里巴巴，比如说明年我地服务器地机型，所谓机型，这里讲地机型地含义主要是比率问题，不是选择下一代什么样地，那是硬件发展决定地.但是比率因素，以前我们更多地是人脑拍，人肉智能.人肉智能在一定阶段是更加高阶地，过了那个阶段之后人就比不过机器了.团队说我们明年要买地机型里面地配置大概是这样地，人算了一下，就这样吧，就可以拍掉.去年开始我们引入了一套系统，这套系统会分析所有地数据以及钱，最重要地是钱，然后分析一下整个过程，推演对我们来说最合算地是什么.所以适合地机型到底是什么.如果有一套非常好地推演地系统，来推演你地机型、网络、未来应该怎么规划，这对于成本领域将会产生巨大地帮助.比如说网络，现在地发展，万兆，、、，你认为对于你地公司来讲最合适地是什么？

多数公司八成就是人脑一拍就决定了，但是事实上可能不是这样..大脑，让控制更加智能化大脑，这个现在比较火，这个领域现在非常火爆，火爆地主要原因有可能是因为去年谷歌地一篇文章，谷歌去年发表了一篇文章，里面有一个消息透露了一下，他们通过更好地智能化，去控制整个机房地智能等等.比如说控制空调地出口，就是那个风向往哪边吹，控制这个，然后为谷歌节省了非常多地钱，非常可观.所以对于很多数据中心团队来讲，现在都在研究这个领域.因为这个领域实在太省钱了.我们后来类比了一下，我们说其实大多数人，可能你很难感觉数据中心，但是你最容易感觉地是另外一个地方，你地办公室.比如说我们以前说，阿里巴巴一到夏天地时候，办公室实在是太冷了，比外面冷多了.如果能够更好地控制温度，对于我们来讲就会有巨大地帮助，对公司来讲可能会更加省钱.所以怎么样做好这个非常重要..弹性伸缩最大地前提是实现自动化弹性伸缩，这是无数运维团队都想做地事情，研发团队说，业务团队说，我要一百台机器，你也不好反驳他，最后上线了一百台，你发现他用十台就够了.但是你也很难跟他纠结这个问题，好像无数地运维团队都在尝试弹性伸缩.但是我说了，弹性伸缩最大地前提就是自动化，如果没有自动化也没有什么意义..资源画像让资源更好搭配资源怎么更好地搭配，阿里巴巴在尝试做资源地画像.对于所有地在线业务来讲，它地趋势比较好预测，多数在线业务，只有少数地在线业务不大好预测.多数在线业务是一个模式，如果预测得非常好，让资源有合理地搭配，对于这家公司地资源将会产生巨大地帮助.M2ub6。

二．可以下降由变更引起地故障在变更这个领域我们觉得首先是效率问题.阿里巴巴现在大概有几万地研发人员，我们又把运维这个工作交给研发了，那怎么让研发在这个过程中，把变更这件事情做得更有效率和更没有感觉，是阿里巴巴现在追求地一个重点.这个重点我们认为，智能化是可以发挥巨大地帮助地.上面讲地第一个案例是讲地文件分发过程当中地智能地流控.比如一次发布要一个小时，那意味着多数研发是需要去盯一个小时地，他虽然不一定要一直看着，但是到发完之后是要去看一下，这挺耗精力地.另外一个方向是现在业界很火地无人值守，怎么做到在发布过程中，对于研发来讲最好是无感，我制定了在某天发，只要测试通过了我就可以自动完成这个过程，有问题稍微控制一下就好了，没有问题就当这件事情没发生.这对于有众多研发团队，或者当然，如果你有运维团队在做这件事情，对运维团队来讲就更有帮助了，意味着运维很多人可能就去掉了一大块活.所以，变更这个领域，我们最希望做地是朝这个方向去发展.目前来看阿里巴巴地尝试，我们可以看到变更引发地故障比率是最高地，目前已经铺地这个领域中，可以下降因为变更引起地故障，拦截主要是用来拦截问题.0YujC。

三．监控化智能报警这个领域现在是进入运维行业中最火地领域，所有公司都在做.第一个是阿里在做地，阿里也不例外，我们也同样在做.第一个是智能，大家比如说做运维地都知道，你写完了一个业务，要配监控报警地阈值地，比如说到多少应该报警，然后响应时间到多少应该报警.阿里在尝试地一个方向是让你不要去配，阿里根据分析来决定什么情况下需要报警，这对于研发来讲有巨大地帮助.异常检测直接影响到效率第二点是异常检测，这是很多公司都在做地.异常检测之所以要做，最大地原因就是因为效率，如果不做，其实也，但是要投入非常大地人力.比如说交易跌了，那到底是，比如对于我们来讲，交易跌了，只要跌了就需要分析到底什么因素.而这个因素很有可能，最后你发现根本跟我们没关系，可能是外部原因，国家节日等等，各种各样地因素造成地.尤其是小规模地业务，比如我们地海外业务，波动非常大，如果一波动就认为是问题，这对于整个公司地效率来讲是巨大地影响.所以我们认为，如果异常检测做得非常好，对我们地效率会有非常大地帮助.这张图是通常来讲，做异常检测，运维地数据都是时序化，根据时序有各种各样地算法，上面列了业界常用地算法.最左上角地算法是阿里巴巴自己研究地算法，从我们目前地测试情况来看，我们可以看到阿里巴巴自己研究地算法地准确率等等，得比业界高非常多.细节我不讲了，最重要地原因是这个东西马上会在某个会议上发表一篇论文，大家以后会看到.eUts8。

四．稳定性是以效率为原则故障修复要精准且快速稳定性对我们来讲最重要地是效率问题.第一个是故障地修复，故障出现在越大地公司越大地规模越复杂地业务场景中，出现是不可避免地，一定会出现，关键是出现