CPU利用率从10%提升至60%：中型企业云原生成本优化实战指南

作者 | 舒超

编辑 | 蔡芳芳

在互联网早期迅速发展时，相关领域企业更多注重于扩展业务，为了迅速占领市场，往往会投入较高的成本。然而，随着互联网人口红利逐渐消退，以及近几年的疫情影响，越来越多企业开始重视成本管理，从“粗放式经营”转变为“精细化运营”模式，成本优化成为企业重点关注事项。

本文将从一位中型企业运维总监的视角来展现一个较完整的成本优化实战案例，希望为读者提供可参考借鉴的成本优化思路。

降本实战案例背景

本文的主人公小王（化名）在某电商公司担任运维总监，他所在公司自建 IDC 机房，其中总共 1000 台业务服务器（在线 + 离线），由 3 名运维人员管理。机器规格大部分为 8 核 32G，整体 CPU 利用率仅 10% 左右，每年花销在 1000 万以上。

CTO 希望在现有业务市场条件不变的情况下，以业务稳定性为基本前提，将 IT 成本降低至少 30%，且将此定为小王今年的 KPI。

第一阶段

上云 + 公有云厂商 / 算力品牌对比选择

收到任务后，小王先将 IT 成本拆解为算力成本和人力成本两个部分。

目前 IT 成本主要由自建 IDC 机房承载，存在如下问题：

• 自建 IDC 机房机器数量缺乏弹性机制，不便于后期对算力做灵活伸缩；

• 自建 IDC 机房机器进入摊销末期，机型老旧且故障频繁，运维人力成本高。

基于以上分析，考虑到公有云机型更新便捷、基本免维护、可弹性的特点，小王计划先将业务迁移上云。

目前云厂商主要提供了预留实例（包年包月）、按需实例（弹性）、竞价实例三种方式：

• 包年包月：主要针对中长期稳定需求，优点是价格整体比较低，缺点是资源必须长期持有，灵活性差；

• 按需实例：针对短期弹性需求，按秒计费，灵活精准，避免浪费，但价格比较高；

• 竞价实例：以一定幅度的折扣购买，但可能会随时被系统自动回收的实例。价格最低可达到按需实例价格的 10%。由于此类实例随时可能被抢占，所以需要部署的服务应当尽量为无状态服务且有完备的保活和流量调配机制。

为确保系统稳定且尽量减少研发感知，小王先后采取了以下几项措施：

1. 将大部分无状态在线服务和一部分离线服务所在的大概 800 台机器，以包年包月的形式迁移到同等配置的公有云机器上；

2. 腾退相应私有机房机器，并将公有云与私有机房通过专线打通。这样既能保证在线服务上云之后的快速伸缩，又能兼顾数据传输成本及安全方面的考量；

3. 接入公有云相应的部署发布、监控告警、限流自愈等附属功能，从而节省出一个运维的人力。

在上云过程中，小王一方面根据公司需求对比多家公有云厂商后选择最匹配的云资源，另一方面将 CPU 品牌从 Intel 换成 AMD，两者叠加后，降低了 7% 左右的成本。

系统指标描述服务算力特征

完成混合云改造后，小王进一步将算力成本拆解为服务算力成本和基础设施资源成本：

• 服务资源指业务服务程序所消耗的 CPU、内存、磁盘、带宽等算力资源，相应成本取决于业务特征、业务运营行为、研发水平等多个因素；

• 基础设施资源成本指大数据、存储、中间件等底层组件和平台的成本。

结合公司目前的成本占比情况，服务算力成本占了其中的 60% 以上。

算力成本来源占比如下图所示：

图 1  算力成本来源占比

基于二八原则，小王决定以运维第三方视角，本着少侵入业务的前提，集中精力节省服务算力成本。

小王首先检查公司已上云的典型业务的算力特征。由于公司业务偏计算型，所以他选择通过常见性能指标 CPU 利用率来观察算力消耗情况，发现公司业务常在中午 12 点左右和晚上 8 点左右迎来算力消耗高峰。

如下图所示：

图 2   CPU 利用率指标算力图

优化低频冗余算力

根据上面的业务算力模型，小王发现即使业务完全处于高峰，所需要的机器数也不到现有数量的 80%。在公有云弹性的保证下，小王分阶段释放了历史高峰未触及的 200 多台 8 核 32G 包年包月冗余机器，节省了 20% 左右成本。

