阿里巴巴运维体系变迁史

摘要：反正在阿里巴巴，很多的运维人员都说了，我们每年的工作中有一项不用写的工作就是搬迁。未来我们确实相信阿里巴巴，可能在未来搬迁会相对更少一点，我们认为不能让搬迁成为阿里巴巴运维团队的核心竞争力。以上，正是阿里巴巴的运维团队所覆盖的五个领域。

随着大数据、机器学习和 AI 技术的飞速发展，智能化运维成为运维的热点领域。Gartner 的报告宣称，到 2020 年，将近 50% 的企业将会在他们的业务和 IT 运维方面采用 AIOps，远远高于今天的 10%。尽管 AIOps 还是一个新名词，但它无疑代表了运维未来的一种趋势。

智能化运维的终极目标，就是将运维人员从繁琐的工作中解放出来，提高整体运维效率，降低运维成本，实现业务系统的高可用性。

运维环境的异构和复杂化，导致日常运维工作需要付出的人力、时间成本越来越高。 大约两年前，智能化运维开始被大家广泛关注，随着大数据分析、APM、智能异常检测、机器学习等技术的兴起和逐渐成熟，运维需求也逐渐向自动化和智能化过渡。从最初级运维发展到现在智能化运维，大致经历了四个阶段：脚本时代——工具时代——自动化时代——智能化时代。

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

1、阿里的运维体系承载着怎样的责任？

阿里的运维体系介绍

阿里的运维团队，主要覆盖五个层面。

 一．资源的规划与支付是运维的基石

整个运维团队需要负责资源的规划、资源的交付。

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

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

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

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

二．变更 是运维不可避开的坑

对于运维团队来讲，变更也是经常要做的部分，变更信息的收拢，做应用层面的变更，基础网络的 IDC 等等。

三．监控 预测潜在的故障

监控对于阿里来讲主要分为基础、业务、链路，在监控的基础上要去做一些报警等。

四．稳定性 是不少企业追求的目标

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

五．一键建站 让规模化有力保障

像阿里在稳定性上主要会去做多活体系的建设，然后故障的修复、故障定位，然后还有一套全链路的压测。规模化是很多运维团队很痛苦的事情，可能今年机器在这个机房，明年你的基础设施团队可能告诉你，这个机房不够用了，我们要换个机房。反正在阿里巴巴，很多的运维人员都说了，我们每年的工作中有一项不用写的工作就是搬迁。虽然基础设施团队会承诺说三年内不会再搬，可是到了明年他会跟你说，由于某些原因我们还是再搬一下，搬完之后三年不会让你再搬。但是从我们过去发展的三年，每年都在搬。未来我们确实相信阿里巴巴，可能在未来搬迁会相对更少一点，我们认为不能让搬迁成为阿里巴巴运维团队的核心竞争力。

我们在规模化层面做了很多事情，比如说我们做了一键建站，对于阿里来讲，我们对机器资源的交付时间，要求会越来越高。比如说双十一，是提前一个月交付资源还是提前两个月还是提前三个月，对我们来讲付出的钱是完全不一样，而且可能相差非常大。

所以，技术层面能不能更好的把这个时间缩短，是非常重要的。所以一键建站的重要目的就是这个，每年双十一我们都会拓展出非常多个站点，通过一键建站快速完成整个过程。搬迁就是我说的，反正我们每年都要搬，那我们应该把搬迁这套系统做得更好。还有腾挪，阿里很多时候因为需要做一些业务资源的复用，较好是有一个机柜，这个时候怎么更好完成挪的过程也是很麻烦。

我们还需要做一些单元的调整，因为对阿里的交易系统来讲是有单元的概念的，我们怎么更好的控制一个单元内机器的比率是非常重要的。一个单元的机器数可能是比较固定的，那如果比率搭配不好，就意味着瓶颈点会非常明显。

以上，正是阿里巴巴的运维团队所覆盖的五个领域。整个运维体系的演进过程，差不多都是从最早的脚本到工具到自动化，到未来的智能化。

2、从工具化到自动化过关斩将

从工具化到自动化这个层面，过程并没有那么的容易，以及对整个行业来讲，目前更多的工作仍然是在探寻自动化，怎么样让自动化真正的被实现得更好。

