研发哲学第五条：一定要有后备方案

郑昀 20181109

#哲学 #灾备 #devop

过去的九月和十月，厄运接踵而至：

大大小小连续几次事故。

阿里云华北机房网络抖动。

网某银行支付通道抖动。

银联支付通道抖动。

某IDC机房出网流量丢包严重长达几十分钟。

我冷眼旁观

我们第一时间不能确认到底是什么故障，

近期没有版本发布，

数据库/RDS没有慢查，

所有应用正常，

各个机房的出入流量并无大的起伏，

我们甚至不能第一时间明确异地双活的哪一个机房才是正常的，

从钉钉群里听上去全国都有问题（其实只是某个机房概率性网络问题），

以至于无法下决定切换多活机房流量。

结合研发哲学第三条：『这个世界没有什么救世主』，

我们终于深刻地认识到研发哲学第五条：

『一定要有后备方案。』

是的，只有你自己能救自己。

如果只有一个机房，即使是阿里云，也必死无疑。

如果只有一个支付通道，必死无疑。

如果只有一条线路，必死无疑。

事实一再证明我在2017年就未雨绸缪地指出如下事实是何等英明（XD）：

『

分布式系统的维护者总会反复问自己：

我们的系统什么情况下会挂？假如机房挂了怎么办？假如一个城市停电了怎么办（洪水，海啸，地震，滑坡，……）？业务高峰期怎么降低灾难影响？

所以，很多互联网公司都会在多个城市同时支撑商户和用户交易，并且能做到在一个城市所有机房瘫痪的情况下，能够在几分钟内恢复（或者继续新的）所有的交易。

小朋友会问，机房真的会挂吗？

请先阅读一下我写的《 经历不可抗力是一种什么体验 》，了解一下什么是 too young too naive。

然后我们再来回顾一下：

A，2017年1月，公有云 UCloud 公司正在开年会，结果在他们北京B可用区的数据中心外3公里处，架空光缆线杆因卡车撞倒导致光缆断裂，工程师在年会现场紧急处理。

B，2015年6月21日上午9点到10点之间，一些使用阿里云香港数据中心的用户发现服务出了问题，此后阿里云公告称由于运营商电力问题造成香港机房故障。因为供电系统故障导致数据中心大楼整体断电，并触发消防报警。根据当地的消防规定，必须彻底排查隐患并完全消除后，才能获准进场做电力抢修。直至当晚21点22分机房正式恢复稳定供电，阿里云立即执行既定预案逐项恢复服务，21点32分安全防护服务恢复正常，各项服务陆续恢复，截至23点39分全部服务恢复。

C，2015年9月1日，阿里云官方发布致歉公告，称“因云盾安骑士server组件的恶意文件查杀功能升级触发了bug，导致部分服务器的少量可执行文件被误隔离”，但造成影响无法估量。

D，2016年7月6日，上午10点22分，阿里云华北2地域可用区A由于网络设备出现异常，导致部分产品访问受到影响。故障持续约1小时。

E，2016年10月11日，下午16点40分，阿里云华东一区部分服务器故障，导致网络上部分网站无法运行。

F，2018年6月27日，阿里云工程师团队在上线一个自动化运维新功能中，执行了一项变更验证操作。这一功能在测试环境验证中并未发生问题，上线到自动化运维系统后，触发了一个未知代码bug。错误代码禁用了部分内部IP，导致部分产品访问链路不通，进一步导致一些客户访问阿里云官网控制台和使用部分产品功能出现问题。

灾难，总是在你意料之外。

所以对于技术高级干部来说，必须回答这个问题：如果单机房物理不可访问，你怎么办？

』

是的，你得给自己一个灾备通道，

一个后备方案，

最后一条让你起死回生的路。

p,s,:

云纵/禧云的研发哲学

郑昀 创建于2015/2/27 最后更新于2015/3/25

关键词： 哲学、规则、套路、传承

提纲：

1. Don't make me think

2. If it hurts, do it more and often

3. 这个世界从来没有什么救世主

4. 没有苦劳，只有功劳

一，Don't make me think

大家都知道，技术人员从事的是创造性工作，加之是单核处理器，我们的上下文切换非常困难，被打断后从新进入“神游”状态往往需要十几分钟。尤其是研发经理，承担更多的责任，线上线下的问题都要照顾到，还要解答内外的各种咨询，工作时间碎片化严重。我们（包括系统）给出的信息，一定要足够简练，一目了然，让人很容易克服焦躁情绪，啪啪地就处理了，或者啪啪地二次分发出去。 不要让无用的信息折磨这些人。