压测 + 公有云机型规格降配

在粗略去除明显冗余算力后，小王观察到业务算力即使在忙时利用率也不高，尤其是内存闲置较为严重。

接下来小王和业务一起进行了一次压测，最后得出业务机器规格保持在 8 核 3G 的配比，使用率相对均衡。而公有云机器 CPU 核数和内存配比一般是 1:2 或 1:4 的固定比例，所以小王按照公有云厂商的标准配置先将机器规格从 8 核 32G 降为 8 核 16G，节省了 20% 的成本。

小结

第一阶段的优化手段较为常规，取得了一些效果，小王总共节省了 40% 左右的成本，以较低成本吃到了第一波降本红利。

基于第一阶段的优化经验，小王总结出以下待改进点：

1. 根据 CPU 消耗所衡量出的算力消耗情况和业务的实际情况之间仍有一定差距。比如，经常会出现 CPU 消耗偏高但实际业务依然稳定、无需扩容的情况，这说明需要更加精准的算力度量指标。

2. 业务算力模型明显有波峰波谷，但是资源消耗的模型并未较好匹配，虽去除了未触达的冗余算力，但仍是以最高峰配置全时段占用算力，导致闲时浪费明显。

3. 公有云机器规格中，CPU 与内存的比例有明显限制，导致算力资源使用无法进一步均衡，造成浪费。

基于上述分析，小王分析出需要依次解决的三个问题：

1. 以更精准的业务指标，替代以 CPU 消耗为核心的物理指标；

2. 持续采集该指标，精准匹配算力波动曲线并实时联动扩缩容；

3. 获得更匹配实际业务的机器算力规格，提高资源利用率。

针对以上问题，小王对业界现有解决方案进行了调研，发现并无能直接借鉴的普适方法和经验，大部分实现方式都与特定业务场景绑定且需要研发深度参与。

为了能按期实现目标，小王尝试使用云原生基础治理平台 SchedulX 开始第二阶段的深入优化。

第二阶段

MetricsQPS 指标代替 CPU 指标精准衡量算力

小王借助 SchedulX 系统，在不让业务大规模改造的前提下，引入了 MetricsQPS 指标。该指标将 QPS 中不同请求对机器资源占用的时长纳入了考量，通过对 QPS 按时长进行分段并配以相应的权重最终拟合而成。相对于普通 QPS 指标，MetricsQPS 更能精确地反映出业务实际负载情况。该指标基本计算公式如下：

图 3   MetricsQPS 公式

小王利用这一指标执行了第一阶段的“优化低频冗余算力”操作，再次下线 60 台机器，节省约 10% 成本。

用弹性伸缩替换包年包月短时高峰算力

接下来，小王比较了公有云 8 核 16G 包年包月价格（约 600 元 / 月）与弹性机器价格（约 1.20 元 / 小时），发现包月机器 1 天的费用是弹性机器 30 天费用的 70% 左右。

由此推断，对于每天峰值时长低于总时长 30%（约 8 小时）的机器，可以用弹性代替包年包月。

如下图所示：

图 4  短时高峰弹性代替包年包月

对于其它规格的服务器，小王延伸推导如下:

设弹性扩容一台同规格机器 1 小时的成本为 Y 元，高峰时总机器数为 K1 台，高峰时段为 H 小时，包年包月合理机器数为 K2 台，则从省成本角度考虑，需要保证满足以下条件：

（K1-Ｋ2）* H * Y < （X / 30）*（K1 -Ｋ2） => H * Y < (X / 30)

由于 X、Y 均为相对固定值，所以按照此不等式可计算出适合弹性的业务峰值理论时长。于是，在留出一定的安全边际的前提下，小王借助 SchedulX 的度量和弹性能力再下线 50 多台机器，节省约 10% 成本。

包年包月算力低峰共享

面对剩余的包年包月机器，小王发现还是有优化空间的。从波形覆盖面积上来看，空洞波形面积（蓝色阴影面积）至少占到红框中矩形面积的 1/3 以上，如图所示：

图 5  包年包月算力低峰共享

