应对双11挑战，阿里巴巴智能化运维体系演进与建设

摘要： “能用机器做的就不要让人去做，自动化一切可以自动化的。”

导读：DevOps 的概念提出接近10年了，提升协作效率，降低开发成本，更稳健可持续的业务运营是DevOps的主旋律。根据2016年DevOps调查报告显示，一个低效的IT组织跟一个高效的IT组织相比，差距可能是200倍，换句话说低效组织发布一个功能，高效组织可能已经发布了200个功能；故障恢复的效率差距可能是几十倍，低效组织花费几个小时恢复的故障，高效组织可能几分钟就搞定了。

在日益激烈的商业竞争环境下，这么低效的IT组织注定在商业上也是要失败的。因为现在是快鱼吃慢鱼的时代。去年Gartner又提出了AIOps的概念，就是用基于算法来提升运维效率，国内很多公司在各个运维的场景都有了不同程度的应用。

阿里巴巴对DevOps和AIOps有自己的理解和实践，外界也比较关注拥有众多业务的庞大组织，是如何开展DevOps的？ 带着这些问题，阿里集团基础架构事业群运维中台负责人如柏，在2017杭州云栖大会企业高效研发实践专场上，详细介绍了阿里运维体系的演进和在智能化运维方面的工作，希望能给大家带来一些启发和借鉴。

嘉宾简介

毛茂德(花名：如柏)：阿里集团基础架构事业群运维中台负责人。主要负责 IDC 建设、网络建设、基础数据库运维、大数据运维，研发协同等事项，并主导设计构建高可靠、高并发、大规模的基础运维平台和应用运维平台。十余年来坚持不懈的追求研发、测试、运维效率提升，推动DevOps实施落地。现在正致力于打造基于混合云的应用运维无人值守解决方案，以及自动化、数据化、智能化应用运维解决方案。

阿里巴巴是怎么看运维的？

阿里大致也是经历了这么几个阶段：从最开始的人肉运维， 到简单的工具、自动化， 到系统化和平台的过程， 自动化到一定程度后，开始探索智能化，无人化运维这些领域， 并在阿里的多个运维系统里有所沉淀。

 

在这个演进过程中，我们始终秉承一种原则， 能用机器去做的就不要让人去做，自动化一切可以自动化的。很多简单重复的日常运维操作，开始由研发通过运维平台来完成。

阿里巴巴运维能力分层图

上图是阿里对运维领域的大致分层。每个层都会有不同平台/系统来承载，运维团队整体上会帮助业务团队搞定资源，实现高可用的架构，资源成本优化等问题。有了资源，业务就可以部署代码，对外提供服务， 代码上线后会有各种运行时的变更操作， 当然也会有横向的运维操作， 比如操作系统更新，网络升级，DNS，IP等等变更操作。监控也是分层的，横向的有服务器的监控，网络监控， IDC监控， 纵向来看， 有面向业务的监控，确保系统的各种异常能被检测到，并及时提供多种途径的报警。当业务真的发生故障时，我们也有系统需要能及时的恢复故障，定位故障，甚至能故障自愈，故障预测等。

 

针对双11这样的大型活动，我们会做大规模全链路的压测模拟，来发现各种系统异常，为大促做好充分准备。我们也有定期的故障演练系统，来不断提升故障恢复速度。横向，纵向之外，我们还有规模化的运维，这个在大促和业务快速扩张时非常有用。

 

运维是很大的一个概念，里面有很多专业，这5个能力层次每一层就有很多产品组成。从云效2.0-智能化运维平台（以下简称：StarOps）产品的角度来看， 我们可以划分为两个平台，基础运维平台和应用运维平台。基础运维平台是统一的，在阿里有且只有一个，内部叫StarAgent。但是应用类型比较多，每个业务都有特殊性，所以允许除了通用的“应用运维平台”外，有多个面向业务的特色的“应用运维平台”，但也都是构建在通用的“应用运维平台”之上，内部叫Normandy。

StarOps当然不会包含所有的运维能力。但对于互联网企业或者传统企业+互联网的场景，大部分公司需要的是运维能力，StarOps会全部包含，主要集中在基础运维能力(服务器管理)到应用运维能力(PaaS平台)上。而且可以根据用户自身的需求来自定义选择。两个平台本身也具备扩展能力，可以根据我们的SDK来扩展企业自身的业务特色。

 

除了运维平台本身外，还包含软性的一些运维规范，故障治理的原则等。另外，我们在智能化运维方面已经有了实践， 通过算法平台融入到了两个平台的能力上。在界面上，我们提供Web， API，命令行工具，手机客户端，甚至提供大屏产品。

