谈谈 Ops（三）：事务、团队和时间分配

作为普通的开发人员，我们会遇到对于时间分配的思考，没有金标准，只有某些看起来也未必靠谱的 “最佳实践”。不同人眼中对于整体的时间分配也有自己的看法，这篇文章旨在探讨其中的一两种情况。

Ops 的事务类型

Ops 的事务很多很杂，首先要明确一点的就是，Ops 远不止 oncall，远不止线上产品维护。整个软件工程流程中的配置、部署、环境搭建、升级、打补丁，甚至问题定位、故障排查等等，都或多或少可以算作 Ops。

记得在读书的时候，老师给我们把日常事务划为四个象限：紧急重要、紧急不重要、不重要但紧急，以及不重要不紧急。Ops 和一般软件开发活动在这四个象限的分布上来比较，更多地，会偏重于 “紧急”（左侧一半），并且不重要不紧急的比例尤其低。换言之，就传统的 Ops 观念来看，不重要不紧急的事情根本就不会有人主动去搭理——“If it works don’t touch anything.”，甚至，在 Ops 中重要不紧急的事情都会一拖再拖。可见，平心而论，Ops 在传统软件开发人员的心目中，并不具备特别高的地位。

另一个典型例子也可以反映 Ops 地位，作为绩效评估，特别是 promotion（晋升）相关的绩效评估，我们通常都能看到一条，或者 “国际惯例” 一条 “产品/特性的设计开发”，也就是说，如果没有设计开发一个复杂度足够高的产品/特性，这样的 promotion 提议不具备说服力。但是，相比较 Ops 方面在这里的分量却并不常见。换言之，如果一个工程师设计了一个复杂、高效的系统，这可能会成为 promotion 上举足轻重的砝码，但是如果一个工程师在 Ops 工作上兢兢业业，积极响应，极少出错，却不能够成为决定性的 promotion 数据支持。

Ops 个人与 Ops 团队

几乎每一家公司都有 Ops 分工的讨论。我的观点是，一个健康的研发体系，绝大多数 Ops 的工作，就应该交给普通的软件工程师来完成。

有人会有不同的看法，说我们还有单独的 Ops 团队协助呢。

没错，是这样。可是仔细想想，即便有 Ops 团队，假使有充分的工具与设施，他们到底还能够帮到多少忙，我们到底还需要多少单独的 Ops 团队？

Ops 团队，专门做运维的团队，有的公司叫做维优团队（一线团队）。他们往往精通于运维技能，但对开发测试技能要求没有那么高。他们往往被要求熟谙流程，快速响应，长期待命。

前面已经说过，Ops 远不只是维护线上产品，这里面的大多数行为只有开发团队才能做，且无法被替代。即便是 oncall，Ops 团队也无法完成很多问题的追踪修改，我见过许多 Ops 团队只能充当人肉靶子，处理一些回应策略已经清晰但重复率高的问题，以及过滤掉一些基础和客户响应类问题。

而这一类真正可以委托给 Ops 团队做的事情，恰恰有一个共同的特点——都是简单劳动，而且可以自动化。换言之，缺少的是充分和有效的工具。

于是就有人说了，开发人员没有那么多时间去创建这些工具，所以我们需要 Ops 团队。一定程度上说，这话没错，但从成本等角度综合考量，许多 Ops 团队的引进只是类似我在前一篇关于 Ops 的文章中介绍的流程，是一种较为简单粗暴的解决问题的方式。长远来说，多数情况下，投入到工具开发的成本，和让开发人员来做 Ops 的成本，最终会小于聘用 Ops 团队的成本。

我记得有这样一个 “段子”。说一个工程师团队本来独立运作，但是突然有一天来了一个糟糕的程序员，开始写糟糕的代码，质量一塌糊涂。老板看不下去了，给配了一个测试团队来保证质量。可这哥们不只是代码质量不行，时间管理也不行啊，于是老板给多配了一级 manager 来管理。又发现他态度不行，于是又搞了流程管理的一套来约束。代码上线了，不得不配了运维团队来第一时间响应客户抱怨，报告给别的工程师来修复他代码里的问题。于是一个接着一个，队伍就这样壮大起来了。

这似乎有夸张的成分，但是这个朴素的道理却很清楚。Ops 需要反哺，一般情况下，就像只有开发人员才能做好测试一样，只有开发人员才能做好运维。除了开发人员自己做 Ops，没有任何一种组织结构能够提供这样没有回馈损耗的反哺机制，没有任何一种方式能让开发人员 “吃自己的狗食”。另外，我想起了了对于某些团队而言，和客户直接沟通也是这种反哺机制最好的实践之一。Steam 上有不少独立游戏，都是小团队完成的，他们的开发人员可以直接在论坛中和客户讨论。讨论的内容不只是需求，更有问题。

