阿里技术实战：数十万云服务器如何高效运维？

上云后需要运维吗？答案是：当然需要。

上云确实简化了一部分的运维工作，比如传统 IT 中服务器的日常运维等工作都交由云服务商来完成了。但随着云上产品种类的不断丰富和规模的不断扩大，云上资源如何高效运维正逐渐成为运维人员的挑战。

在刚刚落幕的QCon全球软件开发大会（上海站）2020的“弹性工程与运维”专题中，阿里云高级技术专家赵昱（巴梨）针对云上运维话题，分享了阿里经济体全面上云后，如何实现云上数十万台的 ECS 实例自动化运维的实践与经验，本文根据其演讲整理。

阿里云高级技术专家赵昱

云上运维的四大挑战

随着云计算的普及和发展，越来越多的企业选择上云。近几年，阿里经济体在全面上云，在云上运维方面与大多数企业遇到的问题类似，总结来说主要是来自以下四个方面：

• 第一，规模问题。传统的 Human Ops 和写脚本的管理方式在资源少的情况下是玩得转的，但是当规模一大就不行了。人肉管理几十台机器和几万台机器是完全不同的概念，再加上云上资源类型不断丰富，云上资源管理和运维的复杂度指数级上升。

• 第二，安全问题。阿里经济体上云涉及数百个业务方，涉及的运维人员非常的多，如何更好地进行权限控制、审计和审批都既复杂、又非常重要。数据和资源是公司的资产，运维权限过大、增加失误风险，权限过小、增加管理成本，如何安全地使用云账号和资源为管理者带来极大的挑战。

• 第三，效率问题。随着资源规模的增长，如何高效地管理运维、提升研发人员的效率，也是云上运维必须思考的问题。

• 第四，成本问题。业务方在成本优化方面的需求比较明显，包括资源使用人员和财务人员，希望能够提供不同维度的资源使用账单，以便为成本优化举措提供依据。

我们知道，传统方式下资源的分配有专门的资源运营团队负责，项目开发团队只负责使用资源。但是随着业务规模的不断扩大，这种管理方式基本上是不可行的，这时候需要通过分权将基础配置管理权交给业务项目组自行承担，而这种运维模式的转变对企业云上资源管理也提出了挑战。

事实上，阿里经济体云上运维也经历了人肉运维到标准化、数据化和流程化运维的过程。直到 2016 年，内部云上资源管理平台“宙斯运维系统”的雏形基本形成，实现了运维能力和经验的标准化、流程化和系统化。随着资源管理规模的日益庞大和需求多样化，宙斯运维系统随后又接管了云上资源的管控工作。

数十万云服务器如何高效运维？

当前，宙斯运维系统管理着阿里集团内部数百个业务方的 20 多种云上产品和资源，包括数十万台的 ECS 实例，不仅为各业务方提供资了源管理和运维能力，而且还提供了成本分析和治理能力。

图：宙斯运维平台整体架构

整体来说，宙斯运维平台包含资源管理、系统运维、应用运维、监控管理和成本分析五大模块。向上通过控制台和 OpenAPI 为业务方提供服务，向下依赖阿里云平台的云监控、资源编排、运维编排、标签系统、弹性伸缩、运维通道和财务系统等服务，来管理日志服务、云服务器、网络、对象存储等众多云上资源。

账号管理

因为历史原因，宙斯运维平台支持独立大账号和托管账号的两种账号模式并存。独立大账号是宙斯系统运维平台在阿里云平台的服务账号，账号下管理非常多的业务方的资源，业务方将运维功能全部托管到宙斯，因为可以减少很多前置的工作，所以独立大账号是我们推荐业务方的方法。另外，因为是服务账号，不允许业务方直接登录的，业务方只能通过白屏化入口进行操作，减少了操作失误风险。

对于托管账号，它是在宙斯运维平台之前的存量运维账号，为了帮助业务方更好地管理这些存量账号，宙斯运维平台提供了账号托管服务，这些存量账号授予宙斯服务账号的管理员权限，因为托管账号的主子账号与集团的登录系统打通，运维人员可以直接登录来管理。

权限管理

权限管理的主要思路是进行应用分组，应用分组以角色进行权限区分，给予人相应的应用上的角色。

我们给予应用 Owner、开发、运维和安全等角色，对不同的角色予以不同的权限 。Owner 角色拥有应用下资源管理的上帝权限，也负责审批工作；开发人员是日常 CI 工作，以及日常、预发环境的测试工作；运维人员拥有线上发布审批的能力；安全人员主要负责系统运维工作，包括安全扫描、代码扫描等安全工作。

这里所有的云资源都是通过标签挂载到相应的应用上，通过这样的一个权限管理，管理员不仅可以在人的维度上可以看到有权限的应用，也可以应用维度上看到有权限的人。

资源分组

