AICon上海|与字节、阿里、腾讯等企业共同探索Agent 时代的落地应用 了解详情
写点什么

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

  • 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:333700
用户头像

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

关注

评论

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

全面解析企评家网站功能

企评家

企业评价 企评家 企业成长性评价 企业查询

社交电商如何规避传销风险

源字节1号

软件开发

到底什么是企业应用现代化?

Daocloud 道客

云原生 应用现代化

如何基于盘古开发框架开发Dubbo微服务网关

码农大熊

微服务架构 网关

北明软件加入昇腾万里伙伴计划,与华为共建昇腾AI生态,共同推动人工智能产业繁荣发展

科技热闻

Git 常用命令

平凡人生

Open Harmony移植:build lite配置目录全梳理

华为云开发者联盟

HarmonyOS Open Harmony移植 Open Harmony build lite配置

前端 “一键换色“ 的几种方案

CRMEB

PingCode Flow技术架构揭秘

PingCode研发中心

Alluxio 2.8版本重磅发布!3大提升抢先打开数据新世界

Alluxio

分布式缓存 数据管理 Alluxio 大数据 开源

百亿级数据同步,如何基于 SeaTunnel 的 ClickHouse 实现?

Apache SeaTunnel

Apache 大数据 开源 DolphinScheduler workflow

云天励飞与华为签署合作协议,共同推进昇腾AI产业持续发展

科技热闻

2022年医疗+AI,将会如何蓄力发展?

易观分析

医疗AI

【Python】此集合非彼集合

謓泽

5月月更

python进阶-装饰器

AIWeker

Python 人工智能 5月月更

阿里大牛两万字总结+40张图文详解,不信你还参透不了并发编程

Java架构追梦

高并发 java面试 后端开发

石油储运生产 2D 可视化,组态应用赋能工业智慧发展

一只数据鲸鱼

数据可视化 数字孪生 组态 石油开采

2013年,我有点喜欢编程了

勇哥java实战分享

Kubernetes 1.24 - 走向成熟的 Kubernetes

Daocloud 道客

Kubernetes 云原生 容器编排

边缘工业协议网关软件Neuron正式开源,连接海量异构工业设备

EMQ映云科技

开源 物联网 IoT mqtt emq

看 Amazon 如何通过 Nitro System 构建技术优势

亚马逊云科技 (Amazon Web Services)

Builder 专栏

web前端培训interface和type的区别分析

@零度

typescript 前端开发

“操作系统的「冷板凳」要坐多久?”万字长文解读16年开源人的坚持

OpenAnolis小助手

Linux 开源 操作系统 坚持 龙蜥社区

恭喜 Kvrocks 加入 Apache 软件基金会孵化器

Kvrocks

redis 开源 apache 社区

WordPress 如何重置密码

海拥(haiyong.site)

5月月更

浅析分布式系统之体系结构 - 事务与隔离级别(多对象、多操作)上篇

snlfsnef

数据库 架构 设计原则 一致性 事务隔离

使用小程序容器技术快速构建智能电视应用平台

Speedoooo

小程序 物联网 移动开发 小程序容器 智能电视

比心云平台基于阿里云容器服务 ACK 的弹性架构实践

阿里巴巴云原生

阿里云 容器 云原生 客户案例 阿里云容器服务ACK

大数据培训MySQL 索引B+Tree

@零度

大数据

SpringBoot集成开源IM框架MobileIMSDK,实现即时通讯IM聊天功能

JackJiang

网络编程 即时通讯 IM TCP协议

Apache ShardingSphere 企业行|走进携程

SphereEx

Apache 数据库 ShardingSphere SphereEx 企业行

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