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

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

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

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

1 成本优化

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

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

1.1 组建团队

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

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

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

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

1.2 现状分析

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

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

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

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

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

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

月份	云厂商 1 成本	……	合计
2021-01	阿里云	……	合计

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

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

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

云厂商	云产品	当月成本	优化策略	优化预计收益	操作难度	业务风险	优先级
阿里云	OSS	108万	XXX bucket 转低频	10 万	低	中	高

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

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. 精细化运营，建立技术成本控制体系，对技术成本进行精细化运营，解决业务演化过程中成本出现的变化，应对突发事件产生的成本增加；

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

业务	优化专项/措施	解决的问题描述	预计节省成本	当前状态	计划完成时间	负责人	相关文档
基建	SLB 计费方式梳理及调整	解决当前 SLB 计费方式不合理的问题	5000	计划中	2022-11-10	张三	文档XXX

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

技术团队管理者在日常工作中可能经常会遇到如下一些状况：

1. 自测质量差
2. 转测 BUG 多
3. 项目延期
4. 加班赶工
5. 高强度加班后，小伙伴状态不好，导致更多的问题出现

从第 1 点状况演变成第 5 种状况，第 5 点状况继续推动第 1 种状态的持续加强，从而导致整个团队的状态极差，陷入 BUG 多 –> 延期 –> 加班 –> BUG 更多 –> 更多的延期 的死循环。

除了上面的死循环，可能还会有一些非功能性的问题，如性能、扩展性问题等等。

当团队大时，还可能遇到有小团队，各小团队各行其事，各为其主，心不往一处，力不出一孔。 这些问题让技术团队的管理者焦头烂额。

那么如何解决这些问题呢？个人认为可以从以下 4 个方面来逐一思考和优化，从而在一定程度上解决这些问题。

1. 把正确的人放到合适的岗位

所有的执行最终都是落到人身上，有了正确的人，事情会事半功倍。 说到人，我们往往会提起人的「选用育留」，这是一个很大的题目，我们不做详细的讲述，只关注选和用的一小部分。

管理上有一个在大部分场景适用的套路：选拔优先于培养。 这个套路背后有两层逻辑：

1. 改变一个人太难，比如有些人就是懒，抽一鞭子动一下；又或者家境优渥，态度佛系，无欲无求，根本就是油盐不进；又或者玻璃心，安全感差，都很难搞；
2. 成本太高，即使这个人具备可培养性，但从 0 到 1 把一个人培养起来，时间成本太高，而管理者的时间很贵，公司等不起。

所以我们这里是选人，从现有的人中找到合适的，从人才市场找到合适的，能直接用的。

本小节主要是回答两个问题：

1. 正确的人是怎样的？
2. 如何把正确的人放到合适的岗位上？

1.1 选人

在人的层面，主要包括两个部分，执行者和管理者，这里管理者包括整个团队负责人自己。 不同的部分，要求不同，选人的标准也不同。去掉专业技能部分，去掉历史经验部分，我们希望我们的伙伴是这样的：

• 喜欢和投入：对于技术热爱，对工作有投入度，能够专注于自己手上的工作，找到成就感；
• 知道自己想要什么：有一定长远的规划，知道自己走在什么样的路上，不限于一时一城之得失；
• 一路人：认同企业的价值观，价值观认同其本质上是「人以群分」；
• 宁缺毋滥：如果实在没有人，宁缺毋滥吗？这是一个好问题，严格来说是这样的，但实际中往往我们会妥协一部分。

我们选人一个常见的问题是注重人当下的表现和历史的成绩，然而我们选人是要解决未来的问题，更要关注其潜力。 那么如何看一个人的潜力呢？如果具备以下的特性，大概率是一个有潜力的人：

