如何提升cpu的利用率（怎么解决cpu的利用率） - 原点资讯

图 3 MetricsQPS 公式

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

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

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

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

如下图所示：

如何提升cpu的利用率,怎么解决cpu的利用率(5)

图 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 以上，如图所示：

如何提升cpu的利用率,怎么解决cpu的利用率(6)

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

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

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

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

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

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

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

总结

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

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

如何提升cpu的利用率,怎么解决cpu的利用率(7)

图 6 降本流程图

降本配套设施

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

需要明确算力衡量指标体系，前期可以粗略使用 CPU 利用率等系统指标，后期需要借助精准的业务指标，比如 QPS 及单请求的耗时结合的复合指标。
降本过程需要有较完备的监控告警系统及容灾 SOP，防止在优化过程中出现意外情况。比如在优化低频冗余算力环节，小王在下机器的时候，提前根据 CPU 等指标设置好了扩缩容策略，在系统保持一周无异常后才将下线的机器清退。
为了精准量度业务算力，需要搭配压测系统及方案。前期为尽量减少业务投入成本，主要是基于以下思路来操作：测试环境 ->线上日志回放 ->mock 调用接口 ->采集算力衡量指标 ->逐步放大调用压力 ->响应超时的服务器达到一定比例时结束压测。后期可以逐步迭代为全链路压测，从网关到调用链路到存储全隔离的形态，衡量效果会更精准，当然相应研发成本和投入也会更重。
为了充分体现每一步的优化成果，需要有成本看板，对每一阶段优化前后的机器资源和成本消耗进行环比或横比展示。成本看板主要针对中高层人群，所以信息要简明扼要，成本信息突出。

降本遇到的非技术问题

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

项目切入时机问题：
降本工作不仅仅是运维部门或基础架构部门的工作，同时还需要成本管理部门、财务部门、业务部门等多部门协同。降本工作的推进也会影响稳定性保障、业务研发等工作，所以降本工作需要先成为公司的重点项目或者产研团队的 KPI。
由于改造的投入成本和机会成本都很高，所以要求改造带来的收益要足够大。
立项及项目团队组建：
公司确定降本工作是重点项目后，还需要在公司层面或者产研层面进行正式立项，指定项目负责人、项目技术负责人等，并明确项目的目标，以及项目人员的沟通。原则上所有受降本影响的部门都要派出自己的代表，实际可以确保所有的职能都派出代表，这样既能控制项目组规模又有足够的代表性。
比较好的项目组核心人员组合是，由收益最大或工作量最大的部门作为项目的负责方并派出项目负责人，受影响最大的部门派出技术负责人。
成本变革问题：
云化、弹性等都会带来新的预算管理和成本核算方式，需推动公司内部成本管理机制升级。在项目早期，就要对降本项目的优化效果进行量化。只有明确的、量化的目标和明显的收益，方能为各个部门提供足够动力配合推进。
项目推进中的故障问题：
项目在推进的过程中，如果出现严重故障，会极大影响公司对项目的信心以及各部门的支持力度，最坏的情况下甚至会导致项目流产。项目组成员一定要包括试点业务的相关负责人或代表。试点业务要适中，过小的业务没有代表性，而如果业务过大，一旦出现问题，后果会很严重。
在试点业务成功实践之后，再推动到公司的核心业务。核心业务有足够的代表性和说服力，只有在核心业务落地才可能在全公司全面落地。核心业务落地的关键点是做好包括回滚方案在内的各项预案，做到即使出问题也不要影响到核心业务。这也需要项目组与核心业务密切配合，核心业务的负责人或代表最好就是项目负责人或者技术负责人。
项目如何推广到全公司：
项目在单个业务落地后，需要继续往全公司推广，此时会遇到各个部门的支持问题，需要先找一两个典型业务作为标杆，等标杆业务有了效果再继续往其他业务推广。
通过技术沙龙等方式对项目进行介绍和宣传，让标杆客户一同参与宣讲，并广泛邀请潜在的业务部门参与。
项目在公司 30% 以上的业务推广开后，可以寻求高层的支持加快项目的推广，有了试点效果后高层更乐于协助推进。
项目完成后的日常保障：
项目完成后需要由职能团队负责日常的维护和保障工作。通常会放到项目负责人所属的团队，但也可能按照项目成员所在部门进行保障分工。总的原则是，项目推进期间公司比较重视参与的人也多可以跨职能，而项目完成后项目组成员多数回归原团队，保障工作分配尽量契合原有职能分工。
项目的收益分配问题：
针对项目收益分配，比较好的做法是把各种收益进行拆分，然后再依据分别的贡献进行分配。比如项目整体荣誉归项目组、项目管理的收益归项目负责人及其所在部门、项目技术上的收益归技术负责人及其所在部门、各模块的收益归模块负责人及其部门。在晋升时也需要项目负责人协调好各自的边界，避免相互冲突的情况。
项目负责人及其所在部门要把更多的利益分给项目组中其他的部门，从而更好地激励大家积极参与之后的其他改造与建设项目。

结语

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

在推动层级方面，公司成本优化总体来说是一把手工程，过程中难免需要各部门的协同配合及利益分摊，所以由 CTO 发起并提供支持是小王完成成本优化目标的重要前提。
在优化手段方面，和小王相同场景的公司在第一阶段通过一些成熟的业界通用做法就能取得还不错的降本效果，可以此作为让全公司认可降本价值的敲门砖，这样在第二阶段引入外部系统做深入优化就能更顺利。
在优化节奏方面，建议先从成本占比、优化难度、优化效果、是否核心等维度对业务进行排序打分，先从成本占比大，优化难度小，优化效果明显、非核心的业务开始优化。

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