郑昀：技术人间自有法则在

创建于2019/4/28 最后更新于2020/4/16

关键词：法则，规则，捷径，灾难，劫难

提纲：

人间法则零：手中无刀，但心中要有刀
人间法则一：捷径充满荆棘
人间法则二：尽早统一规格
人间法则三：灾难锦囊
自建法则法则长存

法则零：手中无刀，但你的心中要有刀

软件工程和技术领域里虽说法无定法，需求和流程随便怎么做都可以，但也并非可以天马行空恣意妄为，稍不留意就可能天塌地陷墙倒屋塌，酿成不可收拾之惨剧。下面我就说道说道。

2020年1月底2月初，首都医科大学附属复兴医院出现医护人员感染新冠肺炎事件，最终累计确诊34人，既有医护也有患者和家属，原因也非常“感人”：一位有武汉接触史的老太太，本来属于“新冠肺炎疑似病例”在发热门诊看病，但却突发奇想，通过院领导的关系，托关系找心内科ICU主任韩某，愣是从防护森严的发热门诊病房转进了云淡风轻的心内科ICU，结果横扫一片。

我一直说，工程师团队和医护团队都是专业领域机构，管理方式有相似之处。那么在这个案例里，管理者犯了什么错误？心中无原则！

心中无原则，会有一百万种死法。

原则！专业团队的管理者心中一定要有原则，你有了原则，才能要求大家“讲政治，守规矩”！同样，在做设计的时候，先把设计愿景、设计分阶段目标、设计原则写下来，在此基础上画地为牢再做设计推演，莫要天马行空恣意妄为。手中无刀，心中有刀。

法则一：捷径充满了荆棘

外行总觉得软件开发有捷径，有银弹。还是那句话，有一百万种死法等着您呢！

XDD

话说时间回到2019年12月20日，波音公司设计研制的载人飞船“星际客机（CST-100Starliner）”正要从卡纳维拉尔角发射，执行它的第一次飞行测试任务。按照计划，飞船将在这次无人试飞中将与国际空间站对接，为宇航员送上圣诞礼物。但是就在与火箭分离后，飞船上的一个关键设备出现了异常，可以简单理解为飞船的一个时钟错误，让飞船误以为自己正处于提升近地点的变轨过程中。在预设程序里，变轨是需要很高精度的姿态和轨道控制的，因此飞船的 48 台姿轨控发动机开始疯狂工作，在短时间内消耗了大量燃料。由于“星际客机”消耗了过多的燃料，与国际空间站的对接试验不得不取消，原定于12月28日返回的飞船不得不提前到12月22日返回地球。

（图1 工作人员正在回收星际客机的返回舱）

2020年2月28日，调研报告终于出来了，波音公司承认，星际客机软件系统的程序存在严重缺陷。这份报告显示，飞船和火箭助推器的时钟不一致（运维同学可能会心一笑，这真的是非常经典的基础维护错误），而飞船的 Mission Elapsed Timer 提前轮询了火箭助推器的时间，从而提前开始了错误的计时并进入了错误的轨道。

这些明显的错误完全可以被提前测试出来。于是调查小组对测试的流程进行了检查。他们发现软件测试走了捷径：波音公司缩短了对该飞行器软件的关键测试，他们将整个飞行过程分成了几个小单元分别进行测试，但最后却没有做完整的、端到端的集成测试，即没有进行时长为 25 个小时的整体测试。

NASA 载人航天业务负责人道格·洛夫罗表示，波音公司的问题是“根本性的”和广泛的“软件过程故障”。波音的这种软件质量控制，还不知道会导致系统中到底存在多少个 Bug，“到底只有这两个还是会有几百个”。

看到这里，你会不会擦一擦头上的汗欣喜道：幸好这只是无人飞船，而且还只是第一次执行飞行任务而已，有则改之，无则加勉嘛。

更可怕的还在后面呢。

彭博社曾指出：波音 737 MAX 把软件系统外包给了印度外包公司 HCL 和 Cyient 的软件工程师，比起美国正职软件工程师每小时 35 至 40 美元的工资，印度外包的时薪只需要 9 美元，便宜了四五倍呢。更进一步，波音的分包商与供应商同样选择将工程外包到印度，降低成本以保证利益最大化。一位前波音软件工程师在 2015 年表示，企业将裁掉 90% 经过了熟练培训的员工，用“外包”来代替他们，从而缩减开支。

软件外包绝对不是“一包了之”，它是一个需要发包方和承包方高度协作的过程，贴身服务周期长，可变因素太多太多，这使得发包方和承包方都同时面临极大风险。我们见识过太多的外包失败案例，不差波音这一个。

波音的 787 型飞机计划 70% 使用外包，最终导致了延期三年还交付不了，波音表示：“我们同时在技术、工具和供应链上做了太多改变，超出了我们的管理能力”。