基础运维平台

基础运维平台可以说是IT运维的基础设施， 阿里非常重视运维基础设施的建设，这个系统是对众多运维系统共性部分的抽象，对上层的运维业务建设至关重要。 在前面提到的5个运维能力层次中的所有系统都要依赖他， 所以重要性也尤其突出。基础运维平台主要功能是服务器访问的通道（命令通道、文件通道、数据通道），职责是维护企业所有服务器访问的安全，这里的服务器包括物理机、虚拟机和容器。

StarOps产品里主要包含有三大系统：1.堡垒机 2.StarAgent 3. 蜻蜓

堡垒机

阿里巴巴堡垒机

堡垒机，也可以叫跳板机， 是服务器访问的一道屏障。阿里的堡垒机是全球部署的，具备统一的账号/权限/密钥等管理，访问控制，高危拦截，操作录屏等功能， 最高可以承载5000人同时在线， 并通过了ISO27001等认证。

StarAgent

StarOps套件中的基础运维平台，就是在阿里巴巴运维多年实践上沉淀的结果。这个产品的名字叫StarAgnet，它可以当之无愧的说是阿里巴巴IT运维的基础设施。

 

从1万服务器发展到10万台，又逐步达到百万级服务器，基础设施重要性并不是一开始就被意识到的，是逐渐被发现的过程。无论是运维系统稳定性、性能、容量显然已经无法满足服务器数量和业务的快速增长。在2015年我们做了架构升级，StarAgent日均的访问量从1000万提升到了1亿多，系统稳定性从90%提升到了99.995%。

 

稳定性另外体现在高可用上，我们内部有定期的断网演练，任何一个机房网络断掉，自身服务终止影响面都控制在一定范围，都不会对整体的稳定性产生影响， 只要网络、服务恢复，受影响的集群就自动恢复。这种演练在内部是常态进行的，保证我们每个版本的代码都保持健壮。

 

StarAgent 是安全的，我们有非常多的安全策略，比如命令执行的范围控制，账号控制，白名单、黑名单控制，高危命令审计/拦截，全链路加密签名等，在阿里内部安全部有定期的攻防演练，StarAgent无疑就是演练重点。

 

在阿里内部如果说运维效率比较高，原因之一就是我们的StarAgent基本上统一了运维的通道，任何BU任何系统都不会擅自也不允许去建设自己的通道，统一的好处就是可以统一监管，同时也减少了不必要的重复建设。每个业务运维系统只要建设自己的业务即可。

 

刚才提到了基础设施影响面比较大，所以在建设的时候必须有预见性，在性能方面我也对未来5年服务器和业务的增长作出了预估，使我们的这次架构升级至少5年内不需要再次重构， 我们可以在此架构之上构建更多的业务，不会让稳定性和性能羁绊运维业务的发展。目前StarAgent可以满足每分钟55万次调用，几乎对外部系统没有强依赖，数据库、缓存即使失败也不会对系统造成非常重大的影响。

 

StarAgent的架构是灵活的，新的架构是基于插件的模式，插件可以是静态的(脚本、命令)，也可以是动态的(后台服务)，Agent Core 会保证这些插件执行的安全，同时又保证在一定的资源消耗之内， 否则就会杀掉(重启)这个插件进程，插件的开发者当然会收到消息。插件的使用者可以决定在自己的机器上(业务范围内)运行哪些插件，或者停用哪些插件，以及插件需要的版本，默认情况下插件的版本会自动更新。默认的插件当然是平台来维护的， 目前在阿里内部我们已经有了150多个插件，其中包括监控、日志服务、调度、文件分发等。每个插件都可以看作是一个运维系统，而StarAgent的职责就是守护这些运维系统的执行，保证全集团服务器和业务的安全运行。

 

插件的模式同时也简化了Agent本身的运维，Agent Core 是没有任何业务属性的， 职责清晰简单，只做插件的维护和必要的自运维， 所以在版本稳定后，基本上不需要太频繁的更新， 这也符合装机镜像3个月更新一次的频率。

 

对于一个运维百万级服务器的基础平台，本身的运维负担也是比较重的，以前至少需要3个专职的运维，尤其是阿里的网络、服务器环境比较复杂，每天答疑工作也不少。但很多工作其实可以总结出规律，提炼抽象，让机器去做， 所以目前新版的StarAgent自运维能力已经达到95%，不再需要专职的运维了。

 

其他功能诸如Web终端，分布式定时任务等，在云效使用手册里可以找到。不再赘述。

