降本增效是今年的主旋律，对于技术团队来说，最大的成本除了人力成本，就是我们的技术成本。这里的技术成本包括各种 CDN、网络带宽、服务器、存储、云计算服务等。

如果你是一个运维总监，或者是技术负责人，需要在技术成本上节流提效，这篇文章应该对你有一些帮助。

今天所讲的策略是当我们面对一个已有的技术基建和系统，如何有计划地针对技术成本做优化，如何持续运营，让成本降下来，让钱花得有理有据。

整体分为两个阶段，成本优化和精细化运营。

1 成本优化

成本优化是一个「止血」的过程，如果之前没有刻意关注过技术成本，可能存在较多的浪费或者不合理，特别是当业务在高速野蛮发展的时期，一不留神就会出现你想象不到的成本浪费。

我们做成本优化一般有如下几步：

1.1 组建团队

一件事情要想做得比较好，得先有一个团队。对于技术成本优化这种可能会跨团队，跨业务的事情，更需要有一个合适的团队。

在项目成立时，我们可以成立专项小组，小组由以下成员角色组成：

• Owner(组长/负责人) ：负责整个项目的规划、计划安排、人员协调以及对外沟通汇报等，为整个项目负责；
• 运维的负责人（运维总监/ SRE 负责人）：负责整体技术成本的评估、公共技术成本的评估、优化，以及云服务商上相关操作的评估，规划和人员安排， Owner 和运维的负责人可以是同一个人；
• 业务侧的技术负责人（各业务的技术总监/技术经理）：负责各业务侧技术成本的评估、优化落地；
• 财务的负责人（财务总监/财务经理）：负责组织安排技术成本资金的确认、核对以及预决算等。

以上为主要小组成员，一般各负责人还会拉上具体操作的核心同学一起参加，这些同学由以上的负责人自行安排协调。

1.2 现状分析

技术成本之所以浪费，大概率是不知道钱花在哪里了，账有点糊涂，或者说没有人去关注里面的细节，是一个大大的黑盒子。可能大家都依着惯性往前跑，有业务要申请资源，直接上操作台或系统买了分配完事，没有考虑这些投入的价值在哪里。

现状分析主要的作用是把这个黑盒子打开，把里面的东西一个个拿出来，把数点清楚，把每个云产品、去服务使用的情况摸清楚。

在做现状分析时，我们建议先定量分析，再定性分析。

这里的定量分析并非严谨的科学实验中的定量分析，而是以云产品为项，分析其成本金额、实例数等的情况，再在此基础上确认优化的策略。

咱们的定量分析有两个维度，一个是基于时间维度，看每个月的成本，年度成本，对成本有一个大的概览；另一个是基于当月各个云产品的使用情况，看有哪些优化的空间。

如果没有比较好的报表支撑，并且存在多账号，多云服务商等情况，建议直接拉一个 Excel 表格，表结构大概如下：

在以上数据表的基础上，以总的趋势图和饼图等较直观的方式展示出来，趋势图能看到涨跌的情况，饼图能看到组成部分，可以以云产品为维度，也可以自行分类查看，此处建议使用飞书的多维表格，生成仪表盘，当然，如果你 Excel 操作很强，那随意。

通过以上的表格，能大致了解整体成本的情况，对于后续成本的优化评估，年底预算等都会有一个较为直观的印象，以后续决策打下基础。

了解了整体成本的情况，接下来就是要打开盒子，在不明确业务归属的情况下，我们先从云产品的维度来梳理整个成本的情况，对此，我们的定量分析有一个简单的模型表格，如下：

基于以上的模型表格，我们可以快速地确认能「止血」的部分，我们对其做一些定性的分析，如分类。 一般技术成本优化大概有如下的一些情况：

1.2.1 折扣和计费方式

折扣是一个很明显的优化点，当你在某个云厂商消费到一定的金额，应该是有对应的折扣，具体的折扣情况需要和你对接的商务来聊，不同的区域，不同的人，聊的结果不同，但是一定是有空间的；而且不同的产品可以折扣不同，如果你某个产品的消费金额特别高，可以单独申请很低的折扣，很低很低。

不同的计费方式在不同的量级，成本不同，需要根据业务评估，或者是一些续费的方式，不同的续费方式成本也是不同的，如按年或按月的价格差异也蛮大的。

1.2.2 存储

现在的存储大家基本都会用云存储，而不是自己来搭一套。每个业务都往存储里面存东西，基本上没有人太去管。而实际上这里的浪费往往较多，常见的情况有：