1. 有意愿，什么叫有意愿，就是指一个人想变好，有内在的动机去追求更高的目标；这里扩大一些，还包含积极的态度、好奇心和进取心；
2. 有静气，特别是遇大事时有静气，临危不乱；遇到繁琐的事情能一步一步慢慢做好；
3. 有度，做事有度，知道做事的边界在哪，进展有度，但是并不是事事划边界，事事划边界显得格局太小，多数事情还是从大局着眼；
4. 能扛事，遇到事情找方法，不找借口，执行力强；
5. 有所为，天赋决定了能达到的上限，努力程度决定了能达到的下限。努力去做，有所为，并且 以现在绝大多数人的努力程度之低，还远远没有达到比拼天赋的程度。 这里的有所为不仅仅是做事，更多的是学习，不停地学习，提升自己。

1.2 用人

1.2.2 人才梯队

人才梯队从时间上看分为现在和将来。 现在是指盘点现有人才情况，梳理人才结构，对团队中的人进行分层，形成「梯状」。

当前状态的人才梯队分为两个层面，一个是分层，另一个是分层后的职责。 当团队大一些后，需要明确团队的组织分层，这里可能是正式认命的 Leader，也可能是虚拟的负责人，不管是实的还是虚的，最终都会有一个层存在。

分层本质上是一个分饼的行为，什么样的人拥有什么样的资源，承担什么样的责任，行使什么样的权利。

作为一个研发团队的负责人，需要梳理这些层，确定是否有合适的人，这些层的负责人形成了我们所说的「人才梯队」。

德鲁克曾说：「一个组织应该使每个人，特别是每个管理人员和每个专业人员（但也包括每个管理单位）都理解自身的任务」。 在我们做分层的过程中，需要关注每一层的职责和其解决的问题，如我们在软件架构设计的时候一样，每一个分层都有其作用，无用的分层只会增加性能的损耗。

对于将来，未雨绸缪。

当现在的人才正在发挥作用时，培养接班人，我们经常称之为 B 角。当有人才变动时可以快速补位上去。常用的方法有内部培养，跨团队轮岗，外部招聘等。

这块特别狠的可能要算宇宙厂了，在现有人员已经能满足工作需要的同时，会继续招聘，如果更优，可能会换人。

1.2.2 艰难的决定

在我们构建人才梯队的时候，想要做到知人善任是一件很难的事情，并且让每个人的表现都达到预期水平更难。当有些人并不能胜任他当前的工作时，我们应该怎么做？这里可能有以下两种常见的方式：

1. 调岗，一般这种情况可能只是人岗不匹配，或者有些变化跟不上，但是对于人的部分能力还是比较认可。此时我们在公司内给他找一个匹配的岗位，更好地发挥其潜力。在技术团队最常见的例子是有些高 P 的技术同学，被推到管理岗，过了一段时间，发现适应不了，此时我们可以将其调到更能发挥其能力的岗位上来。又或者一些管理者因为团队扩大或者一些其它原因，管理的范围一下子增加了很多，一段时间后发现无法搞定这样的团队，此时可能将其调整到稍微低一级的职位上更合适一些。
2. 离开，尽量让对方体面的离开，公司和个人都体面的分手，该赔偿的赔偿，该理解的理解，如果在外面有合适的机会，顺手推一把，也是个不错的善缘，不枉同事一场。这里经常出现的问题是犹豫不决，最终导致大家都不开心，不欢而散。管理上常说：「心要慈,刀要快」，就是要规避这种犹豫。

1.3 管理者自己

在用人中还包括管理者自己，一个技术管理者，不仅仅要注重技术，不仅仅要设定明确的目标并排出优先顺序，跟进过程发现问题解决问题，拿到结果，还要注意另一个重要的点：业务参与者。

一个优秀的管理者和一个不那么优秀的管理者的主要差别就是他们对业务的参与程度。事实证明，对所负责业务参与的程度越深，你就越能做出更加明智的决策。

什么叫业务参与度？

我认为它不是事无巨细地了解进展，应该到一线去，怎么到一线去，去写代码，去做代码评审？