小王计划将这部分机器利用起来，作为公司整体的共享资源池，供公司其它周期性及离线任务进行错峰使用。因为涉及面较广，小王请 CTO 一起出面推动协调，最终借助 SchedulX 系统贴合业务算力模型曲线实时扩缩容，共节省了 10% 的成本。

裸金属切割，精准适配规格

小王在完成以 MetricsQPS 指标按横向时序的算力优化后，再次将注意力集中到机器规格对业务需求的精准匹配上。

小王采用了公有云上的高规格裸金属服务器，借助 SchedulX 对公有云裸金属原材料进行了二次切割。虽然公有云上的裸金属也是按固定算力资源比例售卖，但是经过切割后的算力规格能够精准匹配业务 8 核 3G 的规格需求。同样是 500 台机器，相对原来的 8 核 16G 云主机，经过切割得出的 8 核 3G 机器能节省超过 15% 的成本。

利用算力地域价格差省成本

做完机器规格的精准裁剪匹配后，现在基本上单体算力规格和时序算力数量与类型都已经完成了优化，小王又将目光放到了算力的地域差异方面。他了解到公有云上西部机房同规格的算力比东部机房更便宜，通过将近 100 台离线服务器迁移到西部机房，同时借助 SchedulX 快速大批量数据迁移的能力实现东数西算，节省成本 10%。

总结

第二阶段基本解决了第一阶段遗留的精准度量算力、精准匹配模型、精准切割规格三大问题。两阶段下来，CPU 利用率上升至 60%，总共节省成本将近 70%，实现并超出 CTO 预期。

综合两阶段，小王的整体优化流程如下图所示：

图 6  降本流程图

降本配套设施

为了顺利推进成本优化，小王除了设计操作各种算力增减外，还借助了以下一些配套措施和系统：

1. 需要明确算力衡量指标体系，前期可以粗略使用 CPU 利用率等系统指标，后期需要借助精准的业务指标，比如 QPS 及单请求的耗时结合的复合指标。

2. 降本过程需要有较完备的监控告警系统及容灾 SOP，防止在优化过程中出现意外情况。比如在优化低频冗余算力环节，小王在下机器的时候，提前根据 CPU 等指标设置好了扩缩容策略，在系统保持一周无异常后才将下线的机器清退。

3. 为了精准量度业务算力，需要搭配压测系统及方案。前期为尽量减少业务投入成本，主要是基于以下思路来操作：测试环境 ->线上日志回放 ->mock 调用接口 ->采集算力衡量指标 ->逐步放大调用压力 ->响应超时的服务器达到一定比例时结束压测。后期可以逐步迭代为全链路压测，从网关到调用链路到存储全隔离的形态，衡量效果会更精准，当然相应研发成本和投入也会更重。

4. 为了充分体现每一步的优化成果，需要有成本看板，对每一阶段优化前后的机器资源和成本消耗进行环比或横比展示。成本看板主要针对中高层人群，所以信息要简明扼要，成本信息突出。

降本遇到的非技术问题

小王在推进降本过程中，还总结了一些遇到的非技术问题及主要解法：

• 项目切入时机问题：

• 降本工作不仅仅是运维部门或基础架构部门的工作，同时还需要成本管理部门、财务部门、业务部门等多部门协同。降本工作的推进也会影响稳定性保障、业务研发等工作，所以降本工作需要先成为公司的重点项目或者产研团队的 KPI。

• 由于改造的投入成本和机会成本都很高，所以要求改造带来的收益要足够大。

• 立项及项目团队组建：

• 公司确定降本工作是重点项目后，还需要在公司层面或者产研层面进行正式立项，指定项目负责人、项目技术负责人等，并明确项目的目标，以及项目人员的沟通。原则上所有受降本影响的部门都要派出自己的代表，实际可以确保所有的职能都派出代表，这样既能控制项目组规模又有足够的代表性。

• 比较好的项目组核心人员组合是，由收益最大或工作量最大的部门作为项目的负责方并派出项目负责人，受影响最大的部门派出技术负责人。

• 成本变革问题：

• 云化、弹性等都会带来新的预算管理和成本核算方式，需推动公司内部成本管理机制升级。在项目早期，就要对降本项目的优化效果进行量化。只有明确的、量化的目标和明显的收益，方能为各个部门提供足够动力配合推进。

• 项目推进中的故障问题：

