谈谈 Ops（一）：我的运维经历

偶然地，在会看这些年写的文章的时候，发现涉及到软件工程方方面面的内容，但是关于 Ops 的内容却非常少。我觉得这是不太合适的，因为在实际工作中，Ops 显而易见地占据了一大块比重。于是我调整了分类目录，增加了这个单独的分类，并且这一次，我想零零散散地讲一讲我关于 Ops 的一些经历，以及关于 Ops 的一些观点。

所谓 Ops，指的就是 Operations，在中文翻译上看，我觉得“运维”这个词可能是最恰当的。作为一个软件工程师，Ops 有时会特指 DevOps ，关于它的定义，在维基百科上有这样一张图片，我觉得基本正确地描述了 DevOps 涵盖的内容（见右侧图）。

可以看到三方面的内容，可是，由于我们会把 Development 单独拿出来讲，会把 QA 单独拿出来讲，因此当我们讲起 Ops 的时候，我们更多的指的就是上图中下面那个紫色的环。

我们都希望代码可以一蹴而就，测试可以面面俱到，软件和产品都可以顺利而愉快地跑起来，可这些都是一厢情愿。我们需要把新版本软件安全快速地部署上去，在出了问题之后需要采取措施减小影响，分析问题，并修复问题……这些问题都需要 Ops 这样不可替代的环节。由于我个人认识的局限性，在以往，Ops 显然是被我轻视的环节。当然，这可能也和我工作以前接受的教育也有关。读书的时候，我们学开发，我们学测试，可是我们从来都不学运维。可以说，上面这三个环的于我而言的重视程度，显然 Development > QA > Operations，这是不可否认的。我猜测着对于许多人来说也是如此。但是，随着工作经验的增加，我越来越意识到 Ops 本身的重要性。于是这些内容，打算分为几篇来讲，来自一个并不喜欢运维的软件工程师之手。

我在华为的经历

我工作的第一家公司是华为，这是一家对于 Ops 有着深刻理解和丰富经验的通讯软件公司。有意思的是，这也是在我熟悉的公司中，在 Ops 上花专人投入比例最高的一家。有许多项目的发布和运行，都是基于不同物理地区和物理站点的，这也是电信软件非常典型的一种部署模式。具体来说，就是华为的工程师，需要出差到电信运营商那里去，去安装部署。如果是一个全新的项目，这个过程叫做开局；如果是从别的服务提供商那里把项目接过来（比如一个项目，本来用的是中兴的软件，现在用户体验基本不变的基础上，挪到华为的平台上），这个过程叫做割接。其他我在十年前第一次出差，在中国联通 3G 机房，位置大概在北京上地，就是去开局。和开局花费的时长相比，割接通常更为迅速，但是压力更大，因为割接的场景通常意味着目标设备只有非常短的服务停止的时间，甚至要求无服务中断；另外，有时候竞争对手的关系，没有办法得到之前系统完整的信息，有许多决策需要根据经验来判断，甚至猜测——比如原数据库要从前一家竞争对手的老库迁移到华为的新库，数据转移的时候，某一列原数据库表里的字段在原始文档里没有，需要根据其内容和结构来推理其实际含义，再转移到新库恰当的位置上。

这种方式明显更为传统一些，从客户的角度来说，好处在于，我们跑到客户的地盘上，在他们的设备厂房里做文章，很多事情他们都更方便控制。对于一些复杂项目，需要有多家服务提供商协同合作的情况，甲方客户可以和各家乙方面对面工作，沟通和组织都会更加顺畅。至于这种方式的弊端之一——成本，对于国内的三大电信运营商来说，通常都不是一个问题。

上述成本包括人力成本，毕竟这样的方式需要有专职的运维人员看守。出于安全、审查等等角度的考量，设备是隔离的，网络是隔离的，运维人员需要在现场驻守，以处理预期内或预期外的各种问题。我们把那里叫做前方。而研发基地的工程师团队需要和运维团队沟通协作，解决各种各样的问题。这就是后方。通常后方的研发工程师没有办法直接动手，而是需要和运维工程师沟通以便采集数据和分析问题，在特殊情况下，为了增进效率，后方的研发工程师会出差前往前方现场，直接处理问题。

我还记得在那次开局的过程中，要和所有周边系统协同调试工作，这个过程叫做联调。由于整个 3G 系统庞大，我所负责的视频运营平台，以省为单位，要和不同的服务接口，比如计费服务等等，而甲方客户期望分散风险，每个省份的服务又都是独立的，而且实现厂商都是根据招标结果而来，每个省份都是独立的。因此和我们联调的服务来自各家厂商，这样的协同合作变得无比困难。这里面多数都非软件的问题，而是管理和沟通的问题。

出于成本的考量，如今互联网公司的很多机器设备多为普通性能的廉价设备，而硬件损坏的容错是作为整个分布式系统设计常规的一部分进行的。可那个时候，电信运营商的机器设备和如今互联网公司是大不一样的。我还记得我们的软件是部署在整个机架中间的数块单板上的，存储系统是部署在磁盘阵列上的，而数据库是部署在 IBM 小型机内的……于是我们许多的 Ops 操作，都是基于单台机器进行的。加上联调的许多工作，存在大量重复性的劳动。为此我写了很多 shell 脚本，来帮助提高工作效率，当时觉得很自豪。可是后来才慢慢感受到，真正优秀的 Ops 流程，是不需要自己现场去手写这些脚本的，工具应该帮我们干了几乎所有的事情。手动脚本是介于手动命令和 工具 之间的手段，但总体来说依然是一个容易犯错而且缺乏延续性的做法。一个成熟的运维流程，应该把这些犯错的可能减到最小。

这种 Ops 的模式可以让研发团队的工程师更专注于本职的研发工作，但是也会带来和实际场景脱节的问题。比如说，我在那个联通项目之后，转去做某一个新产品的基线版本了，基线版本多数情况并不直接上线，而是需要由定制团队进行本地化和具体项目化的定制，之后才能发布上线。这就足以见得我们离实际产品部署有多么遥远了。由此产生的其中一个典型问题就是，当时我们做的那个产品中，网站的那部分，由于搜索引擎优化等等问题，居然被 Google 爬虫给爬死了。这样严重的事情等一层一层分析、讨论和传播上来，等我们获知这样变体了多次的消息的时候，已经过去了很长一段时间，有一些具体的有价值的信息也丢失了，这让我们觉得离实际的产品仿佛很遥远。

我在 Amazon 的经历

Amazon 的库房遍布世界各地，而且更为零散和复杂，因而这种需要奔赴现场才能进行 Ops 的模式，多数情况下都是不适用的。Amazon 的不同团队会负责不同的服务，多数服务只用中心数据库或者数量有限的几个区域数据库，少数服务才在当地库房里面设置数据库。在 Amazon 内部，有一套专门负责版本管理和部署的工具，软件版本、依赖项目、包管理、分析、编译、测试、部署，等等等等，全部都由这套工具来完成。无论是 1 台机器，还是 100 台机器，软件工程师要做的，就是在适当的时候，盯着这套工具提供的界面，把软件按照指定的某种方案，部署到实际的机器上面去。任意两台机器具体部署的代码版本，通过工具就可以对比，如果要打补丁，要升级系统，要改权限，这套工具就可以完成。换言之，多数情况下都不需要 ssh 登陆到具体的机器上去。

我有一些互联网大公司的朋友，包括国内国外，从侧面了解过，再加上如今我所在的公司，综合比较起来，Amazon 内部提供给工程师用于 Ops 的工具应该说多数都非常先进，有些能够领先业界好几年，而这套部署工具尤其可以说极少公司能出其右（我以前的一位老板打趣说过它是 Amazon 内部“四大金刚”工具之一）。其实，极少有公司愿意在没有必要的情况下把一个内部工具功能做得无比强大，更何况是以 frugality 作为领导力准则之一的 Amazon。其原因之一就是，工程师的成本。招聘运维团队的工程师，其实并不容易，而如果能够用尽量少的研发工程师团队，“顺便”去把运维的事情做了，这无疑是很节约成本的事情。从这个角度说，资源的限制才能促进创新和发展。

有了一系列 Ops 工具，Amazon 不需要招特别多的专职 Ops 团队，而多数 Ops 工作自然由不同的工程师完成。其中一个最典型的事情就是 oncall。所谓 oncall，就是值班，一般研发团队里的工程师轮值，一旦出现严重的线上问题，警报就会想起，这个过程叫做 page，这种情况一旦出现，不管是上班时间还是下班时间，都要立刻投身问题应急处理的行动中去。事实上，Google 也好、Facebook 也好，Netflix 也好，专职 Ops 团队的人数相对研发整体来说都比较小，但是我依然认为 Amazon 是其中最不容易的一个，因为 Amazon 的许多产品和服务尤其需要繁重的 Ops 工作，在如今的公司做了将近一年的云设施的工作才慢慢了解，和其它一些互联网服务比起来，提供基础设施的 AWS 需要的运维工作量非常非常巨大。

有人说，让研发工程师去做运维，能做好吗？不是应该让专业的人去做专门的事情吗？这个观点是两说的，运维技能的缺乏可以通过优秀的运维工具来环节；而另一方面，每多一种“专业的人”，就意味着整个工作系统中，多了一个角色，多了一个 N 个需要沟通的环节，这些都是内耗。我在这篇文章 里面曾经比较过使用专业运维人员和使用研发人员来代理运维工作的情形。这种方式下，出现的问题能够最快速度和最大程度地引起开发人员的注意，有反向强化软件质量的作用。我相信多数软件开发工程师都不喜欢 Ops，这也容易理解，但是不参与 Ops 是很难想象能够做好产品的。

说一个具体事例。我记得在 Amazon 的销量预测团队工作的时候，有一次我 oncall 被 page 醒，因为新发布的软件本身暴露出来了一个问题，于是着手回滚到上一个版本。可是经过 rollback 之后，发现问题并未解决，调查获知原因是客户端缓存了前一个版本的某些有问题的信息，于是连夜赶补丁，刷新客户端内的信息，从而修复问题。事后，我们团队排查了类似的问题，相当于吃一堑长了一智。这样严重的问题不经过 oncall 这样典型的 Ops 经历，是很快速难反向强化回代码上的。

在我目前的公司中，Ops 方面所采用的方式和 Amzon 是类似的，Ops 在每个研发团队中的占比不同，我见过 10% 的，我也见过 80% 的。在我目前的项目团队，由于种种原因，Ops 的比重大概占到 40% 左右，这比我今年在前一个项目组中的 Ops 高了近一倍，也比我在 Amazon 期间最后一个团队的 Ops 工作量 30% 高，以我的理解来说，这明显偏高。其中的原因比较复杂，我们希望我们能够努力把它降到 25% 左右。当然，这并不是一件容易的事情，我对此也有一些思考，有关的内容等合适的时候再说吧。