到一线去，有两个层次，一个是业务的一线，用户或产品，看用户的反馈，产品的实现，二是工作的一线，看工作流程的卡点，系统化的情况，可视化的情况。不要自己去做这些事情，主要是收集信息，决策或者发现问题解决问题，这里确定做什么的原则是： 你做的事情的价值大小，而价值大小可以从时间杠杆，团队杠杆上来指数级扩大，如果做一件事只有短期的一件事的价值，那这些事情就不是你应该做的，应该停下来去思考要做的事情。

2. 组织

说到组织，你是想要一个「令行禁止，使命必达」的组织，还是一个「简单可依赖」的组织？

组织是为实现共同目标而采取的一种分工协作体系，是人与人之间的关系，组织结构往往会随着组织的重大战略调整而调整。

而企业在商场中求生，随着外部环境的变化，行业的变化，内部环境的演进而会不断进行迭代，不断调整组织结构，因此我们经常需要重新设计组织结构。

2.1 设计组织结构

我们在设计组织结构的时候通常要思考以下五个问题：

1. 组织的目标是什么？因为组织是为了共同目标而存在的人与人的关系，目标不清楚，组织结构肯定也是不清楚的。
2. 组织由哪些层，哪些单位组成？组织是一个体系，由不同的单元组成，需要明确各层或单元分别是什么，职责是什么，其作为一个子结构需要有自己的目标和使命。
3. 组织各部分的规模和形式应该是怎样的？根据现实的情况，在设计组织结构时需要着重考虑规模和形式，多少层级？流程型？考虑管理者的有效管理幅度。
4. 组织的哪些部分应该结合在一起，哪些部分应该分开？
5. 组织内各单元之间的关系和协同应该是怎样的?

设计组织结构最难的问题可能是分和合的问题，这里有一个原则： 凡是做出同样的贡献的活动可以结合在一个部门中统一管理，不论它们的技术专业是什么。那些不是做出同样贡献的活动则一般不应合在一起。

在考虑组织结构，特别是研发团队的组织结构的时候，千万不可忽略了康威定律，甚至我们有时需要「逆康威定律」，通过适配康威定律，在明确技术架构方向的基础上，以组织结构的调整来推动技术架构的演进。

2.2 组织的形态

每家企业都有自己的文化和组织形式，抽象出来大致可以分为权力型，流程型和交易型，落到研发团队内部，一般只有前两种。

现在许多人强调去中心化、去科层化、去权力化，实际上，在大多数情形下，权力连接还是最直接、最简单、最有效的机制。权力组织讲究的是执行。

组织中的权力主要有四种。除了决策权，还有建议权、审核权和知情权。

• 决策权，对一个事情决定资源投在哪里，是不是可以做的权力；
• 建议权是提出方案、预案的权力。注意，这是一种权力：建议权拥有者如果未提出建议，上级决策者不能替代或强压；
• 审核权是对有关事项程序性、合规性的审查与核准。注意，这种权力不是对事项进行决策；只要有关事项符合程序、合乎标准和规范就予以通过放行。我们经常会看到一些企业的职能管理部门把审核权误当成了批准决定权，导致审批流程变长、决策效率降低，这是需要反思改进的。
• 知情权是信息共享权，即获取信息的权力。

以上 4 个权限很容易让我们想到项目管理里面的 RACI 矩阵：

• 谁负责：（R = Responsible），即负责执行任务的角色，他/她具体负责操控项目、解决问题。
• 谁批准：（A = Accountable，决策权），即对任务负全责的角色，只有经他/她同意或签署之后，项目才能得以进行，是整个事情的决策者；
• 咨询谁：（C = Consulted，建议权），拥有完成项目所需的信息或能力的人员，多提出建议。
• 通知谁： (I =Informed，知情权)，即应及时被通知结果的人员，却不必向他/她咨询、征求意见。

