谈谈 Ops（汇总 + 最终篇）：工具和实践

除了主要内容——工具和实践，这篇文章也对 “谈谈 Ops” 系列做一个汇总，提供一个访问入口。之前几篇，从一个纯粹 dev 狭窄的视角，谈了谈自己对 Ops 的一些认识：

在往下继续以前，如果没有看过前面的文字，不妨移步阅读，因为上面的内容对下面的内容做了一定程度的铺垫。

现在在写的这一篇文字，我准备是最后一篇，主要谈论这样几个事情：一个是工具，另一个是实践。我依然还是从 dev 的视角，而不是从一个专业运维的视角来记叙。

工欲善其事，必先利其器。我在主要且通用的工具中挑了几个，和最佳实践放在一起介绍，并且按照功能和阶段来划分，而不执着于列出具体的工具名称。其中最主要的阶段，包括开发阶段，集成测试阶段，以及线上部署维护阶段。顺便也再强调一次，Ops 远不只有线上系统的维护。

Pipeline

把 Pipeline 放在最先讲，是因为它是集成下面各路神仙（工具）的核心，通过 pipeline，可以把一系列自动化的工具结合起来，而这一系列工具，往往从编译过程就开始，到部署后的验证执行结束。

Pipeline 最大的作用是对劳动力的解放，程序来控制代码从版本库到线上的行进流程，而非人。因此，对于那些一个 pipeline 上面设置了数个需要人工审批的暂停点，使得这样的事情失去了意义。这样的罪过往往来自于那些缺少技术背景的负责人，其下反映的是对流程的崇拜（前面关于流程和人的文章已经提到），而更进一步的原因是不懂技术，就无法相信代码，进而无法信任程序员，他们觉得，只有把生杀大权掌握在自己手里，才能得到对质量最好的控制。这样的问题从二十多年前的软件流程中就出现了，到现在愈演愈烈。我只能说，这无疑是一种悲哀。

我见过懂技术的老板，也见过不怎么懂技术的老板，还见过完全不懂技术的老板。但是最可怕的，是那种不太懂或完全不懂，却又非常想要插一手，对程序员在软件流程方面指手画脚的老板。为什么是流程？因为技术方面他们不懂，没法插手，却又觉得失去了掌控，只好搞流程了。

我曾经遇到过这样一件事情：程序有一个 bug，因为在一个判断中，状态集合中少放了一个枚举值，导致了一个严重的线上问题。后来，程序员修正了问题，老板和程序员有了这样的对话：

老板：“你怎么保证未来的发布不会有这样的问题？”

程序员：“我修正了啊。”

老板：“我怎么知道你修正了？”

程序员：“我发布了代码改动，我使用单元测试覆盖了改动。”

老板：“好，我相信你开发机的代码改动做了。可我怎么知道你发布到线上的版本没有问题？”

程序员：“……发布的代码就是我提交的啊。”

老板：“你怎么能保证代码从你提交到线上发布的过程中没有改动？”

程序员：“……（心中一千头草泥马奔腾而过）我可以到线上发布的 Python 包里面查看一下该行是不是已经得到修改。”

老板：“好。我们能不能在 pipeline 里面，添加这样一个步骤——执行部署的人到发布包里面去检查该行代码是不是正确的。”

程序员：“……（现在变成一万头了）不要把，这样一个额外的检查会浪费时间啊。”

老板：“检查一下需要多少时间？”

程序员：“5 分钟吧”

老板：“花费 5 分钟，避免一个严重的问题，难道不值得吗？”

程序员：“……（现在数不清多少头了）如果这一行要校对的话，为什么其它几十万行代码不用肉眼校对？”

老板：“就这一行需要。因为这一行代码曾经引发过严重问题，所以需要。”

程序员：“……”

如果你也见过这样的情形，不妨告诉我你的应对办法是什么。

依赖管理

以 Java 为例，有个搞笑的说法是 “没有痛不欲生地处理过 Jar 包冲突的 Java 程序员不是真正的 Java 程序员”，一定程度上说明了依赖管理有多重要。尤其是茁壮发展的 Java 社区，副作用就是版本多如牛毛，质量良莠不齐，包和类的命名冲突简直是家常便饭。我用过几个依赖管理的工具，比如 Python 的 pip，比如 Java 的 Maven，但是最好的还是 Amazon 内部的那一个，很可惜没有开源。注意这里说的依赖，即便对于 Java 来说，也不一定是 Jar 包，可以是任何文件夹和文件。一个好的依赖管理的工具，有这么几点核心特性需要具备：

