写点什么

复杂系统是如何失败的?

2021 年 2 月 03 日

复杂系统是如何失败的?

1.复杂系统本质上是危险的

所有有趣的系统(例如交通、医疗、发电)本身就具有固有且不可避免的危险性。危险暴露的频率有时可以改变,但是系统中涉及的过程本身具有内在且不可削减的危险性。正是这些危险的存在推动了针对它们的防御措施的建立。

2.复杂系统非常成功地规避了故障

随着时间的推移,故障所带来的后果促使我们建立起对故障的多层防御。这些防御措施包括技术方面的(例如备份系统、设备的“安全”特性)和人员方面的(例如,培训、知识),以及各种组织、机构、监管部门的防御措施(例如,政策和程序、认证、工作守则、团队培训)。这些措施提供了一系列防护,通常可以让运维远离事故。

3.单个故障不足以导致灾难,但多个故障会

当一些小故障交织在一起,就有可能变成一个系统性故障,灾难性事故在这个时候就会发生。这些小故障中的每一个都是导致灾难的必要条件,但只有当它们组合在一起才足以导致灾难发生。换句话说,发生小故障的机率比发生灾难性系统事故的机率要大得多。大多数初始故障轨迹都被设计好的系统安全组件阻断。大部分达到运维层面的故障轨迹通常被相关的实践者阻断。

4.复杂系统包含潜在的不断变化的故障混合因素

这些系统的复杂性使得它们不可能在不出现缺陷的情况下运行。由于这些缺陷单独不足以导致故障,因此在运维过程中被视为次要因素。消除所有潜在故障主要受经济成本的限制,但也因为在事故发生前很难了解这些故障会如何导致事故。由于技术、组织和消除故障措施的不断变化,这些故障也在不断变化。

5.复杂系统在降级模式下运行

从上一点得出的推论是:复杂系统会像一个破碎的系统那样运行。这个系统之所以能继续运行,是因为它有很多冗余,而且尽管存在很多缺陷,人们还是努力让它正常运行。在进行事故调查后,人们几乎总会发现这个系统曾经有导致灾难的历史。认为这些降级条件应在事故发生前被识别出来的争论通常是基于对系统性能的朴素理解。系统运维是动态的,组件(组织、人员、技术)发生故障并不断被替换。

6.灾难随时随地都可能发生

复杂系统具有发生灾难性故障的可能性。实践者几乎总是在物理和时间上接近这些潜在的故障——灾难可能在任何时间和几乎任何地点发生。灾难性后果的可能性是复杂系统的一个特征。要消除这些灾难性故障是不可能的,这些故障的可能性总是由系统本身的性质决定的。

7.事后将故障归因于“根本原因”,这种做法是错误的

由于公开的事故是由多个缺陷一起引发的,因此一个事故不存在孤立的“原因”。事故的发生会有多个原因,每一个原因都是必要的,但它们单独是不足以导致事故的,只有这些原因结合起来才足以导致事故。事实上,正是这些原因联系在一起,才造成了事故发生所需的环境。因此,事故不可能存在孤立的“根本原因”。基于“根本原因”进行的评估并不能反映出对故障性质的技术性理解,它只能反映将结果归咎于特定、局部的力量或事件的社会和文化方面的需要。

8.事后诸葛亮偏向于对人类表现的事后评估

对结果的了解让导致结果的事件在当时的实践者看来似乎比实际情况更为突出。这意味着,对人员因素的事后分析是不准确的。对结果的了解影响了事后观察者的能力,使他们无法重现事故发生前实践者对这些因素的看法。似乎实践者“本应该知道”这些因素会“不可避免地”导致事故的发生。事后诸葛亮的偏见仍然是事故调查的主要障碍,尤其是当涉及专业人员的表现时。

9.实践者有双重角色:生产者和故障抵御者

系统实践者的工作是让系统产出预期的结果,同时也努力防止事故的发生。这种动态的系统运行质量以及取得产出需求与初期故障可能性之间的平衡是不可能避免的。局外人很少承认这个角色的双重性。在事故没有发生时,强调的是生产的角色,而在事故发生后,强调的是防止故障的角色。对于这两种情况,局外人通常误解了实践者其实经常同时扮演两种角色。

10.实践者的所有行为都是在赌博

事故发生后,往往认为公开的故障是不可避免的,而将实践者的行为视为错误或有意无视某些即将发生的故障。但实践者的所有行为都是在赌博,即在不确定的结果面前发生的行为。不确定性的程度每时每刻都在发生变化。实践者的行为是赌博,这一点在事故发生后变得很明显。一般来说,事后分析会将这些赌博视为失败,反过来,成功的产出也是赌博的结果,但这一点并没有得到广泛的认可。

11.果断的行动可以解决所有的歧义

组织对于产出目标、资源的有效利用、经济和运营成本以及事故的可接受风险之间的关系存在歧义,而且往往是有意这样的。所有含糊不清的问题都是通过系统尖端的实践者的行动来解决的。事故发生后,实践者的行为可能被视为“错误”或者“违规”,但这些评估在事后看来带有很大的偏见,并忽视了其他驱动力,尤其是生产压力。

12.实践者是复杂系统的适应性元素

实践者和一线管理人员积极调整系统,从而最大化生产并最小化事故。这些适应性措施通常是在一个时刻接着一个时刻发生的。其中一些适应性措施包括:

(1)重构系统,从而减少脆弱部分的暴露所引发的故障。

(2)将关键资源集中在预期的高需求领域。

(3)为预期故障和意外故障的恢复或恢复提供路径。