以上四种权力，决策权和建议权是权力主线，审核权和知情权是权力副线。主线是上下级逻辑，副线是平级或流程型逻辑，而我们往往理解的权力是主线权力。

在强权力主线的基础上，权力型组织的有以下 3 个缺点：

1. 唯上，组织内的成员对决定其资源或发展的上级负责；
2. 组织的发展由上级决定，当上级缺位、能力不足或脱离实际时可能会出现瞎指挥，乱指挥的情况；
3. 层级过多，导致执行和决策的效率低下。

为规避这些缺点我们需要减少层级，增加连接和协同。

如果把管理层只分为三级，我们一般称之为高层、中级和基层。这三个层要解决的问题不同。高层解决长期发展的问题，中层解决系统效率的问题，基层解决的是事情本身的问题。

比如技术管理者常规上可以分为三个大层：

• 高层管理：解决长期发展的问题，使企业/团队有前途，关注的是未来，不管是技术发展的未来，还是业务发展的未来；
• 中层管理：解决系统效率的问题，使系统更有效率，要不断强化研发流程的统一性和适应性，确定并执行好标准和规范，提升协同的效率，标准化和系统化，同时为上层的选择和决策提供依据和保障；
• 基层管理：解决事情本身的问题，而事情往往会落到一线的开发同学身上，于是经常我们基层管理者的主要工作是使一线开发同学工作有成就，培养一线开发同学，提高他们承担工作的能力和意愿，帮助他们解决问题。

我们期望是每个层能做好自己的事情，但是实际上往往是高层在做中层的事情，中层在做基层的事，基层在做一线的事情，错位了。于是，我们需要将管理层归位，各行其职，更专业的做事情。

在明确职责的基础上，尽量减少管理的层级，尽量不要出现 「副XX」 的岗位。

在协同方面我们用流程来解决协同合作的问题。流程本身的逻辑是对事情负责，对自身的任务及向下事项/环节负责。其驱动力是责任感和依赖。百度文化里面的「简单可依赖」能较好地说明流程的底层逻辑。当我们使用流程来解决协同的问题时，要经常迭代流程以优化协同的效率：

• 注意流程是为了解决过程中的问题，不是为了设置卡点，每个人都有扩大自己权力的欲望，这是我们在流程建设中要特别注意的；
• 尽量减少流程环节，聚合责任主体，我们经常遇到一个事情在某职能部门还需要经过两三道审核的情况，这种损耗可以通过聚合责任主体的方式来解决；
• 控制流程时长，这里控制流程时长还包括流程环节的前置准备，就和我们开会一样，如果开会前准备充分，会议本身的时长就有极大可能减少。

用权力解决「力出一孔」的问题，用流程解决协同合作的问题。

简单来说，在权力体系的基础上，用流程连接各环节和负责主体，现在比较常见的矩阵式组织结构基本符合这个逻辑。当然这里有一个以流程为主还是以权力为主的问题，具体是哪种，还得看公司当前组织结构的逻辑。

2.3 分工的粗和细

Adam Smith 在 1776 年的《国富论》中提出了分工，分工对于手工业生产效率有较大的提高，其总结了三个优点：

• 熟练程度的增加，当一个人专注于一块工作，不停的练习极大的增加了熟练度，熟练度的增加将导致质量和产量的增加；
• 当熟练后，人们对于重复的操作进行机械化或自动化，从而更大的提高质量和产量；
• 分工明确了输入和输出，在明确的分工下，从一个工序转为另一个工序的时长减少了。

自从分工提出来了，产生了大量的争论，有人提出了以下的一些缺点：

• 一叶障目，不见泰山，分工越细，所关注的东西都小，当人陷于某个事情越来越小的部分时，其大局观往往受限，可能会导致局部提升而全局受损的情况；
• 分工越细意味着沟通协作成本的增加，当分工获得的收益小于沟通协作的收益时，将产生极大的成本浪费；
• 分工一定关系到组织结构的分块，当沟通不畅或没有沟通时，有可能出现组织上的「孤岛」