1. 支持基于包和包组的依赖配置。目标软件可以依赖于配置的 Jar 包，而若干个 Jar 包也可以配置成一个组来简化依赖配置。
2. 支持基于版本的递归依赖。比如 A 依赖于 B，B 依赖于 C，那么只需要在 A 的依赖文件中配置 B，C 就会被自动引入。
3. 支持版本冲突的选择。比如 A 依赖于 B 和 C，B 依赖于 D 1.0，C 依赖于 D 2.0，那么通过配置可以选择在最终引入依赖的时候引入 D 1.0 还是 2.0。
4. 支持不同环境的不同依赖配置，比如编译期的依赖，测试期的依赖和运行期的依赖都可能不一样。

当然，还有许许多多别的特性，比如支持冲突包的删除等等，只是没有那么核心。

自动化测试

代码检查、编译和单元测试（Unit Test）。这一步还属于代码层面的行为活动，代码库特定分支上的变动，触发这一行为，只有在这样的执行成功以后，后面的步骤才能得到机会运行。单元测试通常都是是 dev 写的，即便是在有独立的测试团队的环境中。因为单元测试重要的一个因素就是要保证它能够做到白盒覆盖。单元测试要求易于执行，由于需要反复执行和根据结果修改代码，快速的反馈是非常重要的，几十秒内必须得到结果。我见过有一些团队的单元测试跑一遍要十分钟以上，那么这种情况就要保证能够跑增量的测试，换言之，改动了什么内容，能够重跑改动的那一部分，而不是所有的测试集合。

集成测试（Integration Test）。这一步最主要的事情，就是自动部署代码到一个拟真的环境，之行端到端的测试。比如说，发布的产品是远程的 API，UT 关注的是功能单元，测试的对象是具体的类和方法；而在 IT 中，更关心暴露的远程接口，既包括功能，也包括性能。集成测试的成熟程度，往往是一个项目质量的一个非常好的体现。在某些团队中，集成测试通过几个不同的环境来完成，比如α环境、β环境、γ环境等等，依次递进，越来越接近生产环境。比如α环境是部署在开发机上的，而γ环境则是线上环境的拷贝，连数据库的数据都是从线上定期同步而来的。

冒烟测试（Smoke Testing）。冒烟测试最关心的不是功能的覆盖，而是对重要功能，或者核心功能的保障。到了这一步，通常在线上部署完成后，为了进一步确保它是一次成功的部署，需要有快速而易于执行的测试来覆盖核心测试用例。这就像每年的常规体检，不可能事无巨细地做各种各样侵入性强的检查，而是通过快速的几项，比如血常规、心跳、血压等等来执行核心的几项检查。在某些公司，冒烟测试还被称作 “Sanity Test”，从字面意思也可以得知，测试的目的仅仅是保证系统 “没有发疯”。除了功能上的快速冒烟覆盖，在某些系统中，性能是一个尤其重要的关注点，那么还会划分出 Soak Testing 这样的针对性能的测试来，当然，它对系统的影响可能较大，有时候不会部署在生产环境，而是在前面提到的镜像环境中。

部署工具

曾经使用过各种用于部署的工具，有开源的，也有内部开发的。这方面以前写过 Ant 脚本，在华为有内部工具；在 Amazon 也有一个内部工具，它几乎是我见过的这些个中，最强大，而且自动化程度最高的。部署工具我认为必须具备的功能包括：

