阿里智能运维平台如何助力研发应对双11挑战

12月13-14日，由云栖社区与阿里巴巴技术协会共同主办的《2017阿里巴巴双11技术十二讲》顺利结束，集中为大家分享了2017双11背后的黑科技。本文是《阿里智能运维平台如何助力研发应对双11挑战》演讲整理，在回顾了阿里巴巴运维历程后，为我们讲解了阿里基础运维平台和应用运维平台，并介绍了阿里相关运维产品及阿里在智能运维平台上的发展成果。内容如下。

分享嘉宾：

 

如柏（毛茂德），阿里巴巴高级技术专家，Apache顶级项目CXF初创成员之一，阿里集团基础架构事业群运维中台负责人，亲历者。

如柏：双11已经过去两周了，但双11的热度还在继续。双11从09年开始，到12年就变成了一个节日，变成了消费者日，商家感恩消费者的节日。不仅是阿里奉献给国人的一个节日，更是阿里奉献给世界的全球购物狂欢节，因为今天阿里的业务已经遍布全世界。业务的爆炸式的增长给技术带来前所未有的挑战，今年双11在技术上又创造了新的高峰。所以在在阿里内部，我们也常说双11是技术的练兵场，是业务和技术的大协同。每年双11后，阿里都会给大家分享阿里在双11中的前沿技术理念和技术成果，运维是阿里双11技术分享以来的首次分享。运维是业务的重要支撑，运维平台如何让业务在如此迅猛的发展下依然稳定、高效的发展是对我们巨大的挑战。

今天我给大家分享的是阿里智能运维平台如何协助研发应对双11的挑战。今天的分享主要分为四个部分：

• 回顾阿里运维历程
  
• 基础运维平台分享
  
• 应用运维平台分享
  
• 阿里在智能运维平台上的发展成果

阿里的运维和很多公司有相似之处，也经历了四个阶段：

• 使用命令行工具运维
  
• 系统化工具运维
  
• 自动化平台
  
• 智能化平台与无人值守实践
  

每个阶段的转变都是一个非常漫长的过程。在这个过程中我们一直秉承一个原则：让机器做人去做的事；让系统做可重复的事；让系统做人做不好的事。

运维是一个非常大的概念。很难用一两句话能描述清楚，在维基百科中，Operations有十几个解释。在我看来中文的“运维”其实非常好的描述了运维的本质，“运”就是让业务稳定持续的运行，“维”就是运行过程中针对任何出现的问题进行维护，使业务保持继续运行的能力。运维本质就是让业务稳定、高效的运做，并在此基础上逐步降低运维成本。运维的职责覆盖了产品从设计到发布、运行、成本技术优化及至下线的生命周期。

我们把运维分成五个层次。

• 资源：Quota管理、资源规划、资源采购、资源调度、bootstrap
  
• 变更：变更信息、应用变更、基础软件变更、网络变更、IDC变更
  
• 监控：基础监控、业务监控、链路监控、报警、视图
  
• 稳定性：多活、故障修复、故障定位、故障注入、全链路压测
  
• 规模化：一键建站、搬迁、腾挪、单元调整

在产品发布前，运维需要对产品的整体架构做合理评估，把控资源诉求，分析产品是否有单点、是否有足够的容量，是否可容错，是否有强耦合等。资源规划评估，包括所需的服务器资源、网络资源以及资源的分布等，同时把相关产品对资源预算申请的合理性，控制服务成本。

当所有的资源都到位后，把服务部署到线上，形成线上运行的业务。由于软件需要不停的迭代，这个过程中会发生如网络架构的变化、服务器淘汰等各种变更。

在运行过程中，监控是必不可少的。基础服务、基础软件、业务、舆情等各方面都需要做监控。

互联网的快速发展导致业务必须具备非常快速的迭代、快速部署，这要求运维要有规模化的能力，能进行快速复制。比如，如何让新收购的海外公司融入集团运维体系里，这是一个非常关键的业务。

运维的五个层次不可能只用一个系统来承载，每个层次都是有非常多的系统。基础运维平台和应用运维平台主要体现在资源和变更层次，一些监控、规模化的内容也涵盖在这里。我们把基础运维平台定义成IT运维的基础设施。

基础设施是怎样的？电、水、桥梁、机场都是日常生活中的基础设施，这些基础设施都有一些共同特征：稳定、安全、统一、有预见性、无需感知。如果电力的供应不稳定，经常发生断电，我们的财产和日常工作都会遭受到非常大的损失。如果自来水不安全，居民的生命也会造成非常大的损。在运维领域，我们也需要有稳定、安全、统一、有预见性的基础设施，保证业务的持续稳定发展。

StarAgent就是阿里运维的基础设施，它的稳定性已经达到99.995%。它也非常安全，因为它关系到整个阿里巴巴所有服务器、所有网络、所有业务。它有自我保护措施，保证任何人的操作都不影响整个集团的业务。

基础设施的统一包含统一的标准和统一的数据。统一有三个好处；

1. 保证不需重复建设一些系统；
   