分工落到一个研发团队，我们通常按编程语言分为 Java、PHP、C++、Javascript，或按端分为安卓端、iOS 端、前端、后端、算法、数据等，又或者大一点分为开发、测试、运维，架构师。

虽然「术业有专攻」，但多跨一步会让分工后的协同更高效一些，这里最常见的可能是测试左移和测试右移。

• 测试左移是指在研发流程中，把测试的覆盖范围从传统的测试节点中释放出来，将其向左扩展，介入代码提测之前的部分，如开发阶段阶段，需求评审阶段，让研发人员在架构设计时就考虑产品的可测试性，并尽量进行开发自测，同时评估需求的质量，比如分析需求的合理性以及完整性等。
• 测试右移是指把测试的覆盖范围从传统的测试环节中切出来，将其向右扩展，更多地融入代码部署、发布，甚至上线之后的步骤中。

更极端一些，走全栈路线，一个人从头到尾完成需求的所有工序。但是这种方式，对于人员素质的要求，对于团队组织的要求和常规不一样，且人的精力是有限的，能在每个方面都做到精通的，少之又少，除非所做的事情只需要略懂即可。

思考一下，你所在团队应该如何来做？

成本和效率？组织大小？技术发展？架构演进？

3. 机制

3.1 DRI 机制

3.1.1 DRI 的由来

DRI 是 Directly Responsible Individual 的简称，中文翻译为「直接负责人」。最开始是从苹果流传出来的内部管理概念。

DRI 不是流程、过程，也不是框架，而是一个负责人，对某部分的整体负责，小到 BUG，大到技术方向。 DRI 是为了解决责任主体的问题，其有助于避免责任分散。责任分散这个概念也被称为「旁观者效应」，也就是人们身处团队中时无法对某事负起责任，责任分散到了团队中的每个成员身上，而不是集中在真正有责任的人身上，因为每个人认为那个责任应该由其他人承担，表现得像一个旁观者。

3.1.2 DRI 的职责

• 聚焦目标；
• 督促、监督团队成员完成自己的任务；
• 清楚团队中发生的一切；
• 统筹策划，搞定所有的干系人，从头到尾负责到底，说简单点就是团队成员专注的做好手上的事儿， DRI 排除干扰，解决各种烦人的问题来，发现问题，解决问题；
• 有一定的领导责任。

简单来说，当你是某个事情的 DRI 后，这个事情就是你自己的事情。特别是当职责不清或者突发问题时，DRI 就需要发挥主人翁的精神，拉起团队成员去分析问题，解决问题。

3.1.3 什么人适合做 DRI

DRI 和工作年限无关，和是否资深无关，和技术工种无关，你想你就是。

但是在操作过程中，我们会根据实际的场景做一些偏重。如果是一个后台的活儿居多的项目，其 DRI 大概率是后台的开发同学，如果是一个质量问题较多的项目，其 DRI 大概率是一个 QA 同学。

这里我们会充分考虑同学的主观意愿，有些同学想，有些同学不愿意，只想做好手上的工作，那么他做好他手上工作的 DRI 就可以了。

DRI 无关项目大小，无关职位高低，无关所在层级，每一件大事，小事都需要有一个 DRI，且只有一个 DRI

这玩意儿换成中文其实就是我们在标语里面经常看到的「责任到人」差不多，但是更强调责任主体的唯一性。

3.2 构建良好的协同机制

公元前 221 年，秦始皇用了十年的时间，先后灭了韩、赵、魏、楚、燕、齐六国，完成了统一中国的大业。在以后，他陆续颁布了多条律法，以稳固国家的统治，包括「书同文」、「车同轨」、「度同制」等。

一个国家，一个组织，要想成为一个高效执行的团队，一定要有标准，一定要有人告诉大家怎样做是对的。 落到我们团队管理，标准，流程是必须要做的，特别是当你的团队是由若干个团队整合或融合的时候。

