复杂系统故障面面观
回顾Amazon针对这次事故的官方报告,以及自己在过去若干年间遇到的种种线上事故,几乎无不落入这十八条之内。这篇文章并没有将视线局限在技术领域,而是从系统、从业人员、事故评估等一系列角度全方位地探讨了复杂系统故障的性质,点破了复杂系统中的一系列“潜规则”。有意思的是,本文讨论的本是医疗IT系统,得出的结论却同样适用于大规模互联网基础服务,真可谓大道归一。在今年的Velocity大会上,Richard Cook就同一主题发表了演讲(YouTube视频),同样值得推荐。
需要指出的是,这篇文章没有任何量化分析,也没有提供任何实际案例,这种情况下文中的观点很容易引发争议。所谓经验,无非就是以非形式化的语言对过去遇到过的问题进行建模。对于采纳相关经验的人来说,如果当前面对的问题与该经验背后的模型相契合,那么经验就生效;反之,该经验便无效。若这十八条能够给读者带来启示,那最好不过;反之,若认为文中观点有偏颇之处,也请先结合具体场景再加以讨论。
独乐乐不如众乐乐,特将此文译出,以飨读者。这篇文章字数不多,译起来却颇费功夫。如果有错译之处,还请在评论中不吝赐教。
复杂系统故障面面观
(这篇短文讨论了故障的性质、如何评估故障、如何推断故障肇因,以及由此引出的有关病患安全的新的认识)
Richard I. Cook, MD
芝加哥大学认知技术实验室
复杂系统本质上都是高风险系统。
各种备受瞩目的复杂系统(如交通系统、医疗系统、电力系统等)都是高风险系统,这是它们固有的内在属性。尽管风险事故的爆发频度时有高低,导致系统固有高风险性的内因却无从化解。这些风险又催生了各式各样的风险防范措施,进而塑造了形形色色的复杂系统。
复杂系统都对故障严加防范并且行之有效。
故障造成的高昂代价促使人们逐渐构筑起重重防范措施来抵御故障。其中既包括必要的技术措施(如后备系统、设备的各种“安全”功能等)和人力措施(如培训、经验传承等),也包括多种机构性措施、制度性措施和监管性措施(如政策流程、资格认证、工作守则、团队培训等)。这些手段构成了一系列防护,令日常运维得以远离意外事故。
灾难性事故是由多起故障共同造成的——单点故障不足以兴风作浪。
多重防范的确行之有效,一般情况下足以保障系统正常运转。重大灾难性事故往往是由多起无足轻重的轻微故障共同导致的系统性的意外事故。这些轻微故障中的每一起都是事故的诱因,但只有当它们叠加在一起时,才会酿成事故。换言之,故障的发生概率比重大系统事故的发生概率要高得多。系统内预设的安全组件可以排除大部分故障。渗入到业务层面的故障绝大部分也会被排除,这一层面的故障通常需要从业人员人工处理。
复杂系统中潜伏着变化多端的故障组合。
由于复杂性过高,这些系统在运转时总是伴随着多种缺陷。然而这些缺陷在系统运转过程中显得无足轻重,因为其中的任何一种缺陷都不足以单方面导致故障。要彻底清除潜在故障,经济成本往往太过高昂。此外,除非真的发生事故,否则我们也很难看出这些故障如何会诱发事故。不断演变的技术和工作机构,再加上人们为了排除故障而付出的种种努力,使得故障也不断地发生变化。
复杂系统运转时总是处于降级模式。
由上一条可知,运转中的复杂系统总是残缺不全。之所以还能运转,是因为系统内备有充足的冗余部件,即便存在诸多缺陷,人们仍然有办法让它工作。从以往的事故评估结果来看,事发之前系统几乎都出现过险些酿成灾难的“准事故(proto-accident)”。有观点认为,通常情况下,简单的系统性能监控手段便足以发现这些系统降级情况,它们本该在重大事故发生之前就得到应有的重视。系统的运作过程是动态的,各种(机构、人员、技术)部件会不断发生故障进而被更替。
灾难总是近在咫尺。
复杂系统都有可能引发灾难性故障。在从业人员的身边,各种潜在故障每时每刻如影随行——灾难随时随地都有可能发生。所有复杂系统都有可能导致灾难性的后果,这是它们的标志性特征之一。人们不可能完全杜绝这类灾难性故障;这是由系统自身的性质决定的。
在事发之后将事故归咎于某一“罪魁祸首”的做法是完全不可取的。
重大故障都是由多重失误共同造成的,因此事故背后的“肇因”不可能是孤立的。导致事故的因素多种多样,但其中任何一种都不足以单方面造成事故。只有当这些因素叠加在一起时事故才会发生。实际上,滋生事故的温床正是由这些因素环环相扣共同形成的。因此,事故背后根本就不存在孤立的“罪魁祸首”。这种将事故归咎于某一“罪魁祸首”的做法无法反映故障的技术本质;之所以抓住某一局部力量或事件不放并加以责难,无非为了迎合社会和文化诉求罢了。[1]
事后成见会扭曲事故评定人员的认知。
在已知事故后果的情况下,人们会产生一种错觉,倾向于认为当事人理应更早注意到酿成事故的种种事件。这意味着人们无法客观地分析事故经过。已然了解事故后果的事故分析人员往往会先入为主,难以站在当事人的角度忠实地还原事故经过。当事人似乎“理应注意到”这些因素“必将”导致事故。[2] 事后成见一直是事故调查中的主要障碍,尤其是在有专家参与的时候。
操作人员分饰二角:他们既是故障的始作俑者,也是故障的防范者。
系统内的从业人员一边操纵系统从事生产,一边防范事故的发生。系统运转过程中的这一动态特质,以及业务需求与故障滋生风险之间的矛盾是不可避免的。外界很少有人能够认识到这一角色的二重性。系统正常运转时,唱主角的是生产角色;事故发生后,主角则换成了故障防范角色。实际上,系统操作人员一直长期且持续地分饰二角,这一点往往为外界所误解。
当事人的举动完全是在冒险。
事故发生之后,人们往往会认为早在事发之前导致事故的重大故障就已经在所难免,之所以最终会酿成事故,是因为当事人在故障迫近时处理失当或玩忽职守。但实际上,当事人在采取行动时完全是在冒险,他们无法预知自己的行动会导致什么后果。其中的不确定性在程度上时有不同。当事人的冒险行为在事故之后体现得尤为明显;灾后分析通常都不会将这些行为判作明智之举。反过来看:即便处理得当,也不过是瞎猫碰上死老鼠,无法得到广泛认同。
风口浪尖上的行为令一切模糊性消失殆尽。
各种组织机构都存在一定的模糊性,而且这种模糊性往往是蓄意造成的,它体现在生产目标、资源使用效率、运作成本,以及对不同程度的潜在事故的容忍度等多个方面。然而在评判那些被抛至风口浪尖的从业人员的行为时,这些模糊性却消失殆尽。发生事故之后,当事人的行为往往会被视为“失误”或“违规”,但这类评判带有严重的事后成见,往往无视业绩压力等其他诱因。
从业人员会对复杂系统进行调整。
从业人员及一线管理者会积极调整系统,一边扩大产值一边减少事故。这种调整每时每刻都在进行,包括:(1)系统重组,避免脆弱部件遭受故障。(2)集中稀缺资源,应对关键需求。(3)留出后路,用以躲避或修复各种可预期及不可预期的故障。(4)针对系统性能的变化建立各种早期检测手段以妥善紧缩生产规模,或通过其他手段提高系统的恢复能力。
复杂系统中的专业人才不断更替。
运作和管理复杂系统需要大量专业人才。迫于技术革新的压力,同时也为了填补人才流动所致的空缺,从业人员的专业知识必须不断更新。无论出于什么目的,技能和专业知识的培训和锻炼都应该成为系统自身的职能之一。由此可见,复杂系统中时刻存在着身怀不同程度的专业知识的从业人员和受训人员。有关专业知识的关键问题主要表现在(1)对能够胜任最困难、最艰巨的生产任务的稀缺专业人才资源的需求,以及(2)为了应对未来需求而进行的技术储备。
变化会引入新的故障。
在可靠性较高的系统中,重大事故的发生频率较低,这使得人们更乐于接受变化,尤其是以减少影响较小的频发性故障为目的引入新技术。然而这些变化有可能会引入新的、后果严重的偶发性故障。在应用新技术清除已知的系统故障或追求更高的性能的同时,往往会埋下可能引发新的大规模灾难性故障的隐患。不少情况下,比起采用新技术清除掉的那些故障,这些新的、罕见的灾难性事故所造成的影响甚至更加恶劣。事发之前很难发现这些新型故障;人们的注意力大都集中到设想中的借由变化带来的收益上去了。由于这类新的恶性事故发生的频率很低,事发之前系统可能已经经历过多次变更,加大了识别事故的技术原因的难度。
抵御未来事件的效果受限于人们看待“肇因”的方式
发生事故之后,为了防范事故中的“人为失误”,人们通常会想方设法阻断各种可能“导致”事故的事件。这种做法治标不治本,在事故防范方面起到的作用十分有限。实际上,由于潜在故障的模式不断地发生变化,相同事故重复发生的概率非常低。这类事后防范措施往往难以起到增强安全性的作用,反而还会加重系统的耦合性和复杂性。这么做不仅会催生更多潜在故障,而且还会加剧事故的排查难度。
安全性是系统整体的特性,而不是系统中各部件的特性。
安全性是系统的自发属性;它不是独立的个人、设备、组织中的某个部门或系统所能决定的。安全性无法通过购买或生产途径获取;它无法脱离系统中的其他组件而独立存在。因此人们无法像加工原材料那样加工安全性。无论何时,安全性在任何系统中都是动态的;系统自身持续不断的变化必然导致灾难性故障及其应对方式发生相应的变化。
人们持续不断地营造安全的环境
无故障运营的背后凝结着人们付出的种种努力,他们想方设法将系统的性能波动控制在可承受范围内。这些努力中的一大部分原本就是日常运维工作的一部分,相当直截了当。然而系统的运转过程从来都不是一帆风顺的,迫于周遭条件的变化,从业人员必须及时采取措施,不断营造安全的环境。这些措施通常都出自一组经过充分演练的对策集;但有时也会出现新颖的策略组合或完全创新的解决方案。
无故障运营需要故障处理相关的经验。
只有真刀真枪地处理过故障的人才能识别出灾难性故障,并成功地将系统的性能波动维系在可承受范围之内。如果运维人员充分重视系统的极限情况,系统的表现往往就会更加稳定。一旦被逼入极限情况,系统的表现便开始恶化,变得捉摸不定,或是难以恢复稳定。对于具有内在高风险性的系统,运维人员应当以把控系统整体运作情况为主,正确认识到事故的必然性并予以重视。安全性的提升离不开对意外事故有正确认识的运维人员;同时,运维人员也必须清楚地认识到自己采取的措施会如何影响系统,如何令系统逼近或远离极限情况。
脚注
[1] | 人类学研究为我们揭示了与“肇因”这一概念最为接近的社会构造(参见Goldman (1993), The Culture of Coincidence: accident and absolute liability in Huli, 纽约:克拉伦登出版社;以及Tascal L (1990),The Social Construction of Human Error,纽约州立大学斯托尼布鲁克分校社会学院未发表博士论文。) |
[2] | 这一现象并不局限在医疗诊断或技术领域内,它取决于人类对过往事件及其原因的认知模式。 |
疑难词汇译注
catastrophe 灾难性事故。在本文中严重程度高于hazard和accident。 failure 故障。本文中failure主要指不会单方面导致事故的轻度故障。 hazard, accident 事故、意外事故。在本文中这两个词的严重程度相当。 practioner 从业人员;当事人。本文针对的是医疗IT系统,文中的从业人员应该主要指医护人员和医疗IT系统的操作、维护人员。在具体到事故中的当事从业人员时,译作“当事人”。 trajectory 直译为“轨道、弹道”,本文没有单独专门译出这个词(原文中的failure trajectory和accident trajectory分别被译作“故障”和“事故”)。根据Error Reduction in Health Care: A Systems Approach to Improving Patient Safety第25页图2.1及相关文字的描述,该词形容的应该是系统内部产生的故障被“抛射”出来的情形;这些故障一路突破层层防御,最终被某一层的防御屏障拦截,或是最终引发事故。扫一扫订阅我的微信号:IT技术博客大学习
- 作者:连城 (Lian Cheng) 来源: :wq ~/notes
- 标签: 系统故障
- 发布时间:2012-09-19 23:34:59
- [72] Twitter/微博客的学习摘要
- [64] find命令的一点注意事项
- [62] Go Reflect 性能
- [62] Oracle MTS模式下 进程地址与会话信
- [62] IOS安全–浅谈关于IOS加固的几种方法
- [61] android 开发入门
- [61] 如何拿下简短的域名
- [60] 流程管理与用户研究
- [57] 【社会化设计】自我(self)部分――欢迎区
- [56] 读书笔记-壹百度:百度十年千倍的29条法则