这个行业的发展跟其他传统的软件，标准的软件研发行业，我觉得很不一样。比如说阿里从工具化到自动化这个过程中，我们认为工具化，其实挑战相对小，即使传统的运维人员也很容易写一些工具，比如用 Python 去写更多的工具体系。但是如果你的工具最重要变成能够到自动化这个阶段，就意味着对工具的要求会越来越高，比如说工具的质量，如果你写出来的工具经常有问题，规模一大就扛不住，这个时候对于大家来讲慢慢会越来越失去信任感。最后会很难完成这个过程。

运维团队转型研发团队 组织能力是较大的壁垒

阿里过去走这条路的过程中，我们觉得较大的挑战是组织的能力问题。运维团队怎么样更好的完成朝研发团队的转型，这个过程对于很多运维团队来讲都是巨大的挑战。对于一个组织来讲怎么完成这个过程也是非常重要的。

我想很多团队都有这个感受，工具研发的团队跟做运维操作的团队之间，很容易产生一些冲突等等。所以阿里巴巴在走这个过程的时候，思考的核心就是怎么让一个运维团队真正从组织能力上，演变成我们所需要的更好的团队。

阿里在走这条路的时候，走了四个过程。这个过程阿里在不断的摸索，最终到现在为止我们认为阿里的方式相对来讲还是不错的。我们最早跟大部分公司一样，有一个专职的工具研发团队和一个专职的运维团队。工具研发团队做工具，做出来给运维团队用。这个过程中容易出现的最明显的问题就是工具做完了，运维团队说这个工具太难用了，不符合需求。要么就是运维团队执行的过程中，经常出问题，出问题还要找工具研发团队来帮忙查问题在哪里。本来运维几行脚本全部能搞定的问题，结果还要依赖工具团队。慢慢这个局面越来越难突破，很难改变。

所以阿里后来做了一个尝试，既然两个团队很难做很好的结合，那有一种方式是工具研发团队做完工具以后，比如说做了一个发布，做完这个功能以后，这个运维工作就彻底交给工具研发团队，不让运维团队做了，运维团队就可以做一些别的事情。这个模式看起来就是逐步接管的模式，让工具研发团队逐步解耦。

这个做了一段时间，碰到的较大问题还是组织能力问题。对于运维工具来讲，质量怎么做到很高，运维好像很容易做的样子，但是实际上运维工具相当难做，它的复杂度比在线业务更大，就是它不是逻辑上的复杂，更多的是环境层面的复杂。因为比如会涉及网络涉及服务器涉及机房等等，这跟业务完全不一样。所以做了一段时间之后，我们觉得这还是一个问题。

将工具的研发和运维融为一体 突破组织能力问题

后面我们做完这轮之后又开始做另外一个方向的尝试，让工具的研发团队和运维团队做一个融合。所谓的融合就是把很多工具研发的人分派给运维团队，到运维团队去做。我们期望通过工具研发的人带动整个运维团队转变成研发型团队。这是我们的思路。

阿里巴巴在走前面这三步的时候，大概花了近一年半左右，意味着这其中我们大概做了三轮组织结构调整。因为我们认为这些都是要有组织层面的保障才能被实现的。

DevOps 是如何真正落地的

去年 6 月，我们做了一个较大的组织结构调整，把日常的运维工作交给研发做，研发自己会把日常的运维工作都做掉。但并不是说所有运维工作，现在仍然有一个做运维的团队，这个运维团队相对来讲更不一样，跟以前有非常大的不同。

我们认为这是 DevOps 真正的被彻底的执行。因为这个好处是，日常的运维工作交给了研发，运维团队转变成研发团队这个过程非常困难，其实不完全是能力上的差距，更大的原因是，运维团队要承担非常多的日常杂活，尤其像集团性的公司，不管是阿里、腾讯、百度都一样，集团性的公司多数支撑的 BU 都是无数个。你一个人支撑二十个 BU 一个 BU 里面一天有一个人找你，你一天就不用干别的活了，你一天就在跟他们不断的聊天，做操作，嘴里又叫着这个团队要升级，要做组织升级，要转变成研发团队，实际上就是逼别人走向了一条死路。

所以我们认为，谷歌的做法，谷歌在 SRE 那本书提到的是，会强制留 50% 的时间给研发团队做研发工作。这个说实话，在大多数公司很难执行这个政策，除非运维团队跟研发团队有非常强的话语权。但这个很难。所以阿里的做法我认为更为彻底，阿里告诉研发团队，以后日常运维的工作不要找运维团队，自己干。这可能粗暴了一点，在运维体系还没有准备得很好的情况下做了这个事情，所以后面相对来讲也导致了问题，比如说运维工具四处建设、重复建设等等现象。

