在技术团队的日常管理工作中，一个管理者做得最多的事情是决策、开会，最不想看到的是线上事故，线上事故给技术团队带来非常大的冲击，而给线上系统带来风险最大的研发环节是线上环境的变更，甚至有人说：「没有变更就没有问题」，对此我们不置可否，但这些变更之所以会导致事故，从根源上来讲大部分是技术同学犯了错。

这里的决策、会议，变更，错误合起来是我们日常工作中的大部分。而对于这些的基本认知是一个技术管理者在带团队过程中逐步提升的，今天我们就来聊聊这 4 个基本认知。

1 决策

在带团队的过程中我们会做非常多的决策，如去决策是否投入足够大量的人力满足某个业务，或者升级架构，或者构建某个流程机制等等。

这些决策中从服务于时间维分为两种：

• 当下的决策，如评估需求优先级，先做什么，后做什么，关注的是当下和已有的；
• 未来的决策，如评估技术架构演进、团队演化和发展等等，关注的是未来。

当下的决策在我们的工作中最常用于评估产品需求、评估技术方案或实现方案。

对于产品需求，技术管理者的作用是把价值不高，或者没有价值的需求干掉，不让其进入研发，不让公司的人力成本白白浪费掉。一般我们会对于提需求的同学问如下的问题：

1. 为什么会有这个需求？ 一般是想看这个需求是怎么来的，用户故事是怎样的；
2. 这个需求的价值是什么？ 一般是想看这个需求做了之后对产品或业务的好处，看产出；
3. 如何度量这些价值？ 一般是想通过数据看到需求的价值，把价值反馈在指标上，如营收指标、效率指标等。

对于技术需求或技术方案，技术管理者的作用是来评估当下的选择是否正确。一般我们会评估如下的点：

1. 有没有做过方案评估，即有没有评估过业内的方案、公司内的方案以及对于当下的现况的分析；
2. 是否合理的方案，有没有明显的缺陷或漏洞；
3. 有没有显得特别高大上，特别先进，防止过度设计，浪费资源。

未来的决策更多是管理者站在当下思考团队的发展，人员的发展和技术架构的发展等，是一种未雨绸缪的远见。

是基于公司战略，在组织的先进性、技术的先进性的前瞻性布局。如现有的人才梯队和人才密度是否能满足公司三到五年的发展，现在的技术架构是否能满足公司三到五年后的战略，对于行业内新的技术是否我们需要扩大资源投入，去预研并应用在业务中。

这些前瞻性的决策都是管理者基于对公司业务和业务未来发展有足够的认知和理解后做的。

我们所做的这些决策都是以有限的资源达成我们的目的，其本质是资源的分配。当我们分配资源的时候，最最重要是看投入产出比以及和公司战略的方向是否一致。

2 变更

这里的变更是指生产环境的变更。首先我们看一下定义，什么叫生产环境？生产环境是指服务于客户的应用及其运行环境，以及和这些环境相关联的环境和系统。

如果一个应用或环境和生产环境有接触，那它也是生产环境。

什么叫变更管理，变更管理包括什么？

变更管理是指以可控的方式对线上的服务、配置或基础设施进行变更，从而减少变更对业务和服务质量的影响，快速处理变更可能带来的问题，提升系统的稳定性。

在日常工作中我们见到变更有如下 4 种：

1. 应用变更，也称为代码变更，是我们最最常见的变更类型，主要是通过修改代码改变应用程序并通过发布系统发布到线上。这也是我们变更管理中风险最大的地方，因为变更的人，变更的位置和逻辑等都是不确定的。除了正常的发布变更，应用的回滚也是应用变更的一种，因为其改动了线上的应用；
2. 配置变更，是指应用系统的配置变更，一般是通过配置系统来变更，触发线上应用的热更新或滚动，配置如果是写死在代码中，会变为代码变更；
3. 基础设施变更，此变更一般是运维同学来操作，可能涉及网络设施变更，服务解析变更等等，如 DNS 的解析，网络安全配置等等，这些都算到基础设施变更里面，而不是配置变更，又如宿主机挂了，需要替换宿主机，此时也会导致基础设施的变更；
4. 容量变更，此处单独列出是因为相对于基础设施，容量变动的影响逻辑不一样，其主要是通过垂直或水平的方式提升系统的容量，特别是当出现容量告警的时候，此变更经常由运维同学手动，或者系统自动触发。

那么如何控制变更？这里我们先提一下变更管理的标准流程。

变更管理的标准流程：