3.2.1 统一标准规范

当你的团队是由原来多个业务的团队融合而成，大家原来都有做一些标准，现在我们需要按统一的标准达成共识并推行下去。又或者本来标准不完善，需要系统梳理标准来达到标准的统一。

行业标准一般是为了互联互通，而对于研发团队的研发过程来说，标准主要是为了减少过程中的认知成本，提升研发的效率，比如数据库规范，大家按统一的规范来设计数据库，当有其它同学接手你负责模块的时候，能减少在基本结构的认知成本，以及在一些模块间整合或数据迁移时，对于工作会比较友好一些。

标准是什么，标准是一件行为准则，其关注的是结果。

标准和规范一般是为了告诉人们什么是好的，关注的结果，而统一标准是为了让大家互联互通。

标准不是为了成功，而是为了让整个事情不至于太坏，尽量不出现重大的问题。 具体到研发团队，我们一般需要统一如下一些标准：

• 研发过程
  • 代码风格规范
  • 数据库设计规范
  • 代码分干管理规范
  • 代码提交规范
  • 错误码规范
  • Code Review 标准
  • 代码权限管理规范
• 沟通协同
  • 架构规范
  • 技术方案规范
  • 文档规范
  • 接口规范
• 质量标准
  • 代码质量标准
  • 自动化测试标准
  • 测试质量标准
  • 线上质量标准
• 性能标准
  • 服务端性能标准
  • 客户端性能标准
  • 前端性能标准
• 安全标准
  • 信息安全标准
  • 代码安全标准
  • 数据安全标准
  • 线上安全标准

3.2.2 统一流程

流程是什么？

流程是基于时间线，有一定先后序列规则的完成一件事的过程。流程是线性的、连续的。

统一流程是什么？

统一流程就是把一些验证过的好的做事方式，好的经验通过流程的方式固化下来，防止大家重蹈覆辙，在一个坑里踩多次，并且为不熟悉的同学做好指导。

我们做任何一件事都是有流程的，有些是设计过的，有些是自然而然的，设计过的流程可能是别人的经验。并且流程需要持续迭代。

在研发管理中我们常常会构建的流程如下：

• 敏捷流程
  • 需求迭代流程
  • 紧急需求流程
  • 值班需求流程
• 研发流程
  • 代码审核流程
  • 代码发布流程
  • 紧急发布流程
• 协同
  • 对接流程
  • 资源申请流程
  • 线上问题/告警处理流程
  • 事故处理流程
  • 安全问题处理流程

3.2.3 统一工具

以上说了要统一标准，统一流程，这些第一步是要把这些标准和流程做出来，形成文档，落到知识库中。 如果只做到这一步，这些标准和流程可能就真的只是一个文档，情况好一点，有人来推进重视，可能会落实一些，但一旦这个推进人不在了，或者不再关注了，很多形式就不了了之。

要解决这个问题只能通过工具或系统，以工具或系统的形式固化标准和流程，把这此好的经验和方式以更物理的方式沉淀下来。再以这些工具或系统为杠杆，提升整体研发的效率，创造增量的价值。

4. 系统

这里的系统不仅仅是指使用某个系统，在使用系统的基础上整合，实现我们高效执行的目的。 前面我们有了机制，但是事情太多，不能让所有的事情用人来去解决，需要用系统来解决。

机制解决规模化的问题，系统解决规模固化的问题。 系统解决的问题有两个层面，一个是过程跟进，一个是结果度量。

4.1 工作流和过程跟进系统

一个研发部门可以看作一个系统，需求从一端进入，经历各种正确的工序，才能变成产品，如期从另一边离开。 当系统内部存在冲突，或者不和，或者互相针对，那么就会发生各种想象不到的问题，从而让整个系统的产出变少，甚至没有。

着眼于整个工作流，确认瓶颈点在哪，尽可能的运用各种技术和流程来确保工作在计划内有效的执行。因为我们知道：在代码投产之前，实际上并未产生任何价值，因为那只是困在系统里的半成品。

在实际中我们如何让大家更好的协同，更好的让这个工作流运转起来呢？以前可能是 Excel、Word 或者 todolist，再加上邮件或 IM 传来传去，现在更进一步有在线的表格协同，还有更完整的项目管理系统，如 Jira 、Trello、腾讯的 TAPD、阿里的 Teambition、禅道等。工具不同，但是目标是相同的，都是希望做到对项目执行的管控、对团队事务（问题）的跟踪，对需要多人协作任务的快速流转和处理。

除此之外，还需要文档管理，即过程中的物料也需要跟进起来，关联起来。至于是一个系统，还是多个系统，都是可以的。

系统虽有，但用得怎么样不好说，一个好的系统用不起来也是白搭，这里作为管理者需要推动起来的。

4.2 工作可视化

项目管理的系统用起来后，我们的工作流转就会落到系统里面，此时根据系统的数据，我们可以让工作可视化，透明化，能够清晰的观察工作流动的情况，从而发现瓶颈。发现问题是最难的，很多时候我们不知道有什么问题，包括自己。发现问题，才能解决问题，方法总是有的。 在资源有限的情况下，对非约束点的改进看起来很正确，但实质上毫无帮助，甚至会消耗宝贵资源拖累真正需要解决的问题。

我们可以构建一些看板，看一个产品从产品到设计、到研发实现，到测试完成，上线发布，再到线上问题跟进等等的情况。看效率，看一个需求从出现想法到用户看到需要多少时间，每个环节需要多少时间，哪些需求在哪些环节停留太久？不同的需求，不同的人，不同的产品做多个层次的对比，从而发现问题解决问题，让一切都在阳光下进行。

同时，我们可以让系统和数据告诉我们，整体团队的投入如何，有多少同学的工作是可以追溯的，有多少人力是隐藏在不为人知的地方的，能看到我们的时间都去哪了。

基于这样的看板，我们从两个角度优化整个系统：

• 从左到右的流动，看从产品、设计、研发到运维的工作情况。为了最大程度地优化工作流，需要将工作可视化，减小每批次大小和等待间隔，通过内建质量杜绝向下游传递缺陷，并持续地优化全局目标；
• 从右向左的反馈，每个阶段中，应用持续、快速的工作反馈机制。通过放大反馈环防止问题复发，并缩短问题发现时间，实现快速修复。通过这种方式，我们能从源头控制质量，并在流程中嵌入相关的知识。这样不仅能创造出更安全的工作系统，还可以在灾难性事故发生前就检测到并解决它。

总体来说，先透明出来，再优化，打开黑盒，问题会简单很多。

4.3 其它

以上的两个是从任务跟进和结果度量的角度，或者说从项目管理的角度来看整个团队的运转。 换一个角度，从研发同学工作本身，有没有需要系统化的地方？

代码管理是否系统化，Code Review、接口文档、接口自动化测试、Mock 数据、测试数据集管理、用户数据自动脱敏重放，代码从写完提交到代码库之后到上线，线上巡查等等这些是否有系统化？

这并不是今天我们要讲的话题，但是就系统化来说，这些都是必不可少的关键点。不管是哪方面，我们的原则是尽量减少人工介入，把人的经验变成代码和系统。

5. 后记

这篇文章务虚居多，也比较散，但是确实是技术管理者日常工作中要不停思考的点。 思考这些是用来帮助厘清思路，并不具备实操性，也就是不能实际的解决问题。 不同的公司，不同团队，问题不同，解决的方法也不同，欢迎一起探讨。

打开「黑盒」，问题会简单很多。常思考人、组织、机制和系统，这 4 个方面，发现其中的问题，并厘清解决问题的思路，一步一步，有节奏的去解决。

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