• 历史存储，没有人维护，如一些临时性的文件、过期的文件、用户不要的内容等等；
• 无用存储，原来是给业务使用，但是业务新申请一个 Bucket，旧的没有删；
• 冷热存储，用户的一些文件，但是很久没有访问了，属于冷数据了，但是这些冷数据还在存在标准存储中，而在云厂商的逻辑中，除了标准存储，还有低频存储，归档存储，冷归档存储等，建议根据实际的使用场景规划使用哪种存储，以及使用哪种存储过期策略；
• 日志存储，特别是链路跟踪的日志存储，链路跟踪数据的价值是随着时间的推移急速降低的。从我们实际的生产情况看，但凡你发生一个线上的调用异常，如果是真正的问题，我们在半小时以内发现解决，甚至几分钟之内就处理掉。几天后，它就变成了一个无关紧要的异常，也就没有什么价值了。但是如果我们对这些链路跟踪的数据不做处理，其存储量随着时间推移会越来越大，成本也就越来越高。所以我们可以把过去一小时或两小时以外的数据进行采样、清洗最终只保留有价值的数据，实行差异化的链路跟踪数据存储，从而降低存储成本；
• 存储带宽，像阿里云的 OSS 提供外网直接访问服务，如果开放了外网直接访问，建议评估一下，是否走 CDN + 回源更合理，或者有没有本来可以走内网的，却去了外网访问；
• 存储计算，有些存储带有一些图片处理等的计算能力，这些能力也是单独收费的，如果此处费用较高，建议评估以空间成本换计算成本，或者从业务上考虑减少计算量。

1.2.3 机器

主要指我们常见的云服务器，数据库等，其常见的优化点：

• 没人用的机器，这个特别常见，比如某个业务想跑一个定时任务，一段时间后不跑了，也没有知会运维同学，机器就会一直在那里花钱，但是啥价值也没有；
• 线上负载低的机器，一些线上的服务配置超高，如最开始评估容量是 100，但是实际只用到了 10 或者 10 都不到，但是并没有把机器降配，毕竟对于使用方来说，在不考虑成本的情况下，配置高更好一些，特别对于一些 GPU 的机器，特别贵，如果只是偶尔用用，考虑是否直接在内网本地部署；又或者一些小业务在独占某个实例，此时可以合并这些小业务到一个实例，释放其它的实例；
• 非线上环境闲置的机器，一些开发测试环境配置了非常好的机器，或者多个业务各有一套，但是实际使用频次很低的情况；
• 数据库存储浪费，有些存储的数据因为版本升级或迁移等原因，一直留着，没有删除，也没有地方用上，或者是一些没有用的数据也一直存在数据库中，此时可以沟通后删除，释放空间，降低配置。

1.2.4 流量带宽

主要指 SLB、一些网络网关等的流量，常见的优化点：

• 内外网错乱，比如一些请求可以走内网，却走了外网
• 计费方式，流量有按带宽和按流量，根据历史数据测算，哪种更划算一些，可能前期用流量划算，到后期量大了后用带宽更划算一些，这里就需要具体问题具体分析。

1.2.5 CDN

• CDN 带宽，带宽优化最常见的就是压缩了，看 CDN 的压缩机制开了没，特别是对一些图片的压缩，有些甚至可以省一半的带宽；
• CDN 的其它计算成本，如 HTTPS 的费用，不同的云厂商不一样，有些没有这个成本，可以考虑多谈谈折扣。

1.2.6 云服务

像一些安全服务，如 WAF、DDoS，或者云计算之类的服务基本都是云厂商提供的，我们常见的情况：

• 服务共用，像 DDoS 是按实例收费，如果是多业务，可以考虑共用一个实例以减少成本；
• 服务空转，比如像一些治理类的服务，可能当时确实需要，或者试了一把，最后没有用起来，导致云服务还在继续跑，而没有人在用；又或者某些云的数据库各种附加功能，有些是默认开启的，其实可能用不上，一直开着一直浪费成本，如此种种；
• 服务版本，有些服务，不同的版本其价格不同，比如阿里云的 DMS，新版的价格和旧版的价格就不一样；
• 服务超配，服务有其不同的档位，可能是一些历史原因，或者一些奇怪的需求，导致申请了比较高配置的服务，后面没有调下来，一直在消耗成本，没有物尽其用，和业务方沟通后把配置降下来；
• 多服务商对比，如内容安全审核，短信服务等等超公共的业务，可以选择多家云厂商，一个是灾备，另一个是成本控制，像内容安全审核，网易易盾的价格就和阿里云 CDI 价格差距挺大的。

1.3 项目计划和里程碑