但是从组织层面上来讲，我们很欣慰的看到，在做完这轮组织调整过后的一年后，运维团队的大多数人更多的时间是投入在研发工作上，而不是投入在日常的杂事上。我们看到了一个团队的能力，在经过这一轮的调整得到了非常好的升级。而这对于组织来讲是较大的利好。所以我们认为，这种模式是阿里现在更为推崇也更为看好的一个方向，这样整个运维团队将专注在我刚才讲的五个部分的系统层面的研发以及建设上，而不是杂活上。这是阿里从工具化到自动化，最主要是这样的一个过程。

成功率是衡量自动化运维的关键指标

对于自动化来讲最重要的问题是成功率，比如我们看所有的运维操作中，我们最关心的指标是成功率。比如一个运维系统里面的功能，在一个星期内，比如说会用几十万次，我们只关注成功率能不能做到 4 个 9 以上，否则算一下工单数就懂了，这个运维团队得有多少人支持这件事情，这些人又没有时间去干研发的活，又要投入大量的精力做支持性的工作。所以我们在成功率上要做到非常高的保障，运维系统我们以前看过是面临较大的挑战，我以前的背景全部是做在线业务型的系统，比如淘宝的交易等等。

后来我们发现运维系统有个较大的不同在于，运维系统对于成功率的追求比在线业务型系统更高一些。在线业务型系统，比如说我在访问后面一个地方有问题的时候，我们会选择尽快把这个过程失败掉，而不是把时间不断的拖长以及不断的试错。在线系统会更加快的把错误往外抛。但是对于运维系统来讲如果也这样做，就意味着这个成功率非常难保障。所以运维系统要有更好的思考，怎么保障一次运维操作，这背后可能有几十个系统，而且多数是无数的团队写的，阿里以前碰到的情况就是无数个系统，质量层次不起，什么都有。怎么保证在这么复杂的环境下，保证对外的，对用户层面这个成功率可以做到很高的。这是一个很大的问题。

规模带来的挑战也是不容小觑

随着规模的不断增长，所有开源类型的运维类的系统，在规模化，当你的机器规模等等其他规模上升到一个程度以后，通常来讲都会面临非常巨大的挑战。阿里巴巴所有的这种类型的系统，我们论证都是自己做是比较靠谱。较大的原因是规模，规模上去以后会遇到很多问题。像代码托管、代码编译什么的，以前认为不会有太大的问题，事实证明规模上来以后这些里面全都是问题。我们也要投入非常大的精力去做规模方面的解决。

所以我觉得，阿里从以前的工具化走向更加自动化的过程中，我们探讨的核心问题就是能不能有一个非常好的组织去完成这个过程。能让运维的团队更加转型向 DevOps 这样的方向。所以我们一直说，我们一直很纠结运维团队到底应该叫什么名字，我们一致认为，运维研发团队，我们觉得不大对，你的主要的活其实是干研发而不是运维。但是叫研发运维又有点奇怪。后来阿里巴巴基本上是叫研发团队。因为我们认为运维的研发团队和在线业务的研发团队没有本质区别，都是做研发的，只是一个在解决运维领域的业务问题。刚才讲的五个层次，运维领域的业务问题，也是业务，没有什么区别。在线业务，比如解决交易的问题，解决其他问题，这是完全一样的。两个研发团队没有本质区别。

所以这个过程，阿里经过过去这一年的组织调整以后，我们看到整个自动化层面，阿里有了很好的进展，但是离我们的期望还要更加努力继续往前演进。

3、阿里巴巴在智能化领域的探寻之路

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

自动化是智能化的前提

对于我们来讲，我们认为，比如说就像我对这个团队，我自己的团队讲的一样，我认为智能化最重要的前提是，一是自动化。如果你的系统还没有完成自动化的过程，我认为就不要去做智能化，你还在前面的阶段。智能化非常多的要求都是自动化，如果不够自动化，意味着后边看起来做了一个很好的智能化的算法等等，告诉别人我能给你很大的帮助，结果发现前面自动化过程还没有做完全。

