BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

来自复杂系统故障的十八条经验

| 作者 郑柯 关注 3 他的粉丝 发布于 2012年9月16日. 估计阅读时间: 9 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

连城是一名曾工作于网易杭州研究院和百度的自由开发者,也是《Erlang/OTP并发编程实战》及《Erlang并发编程(第一部分)》的译者,前不久,他在自己的博客上翻译了一篇文章《复杂系统故障面面观》,作者是来自芝加哥大学认知技术实验室的医学博士Richard I. Cook,文中总结了十八条关于复杂系统故障的经验,讨论了故障的性质、如何评估故障、如何推断故障肇因等方面。

之所以翻译这篇文章,连城主要是因为看到了今年6月29日Amazon EC2发生事故的官方报告,同时:

回顾自己在过去若干年间遇到的种种线上事故,几乎无不落入这十八条之内。这篇文章并没有将视线局限在技术领域,而是从系统、从业人员、事故评估等一系列角度全方位地探讨了复杂系统故障的性质,点破了复杂系统中的一系列“潜规则”。……本文讨论的本是医疗IT系统,得出的结论却同样适用于大规模互联网基础服务。

这十八条包括:

  1. 复杂系统本质上都是高风险系统。

    各种备受瞩目的复杂系统都是高风险系统,这是它们固有的内在属性。尽管风险事故的爆发频度时有高低,导致系统固有高风险性的内因却无从化解。这些风险又催生了各式各样的风险防范措施,进而塑造了形形色色的复杂系统。

  2. 复杂系统都对故障严加防范并且行之有效。

    故障造成的高昂代价促使人们逐渐构筑起重重防范措施来抵御故障。其中既包括必要的技术措施,也包括多种机构性措施、制度性措施和监管性措施。

  3. 灾难性事故是由多起故障共同造成的——单点故障不足以兴风作浪。

    重大灾难性事故往往是由多起无足轻重的轻微故障共同导致的系统性的意外事故。这些轻微故障中的每一起都是事故的诱因,但只有当它们叠加在一起时,才会酿成事故。换言之,故障的发生概率比重大系统事故的发生概率要高得多。

  4. 复杂系统中潜伏着变化多端的故障组合。

    除非真的发生事故,否则我们也很难看出这些故障如何会诱发事故。不断演变的技术和工作机构,再加上人们为了排除故障而付出的种种努力,使得故障也不断地发生变化。

  5. 复杂系统运转时总是处于降级模式。

    由上一条可知,运转中的复杂系统总是残缺不全。之所以还能运转,是因为系统内备有充足的冗余部件,即便存在诸多缺陷,人们仍然有办法让它工作。从以往的事故评估结果来看,事发之前系统几乎都出现过险些酿成灾难的“准事故(proto-accident)”。系统的运作过程是动态的,各种(机构、人员、技术)部件会不断发生故障进而被更替。

  6. 灾难总是近在咫尺。

    在从业人员的身边,各种潜在故障每时每刻如影随行。所有复杂系统都有可能导致灾难性的后果,这是它们的标志性特征之一。人们不可能完全杜绝这类灾难性故障;这是由系统自身的性质决定的。

  7. 在事发之后将事故归咎于某一“罪魁祸首”的做法是完全不可取的。

    重大故障都是由多重失误共同造成的,因此,事故背后根本就不存在孤立的“罪魁祸首”。这种将事故归咎于某一“罪魁祸首”的做法无法反映故障的技术本质;之所以抓住某一局部力量或事件不放并加以责难,无非为了迎合社会和文化诉求罢了。

  8. 事后成见会扭曲事故评定人员的认知。

    在已知事故后果的情况下,人们会产生一种错觉,倾向于认为当事人理应更早注意到酿成事故的种种事件。这意味着人们无法客观地分析事故经过。已然了解事故后果的事故分析人员往往会先入为主,难以站在当事人的角度忠实地还原事故经过。当事人似乎“理应注意到”这些因素“必将”导致事故。事后成见一直是事故调查中的主要障碍,尤其是在有专家参与的时候

  9. 操作人员分饰二角:他们既是故障的始作俑者,也是故障的防范者。

    系统内的从业人员一边操纵系统从事生产,一边防范事故的发生。外界很少有人能够认识到这一角色的二重性。系统正常运转时,唱主角的是生产角色;事故发生后,主角则换成了故障防范角色。实际上,系统操作人员一直长期且持续地分饰二角,这一点往往为外界所误解。

  10. 当事人的举动完全是在冒险。

    事故发生之后,人们往往会认为早在事发之前导致事故的重大故障就已经在所难免,之所以最终会酿成事故,是因为当事人在故障迫近时处理失当或玩忽职守。但实际上,当事人在采取行动时完全是在冒险,他们无法预知自己的行动会导致什么后果。灾后分析通常都不会将这些行为判作明智之举。反过来看:即便处理得当,也不过是瞎猫碰上死老鼠,无法得到广泛认同。

  11. 风口浪尖上的行为令一切模糊性消失殆尽。

    各种组织机构都存在一定的模糊性,而且这种模糊性往往是蓄意造成的,它体现在生产目标、资源使用效率、运作成本,以及对不同程度的潜在事故的容忍度等多个方面。然而在评判那些被抛至风口浪尖的从业人员的行为时,这些模糊性却消失殆尽。发生事故之后,当事人的行为往往会被视为“失误”或“违规”,但这类评判带有严重的事后成见,往往无视业绩压力等其他诱因。

  12. 从业人员会对复杂系统进行调整。

    从业人员及一线管理者会积极调整系统,一边扩大产值一边减少事故。这种调整每时每刻都在进行,包括:(1)系统重组,避免脆弱部件遭受故障。(2)集中稀缺资源,应对关键需求。(3)留出后路,用以躲避或修复各种可预期及不可预期的故障。(4)针对系统性能的变化建立各种早期检测手段以妥善紧缩生产规模,或通过其他手段提高系统的恢复能力。

  13. 复杂系统中的专业人才不断更替。

    复杂系统中时刻存在着身怀不同程度的专业知识的从业人员和受训人员。有关专业知识的关键问题主要表现在(1)对能够胜任最困难、最艰巨的生产任务的稀缺专业人才资源的需求,以及(2)为了应对未来需求而进行的技术储备。

  14. 变化会引入新的故障。

    在可靠性较高的系统中,重大事故的发生频率较低,这使得人们更乐于接受变化,尤其是以减少影响较小的频发性故障为目的引入新技术。然而这些变化有可能会引入新的、后果严重的偶发性故障。在应用新技术清除已知的系统故障或追求更高的性能的同时,往往会埋下可能引发新的大规模灾难性故障的隐患。不少情况下,比起采用新技术清除掉的那些故障,这些新的、罕见的灾难性事故所造成的影响甚至更加恶劣。

  15. 抵御未来事件的效果受限于人们看待“肇因”的方式

    发生事故之后,为了防范事故中的“人为失误”,人们通常会想方设法阻断各种可能“导致”事故的事件。这种做法治标不治本,在事故防范方面起到的作用十分有限。实际上,由于潜在故障的模式不断地发生变化,相同事故重复发生的概率非常低。这类事后防范措施往往难以起到增强安全性的作用,反而还会加重系统的耦合性和复杂性。这么做不仅会催生更多潜在故障,而且还会加剧事故的排查难度。

  16. 安全性是系统整体的特性,而不是系统中各部件的特性。

    安全性是系统的自发属性;它不是独立的个人、设备、组织中的某个部门或系统所能决定的。无论何时,安全性在任何系统中都是动态的;系统自身持续不断的变化必然导致灾难性故障及其应对方式发生相应的变化。

  17. 人们持续不断地营造安全的环境

    无故障运营的背后凝结着人们付出的种种努力,他们想方设法将系统的性能波动控制在可承受范围内。然而系统的运转过程从来都不是一帆风顺的,迫于周遭条件的变化,从业人员必须及时采取措施,不断营造安全的环境。这些措施通常都出自一组经过充分演练的对策集;但有时也会出现新颖的策略组合或完全创新的解决方案。

  18. 无故障运营需要故障处理相关的经验。

    只有真刀真枪地处理过故障的人才能识别出灾难性故障,并成功地将系统的性能波动维系在可承受范围之内。对于具有内在高风险性的系统,运维人员应当以把控系统整体运作情况为主,正确认识到事故的必然性并予以重视。安全性的提升离不开对意外事故有正确认识的运维人员;同时,运维人员也必须清楚地认识到自己采取的措施会如何影响系统,如何令系统逼近或远离极限情况。