1. 变更申请：在我们的流程中可能是创建发布记录，或者申请紧急发布
2. 变更评审：变更评审主要是检查变更过程是否完备，以降低变更的风险，其包括如下内容：

   1. 就绪分析：材料是否完备，人员、设备、软件、网络是否就绪，测试是否达到上线要求等。
   2. 风险分析：架构、性能、业务、合规等方面的风险评估，变更内容是否属于需求范围，变更是否可控。
   3. 重要程度：变更属于一般、重要、紧急、标准哪一种。
   4. 变更审查：内容是否满足业务需求，内容是否通过测试，测试是否全面、有效。
   5. 应急管理：变更步骤、应急方案、回滚方案、应急预案是否完备。
   6. 变更实施：变更计划时间如何安排，发布及回退操作步骤是否完备，自动化步骤情况。
   7. 变更验证：变更涉及的业务、技术验证方法与时间安排。
3. 变更审批：相关负责人对于变更评审的结果进行确认，并审批通过。
4. 变更执行

   1. 根据发布计划执行发布操作，一般应该有一个灰度的过程；
   2. 验证线上功能并回归主流程；
   3. 持续灰度，观察用户直到灰度完成。
5. 变更验收

   1. 对发布的功能进行验收，对于影响范围内的功能进行验收，对业务主流程进行回归验收；
   2. 留守，并观察日志、监控服务负载等，这个操作是为了及时发现验收检查漏掉的问题，或者及时处理隐藏的问题，以减少变更后产生的问题对线上业务的影响。

我们做这个流程是形式上的安慰，还是僵化的惯性，还是能真正地解决问题，是我们在做这个流程以及执行这个流程中需要着重思考的问题。

在变更前，即我们变更线上环境前需要自己做 Code Review，以及交叉的检查，以尽量减少问题流转到后面的操作中，节省问题的处理成本。

变更管理没有银弹，我们能做的是控制节奏，敬畏线上，以更机制化的方式提前发现问题并解决问题。

3 会议

会议是一个相互沟通、交互信息、形成一致看法，从而解决问题的管理工具。

从会议的定义来看，会议是一些人有组织、有领导地为了某种目的而进行讨论和商议的集会。

当我们思考一个会议要不要开时，可能需要先思考这个会议的目的是什么。

如果一个会议没有需要讨论的地方，没有明确的目的，可能大概率是一个不需要开的会的，又或者仅仅是一个简单的信息同步，直接文档或者在群里同步就可以了。除非文档没法完全解决问题，比如一些战略的宣讲，一些大的事项的发布，需要有一个仪式感的会，现场答疑的会。

如果发现两个会的参会人差不多，那么是否取消其中的一个会呢？不一定，看目的是否一致，如果解决的问题不一样，可以同时存在。

回顾我们常开的几种会议。

• 项目例会：项目信息同步，问题卡点讨论，待办相关同步，这里的项目例会又包括常规项目例会和专项的项目例会，是项目管理中的信息渠道；
• 管理例会：团队仪式感必不可少的部分，除了事项的讨论，还有一个作用是发散的聊天，不用那么严肃，闲谈之中迸发一些火花，并达成一些共识和认知上的一致；
• 单独定期沟通会议：更私密一些的沟通会议，除了常规事项同步，更多的是一个散而不散的个人想法、规划、思路等的探讨；
• 复盘会议：对特定事项和问题的总结，讨论，属于常规会议机制的一种，起总结，沉淀的作用；
• OKR 会议：目标对齐，起方向对齐的作用；
• 需求规划会：有计划的对于需求进行规划，评审，然后进入迭代，开发测试并交付；
• 技术方案评审会：严格准入技术方案，集众人之力评估方案的可行性，看是否有什么缺漏。

着点讲一下周会，周会我们一般是指周例会，属于例行会议的一种，按周或双周召开。

周会的目的是根据会议的属性，定期回顾讨论总结指定的项，可能是专项，也可能是过程中的事项或突发的事情等。开会的目的主要是交流和讨论，那么在周会上我们讨论什么，在确定讨论内容之前，我们先看看哪些不要在周会上讨论：

1. 紧急的事情不适合在周会讨论，出现的时候直接搞定；
2. 非跨团队的问题不适合周会讨论；
3. 纯执行细节问题不适合周会讨论；
4. 大方向决策问题不适合周会讨论。

总结下来，就是涉及与会各团队的，对整体性计划或者需要协同配合的问题，或者里程碑式的改进型问题适合在周会上讨论。

当然，也不绝对，这还是一个人治的过程。

如果是你一个会议组织者，在组织一个会议的时候，需要考虑以下三件事：

1. 这个会议最重要的事情是什么，是想解决什么问题？想讨论什么？
2. 能否达到目标？ 大家对于目标是否有所了解？
3. 如何达到目标？ 达到目标的关键路径是怎样的？干系人都在吗？