一个最典型的 case，阿里巴巴以前一直在讲，我们认为资源的搭配上，其实可以做得更好。比如说你半夜流量比较小，白天流量比较大，你能不能更好的做一些弹性，把资源释放出来去干点别的，然后白天再把它补起来。这从算法层面上并没有那么复杂，从算法层面做到一个简单的提升是很容易做的。所以，当时我们就有很多团队做了一个东西，可以做到这一点。结果等到落地的时候发现，业务不能自动伸缩。如果你想，比如说有些机器上面负载特别高，有些机器特别低，我们希望负载能拉得更均衡，在线业务更加稳定化，做一个算法，比如说背包，更好的去做组合，结果就是这个东西做完了，给出了建议说较好这个应用调到那台机器，那台应用调到这台机器。给完之后业务团队看了一眼，我们不干，因为干这些工作全部要手工干，你还每天给我建议，更不要干了，每天就来调机器了。

所以首先你要想明白你的前提，自动化，具不具备自动化的能力，不具备的话没有必要在这方面做过多的投入。

数据结构化是智能化的源动力

目前 AI 领域基本是靠暴力，暴力破解，未来可能有别的方向，但是目前的 AI 基本上是靠大量数据的积累去寻找一个东西出来，所以它一定需要有大量的数据积累，数据包括非常多的东西，对于运维来讲，可能基础层面的数据，机器的数据，运维变更的数据，上面还有一些场景化的数据，比如你解决故障，有没有更好的结构化的收集数据，这是非常重要的。数据这个层面比较难做的在于，      在最开始阶段，多数公司的运维数据都是不够结构化的，结构化不会做得那么好，当然会有结构化，但是结构化的因素不会足够好。

就像阿里巴巴在讲，我们在电商领域 AI 化，我们较大的优势就是不断对外部讲，我们拥有的是结构化的商品数据，其他公司最多从我们这里扒结构化的商品数据。你扒过去之后还要自己分析，并且做商品结构的调整，这非常困难。但是阿里巴巴自己天然，所有人都会帮你把结构做得非常好。所以对运维来讲也是一样，如果你想在智能化上有更多的突破，数据怎么更好的做结构化，是一个非常大的挑战。你很难想清楚。这两个地方是我觉得首先要想清楚的。

智能化最适合的运维场景

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

阿里巴巴智能化运维五步走

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

一．资源的重点是成本

1. 基础设施选型

对于资源这一块，整个公司层面更为关注的问题，就是成本。你交付的资源具不具备较低的成本，这个智能化确实可以给非常大的帮助。比如第一点，怎么更好的规划这家公司机型、网络和整个数据中心，这为什么要用智能化的手段在于，一个数据中心的选址来自非常多的因素，除了政府层面的政策因素之外，还有很多其他因素需要考虑，比如说气候等等各种各样的因素，都需要在这个阶段去考虑。你需要通过大量数据的积累来分析，比如在中国，在海外，到底有那些地方是对你的业务发展策略来讲最适合的，是在哪里，这要确定一个范围，在一个范围基础上是进一步的人的建立。

对于网络、机型来讲，目前我们认为最可以做的在于，可能因为阿里的模式跟有些公司不一样，阿里更多的机器都来自同一个部门，基本上是同一个部门在教阿里巴巴所有的机器。这就有巨大的好处了，因为都在一个团队。比如阿里巴巴在去年开始建设统一的调度系统，更大的好处就来了，因为大家所有的资源都来自同一个地方，这个地方就收集了整个阿里巴巴的所有的资源需求、数据，数据全部在它手上。

如果你结合这个数据，以及它实际的运行情况，更好的就可以去推导，比如说对于阿里巴巴来讲最合适的机型是什么，这个阿里大概在去年就开始做尝试。在去年以前所有的过程，阿里巴巴，比如说明年我的服务器的机型，所谓机型，这里讲的机型的含义主要是比率问题，不是选择下一代什么样的 CPU，那是硬件发展决定的。但是比率因素，以前我们更多的是人脑拍，人肉智能。人肉智能在一定阶段是更加高阶的，过了那个阶段之后人就比不过机器了。团队说我们明年要买的机型里面的配置大概是这样的，人算了一下，就这样吧，就可以拍掉。去年开始我们引入了一套系统，这套系统会分析所有的数据以及钱，最重要的是钱，然后分析一下整个过程，推演对我们来说最合算的是什么。所以适合的机型到底是什么。