其次，技术人员是“世界”的构建者，不得不做大量琐碎且枯燥的工作，其中，相当大比例的工作是重复性的，如修改配置文件适配不同环境，如打包。

重复的工作一方面容易出错，尤其是在通宵上线时，另一方面消磨人的耐心和斗志。 我在《职场培训第五期：职场的真相》中讲过解题思路：『 要摒弃单纯依靠员工之间互相提醒、依靠个人认真细致来规避相同错误的固有思路，铁打营盘流水兵，靠人终归是靠不住的，最好靠遵循规则的机器 』。

王淮在《以 Facebook 为案例剖析科技公司应有的 工具 文化》一文中谈及，基本理念就是 凡是被很多人不断重复的好习惯，要将其自动化，绑定到工具之中，以"Don't make me think"的方式来推广最佳实践（best practice） 。

基于以上原因，我们认为， 凡是被不断重复的过程，将其工具化，绑定到自动化流程之中，减少不必要的心智负担 。

这也就是过去几年里我们一季季地推进持续集成（Continuous Integration，CI）的原因，把我们的经验教训变成可重复的规则，融入工具中，融入自动化流程中，而不是一代一代口口相传。

好了，在举具体的例子之前，让我们大声读出这几条 Slogan：

• Don't make me think!

• 减少不必要的心智负担！

实例一：

Exception 日志分析邮件是我们非常重要的工具，是我们的宝贵财富。每天凌晨 Python 脚本定时分析各个工程的 Exception 日志，按异常类型归类，用邮件 Push 到研发经理桌面上，它充分体现了我们的哲学： 自动化是王道。

但如果看到邮件内容后，研发经理仍需要费一番功夫才能搞明白这是什么异常，而我们往往没有足够的时间，我们就会嫌麻烦，就会下意识地放过这个 Exception，甚至不再看日志分析邮件和报警邮件，那么“Exception 日清日结”就会沦为一句空话，等攒到每天数以千计 Exception 时已经失去了清理的欲望。

我们都知道，电商的购买流程每增加一个交互环节，就多了一道门槛，用户最终成单转化率=流量入口UV数×步骤1转化率×步骤2转化率×步骤三转化率×……，同样道理，我们要尽量把条理清晰、一目了然的报警邮件和 Exception 日志分析邮件推到大家面前， 操作越少越好，我是在帮你，不是给你找麻烦。

实例二：

Yahoo! 的 Combo Handler 的出现就符合本哲学，阿里还因此出了一款插件 nginx_concat_module。前端工程师可以发布便于阅读的原版 JavaScript 和 CSS 文件，只要模板文件里做一个特殊声明，多个文件就能通过服务器端的插件合并且压缩，配好之后从此不需要再考虑 Minimize HTTP Requests、压缩和混淆了。

实例三：

页面上所引用的 CSS 背景图片可能需要做到 CSS Sprite 图里，然后在 CSS 里写偏移量，每增加一个 CSS 背景图片，这些操作都要来一遍。

也许这是不必要的心智负担，因为机器可以自动做。假如我们引入 Gulp，就可以自顾自地在指定 folder 里放一张张 CSS 背景图片，CSS 里写好声明，然后让 Gulp 这个前端构建工具自己把 folder 下的背景图片合并为一张大的 CSS Sprite 图片，并且它自己修改 CSS 里的背景图片地址和偏移量声明，不需要为此每次费心费力。

二，If it hurts, do it more and often

我们不能死于听天由命和漫不经心。

工程师为什么会听天由命？

• 因为线上日志里的异常实在是太多了，处理不过来。

• 因为异常太多了，淹没了致命异常，以至于服务挂得死死的才发现问题已经存在N久了。

• 因为明天就要提测了，代码合并冲突还有几千个。

• 每到常规版本提测时就心里打鼓，合并个代码都得预留两天时间。

• 因为画时序图好烦，所以复杂系统的数据流转靠“心算”、靠文字描述。

• 人脑容易有思维死角，一个考虑不到，系统就防不住并发提交和重复提交。

• ……

因为已然集腋成裘，所以做事前我们各种纠结和抵触，于是找各种理由拖延。