2. 便于做全局优化；
   
3. 便于统一规划，避免不必要的返工。
   

多个BU建设几个同样的基础设施跟一个BU建设一个基础设施的成本投入是有很大差别的。如果不同团队做同一个设施，只有10%的差别，而专门的团队做基础设施可以做的非常精非常深。在阿里，我们利用中台的思想，把所有的基础设施统一到StarAgent上。

统一基础设施使我们能看到全局概况而不是某一个BU的情况，方便做全局的优化和高度抽象，保证系统具有可扩展性，能适应所有场景，这也是阿里中台思想的核心概念。

如果修马路的人只关注修马路而缺乏统一规划思想，忽略管线的铺设，把马路修完后又重新刨开处理管线的问题，就会造成很大的损失。运维基础设施也是一样，统一规划能避免重复的返工和成本的浪费。

基础设施必须具备预见性。新一代StarAgent在设计之初就考虑到了服务器数量和业务增长的趋势对稳定性和性能可能带来的冲击，保证在3-5年内无需重新架构，在这两方面都必须有预见性的考虑。

基础设施还有一个特点，就是我们不需要任何人感知到它的存在。如果人们都能感知到基础设施的存在，说明基础设施不够稳定，性能不够好。阿里做到现在很少有研发真正能感知到StarAgent系统，就像我们感知不到电，感知不到水，因为现在这些基础设施已经非常稳定，无需我们关注。

堡垒机主要是负责管理整个阿里账号、权限、访问控制、高危拦截、事后审计。阿里堡垒机在阿里是非常具有特色和竞争力的产品，能同时容纳5000人在线，也符合ISO的各个行业规范。

 

StarAgent是一个运维通道，是基础设施中最核心的功能。它主要分3层架构：中央管控、每个机房集群的管控，物理机、虚拟机、容器上的Agent。Agent是一个插件式管理。截止到目前为止，我们已经有150多个插件，1/3的插件属于后台进程类。

 

StarAgent的职责是保证所有插件、所有后台进程的稳定运行和作为运维的通道。我们在资源上做了很多限制，在插件安装前，开发者会定义每个插件所用到的内存、CPU、磁盘、网络上的流量。如果进程的运行超过限定范围，我们就把这个进程杀掉来保障服务器的安全。在运维通道方面，我们做了同步命令执行和异步命令执行，目前日均访问量达1个亿。

在安全方面，我们和集团的安全部合作，安排安全演练和攻防演练，保证系统的安全。我们也做了很多命令的拦截、全链路命令的加密等。

虽然系统庞大，需要的运维的人员并不多，95%的工作都已经自动化，包括IP端的自动关联、Agent的自检自愈等，因此百万级服务器只需半个人负责运维。当然要从半个人运维进化到无人值守运维是需要付出巨大的努力的。

蜻蜓是基于P2P技术的智能文件分发系统，在架构上与StarAgent类似。下图为蜻蜓与wget的技术对比。X轴代表并发客户端数量，从200到7000；Y轴代表完成一个500Mb文件分发的耗时。

 

从图中可以看到，随着客户端数量的增长，蜻蜓的耗时时间都控制在10秒左右，而传统文件分发工具耗时升高，甚至在客户端增长到1200个后，整个集群已无法工作，因为数据源已经被打爆了。蜻蜓不仅可以保护数据源、加快分发速度，也能节省跨IDC带宽，尤其在跨国业务上，能节省很多跨国带宽。在今年11月10日10点， 10000PB同时分发5GB预热数据到上万台服务器，这对蜻蜓是一个前所未有的挑战，也是业务方首次第尝试。今年双11我们完美完成了这个任务，并达到100%的成功率。

蜻蜓运用的主要场景是软件安装，阿里的发布系统也非常依赖于蜻蜓，目前阿里已整体实现Pouch化，所有的业务都已被容器化，在容器镜像的传输方面也是用的蜻蜓。蜻蜓除了支持特大文件传输外，还包括断点续传及一些智能化特性如智能网络、I/O的流控、智能磁盘I/O控制、智能动态压缩等等。

 

蜻蜓的访问次数已经突破了20亿次，分发量方面已突破了4PB/月，从图中可以看到分发量和镜像分发的占比，通过动态压缩，整体提速了30%。

蜻蜓已经在GitHub上开源了，开源协议是Apache2.0，蜻蜓开源版可以在 https://github.com/alibaba/dragonfly访问获取。蜻蜓企业版可以在云效或阿里云容器服务中访问获取。开源版与企业版蜻蜓有略微差别。

• 开源版功能：P2P文件分发，容器镜像分发、局部限速、磁盘容量预热
  
• 企业版功能：断点续传、全局限速、镜像预热、支持内存文件系统、智能网络流控、智能动态压缩、智能调度策略
  

 

镜像预热可以帮助我们在业务庞大时快速拉取镜像。比如应用有上万台服务器，如果发布过程中同时拉取镜像，耗时是非常长的。所以我们在发布前把镜像推送到就近机房的节点中。在真正发布时，就近拉取镜像，这样能大幅度减小的耗时。在实际运营中，根据双11的数据统计，经过预热后镜像拉取耗时降低了67%。

