故事背景
NSX 是 VMware 的支柱产品之一,旨在为企业提供一体化网络虚拟化方案。NSX vSphere 已在市场站稳了脚跟,公司正逐步把开发力量转移至它的后继者:NSX Transformers。去年发布的 Transformers 1.1 版本 [Crosshairs] 正在某家合作伙伴服役,今年推出的 2.0 版本 [Dropkick] 预计会在十余家企业推广试用。
NSX Transformers 曾经使用了 Pivotal 出品的 NoSQL 数据存储套件 GemFire。由于商业调整,GemFire 的核心组件被捐给了 Apache 基金会,产品开发陷入停顿。为了避免使用停止维护的产品,我司把目光投向了 VMware Research 编写的开源数据库 CorfuDB,并打算在 Dropkick 完成实装。这半年多的故事,都是围绕更换数据库展开的。
产品开发
年初的 V 家,显然还没有从硅谷一线公司那里学到两个礼拜 bootcamp 的重要意义。入职当天上午 10 点,我被经理带走配置开发环境。第二天,就领到了第一项任务,让我修改闭源的 CorfuDB 的软件版本号,并把它加到 nsx manager debian package 的依赖列表中。虽然组里没有给我安排一个导师,不过这种任务稍稍 google 一下就知道该如何动手:改一下 pom.xml
工程文件和 debian/control
控制文件就能搞定了。这差不多是一个小时的工作量,但是捣鼓评审系统、找人评审代码,花掉了好几天的时间。好不容易在第二周提交进了仓库,又迅速变身成了 P0 test blocker (P0 表示最高优先级的 bug),第一次出师就打了个全军覆没。我赶紧钻进代码和日志堆里看了一个上午,大概搞明白是因为没有把 CorfuDB 加入测试环境,才让整个流水线崩得体无完肤的。
NSX Transformers 的编译时间大约为四小时,自动化测试大约需十二小时。有一条流水线(持续集成/CI)每隔两个小时编译并测试一个 Transformers 版本。由于代码提交的预测试也挂载在流水线上,因此当它由于某些故障无法工作时,工程师就会被迫休假。按我的估算,以工资计量,流水线每停工一小时的损失约是 4000 美元。更改 CorfuDB 版本号引发的流水线大罢工,在 10 个小时后得以纠正,因此这是一个价值四万美元的教训:在修改工程代码的时候,别忘了看一下测试环境是否也需要修改。
后来的一段时期,我的开发工作主要是围绕 CorfuDB 的打包、安装和维护进行的。有几次提交,比如拆分工程结构、改写启动脚本、加入 systemd 支持等,通过 GitHub pull request 进了开源仓库,因此我也拿到了尊贵的 contributor 头衔。不过开发 CorfuDB 并非我的职责。作为一个 CorfuDB 的“用户”,我依据 NSX 的需要定制了部分功能,更多的提交也仅存在于闭源仓库中。可能是因为几乎只有我一个人单独向闭源仓库贡献代码,导致这两个仓库间的差别外人难以知晓,渐渐地,我很难找到合适的人做代码评审。再加上权限设置的弊病,在这里提交代码不要求他人的评审,事实上提供了暗箱操作的空间。当然,长此以往,自然会搞出事情。
值得一提的事故有两件,而且它们都和 shell 脚本有关,足以见得 shell 是一个绝对危险的领域。第一回,经理让我实现一个根据机器内存大小自动设定 JVM 栈空间上限的功能。我的想法是拿 awk
解析 /proc/meminfo
的数据,搞清楚到底机器上到底有多少内存,再按百分比把合适的数值写到 JVM 启动参数里面。这其中,需要判断某个环境变量是否为空。shell 有两种方法可以解答这个问题:[ -n $STRING ]
当 $STRING
字符串长度不为 0 时返回 true
,而 [ -z $STRING ]
只有当 $STRING
长度为 0 时才返回 true
。听起来很简单吧!但实际的结果会出乎你的意料。
1 | # 当变量 $var 未定义或长度为 0 时 |
为什么 [ -n $var ]
的行为与预期不同呢?它和 [ -n "$var" ]
又有怎样的区别?如果 $var
为空,那么在第一种写法中,test
程序会以为只传入了 -n
一个参数,它按照默认的行为返回 true
。但在第二种写法中,则有两个参数传入(第二个参数是个空字符串),所以 test
程序能按预定的逻辑得出 false
。同样的事情也会发生在 [ ! -z $var ]
身上,但由于存在取反符号 !
,默认的返回值是 false
,恰好逃过一劫。
由于在 shell 脚本中少加了一对引号,导致数据库 JVM 启动失败,管理层应用因无法连接数据库,在初始化阶段宣告阵亡,控制层和数据层应用群龙无首,整个虚拟网络系统陷入瘫痪。这个问题在 12 小时之后得到修复。以每个引号两万四千美元的代价,我自修了 shell 脚本编程极有意义的一课。
第二次事件持续了一天多的时间。为了同时兼容支持 systemd 和不支持 systemd 的系统,需要使用两套不同的 daemon (守护进程) 管理工具。整个流程成功的关键,是正确地判断系统是否支持 systemd。我对 systemd 的直观印象是“一号进程”,即它的 PID 值应当为 1。依据这个原理,我写出了一个花哨的判据:
1 | [ "systemd" = $(ps -q 1 -o comm=) ] |
我找来了不支持 systemd 的 ubuntu 14.04 和 支持 systemd 的 ubuntu 16.04 进行测试,一切工作正常。但是那天下班不久,就有人找上门来,说数据库又双叒叕不工作了。我登进测试用的机器,一次又一次确认上面的判据,没有发现任何问题。但是为什么数据库没能按照预定的方式启动呢?第二天上班,我一边忍受着上百封邮件的轰炸,一边百般思索追溯原因。直到我忽然心血来潮点开了编译日志,才在一瞬间拨开了云雾:原来 systemd 并不是系统原生的,而是在编译环节安装的,那个时候它还没有占据 PID 1 的位置,这一切要等系统重启之后才会发生。在编译阶段误判了系统的类型,使用了一套无效的配置,自然不能期待数据库可以正常启动了。纠正这个问题也很简单,只要把判据改成下面的语句就可以了:
1 | [ $(which systemctl) ] |
这一遭变故让我感慨良多。人生在世,最怕“逞强”、“装逼”四字。莫逞强,压力无助于解决问题,不如早一点儿回滚代码;留得青山在,不怕没柴烧。莫装逼,华丽的书写背后,满是陷阱;越朴素和简洁,就越接近正确与真理。
除了和 shell 的种种陷阱斗智斗勇,我还用 Java 开发了一个新特性。这个特性的开发经历了如下的流程:
- 提出产品需求。
- 经理找工程师写策划书。
- 经理、架构师与工程师开会,商议策划书实施方案。
- 工程师编写并提交代码。
- 测试人员验证产品功能。
一路跟下来,我发现,上面五个步骤中第二和第三步很难实施。工程师在动手写代码之前,几乎无法知道某个特性应当如何编写,所以策划书到头来还是要服从代码,而不是指导代码。至于架构会议,则一定会演变成名词解释会议,就像哲学指导下的物理学一样,能不帮倒忙就不错了。
这次让我开发的产品特性与数据库分表机制有关。组里的大佬们先花了一个月开会,争论三四种分表方案孰优孰劣。等会议上的争吵趋于缓和,我跟他们说,这些方案需要付出的代价都太大了,如果想要一个干净的实现,那就只能屈从于一个简单的方案。大佬们于是又纷纷摆出一副“怎么样都好”的姿态,批准了我提出的 API 兼容的设计。又过了一个月,我在代码评审的拉锯中,从各个角度出发完善它的功能:重构类型注册器、调整应用初始化逻辑、加入 transaction (事务) 支持,经过约 30 个版本的演进(以 git commit --amend
计),变成一千多行的庞然大物。
可能是因为修改面太大,也可能是因为优先级不够高,或是被 CorfuDB 想怎么交就怎么交的任性惯坏了,这次代码提交历经坎坷。第一次因为考虑不周,没有想清楚分表对数据迁移的影响,被撤了下来。数据迁移模块缺乏文档,可以请教的人又身处印度、沟通不畅,我通过看源码摸爬滚打一个礼拜,基本摸清了系统升级和数据迁移的流程。之后的一个礼拜,又成功地把分表机制接入了数据迁移逻辑,满心欢喜地开始了第二次尝试。那个时候,CorfuDB 正饱受高负载条件下“重启即死机”的困扰,组里的一位欧洲小哥开发出了数据预加载通路,可以在应用启动时将缓存调整至活跃状态,显著缩短了开机等待时间。我们都没有意识到彼此的代码在应用初始化时有逻辑冲突。因为他比我早一天提交,因此当测试人员发现机器重启后不能读取数据的时候,在茫茫人海中精确地将我抓获——我的代码第二次从仓库里被踢了出去。
至八月上旬,产品发布的日期一天天迫近,全组开始了以提升性能为最高目标的大会战。每天早上经理都会预订一间会议室,把开发和测试人员全部聚集起来解决问题。我对下午五点准时离场的行为深表不安,因为有人深夜十一点还在用 profiler 观测系统呢!后来,我采取了凌晨五点回邮件的策略以示回应。这真的不是为了要面子,赶在印度测试小组下班之前联络他们是很重要的。
鉴于我的产品新特性与提升性能这个最终纲领并无瓜葛,而且前科累累,是一个极大的不安定因素,经理考虑再三,问我能不能延到下个版本。我想,在全组打团的时候自己偷偷溜走刷副本确实不太厚道,于是欣然同意。等待着我的,是为此额外添加的数据迁移负担。
八月底的我们进入了快乐的海洋。代码提交被严格限制,没有 "ship stop" bug 在身的开发者基本上都开启了带薪休假的时光。我很高兴地为 Dropkick 提交了最后几个 CorfuDB 补丁,包括把日志等级从 DEBUG 升至 INFO。完成 capstone 这一封印之作,过去半年多为之流过的汗、犯下的错,也就一并被埋藏在仓库的历史中了。
运维与测试
与开发相比,我更多的时间是在运维与测试中度过的。如果问我入职的最初两个月,在工作上的主要收获是什么,我肯定会说是 git 技法得到了空前的提升。曾经有一项艰巨的任务,需要在两个相差上千次提交的分支间完成一次 git merge。那次化解 merge conflict 足足花费了我三个小时。借着 git merge 的名义,掌控他人代码的生杀大权,是极为难得的体验。做运维就像天气预报一样,做好了没有存在感,做不好会被所有人斥责。像我这样在 git 江湖行走多年的玩家,也曾经失手过——因为老眼昏花在 merge 后导致代码库编译错误。当然,因为这种 bug 具有秒杀全场的优先级,在大多数人还没有意识到发生了什么的时候,我们就果断出手解决了问题。
做运维让人最不开心的一点,是需要“出警”。流水线打雷下雨的时候,不管我是身处拉斯维加斯、优胜美地还是蒙特雷,都会被邮件或者短信呼叫,然后打开电脑看看到底出了什么问题。如果实在没有带电脑,也得提出一个合理的假设,让别人沿着那思路排查下去——总之不能装死。虽然我承认这其中的一部分故障和 CorfuDB 有关系,但领导们每次出警总是记得把我的邮箱一并写上,就好像多了一位应急修理要员 [1] 能扭转局势一样。最后嘛,大概是我也没怎么帮上忙,他们也没少打扰我。几个月前我还在想,有这么多上下文只有我一人知晓,他们肯定没办法开掉我,不然就没人能帮他们修流水线了。现在,我倒是更希望有人能接手这份运维的工作,把半年来的积累倾囊相授也可以,我只求能享受一份闲暇与清静。
在 Dropkick 打算采用 CorfuDB 的时候,它不能算是一个成熟的数据库产品。准确得说,它以前从未有过真正的用户,而我们是第一个吃螃蟹(xiang)的。缺乏历练的 CorfuDB 选择采用一种周期很长的开发模式:在 Dropkick 测试中发现数据库的 bug,然后到开源仓库打补丁,随后同步到闭源仓库,编译新的数据库,再重新运行测试。这其中的一个重要环节是代码同步。我们绝不希望把有缺陷的开源代码同步过来,所以需要预先运行一些 NSX 测试集以保证 CorfuDB 的质量。这份工作本来是另一位工程师和我一同分担的,不过由于我更熟悉内部工具与测试流水线,又长期在闭源仓库贡献代码,而且经常和工具链/维稳领导小组 [2] 打交道,那位活跃于 GitHub 的工程师遂逐渐淡出,工作不久就改为由我一人承担。
代码同步与预测试的流程几乎是固定的。为了从繁琐的手工劳动中解脱,我们萌生了开发自动化工具的想法。经过两个月有意无意地完善,这个近三百行的 shell 脚本已经涵盖了整个同步工作和绝大多数测试工作。如果 CorfuDB 没有 public API 更改,我在脚本运行的六至十五个小时里就可以安心睡大觉。如果测试结果良好,经理就会让我发一辆车,把最近的补丁全搭载上去。不过身为司机也有自己的苦衷:明明是我开的车,但你们上车的动作为什么这么熟练啊?哎,果然我自己写的代码优先级就是不够高,都没有搭车的资格。
那份自动化 shell 脚本当然不会进仓库,但不能否认它是迄今为止我在公司最得意的作品。在那里,curl
和 awk
珠联璧合,优雅地完成了 API 的调用和解析。虽然偶尔会见到 $(awk '/"ref"/ {print $2}' output.json | uniq | awk -F \" '{print $2}')
这种诘屈聱牙的片段,但它依旧比相应的 Python 实现简短得多。公司的大部分内部系统,要么提供了 API 接口,要么提供了可以自动 POST 的表单,让我的脚本可以畅通无阻。不过,我也遇到过需要校验 CSRF token (跨站请求伪造) 的变态站点,使人叫苦不迭,不得不绕道而行。
程序调教
大多数工程师应该会认为,搞开发比调试程序有趣得多。需要经常调试的,要么是非常不成熟的产品,要么是非常成熟但是记忆失传的产品,我们不幸属于前者的范畴。人们都说,Java 有 IDE 的挟持,调试过程简单粗暴,只要能连上远程 application server,把 debugger 挂载到 JVM 之后,就可以尽情发挥想象力了。不过呢,第一次的经历总会有些特别。
那是我第一次用 Intellij(虽然 ECE6102 有写过 Java 但当时用的是 eclipse)。四位 staff engineer 围坐在会议室中,看着电视机里我的电脑屏幕,七嘴八舌地下达各种指令:
“按一下 Ctrl + n,输入 XXX 类。”
“嗯,能不能按下 Ctrl + b,看一下这个类的定义?”
“能不能在第 XXX 行设置一个条件断点?”
“能否用 Alt + F7 看看都有谁调用了它?”
“application server 的链接已经断了,重新连一下吧。”
……
那种气氛迷之尴尬。在我看来,我就像牵线木偶一样任人摆布。不过,在他们看来,把打团战这么宝贵的时间花在 Intellij 快捷键新手教学上,也是对公司资源的极大浪费。好啊,既然我们都不满意,那为啥一开始要投影我的电脑屏幕呢?似乎是因为这次教训,后来 war room 打团就很少用投影了。
调试的次数多了,会发现组里的各种 bug,除了 CorfuDB 本体的种种缺陷以外,差不多就那么几个来源。关于 Spring Framework 的错误配置是比较浅显的,Application Context 的问题都和它有一腿。深入到具体原因,Java/xml 配置、依赖关系、实现与继承、注解等,全都需要排查一遍,可以算作是体力活了。关于序列化与反序列化的问题,由组里的一个老牌工程师独自担起了整个序列化机制的设计和编码,在这种没有话语权的情况下,我就不多插嘴了。至于多线程引发的故障,虽然归结起来只有 race condition 这一个根本原因,但大家都不愿碰这块烫手山芋。因为和前两者不同,多线程竞争问题是无法调试的。
我就遇到过一个诡异的案例:某个单元测试在正常运行时总是报错,但只要加了一个断点就立马能够通过。我们无从知道 JVM 线程调度的细节,因此也无法预知什么情况下会发生什么。对付多线程难题,有对症下药和釜底抽薪两种解决思路。对症下药就是找出竞争发生的位置,用 synchronized
包装起来。这药方得良医来开才行,庸医若是想到处加上 synchronized
碰碰运气,则反而容易陷入死锁(如果不是可重入锁)。不过庸医还有釜底抽薪的法子:他们可以考虑把逻辑改成单线程的,这样就安全得很了。用这招就好比捕获异常的时候写上 catch (Throwable e)
,其实是为人所不齿的。但是,不少多线程逻辑改成单线程后,并没有性能损失,因此这个药方就得以流传开来。
长期跟 debug 打交道,让我真正学会了如何做一个云淡风轻的人。初来乍到的我,被安排了一个 P0 就火急火燎寝食难安。后来我身上挂着 5 个 P0、8 个 P1 的时候,想到这么多 bug 绝不可能在一个月内解决掉,竟一下子释然了。把 bugzilla 从邮箱中拉黑,凌晨爬起来看日语直播课,晚上到家了打音游,积极占领原本属于加班的时间。睡眠依旧不足,bug 终究还是要处理,但心头不被石头压着,会好受很多。
这半年多以来,我要感谢所有一同战斗过的同事。令人惊讶的是,我在职场上打过交道的同事,无不是兢兢业业、一丝不苟,从未遇到过意气用事、厚颜无耻之人。就算我的工作一再成为产品开发的不安定因素,大小经理、以及其他组的领导,也始终表现出宽容大度。当然,与学习同事的优秀品质相比,我倒是更盼望公司早一点儿把奖金发下来,别让我总以为自己的奖金因故被克扣了。急,在线等……
[1] 应急修理要员:网页赌博游戏《舰队Collection》中用于快速修理受损舰娘的装备。因在交战中受损状况是随机的,所以应急修理要员不如电探(雷达)和水听(声呐)实用。此处指公司应将更多的资源投入到基础设施建设中,减少对运维的不必要的依赖。
[2] 维稳领导小组:掌握超级权限,跟踪产品开发进度,随时准备把不良代码剔除出产品的小组。
shell 能力考试题
通晓 shell 的读者可以通过下面三道试题评估自身水平。题目是我出的,欢迎来信讨论解题过程。
1 | 1. 请从下面四个选项中,选出工作正确的一个。 |
1 | 答案 |