哪有什么捷径啊？只有外行领导的一厢情愿而已。

1999年 NASA 当年发射了两艘火星探测器，心想这下总是双保险了吧。结果，一个失联，一个在火星坠毁。咋回事呢？也是同样的锅：集成测试做得不好。

第一架名叫火星气候探测者。1999年9月23日失联于地球太空。

RCA报告这么写道：

它的飞行系统软件使用公制单位“牛顿”计算推进器动力，而地面人员输入的方向校正量和推进器参数则使用英制单位“磅力”，1磅力=4.4482216152605牛顿，导致探测器进入大气层的高度有误。

在该探测器的悲剧中，轨道模型来自于属于政府部门的NASA（采用公制单位如米和厘米等），而飞行控制软件来自于私营承包商洛克希德·马丁公司。

洛克希德·马丁公司的码农们没有按照飞船工程的接口规范设计软件，而是习惯性直接使用了英制单位，大祸在上天前就已经注定。

（图2 当时的讽刺漫画 Remember the Mars Climate Orbiter incident from 1999，

左边宇航员背上是NASA，右边是Lockheed，即洛克希德）

第二架名叫“火星极地着陆者”。1999年12月3日坠毁于火星表面。

（图3 火星极地着陆者号登陆火星艺术效果照）

RCA报告执笔者无奈地写下：

RCA类型：缺乏集成测试！

有一个甲小组测试探测器的脚落地过程（leg fold-down procedure），即探测器的三个着陆支架如果触地了，制动发动机就会提前关机。

有一个乙小组测试飞船着陆过程的其他部分。乙小组总是在开始测试之前重置计算机、清除数据位。

这两个小组的工作都没什么问题，但就是没有合在一起测试。

没想到着陆支架伸展出来的这个动作产生了意外的信号，制动发动机以为已经触地了，于是在探测器距离火星表面还足足有40米的时候就提前关机了。咔咔，蛋碎。

最后说一句，图快懒省事儿，不做集成测试，不做回归测试，尤其是涉及软硬件的，您真的会死得很难看。

法则二：尽早统一规格，别让杂草到处长

技术团队人多了，就会分好多组，并发干活，人上一百，形形色（sai）色（sai），如果没有居中协调人，比如一个 CTO 或者大 PM，就很可能会各自为战，完全取决于技术 Leader 的喜好和意识。这会有什么问题呢？

这里有一个经典故事：阿波罗13号。很多人可能都看过这部据真实事件改编的电影。

1970年4月，阿波罗13号发射升空之后，液氧贮存罐意外爆炸，指令舱和服务舱失去了两个氧气罐中所有的氧气，所幸宇航员没有受到影响。面对这种情况，NASA 不得不放弃原定的登月计划，改为以顺利返回地球即生还为最重要目标。经过紧张计算，地面指挥中心发现可以借用登月舱的资源保证宇航员生存，所以原本设计供两名宇航员使用两天的登月舱需要容纳三名宇航员生存四天，但这样就会存在极大的风险，宇航员可能窒息而死。

果不其然，登月舱的二氧化碳氢氧化锂过滤罐不堪重负，好在天无绝人之路，指令舱有备用的过滤罐。这时候才发现，登月舱和指令舱的过滤罐由不同供应商提供，所以一个接口为方形，一个接口为圆形，并不兼容。

（动图1 电影《阿波罗13号》中寻找解决二氧化碳问题的片段）

天上和地上只能同时想办法，在“每一克重量都极宝贵”的飞船上想出办法来解决这个问题……

（图4 宇航员们临时拼装的二氧化碳过滤装置，工程师们将其戏称为“邮箱”）

当然，烧脑大战之后，最终还是成功地解决了这个问题，如上图所示。

技术 Leader 们，平常多聚会多碰头吧，很多东西从文档上根本看不出来，只能靠当面多沟通多交流，才会发现这种潜在隐患……

法则三：灾难锦囊，大恩不谢

灾难我们见得多了//不愧是老兵～

每临大事有静气，不信今时无古贤//但是我们每次都慌得不行～

关键是每次灾难都不一样//它不重样诶，你待我何～

（图5 北京有家饭馆，楼里挂了一块匾，上面写着四个字：何事惊慌)

如果灾难真的来临，我们该怎么办？

在著名的“4英寸发射”事件中，Christopher Kraft 给航天任务定下的第一法则：如果你不知道发生了什么，那你就什么也不要做（If you do not know what to do, don't do anything）。

在这次阿波罗12号飞船升空遭雷击的事故中，宇航员本来可以启动逃生程序的，但关键时刻他们想到了这条原则，所以什么也没有做，最终在指挥中心的 Aaron 给出了著名的经典的明确的指令：“try SCE to AUX”，登月行动得以顺利进行。