基于上面的现状分析，我们大概清楚了我们能做什么，以及做了这些后可以得到的收益。根据收益的大小、操作的难易度、风险的大小来评估优先级，对于收益大的，操作简单，风险小的先快速落地；对于收益小，复杂且风险高的往后放放。

根据优先级，我们下一步是制定详细的计划表和里程碑。

大的里程碑可以分为三个：

1. 止血，第一批快速落地里程碑，尽量控制在当月底，快速把通过运维部门操作能优化的点做了，解决明显的浪费和不合理使用的情况，快速见效；
2. 业务优化，一些需要业务侧优化的高收益的优化，一些需要和云厂商重新签合同等依赖于第三方的操作，属于有些难度的止血疗伤操作，此时需要业务侧一起参与进来评估，优化，见效时间为一到三个月；
3. 精细化运营，建立技术成本控制体系，对技术成本进行精细化运营，解决业务演化过程中成本出现的变化，应对突发事件产生的成本增加；

在里程碑的基础上，列出每一个里程碑中的详细计划跟进表，大概如下：

1.4 沟通和汇报

在我们执行成本优化过程中，需要和业务方打交道、需要和财务交互打款，核对消费金额，需要和老板们汇报项目进展，基于此，我们需要构建针对本项目的沟通和汇报渠道。

我们可以通过报告/文档，以及月度会议的方式沟通和汇报。

文档包括以下几种：

• 月度分析报告，主要是在月度账单出来后，按月分析上个月的成本花费情况，回顾上月计划执行情况，成本优化目标达成情况，如果没有达成，分析原因并做出对应的解释和应对计划，同时对比上上个月的的成本情况，按云产品比对，发现增长了的云产品，以及减少未达标的项，比如 11 月 5 号出 10 月的分析报告，对比 9 月的情况。
• 业务技术成本分析报告，与上一个报告的不同点在于增加了业务维度的，不同的业务其在云产品的消耗不同，能看出业务侧云产品的涨跌，为后续精细化运营的业务分摊做准备分析；
• 财务分析报表，基于财务的角度对技术成本分析，这个报告是由财务同学输出，以一个非技术同学的角度看技术成本事项，可能会列更关注成本花在哪里，以及各种维度的涨跌。

在准备了这些文档后，我们按月召开技术成本优化月度会议，与会人员为上面我们所列的小组成员。会议主题主要是同步月度成本情况，以及协调资源做业务成本的优化。这里可能逐渐要形成各业务自己为自己的成本负责的逻辑和意识。

每个月所有以上的报告，会议完成后，和小组各成员确认了结果，可以整理文档和说明，邮件或 IM 将相关结果发送给与本项目相关的老板们，如 CTO、CFO 等。

技术成本的优化基本在 3 个月到半年内完结，再接下来就是针对技术成本的精细化运营，在已优化好的成本水位的基础上，保持水位的不增/随业务体量正常增加，或者减少。

1.5 其它原则和注意事项

1. 以不影响公司业务为前提；
2. 在激进的方案中，可以少量影响一些工作的效率；
3. 先止血，再优化，即把能快速节省成本的操作先做了，如空闲或负载低的服务器，用得少的云服务，不合理的折扣等，对于报表建设，需要改动线上代码的优化往后排一些；
4. 部分优化的生效具有滞后性，即某些优化当月操作后，需要下个月才能生效，因为有很多云服务的计费项是按月收取的，如 CDN 带宽；
5. 分清主次，看业务的主要成本在哪里，优先处理可节省成本高的部分，比如存储的费用多，可能一点小优化就抵其它的全部成本；
6. 掰开了，揉碎了去优化，把每项的成本都列出来，评估每项成本的合理性和必要性；
7. 把业务方和财务拉到一起来搞，部分压力传导给业务方，一些成本项的责任人放到业务方，让财务加入，是想通过财务的沟道，把成本优化透明化出来，让公司更快的知道，同时从财务的角度看成本优化的问题；
8. 多厂商对比，优先选择大厂商，他们的客户多，遇到的问题多，当下你所难解决的问题，可能他们在其他客户那里就已经解决过了，你只需要接入使用就可以了。比如短信服务，被攻击的情况很多，不停的对抗，在大的云厂商已经在海量客户和用户的基础上形成了很强的安全策略；
9. 从一个云厂商 A 迁移到另一个云厂商 B，建议找云厂商 B 分摊一些迁移成本，比如你有 5 个 PB 的数据迁移，这个过程中会产生机器成本，流量成本以及过渡阶段的存储成本等，就这体量算是一个大单了，可以要求 B 搞定迁移成本。从云厂商的角度看，这个成本算是拉新的成本，如果能在未来挣回来，大概率是会愿意掏这个钱的。但是，这个操作尽量在迁移之前搞定，否则当你迁移完后再提这茬，就会有点被动，但是也不至于完全不行，只是难度会大一些，如商务同学和他们内部的产品同学去聊的时候，逻辑是不一样的，有点像男女朋友最开始选择是否在一起的时候样子，求而不得才是议价选择权最高之时 。

