随着早期互联网的快速发展，相关领域的企业更加注重拓展业务，为了快速占领市场，往往会投入较高的成本。然而，随着近年来互联网人口红利的逐渐消退和疫情的影响，越来越多的企业开始重视成本管理，从“粗放经营”向“精细化经营”模式转变，成本优化成为企业关注的重点。
本文将从一个中型企业运维总监的角度展示一个完整的成本优化实践案例，希望能为读者提供成本优化的参考思路。
这个实战案例的背景
本文主人公小王(化名)，在一家电商公司做运维总监。他所在的公司自建了IDC机房，其中共有1000台业务服务器(线上线下)，由三名运维人员管理。大部分机器都是8核32G，整体CPU利用率只有10%左右，每年支出1000多万。
CTO希望在现有业务市场条件不变的情况下，在业务稳定的基本前提下，降低至少30%的IT成本，并将此定为小王今年的KPI。
第一阶段，云公有云厂商/算力品牌的比较和选择
接到任务后，小王首先把IT成本拆解成两部分：计算成本和人力成本。
目前IT成本主要由自建IDC机房承担，存在以下问题：
IDC自建机房的机器数量缺乏弹性机制，不便于后期计算能力的灵活伸缩；IDC自建机房已进入摊销期末期，机型老旧，故障频发，运维人力成本高。
基于以上分析，考虑到公有云模式更新方便、基本免维护、灵活等特点，小王打算先把业务迁移到云上。
目前云厂商主要提供三种方式：预约实例(包月)、按需实例(灵活性)和竞价实例：
全年包月：主要针对中长期稳定需求。优点是整体价格比较低，缺点是资源必须长期持有，灵活性差；按需实例：针对短期灵活需求，按秒计费灵活准确，避免浪费，但价格相对较高；竞价的例子：以一定的折扣购买的例子，但随时可能被系统自动收回。最低价格可以达到点播实例价格的10%。由于这样的实例可能随时被抢占，因此要部署的服务应该是无状态的服务，尽可能具有完整的保持活动和流量分配机制。
确保系统的稳定性，尽量减少研发费用。d感知，小王采取了以下措施：
每月将大部分无状态在线服务和部分离线服务所在的约800台机器迁移到相同配置的公有云机器上；清退相应的私有机房机器，通过专线连接公有云和私有机房。这样既能保证云后在线服务的快速扩展，又能兼顾数据传输成本和安全考虑；接入公有云相应的部署释放、监控告警、限流自愈等辅助功能，从而节省一笔运维人力。
在上云过程中，一方面，小王根据公司需求，在比较多家公有云厂商后，选择最佳匹配的云资源；另一方面，他把CPU品牌从Intel换成AMD，成本降低了7%左右。
该指数描述了服务计算能力的特征。
完成混合云转型后，小王进一步将计算成本分解为服务计算成本和基础设施资源成本：
服务是指业务服务程序所消耗的CPU、内存、磁盘、带宽等计算资源，相应的成本取决于业务特性、业务运营行为、R & ampd级。基础设施资源成本是指大数据、存储、中间件等底层组件和平台的成本。
与co结合
小王首先查看了公司典型业务在云上的计算能力特点。因为公司业务是面向计算的，他选择通过常用的性能指标CPU利用率来观察计算功耗，发现公司业务往往在中午12点和晚上8点左右迎来计算功耗高峰。
如下图所示：
图2 CPU利用率指数计算图
优化低频冗余计算能力
按照上述业务计算模型，小王发现，即使在业务高峰期，所需机器数量也不到现有数量的80%。在公有云弹性的保证下，小王分阶段发布了200多个历史巅峰未触及的8核32G包。
年包月冗余机器，节省了 20% 左右成本。压测 + 公有云机型规格降配
在粗略去除明显冗余算力后，小王观察到业务算力即使在忙时利用率也不高，尤其是内存闲置较为严重。
接下来小王和业务一起进行了一次压测，最后得出业务机器规格保持在 8 核 3G 的配比，使用率相对均衡。而公有云机器 CPU 核数和内存配比一般是 1:2 或 1:4 的固定比例，所以小王按照公有云厂商的标准配置先将机器规格从 8 核 32G 降为 8 核 16G，节省了 20% 的成本。
小结
第一阶段的优化手段较为常规，取得了一些效果，小王总共节省了 40% 左右的成本，以较低成本吃到了第一波降本红利。
基于第一阶段的优化经验，小王总结出以下待改进点：
根据 CPU 消耗所衡量出的算力消耗情况和业务的实际情况之间仍有一定差距。比如，经常会出现 CPU 消耗偏高但实际业务依然稳定、无需扩容的情况，这说明需要更加精准的算力度量指标。业务算力模型明显有波峰波谷，但是资源消耗的模型并未较好匹配，虽去除了未触达的冗余算力，但仍是以最高峰配置全时段占用算力，导致闲时浪费明显。公有云机器规格中，CPU 与内存的比例有明显限制，导致算力资源使用无法进一步均衡，造成浪费。
基于上述分析，小王分析出需要依次解决的三个问题：
以更精准的业务指标，替代以 CPU 消耗为核心的物理指标；持续采集该指标，精准匹配算力波动曲线并实时联动扩缩容；获得更匹配实际业务的机器算力规格，提高资源利用率。
针对以上问题，小王对业界现有解决方案进行了调研，发现并无能直接借鉴的普适方法和经验，大部分实现方式都与特定业务场景绑定且需要研发深度参与。
为了能按期实现目标，小王尝试使用云原生基础治理平台 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 降本流程图
降本配套设施
为了顺利推进成本优化，小王除了设计操作各种算力增减外，还借助了以下一些配套措施和系统：
需要明确算力衡量指标体系，前期可以粗略使用 CPU 利用率等系统指标，后期需要借助精准的业务指标，比如 QPS 及单请求的耗时结合的复合指标。降本过程需要有较完备的监控告警系统及容灾 SOP，防止在优化过程中出现意外情况。比如在优化低频冗余算力环节，小王在下机器的时候，提前根据 CPU 等指标设置好了扩缩容策略，在系统保持一周无异常后才将下线的机器清退。为了精准量度业务算力，需要搭配压测系统及方案。前期为尽量减少业务投入成本，主要是基于以下思路来操作：测试环境 ->线上日志回放 ->mock 调用接口 ->采集算力衡量指标 ->逐步放大调用压力 ->响应超时的服务器达到一定比例时结束压测。后期可以逐步迭代为全链路压测，从网关到调用链路到存储全隔离的形态，衡量效果会更精准，当然相应研发成本和投入也会更重。为了充分体现每一步的优化成果，需要有成本看板，对每一阶段优化前后的机器资源和成本消耗进行环比或横比展示。成本看板主要针对中高层人群，所以信息要简明扼要，成本信息突出。降本遇到的非技术问题
小王在推进降本过程中，还总结了一些遇到的非技术问题及主要解法：
项目切入时机问题：降本工作不仅仅是运维部门或基础架构部门的工作，同时还需要成本管理部门、财务部门、业务部门等多部门协同。降本工作的推进也会影响稳定性保障、业务研发等工作，所以降本工作需要先成为公司的重点项目或者产研团队的 KPI。由于改造的投入成本和机会成本都很高，所以要求改造带来的收益要足够大。立项及项目团队组建：公司确定降本工作是重点项目后，还需要在公司层面或者产研层面进行正式立项，指定项目负责人、项目技术负责人等，并明确项目的目标，以及项目人员的沟通。原则上所有受降本影响的部门都要派出自己的代表，实际可以确保所有的职能都派出代表，这样既能控制项目组规模又有足够的代表性。比较好的项目组核心人员组合是，由收益最大或工作量最大的部门作为项目的负责方并派出项目负责人，受影响最大的部门派出技术负责人。成本变革问题：云化、弹性等都会带来新的预算管理和成本核算方式，需推动公司内部成本管理机制升级。在项目早期，就要对降本项目的优化效果进行量化。只有明确的、量化的目标和明显的收益，方能为各个部门提供足够动力配合推进。项目推进中的故障问题：项目在推进的过程中，如果出现严重故障，会极大影响公司对项目的信心以及各部门的支持力度，最坏的情况下甚至会导致项目流产。项目组成员一定要包括试点业务的相关负责人或代表。试点业务要适中，过小的业务没有代表性，而如果业务过大，一旦出现问题，后果会很严重。在试点业务成功实践之后，再推动到公司的核心业务。核心业务有足够的代表性和说服力，只有在核心业务落地才可能在全公司全面落地。核心业务落地的关键点是做好包括回滚方案在内的各项预案，做到即使出问题也不要影响到核心业务。这也需要项目组与核心业务密切配合，核心业务的负责人或代表最好就是项目负责人或者技术负责人。项目如何推广到全公司：项目在单个业务落地后，需要继续往全公司推广，此时会遇到各个部门的支持问题，需要先找一两个典型业务作为标杆，等标杆业务有了效果再继续往其他业务推广。通过技术沙龙等方式对项目进行介绍和宣传，让标杆客户一同参与宣讲，并广泛邀请潜在的业务部门参与。项目在公司 30% 以上的业务推广开后，可以寻求高层的支持加快项目的推广，有了试点效果后高层更乐于协助推进。项目完成后的日常保障：项目完成后需要由职能团队负责日常的维护和保障工作。通常会放到项目负责人所属的团队，但也可能按照项目成员所在部门进行保障分工。总的原则是，项目推进期间公司比较重视参与的人也多可以跨职能，而项目完成后项目组成员多数回归原团队，保障工作分配尽量契合原有职能分工。项目的收益分配问题：针对项目收益分配，比较好的做法是把各种收益进行拆分，然后再依据分别的贡献进行分配。比如项目整体荣誉归项目组、项目管理的收益归项目负责人及其所在部门、项目技术上的收益归技术负责人及其所在部门、各模块的收益归模块负责人及其部门。在晋升时也需要项目负责人协调好各自的边界，避免相互冲突的情况。项目负责人及其所在部门要把更多的利益分给项目组中其他的部门，从而更好地激励大家积极参与之后的其他改造与建设项目。结语
回顾整个降本之路，除了之前总结的执行中技术 / 非技术的问题外，还有以下几个点值得提出：
在推动层级方面，公司成本优化总体来说是一把手工程，过程中难免需要各部门的协同配合及利益分摊，所以由 CTO 发起并提供支持是小王完成成本优化目标的重要前提。在优化手段方面，和小王相同场景的公司在第一阶段通过一些成熟的业界通用做法就能取得还不错的降本效果，可以此作为让全公司认可降本价值的敲门砖，这样在第二阶段引入外部系统做深入优化就能更顺利。在优化节奏方面，建议先从成本占比、优化难度、优化效果、是否核心等维度对业务进行排序打分，先从成本占比大，优化难度小，优化效果明显、非核心的业务开始优化。
在互联网下半场的今天，降本增效作为企业大势所趋，甚至上升到了公司核心竞争力的层面。在林林总总的成本优化路径和手段面前，谁先朝正确的方向踏出一步，谁就有可能领先对手占据先机。本文综合讲述了一个典型腰部企业的降本之路，希望能对读者有所启发。如果读者有成本优化技术手段相关的需求，可以联系我们共同探讨。
本文大部分内容摘自《星汉未来云原生 IT 成本优化白皮书》，其中提到的 SchedulX 是由星汉未来打造的一站式云原生基础治理平台，目前已推出社区版，通过此链接即可获取白皮书、免费试用 SchedulX 社区版。
作者介绍
舒超，星汉未来 CTO。前美团基础研发负责人，存储中心总架构师，负责美团公司级云原生服务治理系统的开发及演进；前腾讯微博微群及消息流广告负责人。