• 项目在推进的过程中，如果出现严重故障，会极大影响公司对项目的信心以及各部门的支持力度，最坏的情况下甚至会导致项目流产。项目组成员一定要包括试点业务的相关负责人或代表。试点业务要适中，过小的业务没有代表性，而如果业务过大，一旦出现问题，后果会很严重。

• 在试点业务成功实践之后，再推动到公司的核心业务。核心业务有足够的代表性和说服力，只有在核心业务落地才可能在全公司全面落地。核心业务落地的关键点是做好包括回滚方案在内的各项预案，做到即使出问题也不要影响到核心业务。这也需要项目组与核心业务密切配合，核心业务的负责人或代表最好就是项目负责人或者技术负责人。

• 项目如何推广到全公司：

• 项目在单个业务落地后，需要继续往全公司推广，此时会遇到各个部门的支持问题，需要先找一两个典型业务作为标杆，等标杆业务有了效果再继续往其他业务推广。

• 通过技术沙龙等方式对项目进行介绍和宣传，让标杆客户一同参与宣讲，并广泛邀请潜在的业务部门参与。

• 项目在公司 30% 以上的业务推广开后，可以寻求高层的支持加快项目的推广，有了试点效果后高层更乐于协助推进。

• 项目完成后的日常保障：

• 项目完成后需要由职能团队负责日常的维护和保障工作。通常会放到项目负责人所属的团队，但也可能按照项目成员所在部门进行保障分工。总的原则是，项目推进期间公司比较重视参与的人也多可以跨职能，而项目完成后项目组成员多数回归原团队，保障工作分配尽量契合原有职能分工。

• 项目的收益分配问题：

• 针对项目收益分配，比较好的做法是把各种收益进行拆分，然后再依据分别的贡献进行分配。比如项目整体荣誉归项目组、项目管理的收益归项目负责人及其所在部门、项目技术上的收益归技术负责人及其所在部门、各模块的收益归模块负责人及其部门。在晋升时也需要项目负责人协调好各自的边界，避免相互冲突的情况。

• 项目负责人及其所在部门要把更多的利益分给项目组中其他的部门，从而更好地激励大家积极参与之后的其他改造与建设项目。

结    语

回顾整个降本之路，除了之前总结的执行中技术 / 非技术的问题外，还有以下几个点值得提出：

• 在推动层级方面，公司成本优化总体来说是一把手工程，过程中难免需要各部门的协同配合及利益分摊，所以由 CTO 发起并提供支持是小王完成成本优化目标的重要前提。

• 在优化手段方面，和小王相同场景的公司在第一阶段通过一些成熟的业界通用做法就能取得还不错的降本效果，可以此作为让全公司认可降本价值的敲门砖，这样在第二阶段引入外部系统做深入优化就能更顺利。

• 在优化节奏方面，建议先从成本占比、优化难度、优化效果、是否核心等维度对业务进行排序打分，先从成本占比大，优化难度小，优化效果明显、非核心的业务开始优化。

在互联网下半场的今天，降本增效作为企业大势所趋，甚至上升到了公司核心竞争力的层面。在林林总总的成本优化路径和手段面前，谁先朝正确的方向踏出一步，谁就有可能领先对手占据先机。本文综合讲述了一个典型腰部企业的降本之路，希望能对读者有所启发。如果读者有成本优化技术手段相关的需求，可以联系我们共同探讨。

本文大部分内容摘自《星汉未来云原生 IT 成本优化白皮书》，其中提到的 SchedulX 是由星汉未来打造的一站式云原生基础治理平台，目前已推出社区版，点击【阅读原文】即可获取白皮书、免费试用 SchedulX 社区版。

作者介绍

舒超，星汉未来 CTO。前美团基础研发负责人，存储中心总架构师，负责美团公司级云原生服务治理系统的开发及演进；前腾讯微博微群及消息流广告负责人。

今日好文推荐

10万 npm 用户账号信息被窃、日志中保存明文密码，GitHub安全问题何时休？

我们用了一个周末，将 370 万行代码迁移到了 TypeScript

阿里一季度员工减少4000人；程序员写脚本抢挂疫苗号，牟利40万被刑拘；搜狐遭遇史诗级邮件诈骗，张朝阳回应 | Q资讯

转载阿里开源框架Egg.js文档被告知侵权，原作者：难道我才是那个恶人？

点个在看少个 bug 👇