波音飞机的坠落让我再度想起前年the Atlantic（《大西洋月刊》）网站上的一篇文章《The Coming Software Apocalypse》（正应验的软件启示录）。

文章的核心从学术角度方面讲，就是复杂系统存在联级失效的问题，也就是对一个逐渐增加复杂度的系统，一个小的“零件”出现问题，会造成整个系统的奔溃。而人们往往对此常少有意识。波音737 max巨大的新引擎在动力学上是不稳定，波音的解决方法是设计新的控制软件来修复这一机械缺陷，但这次期中有一个传感器失效，而软件没能及时修正。

这里有篇关于 37Max 的新文章，《The 737Max and Why Software Engineers Might Want to Pay Attention》。

启示录一文，我摘录部分重要内容，全文翻译可以见这。这里我做了部分改写。

1. 计算硬件指数性发展了几十年的时间里，软件的开发方式却基本保持不变。随着软件变得越来越庞大，对关键系统的渗透越来越深入，软件正在积累着越来越高的风险。

2. 2014 华盛顿州的 911 断线6 个小时，原因服务器系统提供商 Intrado一个程序员，给这个911热线计数器软件设置了一个阈值上限。超过这个阈值，新的来电都会被拒绝。但知道第二天大家才意识到。

3. 问题在于我们在尝试建立超过自己管理能力范畴的系统。

4. 关于工程失败我们标准的思维框架是在二战后不久形成的（在软件出现之前，针对机电系统）。其想法是通过把部件做得可靠（比如引擎可承受 40000 次起飞与降落周期）以及为那些部件故障做好预案（准备 2 个引擎）来把东西做得可靠。

5. 复杂性难以直观观察。

6. Edsger Dijkstra ：“必须思考一个头脑此前从未面临过的概念层级。”

7. 2007 年 9 月，Jean Bookout 载上自己最好的朋友开着一项丰田凯美瑞正行驶在高速公路上，突然油门好像被卡住了一样。她抬脚松开油门，汽车并没有放缓；她试着踩刹车，但却似乎失去了动力。当她以 50 英里的时速转入匝道时她踩下了紧急刹车。车子划出了一道 150 英尺长的滑痕然后撞上路边的路堤。乘客在这次事故中死亡。Bookout 一个月后才从医院中醒来。

8. 如果软件失灵了也是由同样一套程序处置的话，则这套程序是无法胜任的。

9. 盯着文字编辑器来理解癌症的做法是可怕的。

10. 我们早已经知道如何让负责软件变得可靠，但在太多的地方我们都选择不这么做。

11. 你可以不停地做测试，但永远也无法找完所有的 bug。

12. Esterel 背后的法国研究人员 Gerard Berry 说：“汽车存在着大量的 bug。它不像航空电子，航空电子对待 bug 非常认真。并且承认软件不同于机械。”汽车业可能跟很多行业一样尚未意识到自己其实也身处软件业。在丰田案作证的软件安全专家 Michael Barr 说：“汽车业缺乏了解软件在做什么的软件安全监管者。”他说 NHTSA“只有有限的软件专业知识。”使得基于模型的设计与代码生成对航空业产生吸引力的相同监管压力降临到汽车业身上要慢一些。但达索航空的 Emmanuel Ledinot 认为这种差异也许还有经济方面的原因。汽车根本无法接受零件成本的增加，哪怕几美分都不行，因为乘上几百万就是个大数字；因此嵌入到汽车的计算机必须缩减到最少水平，这几乎不给尚未调整到精益水平的代码太多的运行空间。“我认为过去 10 年引入基于模型的软件设计对他们来说代价太高了。”

13. Gerard Berry 在演讲中说：“计算基本上是不可见的。当你的轮胎没气时，你会看见它是瘪的。当你的软件出问题了，你看着软件却什么也看不到。

napor