手册查看：云效微信号（ ali_yunxiao）菜单栏-云效产品-使用指南

蜻蜓

蜻蜓是基于P2P的文件分发系统，不管是什么类型的业务运维都需要文件分发，所以也是基础设施之一。它的好处是保护数据源，加速分发速度，节约跨IDC和跨国的带宽。

 

下图是一个500MB文件分发的对比测试，X轴是客户端数量，Y轴是分发时长，可以看出传统的文件分发系统随着客户端数量的增加，时长就会增加，而且到1200客户端后就没有数据了， 因为数据源已经被打爆， 在该测试中蜻蜓可以完美的支持到7000客户端，分发时长基本保持在10秒左右。

在阿里内部，典型的应用场景包括：软件安装包、配置文件、数据文件、静态文件、镜像等。镜像包括了物理机镜像、虚拟机镜像、容器镜像。对于容器可以支持Docker，Pouch(阿里自研的容器技术)，Hyper等。架构上非常灵活，没有侵入性，不需要对容器技术做任何改造。

 

高级的功能特性还包括断点续传、智能网络流控、智能磁盘流控、动态压缩、镜像预热等。

  

在阿里内部这个系统的业务覆盖率在95%以上，月均分发量达到了15亿次，容量达到3000TB以上。蜻蜓同时也是双11背后的支撑技术，在双11前，需要完成15GB的数据文件分发到超过1万台服务器上。

应用运维平台

StarOps套件中另一个是应用运维平台，是架构在基础平台之上的混合云PaaS平台，在内部我们叫Normandy。

 

应用运维平台总体上来说是有三大组成部分： 资源管理、发布部署、日常运维。

 

一个应用要正常运行，需要资源，资源不仅仅是服务器（物理机、虚拟机、容器）， 还包括网络（VIP、SLB、DNS等），存储，数据库，中间件等，凡是一个应用正常运行需要的所有的物理资源和服务资源都包括。

Normandy是通过资源编排实现资源的provision(生产)的，通常也被叫做Infrastructure as Code。通过代码的形式将一个应用需要的所有的物理资源和服务资源，以及他们之间的关系都编写在一段类JSON的代码里， 并保存在CMDB中，而且是版本化的， 也就是说资源的任何一次变更改动都会被记录在案。 这也就形成了用户(通常就是应用的研发)对应用部署的基础架构(infrastrucure)的基本需求或者定义。

 

Normandy对于资源的需求和资源实际情况(通常称为资源实例Instance)会做对比(difference)，如果资源实例和资源的用户的定义不同，则会触发资源的生产(provision)直到资源的需求被满足。这也可以被称为自动化的资源生产，也可以被称为资源管理的自愈。如果仅仅就服务器来说，它的功能和Kubernates的ReplicaController是一致的。

 

既然是混合云PaaS平台当然是支持企业内部IDC的同时也支持阿里云，所以应用可以是部署在自有IDC也可以部署在阿里云，也可以一部分在自有IDC，一部分在阿里云上。

 

混合的模式适合那种初步尝试公有云的企业， 也适合那种在个别时间段(比如大促场景，或者压力测试)下需要额外资源的企业，需要的时候在公有云上“弹”(scale out)，用完了再缩回来(scale in)。

阿里巴巴监控智能基线视图

发布(Release)和部署(Deploy)其实是两个不太一样的概念， 发布是用户可见的，部署则未必。Normandy当然可以同时满足客户两种不同的选择。默认情况下部署就等同于发布，当然用户可以自己定制部署而不发布应用(这种需求比较小众)。

 

Normandy支持的发布模式比较多样，发布策略也很多，这跟阿里内部需求的多样性有关。同时也支持容器发布和非容器的发布(我们叫基线模式)。除此外，还支持动态配置或者开关类型的发布(需要中间件支持)。在能力上则支持2万台服务器同时发布，日均可以支持50万次发布。

 

在发布上我们有运维算法平台的支持，可以做到“无人值守”发布， 所谓的“无人值守”发布意味着用户不再需要盯着发布了， 发布系统如果发现系统有故障就会自动停止发布并通知用户， 如果一切正常则自动发布完成，无需人的干预。

 

运维越来越需要得到算法平台的帮助，将人的经验“沉淀”到系统里，不断的累积和完善数据，并依靠算法的帮助来提高运维系统的自动化程度，让人少犯错，尤其是低级的错误。而发布部署是很多故障造成的根源，这种故障给很多企业造成了巨大损失。如果能在这个地方堵住故障，将极大地提升企业运维稳定性。

