1、阿里巴巴运维体系变迁史作者丨毕玄 编辑谢然 每家公司对于所谓运维团队到底应该做些什么，都有各自的看法。本文首先由阿里巴巴的运维团队在整个阿里巴巴的业务里承担的责任为切入点，回顾了阿里巴巴从工具化到自动化的过程，接着分享了阿里巴巴在智能化领域的探索路线，最后总结了未来运维团队所面临的巨大挑战，特别是运维智能化落地，有效性提升，以及最终效率提升及成本节约上带来的挑战。 注：本文首发自 InfoQ 运维公众号，高效开发运维，ID：DevOpsGeek，推荐关注。随着大数据、机器学习和 AI 技术的 飞速发展，智能化运维成为运维的热点领域。Gartner 的报告宣称，到 2020 年，将近 50% 的
2、企业将会在他们的业务和 IT 运 维方面采用 AIOps，远远高于今天的 10%。尽管 AIOps 还是一个新名词，但它无疑代表了运维未来的一种趋势。智能化运维的终极目标，就是将运维人员从繁琐的工作中解放出来，提高整体运维效率，降低运维成本，实现业务系统的高可用性。运维环境的异构和复杂化，导致日常运维工作需要付出的人力、时间成本越来越高。 大约两年前，智能化运维开始被大家广泛关注，随着大数据分析、APM、智能异常检测、机器学习等技术的兴起和逐渐成熟，运维需求也逐渐向自动化和智能化过渡。从最初级运维发展到现在智能化运维，大致经历了四个阶段：脚本时代工具时代自动化时代智能化时代。目前业界真正的智能
3、化运维的落地实践其实并不多，大多还是停留在自动化甚至人工化阶段，然而智能化运维是大势所趋，对于大公司来说，更是尤为重要。以下整理自 2017 上海 CNUTCon 全球运维技术大会上，阿里巴巴研发效能团队负责人，阿里研究员毕玄的演讲智能时代的新运维。1 阿里的运维体系承载着怎样的责任？ 阿里的运维体系介绍 阿里的运维团队，主要覆盖五个层面。一资源的规划与支付是运维的基石 整个运维团队需要负责资源的规划、资源的交付。Quota 管理： 比如我们会跟业务团队做一些预算的管理，对于每个业务团队首先需要有预算。只要你有预算，运维团队一定会把资源交给你，没有预算一切免谈。规划： 比如阿里每年的双十一交易
4、，业务团队要给出下一年的交易额将做到多少，至于背后需要增加多少的机器量，业务团队根本不关心。所以需要运维团队来做从业务需求到资源的转化和规划，这对于公司来讲非常重要，因为意味着最终我在基础设施上要投多少钱，还有节奏的控制。采购： 当规模大了以后，怎么样合理规划资源的数量和交付节奏是非常重要的，比如 5 月份采购这批机器和 6 月份采购这批机器，是完全不同的概念。还需要资源的采购，比如 SSD 采购紧张 ，供应量不够。通常大公司会有更多的渠道获得更好的供应量，小公司就会很困难。怎么做好供应链控制是非常重要的。资源调度： 对于资源团队来讲，调度也很重要，我们交出去的机器是怎么样的交法，怎么保证可用
5、性、稳定性， Bootstrap 等，每个业务都有自己的规划，按照业务需求怎么把整个业务环境全部交给业务方。阿里目前就遇到了很大的挑战，比如在国际化的扩张上，我们可能这个月需要在这里建个点，下个月需要在另一个地方建个点，怎么快速的完成整个资源，不仅仅是机器资源的交付，还有软件资源的交付，是非常重要的。我们现在在扩展东南亚的业务，怎么样在东南亚快速的完成整个软件资源的交付，对于我们的竞争是非常重要的。二变更 是运维不可避开的坑 对于运维团队来讲，变更也是经常要做的部分，变更信息的收拢，做应用层面的变更，基础网络的 IDC 等等。三监控 预测潜在的故障 监控对于阿里来讲主要分为基础、业务、链路，在
6、监控的基础上要去做一些报警等。四稳定性 是不少企业追求的目标 稳定性这个概念我们以前认为针对的是大公司，因为它可能会影响到大众的生活，会比较敏感。但是现在新型的互联网公司，如外卖，ofo、摩拜等，它的稳定性要求比以前很多创业型公司更高，因为它有在那个点必须能用，如果不能用，对用户会有直接的影响。所以稳定性可能在整个运维行业会得到越来越高的重视，但是对于很多中小型公司，稳定性的投入相当大的。五一键建站 让规模化有力保障 像阿里在稳定性上主要会去做多活体系的建设，然后故障的修复、故障定位，然后还有一套全链路的压测。规模化是很多运维团队很痛苦的事情，可能今年机器在这个机房，明年你的基础设施团队可能告
7、诉你，这个机房不够用了，我们要换个机房。反正在阿里巴巴，很多的运维人员都说了，我们每年的工作中有一项不用写的工作就是搬迁。虽然基础设施团队会承诺说三年内不会再搬，可是到了明年他会跟你说，由于某些原因我们还是再搬一下，搬完之后三年不会让你再搬。但是从我们过去发展的三年，每年都在搬。未来我们确实相信阿里巴巴，可能在未来搬迁会相对更少一点，我们认为不能让搬迁成为阿里巴巴运维团队的核心竞争力。我们在规模化层面做了很多事情，比如说我们做了一键建站，对于阿里来讲，我们对机器资源的交付时间，要求会越来越高。比如说双十一，是提前一个月交付资源还是提前两个月还是提前三个月，对我们来讲付出的钱是完全不一样，而且可
8、能相差非常大。所以，技术层面能不能更好的把这个时间缩短，是非常重要的。所以一键建站的重要目的就是这个，每年双十一我们都会拓展出非常多个站点，通过一键建站快速完成整个过程。搬迁就是我说的，反正我们每年都要搬，那我们应该把搬迁这套系统做得更好。还有腾挪，阿里很多时候因为需要做一些业务资源的复用，最好是有一个机柜，这个时候怎么更好完成挪的过程也是很麻烦。我们还需要做一些单元的调整，因为对阿里的交易系统来讲是有单元的概念的，我们怎么更好的控制一个单元内机器的比率是非常重要的。一个单元的机器数可能是比较固定的，那如果比率搭配不好，就意味着瓶颈点会非常明显。以上，正是阿里巴巴的运维团队所覆盖的五个领域。整
9、个运维体系的演进过程，差不多都是从最早的脚本到工具到自动化，到未来的智能化。2 从工具化到自动化过关斩将 从工具化到自动化这个层面，过程并没有那么的容易，以及对整个行业来讲，目前更多的工作仍然是在探寻自动化，怎么样让自动化真正的被实现得更好。这个行业的发展跟其他传统的软件，标准的软件研发行业，我觉得很不一样。比如说阿里从工具化到自动化这个过程中，我们认为工具化，其实挑战相对小，即使传统的运维人员也很容易写一些工具，比如用 Python 去写更多的工具体系。但是如果你的工具最重要变成能够到自动化这个阶段，就意味着对工具的要求会越来越高，比如说工具的质量，如果你写出来的工具经常有问题，规模一大就扛
10、不住，这个时候对于大家来讲慢慢会越来越失去信任感。最后会很难完成这个过程。运维团队转型研发团队 组织能力是最大的壁垒 阿里过去走这条路的过程中，我们觉得最大的挑战是组织的能力问题。运维团队怎么样更好的完成朝研发团队的转型，这个过程对于很多运维团队来讲都是巨大的挑战。对于一个组织来讲怎么完成这个过程也是非常重要的。我想很多团队都有这个感受，工具研发的团队跟做运维操作的团队之间，很容易产生一些冲突等等。所以阿里巴巴在走这个过程的时候，思考的核心就是怎么让一个运维团队真正从组织能力上，演变成我们所需要的更好的团队。阿里在走这条路的时候，走了四个过程。这个过程阿里在不断的摸索，最终到现在为止我们认为阿
11、里的方式相对来讲还是不错的。我们最早跟大部分公司一样，有一个专职的工具研发团队和一个专职的运维团队。工具研发团队做工具，做出来给运维团队用。这个过程中容易出现的最明显的问题就是工具做完了，运维团队说这个工具太难用了，不符合需求。要么就是运维团队执行的过程中，经常出问题，出问题还要找工具研发团队来帮忙查问题在哪里。本来运维几行脚本全部能搞定的问题，结果还要依赖工具团队。慢慢这个局面越来越难突破，很难改变。所以阿里后来做了一个尝试，既然两个团队很难做很好的结合，那有一种方式是工具研发团队做完工具以后，比如说做了一个发布，做完这个功能以后，这个运维工作就彻底交给工具研发团队，不让运维团队做了，运维团
12、队就可以做一些别的事情。这个模式看起来就是逐步接管的模式，让工具研发团队逐步解耦。这个做了一段时间，碰到的最大问题还是组织能力问题。对于运维工具来讲，质量怎么做到很高，运维好像很容易做的样子，但是实际上运维工具相当难做，它的复杂度比在线业务更大，就是它不是逻辑上的复杂，更多的是环境层面的复杂。因为比如会涉及网络涉及服务器涉及机房等等，这跟业务完全不一样。所以做了一段时间之后，我们觉得这还是一个问题。将工具的研发和运维融为一体 突破组织能力问题 后面我们做完这轮之后又开始做另外一个方向的尝试，让工具的研发团队和运维团队做一个融合。所谓的融合就是把很多工具研发的人分派给运维团队，到运维团队去做。我
13、们期望通过工具研发的人带动整个运维团队转变成研发型团队。这是我们的思路。阿里巴巴在走前面这三步的时候，大概花了近一年半左右，意味着这其中我们大概做了三轮组织结构调整。因为我们认为这些都是要有组织层面的保障才能被实现的。DevOps 是如何真正落地的 去年 6 月，我们做了一个最大的组织结构调整，把日常的运维工作交给研发做，研发自己会把日常的运维工作都做掉。但并不是说所有运维工作，现在仍然有一个做运维的团队，这个运维团队相对来讲更不一样，跟以前有非常大的不同。我们认为这是 DevOps 真正的被彻底的执行。因为这个好处是，日常的运维工作交给了研发，运维团队转变成研发团队这个过程非常困难，其实不完
14、全是能力上的差距，更大的原因是，运维团队要承担非常多的日常杂活，尤其像集团性的公司，不管是阿里、腾讯、百度都一样，集团性的公司多数支撑的 BU 都是无数个。你一个人支撑二十个 BU 一个 BU 里面一天有一个人找你，你一天就不用干别的活了，你一天就在跟他们不断的聊天，做操作，嘴里又叫着这个团队要升级，要做组织升级，要转变成研发团队，实际上就是逼别人走向了一条死路。所以我们认为，谷歌的做法，谷歌在 SRE 那本书提到的是，会强制留 50% 的时间给研发团队做研发工作。这个说实话，在大多数公司很难执行这个政策，除非运维团队跟研发团队有非常强的话语权。但这个很难。所以阿里的做法我认为更为彻底，阿里告
15、诉研发团队，以后日常运维的工作不要找运维团队，自己干。这可能粗暴了一点，在运维体系还没有准备得很好的情况下做了这个事情，所以后面相对来讲也导致了问题，比如说运维工具四处建设、重复建设等等现象。但是从组织层面上来讲，我们很欣慰的看到，在做完这轮组织调整过后的一年后，运维团队的大多数人更多的时间是投入在研发工作上，而不是投入在日常的杂事上。我们看到了一个团队的能力，在经过这一轮的调整得到了非常好的升级。而这对于组织来讲是最大的利好。所以我们认为，这种模式是阿里现在最为推崇也最为看好的一个方向，这样整个运维团队将专注在我刚才讲的五个部分的系统层面的研发以及建设上，而不是杂活上。这是阿里从工具化到自动
16、化，最主要是这样的一个过程。成功率是衡量自动化运维的关键指标 对于自动化来讲最重要的问题是成功率，比如我们看所有的运维操作中，我们最关心的指标是成功率。比如一个运维系统里面的功能，在一个星期内，比如说会用几十万次，我们只关注成功率能不能做到 4 个 9 以上，否则算一下工单数就懂了，这个运维团队得有多少人支持这件事情，这些人又没有时间去干研发的活，又要投入大量的精力做支持性的工作。所以我们在成功率上要做到非常高的保障，运维系统我们以前看过是面临最大的挑战，我以前的背景全部是做在线业务型的系统，比如淘宝的交易等等。后来我们发现运维系统有个最大的不同在于，运维系统对于成功率的追求比在线业务型系统更
17、高一些。在线业务型系统，比如说我在访问后面一个地方有问题的时候，我们会选择尽快把这个过程失败掉，而不是把时间不断的拖长以及不断的试错。在线系统会更加快的把错误往外抛。但是对于运维系统来讲如果也这样做，就意味着这个成功率非常难保障。所以运维系统要有更好的思考，怎么保障一次运维操作，这背后可能有几十个系统，而且多数是无数的团队写的，阿里以前碰到的情况就是无数个系统，质量层次不起，什么都有。怎么保证在这么复杂的环境下，保证对外的，对用户层面这个成功率可以做到很高的。这是一个很大的问题。规模带来的挑战也是不容小觑 随着规模的不断增长，所有开源类型的运维类的系统，在规模化，当你的机器规模等等其他规模上升
18、到一个程度以后，通常来讲都会面临非常巨大的挑战。阿里巴巴所有的这种类型的系统，我们论证都是自己做是比较靠谱。最大的原因是规模，规模上去以后会遇到很多问题。像代码托管、代码编译什么的，以前认为不会有太大的问题，事实证明规模上来以后这些里面全都是问题。我们也要投入非常大的精力去做规模方面的解决。所以我觉得，阿里从以前的工具化走向更加自动化的过程中，我们探讨的核心问题就是能不能有一个非常好的组织去完成这个过程。能让运维的团队更加转型向 DevOps 这样的方向。所以我们一直说，我们一直很纠结运维团队到底应该叫什么名字，我们一致认为，运维研发团队，我们觉得不大对，你的主要的活其实是干研发而不是运维。但是叫研发运维又有点奇怪。后来阿里巴巴基本上是叫研发团队。因为我们认为运维的研发团队和在线业务的研发团队没有本质区别，都是做研发的，只是一个在解决运维领域的业务问题。刚才讲的五个层次，运维领域的业务问题，也是业务，没有什么区别。在线业务，比如解决交易的问题，解决其他问题，这是完全一样的。两个研发团队没有本质区别。所以这个过程，阿里经过