作为对比，1960年10月24日，前苏联发生了与“4英寸发射”类似的航天事故，结局则要惨痛许多。

那么让我们看看发生了什么？

1960年，前苏联发射火星探测器，前两次都失败了，如果第三次再失败，就必须再等两年才会出现行星连线的机会。

火箭此时已加注了燃料，但还是有些问题，为了不错过发射时机，为了报答赫鲁晓夫去年提拔自己为炮兵主帅的知遇之恩，聂杰林元帅毅然决然地拒绝了拜科努尔发射现场总指挥延期发射的忠告，坚持要求在发射台上对火箭进行全面检查。

总工程师只得违规准许对各个不同系统并行检查，而不是按照规定一项一项来。

聂杰林希望赶在国庆节前发射，能省的步骤就省，即使这样，灾难发生前工程师们也连续工作了72个小时，为了赶时间工程师们在装满燃料的火箭底下检查点火系统，一个燃料泵有燃料泄漏，电路也有一些短路，搞定之后，他们却已经没有时间重新检查，因为元帅已经到了。参谋总长索科洛夫建议暂缓发射，但聂杰林斥责他是懦夫，索科洛夫一气之下离开基地，反而他因此幸存了下来。

聂杰林本人亲临现场督战，原本按照规定，所有不直接参与发射准备工作的人员都应到地下水泥掩蔽部去，但聂杰林却坐在火箭不远处的凳子上，可谓是尽心尽力。发射场主任两次恳请他转移到安全地方，他都置之不理。

可惜的是，火箭虽然叫“二炮”，但它毕竟不是炮。

（图6 拜科努尔发射中心爆炸现场）

这枚火箭的第二级火箭有自己独立的时钟，它按原计划点火了，结果引发整枚火箭爆炸，3000度以上的火海吞噬了发射场，跟聂杰林一块坐在火箭旁边的几十名将校级火箭专家、技术人员当场团灭。聂杰林烧得连点灰烬都没有留下，只找到半块被烧焦的元帅肩章和已经熔化了的办公保险箱的钥匙。这些东西后来都被装进骨灰盒，安葬在克里姆林宫的宫墙下。

（图7 拜科努尔发射中心爆炸后）

切换到我们的场景，如果你已经完全容器化了，那么灾难发生的时候，系统运维工程师拍马赶到之后，一定是：

重启相关应用；
如果不行，先流量切换多活机房，保证服务正常提供；
目标只是分钟级最快速度恢复，保证SLA四个九！
不需要做任何其他事情，
don't do anything，
不要寄希望于工程师短时间内定位问题，不需要的～
先恢复服务！除此之外的任何事情可能都是奢望，甚至是干扰。

自建法则法则长存

不，没有什么法无定法，技术的世界里一定是有法则的，否则你会死得很难看，别指望我来救你，我救都救不赢。

通过本次讲座，我想强调的是，You！Leaders！一定要通过层层叠加的“Rules”建立起本能反应，一遇到类似的事情，应激般的就知道该怎么设计，怎么行动，怎么救火。

而这些“Rules”是经历了血与火的洗礼铸造的，每一条都有来由有去路。

比如说，我在2018年定义的 DevOps 新八荣八耻，每一条都是血肉长城：

以随时可扩容、可缩容、可重启、可切换机房流量为荣，以不能迁移为耻。
以可配置为荣，以硬编码为耻。
以系统互备为荣，以系统单点为耻。
以交付时有监控报警为荣，以交付裸奔系统为耻。
以无状态为荣，以有状态为耻。
以标准化为荣，以特殊化为耻。
以自动化工具为荣，以人肉操作为耻。
以无人值守为荣，以人工介入为耻。

如何自建法则？

从错误中学习错误！

『学校里学习最好的学生可能往往是那些最不善于从错误中学习的人，因为他们已经习惯了把错题当成失败的代名词，而不是把犯错看成学习的机会，这反而成为他们进步的主要障碍。走入社会之后，聪明的人必须善于拥抱自己的错误和不足，从而能远远超过那些与他们水平相当，但更自负的同学、同辈。』

这也就是为什么平凡人可为非凡事的缘故！

『不要患得患失，要朝着目标努力前行。要自省自警，别人对你很到位的批评，是你能得到的最宝贵的建议。想想看，你的滑雪教练告诉你，你摔跟头是因为你滑行中的重心移动不对，此时你要是认为他在责骂你，你该多么愚蠢和低效。同理，你的上司，我，也可能会指出你工作中的缺点，有则改之，继续努力就是了。』

等有一天你依据本能（也就是你自建的法则）行事的时候，你就会体会到我的良苦用心了！

-EOF-