• 自动下载并同步指定版本的文件系统到环境中。这是最最基本的功能，没有这个谈不上部署工具。
• 开发、测试、线上环境同质化。这指的是通过一定程度的抽象，无论软件部署到哪里，对程序员来说都是一样的，可以部署在开发机（本地）用于开发调试，可以部署到测试环境，也可以部署到线上环境。
• 快速的本地覆盖和还原。这个功能非常有用。对于一个软件环境来说，可能 1000 个文件都不需要修改，但是又 3 个文件是当前我正在开发的文件，这些文件的修改需要及时同步到环境中去，以便得到快速验证。这个同步可能是本地的，也可能是远程的。比如我曾经把开发环境部署在云上，因为云机器的性能好，但是由于是远程，使用 GUI 起来并不友好，于是我采用的办法是在本地写代码，但是代码通过工具自动同步到云机器上。我也尝试过一些其他的同步场景，比如把代码自动同步到本地虚拟机上。
• 环境差异 diff。这个功能也非常有用。开发人员很喜欢说的一句话是，“在本地没问题啊？”，因此如果这个工具可以快速比较两个环境中文件的不同，可以帮助找到环境差异，从而定位问题。

当然，还有其它很有用的功能，我这里只谈了一些印象深刻的。

监控工具

我工作过的三家公司，华为、Amazon，还是 Oracle，它们的监控工具各有特点，但做得都非常出色。且看如下的功能：

• 多维度、分级别、可视化的数据统计和监控。核心性能的统计信息既包括应用的统计信息，包括存储，比如数据库的统计信息，还包括容器（比如 docker）或者是 host 机器本身的统计信息。监控信息的分级在数据量巨大的时候显得至关重要，信息量大而缺乏组织就是没有信息。通常，有一个主 dashboard，可以快速获知核心组件的健康信息，这个要求在一屏以内，以便可以一眼就得到。其它信息可以在不同的子 dashboard 中展开。
• 基于监控信息的自动化操作。最常见的例子就是告警。CPU 过高了要告警、IO 过高了要告警、失败次数超过阈值要告警。使用监控工具根据这些信息可以很容易地配置合理的告警规则，要做一个完备的告警系统，规则可以非常复杂。告警和上面说的监控一样，也要分级。小问题自动创建低优先级的问题单，大问题创建高优先级的问题单，紧急问题电话、短信 page oncall。
• 告警模块的系统化定义和重用。在上面说到这些复杂的需求的时候，如果一切都从头开始做无疑是非常耗时费力的。因而和软件代码需要组织和重构一样，告警的配置和规则也是。

对于其它的工具，比如日志工具，安全工具，审计工具，我这里不多叙述了。这并非是说它们不必须。

糟糕的实践

上面是我的理解，但是结合这些工具，我相信每个有追求的程序员，都对 Ops 的最佳实践有着自己的理解。于是，有一些实践在我看来，是非常糟糕的，它们包括：

• SSH+命令/脚本。这大概是最糟糕的了，尤其是线上的运维，在实际操作中，一定是最好更相信工具，而不是人。如果没有工具，只能手工操作，只能使用命令+脚本来解决问题，于是各种吓人的误操作就成了催命符。你可以看看 《手滑的故事》，我相信很多人都经历过。最好的避免这样事情发生的方式是什么？限制权限？层层审批？都不是，最好的方式是自动化。人工命令和脚本的依赖程度和 Ops 的成熟度成逆相关。
• 流程至上。这里我不是否认流程的作用，我的观点在这篇文章中已经说过了。其中一个最典型的操作就是堆人，发现问题了，就靠加人，增加一环审批来企图避免问题。
• 英雄主义。这是很多公司的通病，一个写优质代码的工程师不会起眼，只有埋 bug 造灾难，再挺身而出力挽狂澜，从而拯救线上产品的 “英雄” 才受人景仰。正所谓，没有困难制造困难也要上。
• 背锅侠。这和上面的英雄主义正好相反，却又相辅相成。找运维不规范操作背锅（可事实呢，考虑到复杂性、枯燥性等原因，几乎没法 “规范” 操作，人都是有偷懒和走捷径的本性的），找开发埋地雷，测试漏覆盖背锅。当场批评，事后追责。
• 用户投诉驱动开发，线上事故驱动开发。这一系列通过糟糕的结果来反向推动的运维反馈开发的方式（其它各种奇葩的驱动开发方式，看这里）。
• 把研发的时间精力投入 ops。这是恶性循环最本质的一条，没时间做好需求分析，没时间做好设计，没时间做好测试，没时间写好代码，什么都没时间，因为全都去 Ops 解线上问题去了。结果呢，糟糕的上游造就了更糟糕的下游，问题频出，于是更多的人花更多的人去 ops。如此恶性循环……

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