阿里巴巴智能化运维体系演进与建设
引言：DevOps
的概念提出接近10年了，提升协作效率，降低开发成本，更稳健可持续的业务运营是DevOps的主旋律。根据2016年DevOps调查报告显示，一个低效的IT组织跟一个高效的IT组织相比，差距可能是200倍，换句话说低效组织发布一个功能，高效组织可能已经发布了200个功能；故障恢复的效率差距可能是几十倍，低效组织花费几个小时恢复的故障，高效组织可能几分钟就搞定了。
在日益激烈的商业竞争环境下，这么低效的IT组织注定在商业上也是要失败的。因为现在是快鱼吃慢鱼的时代。去年Gartner又提出了AIOps的概念，就是用基于算法来提升运维效率，国内很多公司在各个运维的场景都有了不同程度的应用。
阿里巴巴对DevOps和AIOps有自己的理解和实践，外界也比较关注拥有众多业务的庞大组织，是如何开展DevOps的？
带着这些问题，阿里集团基础架构事业群运维中台负责人如柏，在2017杭州云栖大会云效《企业高效研发实践专场》上，详细介绍了阿里运维体系的演进和在智能化运维方面的工作，希望能给大家带来一些启发和借鉴。
嘉宾简介
毛茂德(花名：如柏)：阿里集团基础架构事业群运维中台负责人。主要负责云效2.0智能运维平台建设、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终端，分布式定时任务等，在云效使用手册里可以找到。不再赘述。
手册查看：云效微信号菜单栏-云效产品-使用指南
蜻蜓
蜻蜓是基于P2P的文件分发系统，不管是什么类型的业务运维都需要文件分发，所以也是基础设施之一。它的好处是保护数据源，加速分发速度，节约跨IDC和跨国的带宽。
下图是一个500MB文件分发的对比测试，X轴是客户端数量，Y轴是分发时长，可以看出传统的文件分发系统随着客户端数量的增加，时长就会增加，而且到1200客户端后就没有数据了，
因为数据源已经被打爆， 在该测试中蜻蜓可以完美的支持到7000客户端，分发时长基本保持在10秒左右。
在阿里内部，典型的应用场景包括：软件安装包、配置文件、数据文件、静态文件、镜像等。镜像包括了物理机镜像、虚拟机镜像、容器镜像。对于容器可以支持Docker，Pouch(阿里自研的容器技术)，Hyper等。架构上非常灵活，没有侵入性，不需要对容器技术做任何改造。
高级的功能特性还包括断点续传、智能网络流控、智能磁盘流控、动态压缩、镜像预热等。
在阿里内部这个系统的业务覆盖率在95%以上，月均分发量达到了15亿次，容量达到3000TB以上。蜻蜓同时也是双11背后的支撑技术，在双11前，需要完成15GB的数据文件分发到超过1万台服务器上。
应用运维平台
简体中文
