从黑天鹅事件到墨菲定律

摘要：软件系统的稳定性，主要决定于整体的系统架构设计，然而也不可忽略编程的细节，正所谓“千里之堤，溃于蚁穴”，一旦考虑不周，看似无关紧要的代码片段可能会带来整体软件系统的崩溃。本文我将和大家聊一聊软件质量稳定性之殇，分多篇刊发。

1

舞动的黑天鹅

纳西姆·尼古拉斯·塔勒布(Nassim Nicholas Taleb)写了两部超级畅销书《随机致富的傻瓜》和《黑天鹅》，并且被誉为[黑天鹅之父]。何为黑天鹅？

在发现澳大利亚之前，17世纪之前的欧洲人认为天鹅都是白色的。但随着第一只黑天鹅的出现，这个不可动摇的信念崩溃了。黑天鹅的存在寓意着不可预测的重大稀有事件，它在意料之外并且后果非常严重。

一个黑天鹅事件，具有这三个特点：

（1）稀缺、通常史无前例（rarity），

（2）影响很极端（extreme impact），（3）虽然它具有意外性，但人的本性促使我们在事后为它的发生编造理由，并且或多或少认为它是可解释和可预测的。

在IT系统、社会事件尤其是金融市场，[黑天鹅事件]屡见不鲜。列举著名的黑天鹅事件如下：

2001年9月11日上午，美国人刚准备开始一天的工作，恐怖分子劫持了四架飞机撞向美国纽约世贸中心与华盛顿五角大楼。3000多人在这次黑天鹅事件中丧生，美国的经济此后一度处于瘫痪状态，巨大的经济损失无法用数字来统计。

2013年8月16日11点05分上证指数出现大幅拉升大盘一分钟内涨超5%。最高涨幅5.62%，指数最高报2198.85点，盘中逼近2200点。11点44分上交所称系统运行正常。下午2点，光大证券公告称策略投资部门自营业务在使用其独立的套利系统时出现问题。有媒体将此次事件称为“光大证券乌龙指事件”。

向经验学习的局限性

弗朗西斯·培根就曾经发出这样的警告：当心被我们自己思想的丝线丝丝束缚。无论是“光大证券乌龙指事件，还是泰坦尼克的沉没，如果业态没有类似的案例，其学习的参考是脆弱的，无从学起。即使有业界案例，不同组织，不同公司未必拥有相应的处置经验，那么其实[自己的思想]，[自己的经验]也是非常有局限性的。我们把自己知道的东西太当回事了警醒地指出：我们把自己知道的东西太当回事了，而不知道的事比知道的事更有意义。只有反常地思考一切，才有可能发现更多“不知道的事”。

2

蝴蝶效应

上个世纪70年代，美国一个名叫洛伦兹的气象学家在解释空气系统理论时说，亚马逊雨林一只蝴蝶翅膀偶尔振动，也许两周后就会引起美国得克萨斯州的一场龙卷风。蝴蝶效应的意思是初始条件十分微小的变化经过不断放大，对未来状态也许会造成极其巨大的影响。

我们来读一则吕氏春秋，大抵也有这样的例子。[楚之边邑曰卑梁，其处女与吴之边邑处女桑于境上，戏而伤卑梁之处女。卑梁人操其伤子以让吴人，吴人应之不恭，怒，杀而去之。吴人往报之，尽屠其家。卑梁公怒，曰：“吴人焉敢攻吾邑？”举兵反攻之，老弱尽杀之矣。吴王夷昧闻之，怒，使人举兵侵楚之边邑，克夷而后去之。吴、楚以此大隆。（《吕氏春秋·察微》）]

吕氏春秋里面说个姑娘因游戏起冲突而引发了2个国之间的持续战争，比较形象的放大这样一个道理：如不能见微知著，则其后果无法预知。

对IT系统而言，对于非预期的错误比如：

• 非预期error

• 非预期的调用抖动

• 极少数场景下的规则未被正确处理

• 错误的优惠处理逻辑

• 未正确设置的营销活动

• ……

如果不具备快速、智能的感知能力，那么可能影响的用户变多、影响的商户增加、资金损失增加、业务不可用时间变长…..

3

墨菲定律

“墨菲定律”是一种心理学效应，是由爱德华·墨菲（Edward A. Murphy）提出的。

主要观点：

1. 任何事都没有表面看起来那么简单；

2. 所有的事都会比你预计的时间长；

3. 会出错的事总会出错；

4. 如果你担心某种情况发生，那么它就更有可能发生。

墨菲定律在生活中屡见不鲜。比如关键时刻掉链子（那些驾考被教练最看好的精英们，往往会多补考2次！！！），你出去买爆米花的时候，银幕上偏偏就出现了精彩镜头，所以评论一部电影如何精彩往往会用一个词：无尿点！

对于IT系统而言，墨菲定律的例子太多了。

小明在做系统迁移，历时半年。小明是一位经验丰富的架构师，他对系统迁移过程中的自校验、核对、切流策略、灰度能力、回滚机制、容错处理都进行了充分的考虑。但是对于老系统的一种流程处理的缺陷未充分考虑备案或者处理方案。想想，半年很快就过去了，去年才发生1起这样的特殊规则，我在新系统上完全规避了这个问题…但是不凑巧，这个特殊规则不约而至，而老系统还未迁移完…

再说一个例子，前公司有一个非常古老的系统，一直活得好好的。但是由于RPC调用中有重试机制，在网络异常的情况可能下会被触发。而该系统对于重复请求的机制处理不是很好，导致如果重复了，就需要一个处理机制。而该系统的处理机制在95%的情况下是有效的，而网络重发的概率经过经验测算是一亿分之一。看起来论据很充分了，真心是小概率事件。但是随着业务的发展，以及某些未预期的因素（比如某应用超时的几率）增大，则重发的概率也将增大，导致后来这样的问题连续几周都出现了，我们不得不下决心从根本上解决这个问题。

第三个例子，是我们团队的一个亲身经历。某一天有客户投诉，按理说对于该问题的处理预案是有的，并且团队有充分的备份机制，好几个人都可以解决。But我们并未按预期的速度处理好这个问题。原因是团队的一位同学大婚，大家都去迎亲去了，TL同学只能临时把车停到路边，处理问题。

软件质量的保障不仅仅是正确的做事[习惯、流程、制度、质量保障体系]，做正确的事也非常重要！一场不得不推的完全免费的技术峰会，大数据云计算都有，ALISQL内核技术亦会披露，且看下面

首届阿里巴巴在线技术峰会

 7月19日-7月21日 

 每日 20:00-21:30 ，线上共聚首

关于峰会

首届阿里巴巴在线技术峰会，9位大V集体在线，传道解惑，互动答疑！

• Blink计算引擎— 蒋晓伟（阿里资深搜索专家）

• 云上应用Docker化持续交付与微服务实践—易立（阿里云资深专家）

• 电商互动营销的技术实现—郑恩阳（天猫高级技术专家）

• 基于大数据的全球电商系统架构性能优化—郭东白（阿里巴巴速卖通技术总监）

• 云数据库十大经典案例总结和反思—罗龙九（阿里云资深DBA专家）

• 基于Java容器的多应用部署技术实践—魏鹏（阿里中间件技术专家）

• 阿里聚安全在互联网业务中的创新实践—方超（阿里安全高级专家）

• 企业大数据平台仓库架构建设思路—李金波（阿里云高级技术专家）

• AliSQL性能优化与功能突破的演进之路—何登成（阿里高级数据库专家）

参与峰会，立即报名，请扫描二维码

（点击“阅读原文”亦可以进入峰会报名），并将信息分享给更多伙伴。