基于阿里云的标签系统，宙斯运维系统支持资源按很多个维度分类，比如按部门、环境、Region 等，宙斯运维系统给创建的资源打上相应的标签来方便业务方运进行资源的查找、管理和运维，通过标签管理的模式可以很好地对无序化的资源进行运维和监控、甚至是资源分账。

对于托管账号，可以通过 API 操作，系统通过解析离线的云监控消息通知，让业务方的标签是按照一定的规范来设置，监听到数据变化之后再同步到宙斯和 CMDB 中。

资源交付

对于资源交付来说，最大的挑战是云上资源是多区域、多类型部署的。阿里云平台目前有上百种资源类型，如果每个资源都通过写代码、写 API 的方式来进行操作，不仅复杂、效率还很低。而且，大多数的业务场景不是单字元的交付，若是挨个进行组合来操作，也非常耗时。业务方一般要求场景化交付，大多数业务场景是有一个规范化的常用范式，是可以通过场景化的交付大幅提升资源交付方式。

针对这类场景化交付的需求，一开始其实使用的是写脚本的方式来操作的，但耗费大量的精力和人力，效率比较低下。为了应对多种类型的资源分配场景，宙斯运维系统引入了 Infrastructure As Code 机制进行资源编排，开源的 Terraform 也是同样的思路。

这里，宙斯运维系统采用的是阿里云提供的 ROS 资源编排工具，同时引入集团审批流，将资源部署标准化、流程化。宙斯运维系统将常用场景抽象成本资源编排模板，通过模板一键按照一键按场景交付资源，通过模板这样的方式大幅提升了我们资源交付的效率，同时也降低了新资源的接入门槛。

运维管理

从运维工作类型来看，运维也是分层的。系统层面的补丁管理、安全扫描、安全防护等能力是一个平台的能力，是不需要业务方来关心，宙斯运维系统将这些能力抽象出来后提供统一的机制来管理。

应用层面，主要涉及到资源的运维和 CI/CD。应用资源运维，宙斯运维系统将常用的运维动作抽象成运维编排模板，借助阿里云运维编排服务进行工作流编排，在定义常用运维场景同时支持业务方自定义运维操作，这样可以实现运维流程可积累可复制。另外，利用底层能力支持定时、告警、事件触发的运维操作，进一步提升运维操作效率。

CI/CD 部分，宙斯运维系统主要使用了阿里集团的 Aone(云效)系统，支持基于软件包和镜像的分批发布，同时允许自定义操作。

监控告警

从信息源的角度分类，告警和监控可以分为资源监控、应用监控以及业务监控，越往上监控和告警的准确率越高、但通用性越低。宙斯运维系统实现了多种告警处理方式，通过与监控系统的集成将告警按分组联系人分发，比如短信、钉钉等信息；对于自动化的场景，对接了弹性伸缩和运维编排来触发自动操作，实现自动化运维工作，完成自动化闭环。

诊断和修复

随着使用的资源和业务越来越多，内部业务方关于 ECS 实例、网络等问题的咨询量逐渐增多，为了提升问题的解决效率，同时运维平台也需要有自证清白的能力。于是，我们通过与阿里云内部 ECS、网络、操作系统等团队进行共建，利用历史数据形成了案例库、知识库，再加上专家经验，我们沉淀了诊断和修复的能力，通过一键诊断帮业务方快速定位具体问题。对于一些常见的问题，抽象出常用的修复脚本，提供一键修复能力。 

以 ECS 实例为例，通过实例的监控诊断定位出问题根因，同时我们提供出手动修复方案，同时我们也提供了使用运维编排一键自动修复能力，这个过程支持打快照回滚。通过这部分的建设，让我们日常值班的服务量大幅降低。

成本管理 

成本管理的目标主要是成本优化，有很多业务方申请了很多云服务器资源，使用中发现其实一些机器是没怎么用或是 CPU 利用率比较低，这就造成了资源的浪费。宙斯运维系统通过成本管理的建设，将成本管理的意识传递给到业务方，并推动业务方来完成成本优化。

成本管理的思路里，我们主要是在事前的卡点和事中的分账能力来实现。首先，在资源申请时做审批卡点，如果申请的资源规格特别高就会给出一些提示，询问资源申请是否合理；然后，在资源使用过程中，利用标签和应用分组的分账能力，把资源使用费用分摊到相应的部门和项目组，周期性地向业务方提供账单，财务根据部门的账单做分析，可以判断哪些项目是入不敷出的，同时也推动业务方自己去优化资源的使用。比如，是否切换到弹性伸缩上来优化成本，调整资源配置规格进行优化等等，从成本的角度推动业务方来做优化。

总结

本文主要介绍了阿里经济体上云过程中宙斯运维系统如何高效管理云上资源的经验，总结来说是通过标准化、流程化、自动化和数据化的方式来实现的，希望能给云上运维面临同样问题的运维人员一些参考。