空难与 IT 系统的设计和维护 (中)

最近观看了总共十三季的 Air crash investigation，感到 IT 研发和运维的就像是这些场景的重现。事实上，我们做的许多 IT 系统的复杂程度都接近甚至超过了飞机。因为我们要维护比飞机多得多的内部状态，只不过飞机对稳定性和可靠性的要求比一般 IT 系统要多得多。前人的经验非常值得我们学习。如果你没有那么多时间全部看完，那么请看以下的吐槽（有些案例，例如 法国航空8969号，1994 并未过多涉及行业经验故而略过），挑选自己感兴趣的看一看吧。

前一篇文章请看：空难与 IT 系统的设计和维护 (上)

第七季

泛美航空103号（洛克比空难），1988：

必须对任何的输入参数做彻底的检查；输入的参数可能都符合规定，但是当参数组合使用的时候，也可能产生安全问题；

沙乌地阿拉伯航空 763 号，哈萨克航空 1907 号，1996：

给开发人员和运维人员你能找到的最好的工具；
所有的 IT 从业者都应该学好英语，至少目前看如此；

中华航空 611 号，2002：

维护是个枯燥的工作，但是应当遵守流程。遵守流程可能会带来更多的支出，但是比系统出现严重问题的代价小得多。最可怕的是不按照流程进行操作但是还在日志或者邮件中声称按照流程进行了操作。

帕那航空 394 号，1989

使用原装的机器配件，使用 Licensed 的软件；

美国空军 CA-5 事故，1975：

在设计上进行足够的验证防止误操作发生的可能性，只有操作完全正确的时候才能够提交。

突尼斯国际航空 1153 号，2005

确保系统构建与部署时能够得到版本号正确的依赖组件；
确保主要版本号更新的时候有充分的方式验证组件之间的差异，最好是静态方式；

亚当航空 574 号，2007：

又是不按照流程进行系统运维的范例；
系统的高自动化程度，包括运行，部署，配置会使相关操作的知识快速流失。技术人员会非常依赖自动化手段而不知道如何手动解决问题。在系统异常的时候，他们会显得无能为力。
自动化运维过程中出现的异常应当被恰当的记录以便今后作为案例进行查询；

美鹰航空 4184 号，1994：

忽视其他同行提出的对系统安全可能造成影响的警告，例如，机器环境改变（CPU、磁盘、软件安装或系统升级），可能造成严重的运维失误。
在运维过程中，应当将任何计划外（意料外）的环境变化通知相关的人员，保持畅通的沟通保证大家都了解目前系统的状态。
了解系统的构建历史以及运维历史非常重要，这些信息将帮助维护人员避免重复以往发生的错误。
忽视事实，甚至掩盖事实的做法只能让问题重复发生。

第八季

空游航空 28 号，1985：

不可测试的组件是非常可怕的，因为你不可能清楚维护的结果；
系统异常并不常见，因此应对异常的组件并不常使用和更新，这可能导致真正的系统异常发生时异常处理机制不可用；
集成测试与性能测试应当尽可能模拟真实的环境，否则测试的结果很可能与实际情况有较大出入。
我们设计的软件是给机器运行的，但是同时是给人使用的。人有情感，这可能导致其反应和机器是很不同的。

法国航空 296 号，1988：

系统必须有能力关闭自动化任务转入人工操作；人必须有能力完全控制系统；
保持关键性文档 up to date，过期的文档或者 instruction 是运维的噩梦。
如果有信息需要在 UI 上显示，那么保证这个信息的字体足够大老年人也可以看清楚。

西北航空 255 号，1987：

不要打断程序员，另外，程序员被打断的时候也不要太着急，按照标准程序做就是了，如果需要将 context 写下来会避免遗漏事情。
系统的异常往往是几个一起发生的，确保这些异常的信息都能够正确的显示而不是一个被另一个淹没；
如果运维人员经常忽略莫一个异常，应当从设计的角度去考虑如何正确的实现异常处理，以免单纯忽略引发更大的问题。
在制定 checklist 的时候，应当考虑如何避免这些 checklist 被忽略。一个好的做法是使用 checkbox 标记已经完成的部分。另外，checklist 过长也会造成不想遵照执行，解决方法是将过长的 checklist 切分成小的部分。另外一个重要的做法是能够自动化完成的 checklist 就不要用人来执行，人可以用于监视自动化 checklist 的执行。

全美航空 1493 号，1991：

差点儿发生问题和已经发生问题是等价的，必须马上处理，否则问题就真的来了；
如果你想出事儿就把一堆事儿堆在一个人的身上，如果他完成了，就让他以此为荣；
如果要在 UI 上显示一个警告，那么应当真正考虑警告放在上面是什么样子，而不是忽略整体而只考虑警告本身。否则警告和 UI 整体过于相近可能使其很难被发现。
主动提示比被动询问能够更有效的避免误操作。