Ops 的时间比例

无论是否 “正确” 或 “合理”，基于现有的这般事实，我们在评估和衡量 Ops 时间比重的时候，要积极考虑。对于绝大多数团队来说，Ops 不应当成为团队最大的时间投入。除了特殊的专职 Ops 的团队，我认为普通开发团队中 Ops 的比重应当保持在 25% 以下，即便是一些相对来说业务发展已经成熟，因而天然的运维压力较大的团队，这个比例也不要超过 35%。为什么有了工具还有那么高的 Ops 成本？因为不是所有的问题都值得做一个工具去解决，这里一定存在一个主要基于投入产出比例的 trade-off。

如果这个比例过高，有许多负面因素会加速情况的恶化：

• 忙于救火，忙于解决历史问题。这些问题都是具体而局限的，为了解决这些问题很难保证方案的合理性。实际操作的时候往往都是着眼于问题本身的，只要解决了问题，合不合理很难得到足够的约束。
• 开发人员容易疲劳，这远不只身体的疲劳。据我所知大多数工程师还是更喜欢有节奏的、合理的特性开发，而非不可预见的各种 bug fix。前者更为系统，后者虽然带来职业不同角度的成长，但也容易掉入局限和缺乏规划的境地。
• 重复劳动，特别是限定时间压力下的重复劳动。可能有朋友想起了 oncall，其实无论是不是 oncall，天然地，从 Ops 的角度来看，重复劳动都是难以避免的。我们能通过工具、脚本、自动化等种种途径简化这样的劳动，但是既然说 Ops 比例过高，这里几乎就意味着这样的途径是明显不足的。
• 缺少愿景和规划来吸引人才。这也是显而易见的，一个忙于做 Ops 的团队，其吸引力往往敌不过那些做着有趣和有影响力产品开发的团队。这不止表现在能否吸引外部的人才，也表现在能否留住内部的人才。我见过一些 AWS 的团队，从外面看高大上，但是内部的员工流失率却出奇的高。
• ……

同时需要看到的是，Ops 的比例过高固然不好，要把它降到一个很低的值却也往往很困难，这其中需要付出的代价往往得不偿失。我确实也经历过或者见到过一些 Ops 比例极低的团队，他们有一条或多条这样的特点：

• 这是一个做项目，而非做产品的团队。我在这篇文章中曾经探讨过。这是第一条，也是最常见的原因。就是天生有一些团队，把项目做起来，验收交付出去，故事就结束了。他们就可以转投另一个项目去了。从长远来看这样的团队并不适合工程师平衡发展。
• 业务紧要程度低。有时候这就纯粹是一个花瓶团队了，也许产品已经接近废弃了，也许没有那么多挑剔的用户了。
• 当然还有一个常见原因——这是一个新团队，在做一个新产品。乐观地说，这不是业务紧要程度低，也不是 Ops 工作量不大，而是时候未到。
• 有人说，还有一个可能，某些团队有专门的 Ops 团队配合，因而 Ops 工作比较少。我觉得不是这样的，对于一个健康的体系来说，即便有 Ops 团队，大多数和 Ops 相关的事情，还是需要原始的工程师团队来完成。这一点，前面已经讲到过。

那么如果发现这个比例已经过高了，需要做什么来缓解这样的问题呢？我听过太多不同的说法了，毕竟这是一个太过普遍的问题。但我认为最重要的一点，是把责任明确到和交回给开发团队。不要期望非开发团队去解决代码层次的问题，工程师们请把 “自己的狗食” 夺回来。

对于现有 Ops 压力过载的问题要花大量时间去分析和规划，而不是定义数量上的目标来关闭问题。问题的分析时间往往要大过问题的解决时间。不能期望这些 Ops 的问题可以在一夜之间消失掉，这些是所谓的技术债务，长远看解决他们往往是比各种规避方式要更节约成本，但短期内的回报却未必，这里的平衡需要一个稳定和自洽的团队来把控。一个走马灯一样换的管理团队不可能具备远见。

最后也是最重要的一点，是要尊重软件规律，堆人和追进度的结果，就是留下一堆债务，就是被迫陷入从 dev 赶工到 ops 噩梦的最常见原因。如果这样做了，就要承担数倍于原有时间等工程开销的后果——

和其它软件工程的问题一样，Ops 没有银弹。

文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》