2.精细化运营

精细化运营和前面讲的成本优化不一样，成本优化考虑的是短期效益，为的是解决历史的问题，而精细化运营是一个长期的逻辑，解决的是未来的持续发展的问题。

精细化运营分为三个层面，组织分工，流程机制，系统支撑。

2.1 组织分工

2.1.1 按业务分摊成本

前面短期的成本优化大多数以运维部门为主，少部分需要修改业务方配合，为了快速见效，这里需要有一个强有力的集权性质的组织，让整个项目快速成功。

当成本优化到一定阶段，没有那种短平快的措施后，我们需要结合业务来做深度的优化，整个分工逻辑会有所变化。

原来是运维部门为成本负责，主导成本优化，业务侧以配合为主，当需要修改业务时由业务侧配合修改上线，运维部门来验收确认。

在新的逻辑里面，成本由各业务侧来承接，业务侧的技术负责人为自己业务的成本负责，技术成本优化小组为整个公司的技术成本负责，技术成本优化小组和各业务、财务、运维等部门对于成本分摊逻辑达成一致，认可自己的成本有多少。在此基础上，根据业务的情况，技术成本优化小组可以提出优化建议，各业务侧自行评估或者推动成本优化达成目标。

2.1.2 基于业务的成本优化策略

之所以要把成本分摊给业务侧，是一个「屁股决定脑袋」的问题，是一个责权利对等的问题。

当我们的成本优化进入持续运营阶段，一些优化需要深入到业务才能达成，以及在业务扩张或者有新业务时，只有业务方才能评估成本是否合理，是否是有价值的。

举两个例子：

一个是微信收藏功能的例子，在微信里面我们发的消息，如视频这些是没有永久存储在服务器，而只是临时存储了三天，当你把消息收藏后，这条消息就会永久收藏。

这个功能用得人不多，但是却耗费了很多存储空间，并且用户在收藏后很少去看收藏的内容。但是这块的成本又非常高，在 2016 年那个 2TB 是主流存储的年份里面已经有 7PB+ 的数据，相当于至少要用 1000 多台服务器来存放这些内容。

这里有明显的业务优化空间，于是腾讯的成本优化团队和微信团队一起对其产品逻辑和播放逻辑做出了优化，减少几百台服务器的量。

到现在，收藏功能对于每个用户都有一个存储上限，当到达上限后就无法收藏内容，这也是通过产品策略来减少技术成本的一个方面。

另一个是某网盘的例子，某网盘是一个临时性网盘，用户可以临时传一个文件分享给朋友，朋友拿到分享链接后直接下载，上传的内容七天有效；除此之外，用户还可以上传文件，永久保存，随着用户的增多，成本急剧上升。

深入业务后发现，网盘系统做了全局唯一的存储，以实现秒传功能，所有上传的文件都会存下来，不管是不是临时的。

成本优化团队和业务侧讨论后做了两个优化，临时文件过期删除，永久存储的文件一个月后从标准存储转为低频存储，六个月后转为归档存储并提供解冻功能，此举节省了将近一半的存储成本。

2.2 流程机制

成本要长效地得到控制，需要有对应流程的保证。在成本的流程中，核心是要控制成本的显性增加，以及在过程中监控并检查成本的变化趋势，以快速应对成本的变化。

2.2.1 资源申请流程

资源申请流程主要是通过资源申请的集中管控来控制成本的无序扩张。 各公司对于流程的落地实现不同，有些的有流程系统，有些的直接在钉钉等应用中直接使用其 OA 流程，也有用类似于 Jira 等系统走任务处理流程的，所有的这些都只是咱们流程的落地实现方式。

资源申请流程的核心点有两个：

1. 资源申请模板，以模板的方式承载资源申请的考量因素。模板中至少要包含资源申请原因、使用业务方、规格、容量估算、成本估算等；
2. 流程中必须包含技术成本小组的审批，以评估成本是否超出预算，以及评估成本的合理性，如果成本的业务方过多，考虑多级架构。

对于紧急情况或者没有人能及时审批的场景，可以走紧急流程，先处理，后续再走确认成本变化。

2.2.2 成本预核算机制

在一年结束的时候，我们会对来年的成本做预算。在成本预算的时候我们需要先进行预测，即通过历史数据、业务目标预测来年的成本，从而做成预算。