怎么办？

我在《职业化的7个细节》里讲到， 如果一件事做起来很烦，那就把它拆成很多块儿，每天做一点，每次做一点。

实例一：

以代码合并为例，如果每天早上到公司后，从开发主线合到自己的私有分支上，每天都做，那么等你向测试分支提测时，合并冲突是不是就少很多？

实例二：

如果你觉得画时序图（或泳道图）麻烦，要么是你不会用 visio，要么是你想不清楚调用时序。你应该立即从手头的功能开始画时序图，多练习，以后画时序图、业务流程图只是分分钟的事儿。用 excel 也能做泳道图啊。

很多工程师觉得写设计文档好烦，不开设计评审会的话就不写。我是这么做的：

1. 我动手做一个系统，肯定已经大致想清楚了对象的定义、大致的设计模式；

2. 也就有了一大堆的类文件（空的）以及目录结构；

3. 每个类文件我都先写类功能定义、处理流程、数据类型定义，blabla 一大堆注释。反正写代码之前也得想明白这些事儿，那就直接写成注释；

4. 最后，把这些注释摘出来，配上各种图，一篇设计文档就搞定了。

所以我从来不会为写概要设计和详细设计烦心。

三，这个世界从来没有什么救世主

这个哲学我过去几年里一而再再而三地讲。在《职业培训第五期：职场的真相》中，我说：过去几年里，我们深深地体会到，从来就没有什么救世主，要创造人类的幸福全靠我们自己，不要指望有什么人能救我们，只能绞尽脑汁闯阵。

为什么？

技术团队是互联网公司里最认真最专业最实操最靠谱的一群人，如果我们凡事都要指望别人给我们解决方案和思路，指望别人比我们更认真，那这个公司就危在旦夕了。

所以，我在2012年的飞行研讨会上抛出两个 Slogan：

• 抛掉幻想，勇敢面对！

• 直面白刃战！

实例一：

飞行研讨会上我说：

遇到问题，立刻跟进去Debug

——主管不能仅仅说一些似是而非的官话套话

——主管要投入白刃战

————我党向来是副职打仗下到主攻第一线

————纵队副司令到主攻师，副连长打仗带尖刀排

——围观不能救中国

主管都不出手，指望工程师救你啊？

实例二：

对历史因果关系、系统调用、业务逻辑和数据流转，甚至系统里的脏数据，最了解的人莫过于我们。怎么可能指望上游部门有一个人横空出世，洞悉所有细节，告诉我们该如何设计和实施呢？

是你的终归是你的，躲不过去的。

基于这个哲学，我们衍生出两个 Slogan：

• 不要等死！

• 向前迈半步对接！

四，没有苦劳，只有功劳

早年间，侯小强曾经说过： 如果你在职场，需要有三个好习惯，1，能马上做的事情马上做。2，每个事情要有始有终。3，要有这个习惯思维，没有苦劳，只有功劳。但如果没有极其努力，通常也不会有功劳。

延续着这个思维，我们过去几年里反复强调： 没有结果就没有意义 。不要期望公司因为你和小伙伴们有苦劳而宽容你们没有产出，这是一个商业公司。

实例一：

一些内部研发课题，由于不像主站那样直面消费者的压力，所以工程师会做得不够商业。就算功能 okay 了，但总缺少一股精细范儿， 让我们这些老手浑身难受，迟迟不能投入商业应用。这就属于典型的“没有结果”，没有在指定时间到达指定战场。

实例二：

以下几个征兆会被我判定为“只有苦劳，没有功劳”：

• 如果没有结合前面几个哲学，没有定期审视自己的工作，没有找出痛点并用工具解决痛点，而是低水平重复再重复。累是很累，加班也加了。

• 同样的错误一而再再而三地犯，技术团队因此忙于四处救火，料理脏数据。

以上就是我这四年来总结的研发哲学。我认为，我们团队应该把这些理念结结实实地变成新老员工的“本能”，用哲学来指导我们的行事方式，保证不管我们换了多少人，始终能前后一致。对现代中国曾经有一个说法“每隔十年乱一次”，Why？大抵是十年后掌权的那帮人，不记得十年前发生过什么，传承都丢了，踌躇满志，满怀热情再错一遍。我吐。

-over-

欢迎订阅我的微信订阅号『老兵笔记』，请扫描二维码关注：