大韩航空 007 号，1983：

还是警告的问题，预定数据和实际数据显示难以区分的话很容易导致操作人员混淆两个数据的意义；

因特航空 148 号，1992：

对于运维团队来说，记录以往发生的事件和解决办法和不断的熟悉操作命令是非常重要的；因为他们面临的常常是必须尽快解决问题的情况。
沟通应当尽量的精确和使用术语或领域语言；
如果两个数据的术语过于接近，那么在 UI 上显示他们要格外小心以避免混淆；
对于自动化的手段，应当严格检查输入以确保在安全的范围之内；
给开发和运维人员最好的工具辅助他们是绝对值得的。
技术再发展，也离不开好的研发和运维人员。

安大略航空 1363 号， 1989

违反操作规程的原因除了麻烦之外还有权限的问题。试想一下，如果在 on site 部署的时候发现了一个 show-stopper 级别的 defect，而解决这个 defect 需要整个后方团队工作 2-4 天然后再走一次部署流程的时候运维团队往往无权决定；
不要用感觉证明东西是好的，用测试或工具来证明；
软件的质量不是开发或者运维团队的问题，而是公司文化的问题；

卓克斯海洋航空 101 号，2005：

这个例子的维护状况已经烂到无以复加了，其他的是未遵守 instructions，这个完全是野蛮维护，无话可说；
如果你使用了一个第三方组件作为你的 dependency，需要考虑这个组件的生命周期，对于维护糟糕的组件还是不用为妙；
政治方法可以缓解但是无法替你解决技术上本身存在的问题。

第九季

十字航空3597号，2001：

保持关键性文档 up to date，保证 instruction 经过测试并和实际情况匹配。
从业时间并不代表能力。即使经验丰富，仍然按照instraction操作，尤其是遵守安全规定是一种专业的表现。

英国航空38号，2008：

Defect 的原因是什么，我们一定要知道

北欧航空 751 号：

不要用感觉证明东西是好的，感觉是不稳定的。用测试或工具来证明；
系统必须有手段能够人为的启动和停止，自动化不应当和人的操作相冲突；
谨慎提供让客户惊奇的小功能，即使你认为这个功能很不错。

土耳其航空 1951 号，2009：

事情总是重复，模式切换的时候应该有非常明显的多维度提示（颜色，尺寸，邮件，日志等等）；
当系统出现异常的时候，任何为正常系统设计的自动化手段可能带来风险；
系统难道真的只能越来越复杂吗？事实上，复杂的系统往往由一个小故障就可以引发一连串的错误最终导致系统失效；如何让系统更简单是我们的目标之一；最好的技术并不是取代人而是可以和人更好的协作。

大陆航空 3407 号，2009：

组内的人员只是构成都不一样，你所认为的常识性知识对于其他人来说可能并不是。因此详细的描述这些细节在沟通中十分重要。
在系统部署过程中，最好不要闲聊让自己分心，否则遇到突发情况的时候很可能手忙脚乱；
在面对巨大压力的时候做出正确的判断的基础是平时对基础知识的积累和对系统的不断熟悉；
如果你想出事儿，就让你的团队玩儿命加班，并以此为荣；

全美航空 1549 号，2009：

对系统的完美理解，近乎完美的沟通带来近乎完美的解决方案；

第十季

巴西天马航空 3054 号，2007：

你的服务提供商和你想的一样。Corner case不会成为系统升级的理由，除非发生了重大事故。因此重要数据需进行备份。
技术债一定要尽早还清。
undocumented features很有可能在相应组件升级时失效。不要依赖这些知识。
制定 instructions 时不但要考虑正确性，还要考虑它们是否容易出错。最好调整容易混淆的步骤。

西加勒比海航空 708 号，2005：

一定要关注系统更新，并及时升级系统。
有效地沟通，团队合作比一个人苦思冥想更容易解决问题。

飞剑航空 1285 号，1985：

一些小的细节应引起足够的注意，不要试图完全忽略它们，再事后补救。我认为性能问题首当其冲。

美国大陆航空快运 2574 号，1991：

在进行任务交接时，务必完整的介绍上下文，以及已经完成的功能与相应提交，余下来要进行的任务。如果有hack则更需要着重介绍。
每一次提交都应当详细纪录提交内容及原因，这对今后的维护至关重要。

西北航空 85 号，2002：

系统任何部分都可能失效。即使是那些被认为不可能出错的部分。

大韩航空货运 8509 号，1999：

对错误及解决方案进行记录对系统的维护是很有益处的。
成员的关系应当是完全平等的，将技术问题和职务等级混淆完全没有好处。