如果有一套非常好的推演的系统，来推演你的机型、网络、IDC 未来应该怎么规划，这对于成本领域将会产生巨大的帮助。比如说网络，现在的发展，万兆，25G、45G、100G，你认为对于你的公司来讲最合适的是什么？多数公司八成就是人脑一拍就决定了，但是事实上可能不是这样。

2. DC 大脑，让控制更加智能化

DC 大脑，这个现在比较火，这个领域现在非常火爆，火爆的主要原因有可能是因为去年谷歌的一篇文章，谷歌去年发表了一篇文章，里面有一个消息透露了一下，他们通过更好的智能化，去控制整个机房的智能等等。比如说控制空调的出口，就是那个风向往哪边吹，控制这个，然后为谷歌节省了非常多的钱，非常可观。所以对于很多数据中心团队来讲，现在都在研究这个领域。因为这个领域实在太省钱了。

我们后来类比了一下，我们说其实大多数人，可能你很难感觉数据中心，但是你最容易感觉的是另外一个地方，你的办公室。比如说我们以前说，阿里巴巴一到夏天的时候，办公室实在是太冷了，比外面冷多了。如果能够更好的控制温度，对于我们来讲就会有巨大的帮助，对公司来讲可能会更加省钱。所以怎么样做好这个非常重要。

3. 弹性伸缩较大的前提是实现自动化

弹性伸缩，这是无数运维团队都想做的事情，研发团队说，业务团队说，我要一百台机器，你也不好反驳他，最后上线了一百台，你发现他用十台就够了。但是你也很难跟他纠结这个问题，好像无数的运维团队都在尝试弹性伸缩。但是我说了，弹性伸缩较大的前提就是自动化，如果没有自动化也没有什么意义。

4. 资源画像让资源更好搭配

资源怎么更好的搭配，阿里巴巴在尝试做资源的画像。对于所有的在线业务来讲，它的趋势比较好预测，多数在线业务，只有少数的在线业务不大好预测。多数在线业务是一个模式，如果预测得非常好，让资源有合理的搭配，对于这家公司的资源将会产生巨大的帮助。

二．可以下降 30% 由变更引起的故障

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

所以，变更这个领域，我们最希望做的是朝这个方向去发展。目前来看阿里巴巴的尝试，我们可以看到变更引发的故障比率是较高的，目前已经铺的这个领域中，可以下降 30% 因为变更引起的故障，拦截主要是用来拦截问题。

三．监控 AI 化

智能报警

这个领域现在是 AI 进入运维行业中最火的领域，所有公司都在做。第一个是阿里在做的，阿里也不例外，我们也同样在做。第一个是智能，大家比如说做运维的都知道，你写完了一个业务，要配监控报警的阈值的，比如说 CPU 到多少应该报警，然后响应时间到多少应该报警。阿里在尝试的一个方向是让你不要去配，阿里根据分析来决定什么情况下需要报警，这对于研发来讲有巨大的帮助。

异常检测直接影响到效率

第二点是异常检测，这是很多公司都在做的。异常检测之所以要做，较大的原因就是因为效率，如果不做，其实也 ok，但是要投入非常大的人力。比如说交易跌了，那到底是，比如对于我们来讲，交易跌了，只要跌了就需要分析到底什么因素。而这个因素很有可能，最后你发现根本跟我们没关系，可能是外部原因，国家节日等等，各种各样的因素造成的。尤其是小规模的业务，比如我们的海外业务，波动非常大，如果一波动就认为是问题，这对于整个公司的效率来讲是巨大的影响。

所以我们认为，如果异常检测做得非常好，对我们的效率会有非常大的帮助。这张图是通常来讲，做异常检测，运维的数据都是时序化，根据时序有各种各样的算法，上面列了业界常用的算法。最左上角的算法是阿里巴巴自己研究的算法，从我们目前的测试情况来看，我们可以看到阿里巴巴自己研究的算法的准确率等等，得比业界高非常多。细节我不讲了，最重要的原因是这个东西马上会在某个会议上发表一篇论文，大家以后会看到。

四．稳定性是以效率为原则

故障修复要精准且快速

稳定性对我们来讲最重要的是效率问题。第一个是故障的修复，故障出现在越大的公司越大的规模越复杂的业务场景中，出现是不可避免的，一定会出现，关键是出现之后怎么尽快把故障修复掉。故障修复这个领域，阿里巴巴尝试了非常多的方案，也尝试了很多年。很多的案例都是，这个过程需要慢慢的积累，原因在于信任感地当故障出现的时候，我们都说公司的很多团队都处于高度紧张的状态，这个时候有一套系统抛出了，现在多数这种系统都是抛出三个决定，给你三个建议，然后你来选。有时候经验丰富的处理故障的人一看，你抛出的三个建议都不靠谱。当十个故障中，有八次，不用八次，如果有个四五次都是这样的，以后所有人都不会看这套系统了，太不靠谱了，还不如人来判断。这个系统难度非常高，需要整个公司坚定地朝这个方向走，并且更好的积累很多的数据。

故障修复，阿里现在只尝试了一些非常简单的案例，对于阿里来讲，比如一个机房出故障，因为整个阿里巴巴交易体系的架构是支持多点的，对于我们来讲如果在某种情况下，我们判断一个机房出故障，我们可以自动的做一些流量的切换等等。但阿里现在也认为，智能化在稳定性，尤其故障修复这种动作上，还是要非常小心，万一没事切出了问题，这影响更大。

用智能化做好故障定位

我们以前一直都认为定位这个问题不是个大问题，如果我能快速修复，定位，你慢慢定好了，定个两天我也无所谓。但是现在阿里特别重视的原因在于，故障定位损耗了我们非常多的人力，耗费了我们非常大的团队力量。所以我们认为需要有更智能化的方法，把故障定位出来，以助研发团队更专注投入在其他事情上。比如现在故障一出来，研发查了半天，一看，跟它都没有什么关系。所以就浪费了很多，这张图是我们现在在做的一套系统，从一个异常，那里标一二三四五，当有一个异常出来之后，第一步发现，第二步不断的分析，一直定位到最后到底是哪个地方出了问题，我们的目标是最后尽可能定位到代码层面的问题，或者是网络或者是基础设施等等。

五．边压边弹 做好规模化运维

目前对阿里来讲最重要的问题还是效率问题。比如说我们在每年准备双十一容量的时候，很多人都知道阿里有全链路压测，一个最重要的目的就是调整容量，怎么把一个机房的容量调整成比率是最合适的，比如说 A 应用可能是瓶颈，但是事实上如果搭配得好，A 应用就不再是瓶颈。所以怎么样让一个固定机器数下做一个较好的搭配，我们以前是压一轮调整一下，再压一轮再调整一下，这非常耗费一堆人通宵的精力。我们认为这个过程需要提升，现在改成非常简单的模式，流量过来以后不断的自动调整容量比例，我们会有一个所谓边压边弹，一边压测一边调整比例。相信很多运维同学都干过这个事情，因为业务方给你一个指标，你是要算的，而且很难算的很精准。边压边弹意味着你不需要算得很精准，粗略算一个数就可以了，后面靠这套系统自动给你调平衡。

阿里巴巴在这五个方面，在智能化方面做的探索，阿里认为我们还不足以所有的领域都去覆盖。

4、未来运维领域需要突破的防线

无人化 让梦想照进现实

我认为现在运维这个领域中较大的挑战仍然是，能不能真正的走向无人化，整个过程中是完全没有人的。

从目前来看，要做到无人化最重要的是质量问题，质量做得不够好是没有办法无人化的。另外如果出问题了能不能自动修复等等，所以我们认为无人化对运维领域是较大的挑战，能不能把这个落地变成现实，奠定了智能化的基础。如果说智能化所有的动作要人介入，那基本就不用做了。

智能化 带来效率上的质变

在智能化这一点上，第一点是有效性的问题，如果这个智能表现得比人的智力还差一些，这个慢慢就没有人相信这个东西了。所以怎么样把有效性提升上来，另外最重要的是要看到智能化给运维领域带来效率上的质变。智能化投入非常大，要做大量的收集做大量的分析。所以较好带来的是质变而不只是量变，如果只是量变可能投入都收不回来。对于所有公司而言，更少的人更低的成本是非常重要的。人较好投入在一些更重要的研发等等事情上。

作者介绍

林昊 (毕玄)，阿里巴巴研发效能事业部负责人。2007 年加入阿里，10 年间打造了阿里目前使用更为广泛的核心中间件之一的服务框架；建设了阿里的 HBase 团队，发展到今天 HBase 已经是阿里最重要的 NoSQL 产品；打造阿里基于 LXC 的虚拟化系统，以及集群资源管理系统，不断降低阿里巴巴在机器资源上投入的成本；设计并带领团队实现了阿里巴巴技术发展史上具有里程碑意义的异地多活。