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

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

457 次阅读

发表评论

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

back to top