降本增率是今年的主旋律，对于技术团队来说，最大的成本除了人力成本，就是我们的技术成本。这里的技术成本包括各种 CDN、网络带宽、服务器、存储、云计算服务等。
如果你是一个运维总监，或者是技术负责人，需要在技术成本上节流提效，这篇文章应该对你有一些帮助。
今天所讲的策略是当我们面对一个已有的技术基建和系统，如何有计划地针对技术成本做优化，如何持续运营，让成本降下来，让钱花得有理有据。
整体分为两个阶段，成本优化和精细化运营
成本优化是一个「止血」的过程，如果之前没有刻意关注过技术成本，可能存在较多的浪费或者不合理，特别是当业务在高速野蛮发展的时期，一不留神就会出现你想象不到的成本浪费。
我们做成本优化一般有如下几步：
一件事情要想做得比较好，得先有一个团队。对于技术成本优化这种可能会跨团队，跨业务的事情，更需要有一个合适的团队。
在项目成立时，我们可以成立专项小组，小组由以下成员角色组成：
以上为主要小组成员，一般各负责人还会拉上具体操作的核心同学一起参加，这些同学由以上的负责人自行安排调协。
技术成本之所以浪费，大概率是不知道钱花在哪里了，账有点糊涂，或者说没有人去关注里面的细节，是一个大大的黑盒子。可能大家都依着惯性往前跑，有业务要申请资源，直接上操作台或系统买了分配完事，没有考虑这些投入的价值在哪里。
现状分析主要的作用是把这个黑盒子打开，把里面的东西一个个拿出来，把数点清楚，把每个云产品、去服务使用的情况摸清楚。
在做现状分析时，我们建议先定量分析，再定性分析。
这里的定量分析并非严谨的科学实验中的定量分析，而是以云产品为项，分析其成本金额、实例数等的情况，再在此基础上确认优化的策略。
咱们的定量分析有两个维度，一个是基于时间维度，看每个月的成本，年度成本，对成本有一个大的概览；另一个是基于当月各个云产品的使用情况，看有哪些优化的空间。
如果没有比较好的报表支撑，并且存在多账号，多云服务商等情况，建议直接拉一个 Excel 表格，表结构大概如下：
| 月份 | 云厂商 1 成本 | …… | 合计 |
|---|---|---|---|
| 2021-01 | 阿里云 | …… | 合计 |
在以上数据表的基础上，以总的趋势图和饼图等较直观的方式展示出来，趋势图能看到涨跌的情况，饼图能看到组成部分，可以以云产品为维度，也可以自行分类查看，此处建议使用飞书的多维表格，生成仪表盘，当然，如果你 Excel 操作很强，那随意。
通过以上的表格，能大致了解整体成本的情况，对于后续成本的优化评估，年底预算等都会有一个较为直观的印象，以后续决策打下基础。
了解了整体成本的情况，接下来就是要打开盒子，在不明确业务归属的情况下，我们先从云产品的维度来梳理整个成本的情况，对此，我们的定量分析有一个简单的模型表格，如下：
| 云厂商 | 云产品 | 当月成本 | 优化策略 | 优化预计收益 | 操作难度 | 业务风险 | 优先级 |
|---|---|---|---|---|---|---|---|
| 阿里云 | OSS | 108万 | XXX bucket 转低频 | 10 万 | 低 | 中 | 高 |
基于以上的模型表格，我们可以快速地确认能「止血」的部分，我们对其做一些定性的分析，如分类。 一般技术成本优化大概有如下的一些情况：
折扣是一个很明显的优化点，当你在某个云厂商消费到一定的金额，应该是有对应的折扣，具体的折扣情况需要和你对接的商务来聊，不同的区域，不同的人，聊的结果不同，但是一定是有空间的；而且不同的产品可以折扣不同，如果你某个产品的消费金额特别高，可以单独申请很低的折扣，很低很低。
不同的计费方式在不同的量级，成本不同，需要根据业务评估，或者是一些续费的方式，不同的续费方式成本也是不同的，如按年或按月的价格差异也蛮大的；
现在的存储大家基本都会用云存储，而不是自己来搭一套。每个业务都往存储里面存东西，基本上没有人太去管。而实际上这里的浪费往往较多，常见的情况有：
主要指我们常见的云服务器，数据库等，其常见的优化点：
主要指 SLB、一些网络网关等的流量，常见的优化点：
像一些安全服务，如 WAF、DDoS，或者云计算之类的服务基本都是云厂商提供的，我们常见的情况：
基于上面的现状分析，我们大概清楚了我们能做什么，以及做了这些后可以得到的收益。根据收益的大小、操作的难易度、风险的大小来评估优先级，对于收益大的，操作简单，风险小的先快速落地；对于收益小，复杂且风险高的往后放放。
根据优先级，我们下一步是制定详细的计划表和里程碑。
大的里程碑可以分为三个：
在里程碑的基础上，列出每一个里程碑中的详细计划跟进表，大概如下：
| 业务 | 优化专项/措施 | 解决的问题描述 | 预计节省成本 | 当前状态 | 计划完成时间 | 负责人 | 相关文档 |
|---|---|---|---|---|---|---|---|
| 基建 | SLB 计费方式梳理及调整 | 解决当前 SLB 计费方式不合理的问题 | 5000 | 计划中 | 2022-11-10 | 张三 | 文档XXX |
在我们执行成本优化过程中，需要和业务方打交道、需要和财务交互打款，核对消费金额，需要和老板们汇报项目进展，基于此，我们需要构建针对本项目的沟通和汇报渠道。
我们可以通过报告/文档，以及月度会议的方式沟通和汇报。
文档包括以下几种：
在准备了这些文档后，我们按月召开技术成本优化月度会议，与会人员为上面我们所列的小组成员。会议主题主要是同步月度成本情况，以及协调资源做业务成本的优化。这里可能逐渐要形成各业务自己为自己的成本负责的逻辑和意识。
每个月所以以上的报告，会议完成后，和小组各成员确认了结果，可以整理文档和说明，邮件或 IM 将相关结果发送给与本项目相关的老板们，如 CTO、CFO 等。
技术成本的优化基本在 3 个月到半年内完结，再接下来就是针对技术成本的精细化运营，在已优化好的成本水位的基础上，保持水位的不增/随业务体量正常增加，或者减少。
精细化运营和前面讲的成本优化不一样，成本优化考虑的是短期效益，为的是解决历史的问题，而精细化运营是一个长期的逻辑，解决的是未来的持续发展的问题。
精细化运营分为三个层面，组织分工，流程机制，系统支撑。
前面短期的成本优化大多数以运维部门为主，少部分需要修改业务方配合，为了快速见效，这里需要有一个强有力的集权性质的组织，让整个项目快速成功。
当成本优化到一定阶段，没有那种短平快的措施后，我们需要结合业务来做深度的优化，整个分工逻辑会有所变化。
原来是运维部门为成本负责，主导成本优化，业务侧以配合为主，当需要修改业务时由业务侧配合修改上线，运维部门来验收确认。
在新的逻辑里面，成本由各业务侧来承接，业务侧的技术负责人为自己业务的成本负责，技术成本优化小组为整个公司的技术成本负责，技术成本优化小组和各业务、财务、运维等部门对于成本分摊逻辑达成一致，认可自己的成本有多少。在此基础上，根据业务的情况，技术成本优化小组可以提出优化建议，各业务侧自行评估或者推动成本优化达成目标。
之所以要把成本分摊给业务侧，是一个「屁股决定脑袋」的问题，是一个责权利对等的问题。
当我们的成本优化进入持续运营阶段，一些优化需要深入到业务才能达成，以及在业务扩张或者有新业务时，只有业务方才能评估成本是否合理，是否是有价值的。
举两个例子：
一个是微信收藏功能的例子，在微信里面我们发的消息，如视频这些是没有永久存储在服务器，而只是临时存储了三天，当你把消息收藏后，这条消息就会永久收藏。这个功能用得人不多，但是却耗费了很多存储空间，并且用户在收藏后很少去看收藏的内容。但是这块的成本又非常高，在 2016 年那个 2TB 是主流存储的年份里面已经有 7PB+ 的数据，相当于至少要用 1000 多台服务器来存放这些内容。这里有明显的业务优化空间，于是腾讯的成本优化团队和微信团队一起对其产品逻辑和播放逻辑做出了优化，减少几百台服务器的量。到现在，收藏功能对于每个用户都有一个存储上限，当到达上限后就无法收藏内容，这也是通过产品策略来减少技术成本的一个方面。
另一个是某网盘的例子，某网盘是一个临时性网盘，用户可以临时传一个文件分享给朋友，朋友拿到分享链接后直接下载，上传的内容七天有效；除此之外，用户还可以上传文件，永久保存，随着用户的增多，成本急剧上升。深入业务后发现，网盘系统做了全局唯一的存储，以实现秒传功能，所有上传的文件都会存下来，不管是不是临时的，成本优化团队和业务侧讨论后做了两个优化，临时文件过期删除，永久存储的文件一个月后从标准存储转为低频存储，六个月后转为归档存储并提供解冻功能，此举节省了将近一半的存储成本。
成本要长效的得到控制，需要有对应流程的保证。在成本的流程中，核心是要控制成本的显性增加，以及在过程中监控并检查成本的变化趋势，以快速应对成本的变化。
资源申请流程主要是通过资源申请的集中管控来控制成本的无序扩张。 各公司对于流程的落地实现不同，有些的有流程系统，有些的直接在钉钉等应用中直接使用其 OA 流程，也有用类似于 Jira 等系统走任务处理流程的，所有的这些都只是咱们流程的落地实现方式。
资源申请流程的核心点有两个：
对于紧急情况或者没有人能及时审批的场景，可以走紧急流程，先处理，后续再走确认成本变化。
在一年结束的时候，我们会对来年的成本做预算。在成本预算的时候我们需要先进行预测，即通过历史数据、业务目标预测来年的成本，从而做成预算。
无论是从成本控制的角度，还是从技术运营的角度，我们所使用的设备、带宽、流量、存储，必须要预核算管控。
如果公司已经有现成的预核算系统或流程，直接走现成的即可，如果没有系统化的做预核的逻辑，可以以相对「土」的方式实现预核算管控。这里所说的「土」的方式，可以是一个EXCEL 或一个文档，说明指标体系和预测模型。
预测的技术成本等于预测的固定成本和变动成本。固定成本是指不会随着业务的增长，用户的增长而有一定趋势增长的成本，如一些管理系统、安全基础设施等。变动成本是指会随着业务增长而增长的成本，如机器、带宽、流量，存储等等。我们这里要做的预测工作主要是围绕变动成本来做。 变动成本的预测需要先有预测指标。预测指标是指在技术成本中和在我们做预测的时候，需要先有预测指标，即技术成本是如何随着业务的变化而变化的，如 CDN 带宽可能和日活强相关，存储和存量用户数相关等等。常见的指标如下：
除此之外，还可以有数据存储，日志存储，网络带宽、媒体计算、大数据成本等等，根据实际的业务情况拆分。不过也不用太细，按大的分类就行。
在确定了预测指标后，根据业务目标估算指标中的 DAU、MAU、用户数等等分母的值，求和或加权求和得出预测值。
得出预测值后，根据公司流程走完预算逻辑。
在持续运营的过程中，每个月持续的迭代预算，当遇到不可抗力时，可以考虑申请预算滚动，即重新调整预算。
比如公司战略在年中有调整，需要新增业务线，又或者业务调整，某块业务不做了等等。
在每个月初，通过系统的方式，复盘核算上个月的总成本情况，各云产品的成本情况，各业务的成本成本情况，得出下个月的重点关注点和行动事项，持续迭代，保证年度成本预算不超。
在项目早期，不用着急着上系统，一些事情可以手动先搞，如一些报表，数据统计，信息同步等。
在持续运营的时候，系统就成了一个必选项，通过系统支撑前段时间我们的手动逻辑，可能包括如下一些内容：
基于业务情况，成本情况，对当月，当年的成本预测等等
除了成本以外，我们在系统中还需要包含资源利用率，纯粹从技术出发，查看资源的使用情况，如机器的使用率，内存/CPU 的使用率，将资源利用率和成本关联上，以更好的控制成本。
我们通过系统，提供成本的透明度以支持成本优化。 提高透明度的目的是想知道发生了什么，将要发生什么。
系统支撑除了报表等透明化逻辑，还有监控提醒逻辑，通过对业务的监控和成本的监控，快速知道成本的变化和过程中的问题，以快速解决这些问题。
技术成本优化是一个持续的工作，以精细化运营的方式，责任到人，把成本管控起来。
技术成本运营没有终点，成本优化和精细化运营只是其中的一个环节，需要持续迭代和优化，不断的升级。
从现在的阶段来看，我们还可以朝统一可视化，自动化，智能化等方向再迭代迭代。
★ 你好，我是潘锦，超过 10 年的研发管理和技术架构经历，出过书，创过业，带过百人团队，也在腾讯，A 股上市公司呆过一些年头，现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM，对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣，平时喜欢读书、思考，终身学习实践者，欢迎一起交流学习。微信公众号：架构和远方，博客： www.phppan.com