应用运维平台是真正面向研发的运维平台，是研发经常需要用到的平台。在应用运维平台上，我们提供了以下几个能功能。第一个功能是基础设施即代码。一个应用可以通过代码描述的形式把它需要的所有基础设施、所有资源描述清楚，并保存在CMDB上作为用户对应用的资源的需求。所有资源的变更都会被保存下来并且都是版本化的，运维人员可以非常清晰的看到资源的变化情况和操作者是谁。基于这个文本，定义后台所有资源的生产。我们还有定期巡检，查看实际资源与用户定义是否有差异。如果有差异，我们会自动化地帮用户调整资源，资源的弹性扩容和缩容也是基于这种方式做的。基于传统模式生产资源构建应用与这种模式相比效率相差几乎20倍。通过这种方式AE能快速在全球部署一个站，快速复制俄罗斯的一个站点等，得到很大的效率提升。

 

第二个功能是无人值守发布变更。传统研发在发布过程的每一步结束时查看各种监控指标及应用日志。在无人值守发布过程中，这个工作交给系统，系统会告诉你哪项指标有异常。人只需要在接收到指标时做评判和决策。判断异常是不是问题，如果不是，类似的问题可能不会再提出来。举个简单的例子，我们在写代码的时候都会写日志并保存下来，分析日志里是否发生异常。当分析出异常时，判断这个异常是否从未发生过，如果从未发生过，我们就会提示用户有一个新的异常，发布暂停并让用户确认。如果这个异常曾经发生过，但频率没有这次发布中高，我们也会认为这是一个异常并提示用户。类似这样的指标共有四十多项。通过无人值守发布，降低在发布过程中可能产生的业务故障。实际11月11日的24小时内，我们有大量的发布同时发生，无人值守系统非常好的保障了上线代码的质量。

 

应用运维平台在WEB端和移动端都可以使用，用户非常容易就可以在手机端得到无人值守发布、资源的创建等情况的消息并快速做出决策。除手机屏外，在阿里双11协同作战中也用到了很多监控大屏，这对沟通成本的降低非常有帮助。实际上，整个业务运维平台上有非常多运维大屏、业务大屏、技术大屏等。整个业务运维平台有PC端大屏、移动端小屏、作战大屏。下图是阿里全新设计的UI，也是在今年双11用到的大屏。

 

AIOps是2016年Gartner发布的新概念，强调基于算法的IT运维实践，核心是数据和机器学习。在AIOps闭环里会用到监控，观察所有业务运行状况，将这些数据分析处理，最后形成自动化执行任务。在智能运维里，最重要的是场景、数据、算法。所以AIOps跟阿里运维过程是密不可分的，在整个智能运维过程中核心问题是如何保证业务发展的稳定，在业务发展稳定后如何提升效率和降低成本。

 

“亻动”是日语里的自动化的“动”字，概况了我们目前在运维领域的状态，实际上我们所谓的自动化还是需要人的介入，人是非常关键的一个因素，所以智能化运维跟最终实现无人值守运维还存在非常大的差距。

下图是智能化运维的整体划分，跟自动驾驶非常相似的，从人工运维过渡到自动化，并且能一键化提示，最终实现无人值守运维的过程。

 

我们在运维平台做的最多的两件事是如何保证业务的稳定性和在业务稳定的基础上如何提升运维效率。在稳定性方面，我们做了异常检测、根因分析、根源定位，并且尝试做故障的自愈、故障的预测。在运维效率上我们做了智能参数的调整尝试。蜻蜓跟IDST合作在智能网络流控上做了一些工作，它的核心思想是蜻蜓在网络流控上提供参数，帮助我们设定蜻蜓可利用网络带宽的量，保证业务不受影响的情况下，最大限度的利用所有网络资源。之前我们让用户非常方便地设定参数，实际上这是不科学的。我们会做一个全局设定，通过智能化的参数调控、实时大数据分析知道下一个时刻需要用多少网络带宽，所有参数包括网络、磁盘、智能压缩都不再需要通过人为设定，而是系统在运行中自动化调整到最优的状态。

在自动化操作包括扩容、限流、降级也是同样的思想，不需要再人为设定固化的参数，让系统自动化的调到最优的状态。我们核心的思想就是希望以前基于专家的经验转化成算法和机器学习，充实到整个运维平台里。

 

上图是整个StarOps产品体系，最底层是所有的资源，包括云上资源、混合云资源。在这之上是基础运维平台，基础运维平台里由很多的模块组成的，如堡垒机、文件分发等。在基础运维平台上是应用运维平台，它涵盖资源、变更、监控、故障治理、日常运维等。横向的来看我们的算法平台覆盖了所有板块。除了上图显示的这些系统外，还有很多流程规范、运维红线、故障管理等。面向用户侧的是最上面的一层，有PC端的web、API、SDK、命令行、移动端运维、大屏等。

---