应对双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屏外，我们还有大屏产品可以独立部署。