工程事故与现实世界

每年的双十一都是电商行业程序员们的一次大考。今年的双十一刚刚过去不久，在双十一之前的那一周，我几乎每天都会想一个问题：如果系统会发生故障，那么可能会在哪里？

双十一前一个月，是为数不多能暂缓业务需求，集中进行系统检修的机会，在这期间会发现之前积累下来的各类隐患和小缺陷，并进行集中修复，然后上线压测。虽然这已经是我经历的第八次双十一，各类备战准备流程已经轻车熟路，一套架势打下来，基本也算相对比较全面了。但还是没有百分百的把握，因为事故，特别是工程上的事故总是发生在你想不到的地方。

就怕想不到，不怕做不到；备战期间，专门找了一些工程上的失败事故来看看，启发一下思维路径。这些工程事故都不是软件开发方面的，而是更广泛的传统工程行业，但其事故影响也更加触目惊心。每读完一个事故的描述，我心下都是一惊，一回味，似乎类似的错误，要么自己犯过，要么碰到过。

简单分享一些其中的事故。

量级问题

1940 年，美国华盛顿州的塔科马海峡大桥，在一次大风中坍塌。

塔科马海峡大桥是当时最长的悬索桥，桥梁设计师复制了现有结构较小的悬索桥，简单构建了一个更长的悬索桥。这种结构在短跨度的桥上已经得到了验证，工程师未经仔细计算想当然地扩大到了长跨度的桥上。后来，一天海上刮起了强烈的大风，桥开始波动并扭曲，随后坍塌了。

曾经我在程序实现中就碰到过一个类似的场景：一个字符串替换函数的实现。这是一个公共的工具函数，但其实现并不合理，当字符串的长度比较小的时候，比如说 50K 以内吧，它的执行耗时对整个系统的影响几乎感觉不出来。但一旦字符串比较大了以后，性能会急剧下降。

而系统中确实偶尔就会出现超大的字符串输入，达到 100K～200K，这时这个函数的执行耗时会高出一个量级，系统的并行吞吐能力就瞬间下降很多，感觉非常明显了。

这就是典型的量级问题，跨越了某个量级的边界，逻辑就可能变了，而预期结果也不一样了。

实施偏差

1981 年，美国堪萨斯市凯悦酒店，酒店大堂悬在半空中的走廊，在开业聚会上，人们在上面跳舞，产生了坍塌，导致 100 多人死亡。

空中走廊的固定方案，设计师的意图在实施时却变了样。因为承包施工方不知道整体结构的设计影响，而为了赶工期急于完成这项工作，对设计方案的施工作了看似无关紧要，但却最终致命的修改。

这在程序设计与实现中，简直太常见了。软件工程相比建筑工程，其从设计到实施的严谨性，规范性相差可以说是天壤之别。建筑工程中尚且无法完全避免，软件工程中简直是家常便饭了。

实施中，很可能为了便利的选择，从而减弱了设计的初衷。

这有好的办法来控制这个过程，减小实施偏差吗？Code Review 算是一种吧，属于实施走查，可以降低偏差的概率。但它也有成本，相对来说越是核心关键系统的代码，实施 Code Review 即使成本很高，也更容易推行。

比如说，底层存储类数据库系统，如果引发灾难级事故，其影响很可能是不可逆的，那么再高的成本也得承担。但更多的业务类代码，业务本身在探索、演变和进化，而业务错误大部分也不是难以承担的不可逆错误，所以在效率和成本之间就需要经常去平衡了。

现实中确实有这种情况，我们在写代码实现时也许能发现更好的方法路径，但做出这种改变时，要特别反思一下当初设计的初衷，是否把所有的点都考虑全面了。

场景缺失

1968 年 1 月，挑战者号航天飞机升空后不久爆炸。

挑战者号是在美国佛罗里达肯尼迪航天中心发射的，爆炸的原因是航天飞机的多节推进器连接的 O 形密封圈破裂，火焰从裂开的密封圈喷出并点燃了相邻的燃料箱。

为什么会破裂呢？因为这个密封圈缺乏在 0 度环境以下的测试。发射当天，气温很低，达到了 -2 摄氏度，这对于处在亚热带地区的佛罗里达是一个异常的低温。过度冰冷的密封圈变得太脆，从而发生了低温破裂。

我再想，如果当时发射时间选在春夏季节，也许就不会发生这次事故，但这个隐患可能很久都无法被发现。有些 Bug 会隐藏很久，但该来的总会到来。

大概是在上一次双十一吧，我们的系统中就埋藏了类似这样一个 Bug，那次公司在电视上作了互动，整点通过打开 App 摇一摇来抽奖。本以为这个场景和我们没啥关系，但没想到在代码层面真有了关系，每次摇动的用户都和我们系统建立连接并发起了登录，这部分流量完全在我们的预估之外，导致了系统访问量比预估的最大量还高了十多倍，直接引发了限流，降低了用户可用性和体验。

这就是场景考虑缺失的问题，佛罗里达也许很少有这样的低温天气，而我们也没想到还有这样一个场景。

想不到的，才是最危险的。

有什么好办法来预防吗？也许可以让团队来开一个事故头脑风暴会，把大家各自掌握的信息和思维路径都分享碰撞以下，也许会有一些启发。

...

今天写不完了，还有一些其他颇有启示的事故案例，下次续一篇再聊。