4 错误

工作中我们会出一些错误，生活中我们也会出一些错误，这些错误可能会影响同事朋友，或者影响线上产品，公司业务，甚至可能会造成个人或公司的经济损失，错误有其类型，在了解了这些类型后，我们可以适当的减少出错或规避这些错误。

从个人的角度来看，错误可分为成长之错，无心之错和性恶之错。

1. 成长之错，我们都是从懵懂孩童，成长为有知识的学生，到长大成人，出来工作，工作中也是从不会到会，到熟练和精通，在这个过程中，正是因为一个个的错误，才成就了我们的成长，成长之错为正常之错，可允之；
2. 无心之错，非有意为之的错误，一时失察导致工作出现错误，从而给别人带来不好的影响，或者粗心导致过错，其出发点都非有意，出错了就认，改过即可，不可连续；
3. 性恶之错，以人性之恶为出发点或者动机，此种错不可原谅。

从工作的角度，错误可以分为超出型错误，信息型错误，粗心错误，态度型错误和风险型错误。

1. 超出型错误，当你尝试去做能力之外挑战的时候，或者你不熟悉的领域或知识盲区，或者超出当前因为自身能力或其他条件的束缚，做得不够好而犯的错。比如一些新的想法的落地，一些新技术的试点等等，这些都没有人前人尝试过，至少在当前范围内没有，此时可能会遇到想象不到的坑，或者无法解决的问题，从而出现错误，甚至失误。这种创新或者超前的错误是可以接受的；
2. 信息型错误，属于信息不对等，或者信息不全，知识不全面导致的错误，特别是对于工作中面对某个项目一些信息没有，或者没有去全面了解背景信息从而做出错误的决策，这种错误不会反复出现，但尽可能避免在不同类型的事情上犯同类型的错误；
3. 粗心错误，这种比较常见，与无知错误不同，这种情况是你明明知道怎么回事，但是因为不小心或者忘记了而导致的错误，如果是粗心之人，可能会一错再错，此时需要反思自己，以某种方式规避；
4. 态度型错误，指做事的态度有问题，比如眼看自己负责的一件事情要出问题或者已经出问题了，但是没有想办法去解决，没有付出努力，而是躺平，让事情自己变坏，甚至影响面不可控，这种错误是不允许的；
5. 风险型错误，主动去做事情，但风险很高，是否会犯错不受自己的控制。比如你面临一个重要的选择，但在结果出来之前，你之前掌握的所有信息都无法告诉你哪个选择是绝对正确的，你只能去做自己认为是大概率的选择。而这种错误在工作中是极有可能遇到的。

对于工作中的错误我们应该如何减少或者规避呢？

1. 超出型错误，从公司层面或者团队层面提供一些培训，或者在新人安排导师，提升大家的能力，或者通过流程机制让更有经验或者能力更强的人对于新的内容做一些把关；
2. 信息型错误，信息型错误可以在公司层面搞定完善的文档和快捷的查询机制，任何技术或产品讨论以及达成的共识，要尽可能用某种沟通渠道发送到所有相关的人。让大尽可能的掌控更全面的信息；
3. 粗心错误，设定一些机制来规避，如复盘机制，通过复盘，深挖过程中的问题，总结经验，为后续减少此类问题做准备，同时可以在流程上做一些 check 机制，通过多人的 check 减少错误的出现；
4. 态度型错误，本着治病救人的态度先看看，如果实在不行，考虑换个人吧；
5. 风险型错误，针对高风险的事情，尽可能的准备一个 PlanB，当事情没有按我们预想的方向发展时，启用 PlanB，减少损失，这也是我们下棋时通常会用到的策略，走一步，想三步。

从团队来看，一个人犯错，可能是人的问题，一群人犯错，一定是机制或系统出了问题。

当然，工作中我们允许试错，但是不能一错再错，避免一些不应该犯的错误，最大可能从错误中成长，这才是我们应有的态度。

除了以上，《清单革命》中说人类的错误可以分为两大类型。第一类是「无知之错」，我们犯错是因为没有掌握相关知识。第二类是「无能之错」，我们犯错并非因为没有掌握相关知识，而是因为没有正确使用这些知识。

现在，我们面临的错误更多的是「无能之错」，也就是如何持续、正确地运用我们所掌握的知识。「无知之错」可以原谅，「无能之错」不被原谅。

5 后记

管理是门实践的科学，大多数的书籍和文章都是个人或组织的经验之谈，没有公理，只能在俗世不断修行和精进，以求能「知行合一，止于至善」。

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

”

降本增率是今年的主旋律，对于技术团队来说，最大的成本除了人力成本，就是我们的技术成本。这里的技术成本包括各种 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