(4)建立早期检测系统性能的方法,以便能在生产环境中进行适当的伸缩或采用其他方法提高弹性。

13.人类有关复杂系统的专业知识在不断发生变化

复杂系统的运维和管理需要大量的专业知识。这些专业知识随着技术的变化而变化,也会因为专家的来去而变化。在任何情况下,技能和专业知识的培训都是系统功能的一部分。因此,在任何时候,一个给定的复杂系统都将包含具有不同程度专业知识的实践者和学员。与专业知识相关的关键问题来自:

(1)需要将稀缺的专门知识作为资源用于最困难或要求最高的生产需求

(2)需要开发专业知识以备将来使用。

14.系统演化会引入新的故障形式

在可靠的系统中,明显的事故发生率较低,这可能会鼓励人们做出改变,特别是使用新技术来减少低后果但高频率的故障数量。这些变化实际上可能为新的低频率但后果严重的故障创造机会。当新技术被用来消除众所周知的系统故障或者获得高精度性能时,它们往往会引入新的途径,导致大范围的灾难性的故障。这些新的罕见的灾难比新技术消除的灾难影响更大,这一点也不奇怪。这些新形式的故障在事故发生之前很难被看到,因为人们主要关注的是这些变化的假定有益特征。由于这些新事故发生率很低,事故发生前可能会发生多个系统更改,因此很难看出技术对故障的发生所带来的影响。

15.对“原因”的认知限制了防御未来事故的能力

事故后对“人为错误”的补救措施通常是基于可能“引起”事故的活动。这些末梢措施对降低进一步发生相同事故的可能性作用不大。事实上,发生相同事故的可能性已经非常低,因为潜在的故障模式在不断发生变化。事故后的补救措施通常会增加系统的耦合性和复杂性,而不是提高系统的安全性。这增加了潜在故障的潜在数量,也使得事故轨迹的检测和阻断变得更加困难。

16.安全性是系统的特征,而不是组件的特征

安全性是系统的属性,并不存在于一个组织或系统的个人、设备或部门当中。安全性是不能通过买卖或制造获得的,它不是与系统其它组件相分离的特性。这意味着安全不能像原料或原材料那样可以被操纵。任何系统的安全状态都是动态的,持续的系统变化确保了风险和风险管理也是不断变化的。

17.人们在不断地创造安全性

无故障运维是实践者将系统保持在可容忍性能范围内的活动的结果。这些活动在很大程度上是正常运维的一部分,表面上看很简单。但是,由于系统运维从来都不是无故障的,实践者对不断变化的条件的适应实际上是在创造安全性。这些适应性措施相当于从可用的响应库中选择一个精心排练的例程,但有时候也是新组合或新方法的重新创造。

18.无故障运维需要有处理故障的经验

识别危险并成功地运维系统,从而保证系统运行在可容忍性能的范围内,需要与故障进行密切的接触。在实践者能够识别“边界”的系统中,可能会出现更稳健的系统性能,这就是系统性能开始恶化、变得难以预测或无法轻易恢复的地方。在危险的系统中,实践者需要处理遇到的危险,从而获得理想的整体性能。安全性的提升取决于为实践者提供的危险校准准则,还依赖为实践者提供的如何将系统性能推向或远离“边界”的校准准则。


原文链接:

https://how.complexsystems.fail/

2021 年 2 月 03 日 15:421727
用户头像

发布了 124 篇内容, 共 40.5 次阅读, 收获喜欢 219 次。

关注

评论

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

【架构师训练营第 1 期 06 周】 作业

Bear

极客大学架构师训练营

架构师训练营 week2 课后练习

花果山

极客大学架构师训练营

架构师训练营第二周作业

张小胖

极客大学架构师训练营

WK1作业

Gavin_From_Mars

架构师训练营第六周总结

xs-geek

极客大学架构师训练营

第 5 周 作业

Pyr0man1ac

第二周总结

孤星

第二周作业

hunk

极客大学架构师训练营

【面经】面试官:如果让你设计一个高并发的消息中间件,你会怎么做?

冰河

面试 高并发 异步 限流 消息中间件

第二周课后练习

jizhi7

极客大学架构师训练营

依赖倒置原则

落朽

架构第六周作业

Geek_Gu

极客大学架构师训练营

第六周作业 (作业二)

Geek_83908e

极客大学架构师训练营

架构师训练营 第二周作业

阿光

架构师1期week05

FG佳

第二周作业总结

hunk

极客大学架构师训练营

第二周-总结

jizhi7

第二周总结

willson

架构师训练营week06

FG佳

架构师一期

第六周作业

Geek_ac4080

第二周作业

阿呆

架构师训练营 第二周学习总结

阿光

第 2 周 - 命题作业

willson

第 6 周 作业

Pyr0man1ac

架构师训练营第六周作业

CmHuang

架构师系列之3 接口分离原则

桃花原记

极客时间 - 架构师一期 - 第六周作业

_

极客大学架构师训练营 第六周作业

链表实现插入排序、机器学习Top 10 算法、图数据库实战Neptune、John 易筋 ARTS 打卡 Week 24

John(易筋)

学习 ARTS 打卡计划 链表实现插入排序 图数据库实战 Neptune

架构师训练营第二期 Week 2 总结

bigxiang

第 2 周 框架设计作业

心在那片海

第 2 周 框架设计总结

心在那片海

演讲经验交流会|ArchSummit 上海站

演讲经验交流会|ArchSummit 上海站

复杂系统是如何失败的?-InfoQ