读者可以点击该链接查看连城对该文章的全文翻译。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

分治和KISS是解决复杂系统的有效方法! by 高 翌翔

必须从复杂系统的架构设计上着手解决。

Re: 分治和KISS是解决复杂系统的有效方法! by gao gavin

出故障了,扣工资,能有效控制控制吗?

Re: 关于“出故障了,扣工资”的看法! by 高 翌翔

首先“出故障”仅仅是结果,而非问题本身;其次“扣工资”对于有效降低复杂系统的故障率几乎无效。
因此,所谓的“出故障了,扣工资”完全是一种行政干预手段,其作用充其量与“搅屎棍”相当!

至于“有效控制”的有效方法无非两种:
一是,撤换出台此种政策的领导(估计没戏);
二是,主动离开这种“屎盆儿”项目(想自毁前程者除外)。

胡言乱语,仅供参考。 :D

Re: 分治和KISS是解决复杂系统的有效方法! by 钟 健鑫

这种措施,很有可能导致人员流动增大,系统更佳不稳定!

第七条末尾的脚注链接应删除 by Cheng Lian

或者附上原文的脚注

Re: 分治和KISS是解决复杂系统的有效方法! by andnls andnls

明显不能,因为最终出错的环节不是真正出错的原因,经常会搞错真正的对象而让错误继续存在

Re: 关于“出故障了,扣工资”的看法! by andnls andnls

首先“出故障”仅仅是结果,而非问题本身;其次“扣工资”对于有效降低复杂系统的故障率几乎无效。
因此,所谓的“出故障了,扣工资”完全是一种行政干预手段,其作用充其量与“搅屎棍”相当!

至于“有效控制”的有效方法无非两种:
一是,撤换出台此种政策的领导(估计没戏);
二是,主动离开这种“屎盆儿”项目(想自毁前程者除外)。

胡言乱语,仅供参考。 :D

我觉得你说的很对。很多问题最大的原因是在于leader(集成者),而很小取决于模块实施者。无谓的黑锅不要背,无进步的团队也不要呆。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

7 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT