谈谈 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 没有银弹

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

1,670 次阅读

发表评论

电子邮件地址不会被公开。

back to top