写点什么

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

  • 2012-09-14
  • 本文字数:2884 字

    阅读完需:约 9 分钟

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

  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. 无故障运营需要故障处理相关的经验。

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

2012-09-14 22:333847
用户头像

发布了 479 篇内容, 共 174.4 次阅读, 收获喜欢 52 次。

关注

评论

发布
暂无评论
发现更多内容

网络安全小白别拜师了,求人不如求己

网络安全学海

黑客 网络安全 信息安全 渗透测试 安全漏洞

架构实战营模块六作业

老猎人

架构实战营

极客时间【架构实战营】第二期 模块一作业

Geek_91606e

架构实战营

初识html,一文搞懂HTMl骨架标签都有哪些含义及浏览器内核

你好bk

html html5 大前端 浏览器 html/css

架构师实战营作业[模块一]

看,有只猪

学习心得-架构训练营-第一课

Fm

微信业务架构图-作业

Geek_a772a7

01. 你身边的AI

Databri_AI

人工智能

【DPDK工程师手册】 —— 官方文档,最新视频,开源项目,论文,大厂内部ppt,知名工程师一览表

奔着腾讯去

Linux DPDK VPP

🚀【Guava技术指南】「RateLimiter类」服务请求流控实现方案

码界西柚

Java ratelimiter Guava 8月日更

作业

Li. Mr

在线JSON转XML工具

入门小站

工具

HTTP接口测试基础【FunTester框架教程】

FunTester

自动化测试 教程 接口测试 测试框架 FunTester

架构训练营 模块一作业

初一

图像分类-cifar100 实验研究

毛显新

人工智能 神经网络 tensorflow 图像识别 keras

架构训练营模块一作业

guangbao

graphql中的'子查询'

杜艮魁

开源 后端 graphql

搜索引擎渐行渐远,未来路在何方

石头IT视角

python通过PyQt5实现登录界面

Python研究者

8月日更

学生管理系统(作业)

Geek_a772a7

Linux之nohup命令

入门小站

Linux

微信的业务架构图

Rabbit

架构实战营

Flutter 安卓 Platform 与 Dart 端消息通信方式 Channel 源码解析

工匠若水

flutter android 8月日更

百度地图开发-实现离线地图功能 05

Andy阿辉

android 百度地图 Android 小菜鸟 Android端 8月日更

AI巨头们建造的“新世界”,进展如何?

脑极体

正经人一辈子都用不到的 JavaScript 方法总结 (二)

编程三昧

JavaScript 大前端 8月日更

☕【Java技术指南】「OpenJDK专题」想不想编译属于你自己的JDK呢?(Windows10环境)

码界西柚

Java jdk Openjdk 8月日更

OceanBase 源码解读(三)分区的一生

OceanBase 数据库

数据库 分布式数据库 oceanbase OceanBase 开源 OceanBase 社区版

[架构实战营]模块一

Amy

架构实战营 业务架构图

模块一作业

potti

架构实战营

仓储执行系统(WES)

申扬科技

WCS wms WES 仓储执行系统

来自复杂系统故障的十八条经验_服务革新_郑柯_InfoQ精选文章