监控

StarOps套件还提供了不同维度的监控系统，我们有基础监控(IDC层面)也有系统监控和业务监控，可以分别部署。监控系统我们也在做智能化运维探索，比如智能基线， 可以让我们彻底结束一个业务监控数十个监控配置的困扰，可以预测下一个时间点的业务走向，监控配置只要根据这个“智能基线”来配置阈值即可。同时我们的监控系统还具备智能故障定位的功能。

 

历经阿里纷繁复杂的业务和双11的各种考验，监控除了丰富的功能和稳定健壮的内核，还提供了非常炫目的视觉产品，除了传统的PC屏外，我们还有大屏产品可以独立部署。

   

阿里巴巴智能化运维大屏

除了前面提到的基础运维平台、应用运维平台、监控、算法平台外， StarOps套件还包括了诸如掌上运维(支持IOS， Android)，ChatOps等功能。            

智能运维 AIOps

简单的讲运维本质是帮助业务持续稳定的运行所要做的所有维护性的工作。 在保持业务稳定性的基础上能降低运维成本，提升运维效率，是运维系统的核心本质。

 

智能运维(AIOps)是需要融入在平台方方面面的。智能运维是从手工运维到自动化运维一步步走过来的一个自然的结果， 需要场景、数据和算法。

 

我个人对智能运维的理解是：利用运维算法实现运维的自动化，最终走向无人化运维。所以Gartner对AIOps的解释是Algorithm IT Operations，并不是一开始以为的人工智能(Artificial Intelligence)运维。

 

我个人认为AIOps可以在两方面来帮助运维：

 

一、稳定性：运维的本质就是维护系统的稳定性，如何能让系统平稳的运行，变更更加稳定，故障全面治理是首要考量的，所以稳定性方面的智能运维技术演进大致是：

 

异常检测(Reactive)-> 根因分析(Root Cause Analysis)->根源定位(real time) -> 故障自愈(auto-healing)-> 故障预测(proactive)

 

无人值守发布中应用的是异常检测的算法，而智能故障定位需要用到的就是后两种技术。

 

二、效率：在稳定的基础上我们希望能看到极致的运维的效率，极低的运维成本。

 

智能参数调整系统优化

智能调度、扩容、限流、降级…

 

智能运维的场景很多，在运维的每层都有用武之地。每个点的微创新的累积最终会给智能运维带来颠覆性的变化。真正实现这种专家经验和”拍脑袋“运维模式转变为基于算法和人工智能的自动化运维，最终走向无人化运维。

 

“无人化”当然短期内只是一个“自动化程度非常高的”的代名词，在可以看到的未来，“无人化”还是由人来干预或者参与的，尤其是故障处理。

 

其实自动化被叫做“自働化”更为合理， 人和机器更多是职能上的区别，需要优势互补，人不再做具体的操作了，由机器替代，但人依然是运维的灵魂，是运维的制定者和修改者，机器只是执行者，机器只是帮助人或者提醒人来完成运维操作。

阿里巴巴智能化运维能力体系

总结

运维对企业很重要，可以说是核心竞争力，不能让运维拖了业务的后腿。

 

• 基础运维平台是运维体系建设的基础设施， 是运维成败的关键。
  
• 稳定是运维的本质， 在稳定性的基础上追求极致的运维效率和极低的运维成本。
  
• 智能运维不能一蹴而就，必须按部就班，重在场景和数据的建设。

云效2.0 智能化运维产品体系

 

很多公司业务发展的非常好，但就是运维做的不好，导致业务非常不稳定，三天两头出故障，一出故障半天才能恢复。一做发布变更就交易跌0造成资损。如果长期这样的话，再好的业务也会做黄。这种例子我们看到的比较多。

 

随着阿里巴巴越来越重视技术，也越来越开放，运维的几个产品会逐步开源，同时也会有商业化的产品孵化，比如最近在做的云效2.0-智能化运维产品StarOps，我们希望阿里在运维领域多年来沉淀的经验、走过的弯路，能给大家带来些启发，也希望StarOps产品能真正为企业的业务保驾护航。

 

云效2.0 智能化运维产品体验： https://www.aliyun.com/product/yunxiao 

同步直播收看：智能运维——百万级服务器自动化运维怎么玩？11月 9日20:00 在线 开启！点击报名

PS: 云效2.0智能运维平台诚聘资深技术/产品专家， 共同打造具备世界级影响力的智能运维平台。

工作地点：杭州、北京、美国

详情链接：https://job.alibaba.com/zhaopin/job_detail.htm?refNo=GP042139