谈谈 Ops（二）：流程和人

第二部分，我想谈一谈流程，依然来源于我的理解。Ops 的实践上面，有两部分内容紧密结合，不但共同显示了 Ops 的生产力，也在相当程度上体现了 Ops 的技术水平。这第一部分就是流程，也是今天要说的内容，另一部分是工具（也包括和使用工具相关的技能），下一次再说。

我认为 Ops 可以分为几个层次，最次的的一层，其特点是重度依赖于的人的直接 “操作”。风险管理、因果行为，都通过流程来统一把控，并且遗憾的是只有流程——除了它基本没有可靠有效的工具，或是其他办法。

其实，流程本是个好东西。有时候某些工程师被散漫和自由主义惯坏了，听到流程就反感。事实上，流程在很多情况下都有着举足轻重的作用。它们很容易控制，也很容易实施，基本是立竿见影，在不想要深入，不想要挖掘原因和研究对策的时候，流程上做一点改进，很快就能看到效果。

举个例子来说，多数的公司和团队，在线上代码发生变更的时候，都需要进行风险管理，这里面几乎一定会有流程。比如或最有名的叫做 “变更管理”（change management）的请求，一般由开发人员撰写这样的请求，然后由项目经理和 Ops 的责任人审批。这样的请求中，需要包括诸如变更内容、必要性、风险、部署步骤、验证方法、回滚方式等等内容。这样的目的，在于尽量把变化的因素变成预期内的、可控的因素，尽早发现可能存在的问题，降低风险。

但是，流程这样的方式，也有着负面效应。最大的效应就是，它单纯地固化行为，而拒绝人主动的思考。就像几年前国内热炒的 “敏捷” 一样，流程不应该是本质，工具也不应该是本质，只有人才是本质。

在我曾经的一个团队中，在项目发布以前的最后阶段，有限的时间里面（一般都是一个晚上），需要把最重要和最核心功能过一遍，这个功能清单叫做 checklist。为什么不把所有的测试案例都覆盖了？因为时间有限。这就是一个很简单也很容易执行的流程。但是，随着时间推演，问题变得很多。比如产品发布了以后，发现有一个比较大的问题，于是研发团队就要回溯问题，发现问题以后，为了杜绝问题的再次发生，就打算采取某些措施。（到目前为止做法上面都没有什么问题，可接下去就有争议了。）于是一条用于检测这个问题的识别项被加到这个 checklist 当中。这里面有很多检查项事实上在问题修复以后是不会再出现的了，也有一些检查项明显是用于覆盖位于边角的 corner case，而不是主要的 case，但是既然出过问题，为了保险起见，还是都加进去了。就这样，随着时间和版本的演进，这个 checklist 变得越来越长，某些验证项的执行难度颇为复杂，在几年以后，已经到了几个小时都无法过完这个 checklist 的地步，于是这个流程就变成了一个越来越难以执行的累赘。

造成这一问题的原因是什么，就是流程太简便了，太有效了，以至于这些聪明人不再思考应该采用什么样的方式来从根本上彻底地解决问题。

现在我不想进一步分析上面的问题，而是来看看这样一个争议。这个 “古老” 的争议和流程关系密切，到底应该保留单独的测试团队，还是应该让开发来做测试？

无论你对这个争议的观点如何，无论二者取舍的利弊如何，无论这两种结论的场景适用性如何，这个争议本质上反映了一件事——我们是应该用更多流程加上多个单一职责的团队来解决问题，还是用更少流程加上单个承担多种职责的团队来解决问题？

在回到上面 checklist 的那个问题上，这个问题恰恰出在开发和测试团队单独运作的体系之中。有人问，这些新增加的问题中，既然有一些检查项是不会再出现的，既然有一些检查项覆盖的是边角非主要用例，为什么大家还要同意加上去？这就和上面说的测试和开发团队分离的情况有密切关系。因为测试团队多数都做不到白盒，不知道实现，只想用输入输出覆盖黑盒用例的方法来保证正确性，因而所谓的问题 “不再出现” 就无从谈起；而团队和人一样，一朝被蛇咬，十年怕井绳，出过问题，不知道实现，也自然没有人愿意承担这个再出问题的风险，哪怕它曾经说一个边角的 case。

事实上，这个争议的观点可以扩展到更多角色。不要以为只有测试团队遇到这样的困惑。Ops 也是如此——到底应该保留单独的运维团队，还是应该让开发来做运维？

于是，我听过 Ops 团队的朋友说过这样的话，听起来很有意思：

如果线上问题少，boss 说，要你们何用？

如果线上问题多，boss 说，要你们何用？

当然，这些争议，最终都需要达成某种平衡，没有一种方法是放在所有场景下的万全之策。比方说，一些 AWS 服务中，Ops 的比重居然占到了 85% 以上。且不说其最终的合理性，市场和人才等方面的策略永远制约着团队去寻找最优雅的解决方案，而是选择最 “合理” 的解决方案，即便如此，和其庞大的基础设施业务相比，其 Ops 团队依然是小而优秀的。这些单独的 Ops 可能在整个服务的漫长生命周期中始终无可替代，没有他们，开发团队也无法专注于核心功能，而要被大量的 Ops 事务困扰。这也是为什么许多互联网大公司在推行小团队和综合型团队，强调工程师职责需要覆盖 Development、QA 和 Ops 三部分的同时，依然保留少量的独立 QA 团队和独立 Ops 团队。

再从公司和团队发展壮大的角度观察流程在 Ops 中的变化。

在一家公司还小的时候，团队更为原始，但是 Ops 却更容易聚焦在核心问题上面。用户有困难？解决困难。产品有问题？解决问题。没有繁荣缛节，也没有太多可以复制的模式和需要遵循的流程。慢慢地流程多了起来，人做的事情也更加专业，这里可能会达到一个最佳的平衡点。因为再往后，因为那些流程的过度复杂性和开销，使得效率和质量的平衡被打破，一切向着低效和臃肿慢慢滑落。

从这个角度说，互联网公司在这方面要比传统企业更懂得简化和合理化流程的重要性。即便在公司壮大以后，依然有一些自下而上的反馈行为帮助这件事情发生。

总的来说，Ops 和 Dev 一样，兼具影响力、效率，以及风险。和 Dev 比起来，Ops 往往更为枯燥，不可控性更多，有时候不得不响应一些紧急的事情。对于从这三者的角度看来，流程更多地，是用来在效率损失可以接受的情况下，控制风险，从而导向正向的影响力。对于一些服务更 critical 的团队来说，风险控制相对地，更为重要，因而流程的比重可以适当增加；反之，流程需要简化，保证效率在一个高标准之上。

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