无论是从成本控制的角度，还是从技术运营的角度，我们所使用的设备、带宽、流量、存储，必须要预核算管控。

如果公司已经有现成的预核算系统或流程，直接走现成的即可，如果没有系统化的做预核的逻辑，可以以相对「土」的方式实现预核算管控。这里所说的「土」的方式，可以是一个EXCEL 或一个文档，说明指标体系和预测模型。

预测的技术成本等于预测的固定成本和变动成本。

固定成本是指不会随着业务的增长，用户的增长而有一定趋势增长的成本，如一些管理系统、安全基础设施等。

变动成本是指会随着业务增长而增长的成本，如机器、带宽、流量，存储等等。我们这里要做的预测工作主要是围绕变动成本来做。

变动成本的预测需要先有预测指标。预测指标是指在技术成本中和在我们做预测的时候，需要先有预测指标，即技术成本是如何随着业务的变化而变化的，如 CDN 带宽可能和日活强相关，存储和存量用户数相关等等。常见的指标如下：

• 每用户存储成本 = 存储成本 / 总用户数
• 每活跃用户 CDN 带宽成本 = CDN 月成本 / DAU(如果有明显活跃周期，可以用活跃周期的 DAU，如活跃日 DAU，因为 CDN 一般是按 95 峰值计费)
• 每活跃用户接入带宽成本 = 接入带宽月成本 / DAU(如果有明显活跃周期，可以用活跃周期的 DAU，如活跃日 DAU)
• 每活跃用户机器成本 = 当月机器成本 / DAU ，机器成本包括ECS、K8S、各种数据存储、数据传输、消息队列等等，DAU 逻辑同上，月使用的上限决定机器的成本
• 每活跃用户流量成本 = （月 CDN 流量成本 + 回源成本 + 负载均衡流量成本 + 网络流量成本）/ MAU（流量成本一般是按流量计费，用多少算多少，所以用 MAU 来算更准确一些）

除此之外，还可以有数据存储，日志存储，网络带宽、媒体计算、大数据成本等等，根据实际的业务情况拆分。不过也不用太细，按大的分类就行。

在确定了预测指标后，根据业务目标估算指标中的 DAU、MAU、用户数等等分母的值，求和或加权求和得出预测值。

得出预测值后，根据公司流程走完预算逻辑。

在持续运营的过程中，每个月持续地迭代预算，当遇到不可抗力时，可以考虑申请预算滚动，即重新调整预算。

比如公司战略在年中有调整，需要新增业务线，又或者业务调整，某块业务不做了等等。

在每个月初，通过系统的方式，复盘核算上个月的总成本情况，各云产品的成本情况，各业务的成本成本情况，得出下个月的重点关注点和行动事项，持续迭代，保证年度成本预算不超。

2.3 系统支撑

在项目早期，不用着急着上系统，一些事情可以手动先搞，如一些报表，数据统计，信息同步等。

在持续运营的时候，系统就成了一个必选项，通过系统支撑前段时间我们的手动逻辑，可能包括如下一些内容：

1. 各云，各产品，各业务的成本日报，月报，周报；
2. 月度小结报表，增加了多少，减少了多少，每个产品的变化趋势，各业务的变化趋势，总成本；
3. 自动形成报表，邮件或 IM 消息发送；
4. 定时报表，产品报表，部门报表。

基于业务情况，成本情况，对当月，当年的成本预测等等

除了成本以外，我们在系统中还需要包含资源利用率，纯粹从技术出发，查看资源的使用情况，如机器的使用率，内存/CPU 的使用率，将资源利用率和成本关联上，以更好地控制成本。

我们通过系统，提供成本的透明度以支持成本优化。 提高透明度的目的是想知道发生了什么，将要发生什么。

系统支撑除了报表等透明化逻辑，还有监控提醒逻辑，通过对业务的监控和成本的监控，快速知道成本的变化和过程中的问题，以快速解决这些问题。

3 写在最后

技术成本优化是一个持续的工作，以精细化运营的方式，责任到人，把成本管控起来。

技术成本运营没有终点，成本优化和精细化运营只是其中的一个环节，需要持续迭代和优化，不断地升级。

从现在的阶段来看，我们还可以朝统一可视化，自动化，智能化等方向再迭代迭代。

你好，我是潘锦，超过 10 年的研发管理和技术架构经历，出过书，创过业，带过百人团队，也在腾讯，A 股上市公司呆过一些年头，现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM，对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣，平时喜欢读书、思考，终身学习实践者，欢迎一起交流学习。微信公众号：架构和远方，博客： www.phppan.com

• Previous
  跨端架构的技术选型 2022
• Next
  技术团队管理中的 4 个基本认知