太平洋西南航空 182 号，1999

如果你的系统日志中有很多异常，即使这些异常通常认为是可以被忽略的，也说明了系统存在着某些隐患。

北欧航空686号，2001

在配置中使用相近的词语，代码中使用容易混淆的术语，instructions 中使用模糊不清的词汇容易铸成大错。
没有必要就不要随便增添接口，如果添加了则必应定义良好。

联合航空232号，1989

人工的检查几乎无法发现隐含的系统错误。自检功能对于复杂系统是非常必要的
劣质的代码可能能让系统在某个时期正常运行，但绝对是悬在头顶的一把利剑。不断改善代码质量是必要的工作内容。
合作，合作，合作

第十一季

里夫阿留申 8 号班机，1983

最后一公里是最难的，在即将上线的前夕发现问题对谁来说都是噩梦，但是大部分的尝试是无论如何都想让系统赶快上线而不顾问题。此时保持冷静，分析问题并作出决策才是上上之选。

瓦卢杰航空 592 号班机，：

对系统进行的任何改动都应该被记录并有据可查，尤其是和系统的安全相关的部分。悄悄更改系统而不让其他人知道会造成严重的问题并影响问题的解决；
沟通中使用精确的语言避免误解非常重要；
系统的任何设计均有其原因，在修改之前了解这些原因是很重要的；

新加坡航空 006 号班机，：

如果系统的某一个功能禁用了，那么不要让客户能够从 UI 上看到这个功能；
在出现严重问题的时候，更改计划比起强硬的继续执行计划可能对解决问题更有效；

第十二季

胜安航空 185 号，1997：

系统安全，运维安全，部署安全，不仅指屏蔽外部人员对系统的威胁，还包括内部人员可能对系统产生的无意或者蓄意的破坏；

秘鲁国营航空 204 号，2005：

不要忽略简单的程序功能失效，大的灾难有可能是由一些简单的失误连锁反应得来的。
和缺乏经验的人员一起进行关键工作，尤其是在客户现场工作时替补人员应始终保持available状态。
不要给开发人员繁重的压力，这只能造成更多错误。
pair的好处在于，两个人可以关注更多的方面。但是如果两个人关注的事情始终一样那么这和一个人做没什么两样。

大峡谷撞机事件，1956：

记录每一次系统失败的原因，不能记住历史的人必然重蹈覆辙。

联合航空173号，1979：

在结对中，确保大家对解决的问题达成共识，确保你想做的每一件事情对方都明白并可以进行合作。
团队的成员应保持平等的关系，在资深成员的解决方向出现重大偏差的时候其他成员应努力纠正，甚至接管系统的控制权(抢过键盘)。切忌默不作声。
写出烂代码的人大多没有恶意，很多情况下是当时条件造就的产物。

埃塞俄比亚航空 409 号，2010：

过度疲劳会使技术人员产生轻微的失能，降低其处理问题的能力；

雅罗斯拉夫尔空难雅克航空RA42，2011：

当我们的精力不再能够跟上的时候，我们就该从一线退下来了对吗。这真是令人悲哀；
在技术人员处理问题的时候，非技术人员如果并不是在提供帮助就 TMD 少插嘴；

波兰总统军机空难，2010：

为了忽略烦人的警报和不断出现的异常日志而关闭异常处理机制是非常危险的，正确的做法是正确的评估警报或异常的来源并作出反应；
在评估监控或者统计数据的时候，应当理解这些数据收集的原理以便正确的理解数据的意义。单纯通过数据的值并不可靠；
在技术人员处理问题的时候，非技术人员如果并不能提供帮助就 TMD 别站在他们后面；
给研发和运维人员以工具，你能找到的最好的工具；
学好英语（至少现在如此），避免在语言上的沟通障碍和误解；
能做出正确判断的人员却不具备决策的权限，让决策者时刻待命；

圣巴巴拉航空 518 号，2008：

在部署和运维过程中，不按照正常流程操作，跳过某些步骤，忽略某些警告是危险的。而这种情况多发生在有经验的人员身上。
赶时间是不会有好结果的，从来不会有好结果

美国航空 191 号，1979：

运维流程必然有其意义，违背既定流程抄近道的做法就是在给系统埋下隐患。但是由于短期利益，大家不但抄近路，而且还会把这种经验分享。

法国航空 447 号，2009：

运维工具也是有用户体验的，突如其来的警告可能会使人感到惊吓而无法整理思路。如果平时对系统熟悉不够可能做出糟糕的操作；
Pair 的沟通十分重要，让你的 partner 时刻知道你们在干什么和你下一个操作的目的，不要默默的操作；分清 driver 和 observer 通力合作。
当自动化工具十分流行的时候，人们就会忘记如何手动进行操作，也会忘记其原理；