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。
堡垒机，也可以叫跳板机， 是服务器访问的一道屏障。 阿里的堡垒机是全球部署的，具备统一的账 / 权限 / 密钥等管理，访问控制，高危拦截，操作录屏等功能， 最高可以承载 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 秒左右。
Normandy 是通过资源编排实现资源的 provision(生产) 的，通常也被叫做 Infrastructure as Code。通过代码的形式将一个应用需要的所有的物理资源和服务资源，以及他们之间的关系都编写在一段类 JSON 的代码里， 并保存在 CMDB 中，而且是版本化的， 也就是说资源的任何一次变更改动都会被记录在案。 这也就形成了用户 (通常就是应用的研发) 对应用部署的基础架构 (infrastrucure) 的基本需求或者定义。
Normandy 对于资源的需求和资源实际情况 (通常称为资源实例 Instance) 会做对比 (difference)，如果资源实例和资源的用户的定义不同，则会触发资源的生产 (provision) 直到资源的需求被满足。这也可以被称为自动化的资源生产，也可以被称为资源管理的自愈。如果仅仅就服务器来说，它的功能和 Kubernates 的 ReplicaController 是一致的。
既然是混合云 PaaS 平台当然是支持企业内部 IDC 的同时也支持阿里云，所以应用可以是部署在自有 IDC 也可以部署在阿里云，也可以一部分在自有 IDC，一部分在阿里云上。
混合的模式适合那种初步尝试公有云的企业， 也适合那种在个别时间段 (比如大促场景，或者压力测试) 下需要额外资源的企业，需要的时候在公有云上“弹”(scale out)，用完了再缩回来 (scale in)。
除了前面提到的基础运维平台、应用运维平台、监控、算法平台外， StarOps 套件还包括了诸如掌上运维 (支持 IOS， Android)，ChatOps 等功能。
智能运维 AIOps
简单的讲运维本质是帮助业务持续稳定的运行所要做的所有维护性的工作。 在保持业务稳定性的基础上能降低运维成本，提升运维效率，是运维系统的核心本质。
智能运维 (AIOps) 是需要融入在平台方方面面的。智能运维是从手工运维到自动化运维一步步走过来的一个自然的结果， 需要场景、数据和算法。
我个人对智能运维的理解是：利用运维算法实现运维的自动化，最终走向无人化运维。所以 Gartner 对 AIOps 的解释是 Algorithm IT Operations，并不是一开始以为的人工智能 (Artificial Intelligence) 运维。
我个人认为 AIOps 可以在两方面来帮助运维：
一、稳定性： 运维的本质就是维护系统的稳定性，如何能让系统平稳的运行，变更更加稳定，故障全面治理是首要考量的，所以稳定性方面的智能运维技术演进大致是：
异常检测 (Reactive)-> 根因分析 (Root Cause Analysis)->根源定位 (real time) -> 故障自愈 (auto-healing)-> 故障预测 (proactive)
无人值守发布中应用的是异常检测的算法，而智能故障定位需要用到的就是后两种技术。
二、效率： 在稳定的基础上我们希望能看到极致的运维的效率，极低的运维成本。
智能参数调整系统优化智能调度、扩容、限流、降级…
智能运维的场景很多，在运维的每层都有用武之地。每个点的微创新的累积最终会给智能运维带来颠覆性的变化。真正实现这种专家经验和”拍脑袋“运维模式转变为基于算法和人工智能的自动化运维，最终走向无人化运维。
“无人化”当然短期内只是一个“自动化程度非常高的”的代名词，在可以看到的未来，“无人化”还是由人来干预或者参与的，尤其是故障处理。
其实自动化被叫做“自働化”更为合理， 人和机器更多是职能上的区别，需要优势互补，人不再做具体的操作了，由机器替代，但人依然是运维的灵魂，是运维的制定者和修改者，机器只是执行者，机器只是帮助人或者提醒人来完成运维操作。
很多公司业务发展的非常好，但就是运维做的不好，导致业务非常不稳定，三天两头出故障，一出故障半天才能恢复，一做发布变更就交易跌 0 造成资损。如果长期这样，再好的业务也会做黄。这种例子我们看到的比较多。
随着阿里巴巴越来越重视技术，也越来越开放，运维的几个产品会逐步开源，同时也会有商业化的产品孵化，比如最近在做的云效 2.0- 智能化运维产品 StarOps，我们希望阿里在运维领域多年来沉淀的经验、走过的弯路，能给大家带来些启发，也希望 StarOps 产品能真正为企业的业务保驾护航。
渴望了解更多双 11 背后最新的技术架构2 月 8-11 日，请前往由 InfoQ 举办的 ArchSummit 全球架构师峰会 北京站，大会与阿里巴巴合作策划了 双 11 架构专场，并邀请了顶级技术专家担任出品人，设置了“新一代 DevOps”、“人工智能与业务应用”、“架构升级与优化”等 17 个热门话题，更多详情可点击 阅读原文 了解大会日程。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！