软件质量稳定性之殇（一）

舞动的黑天鹅

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

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

一个黑天鹅事件，具有这三个特点：
（1）稀缺、通常史无前例（rarity），
（2）影响很极端（extreme impact），

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

在IT系统、社会事件尤其是金融市场，[黑天鹅事件]屡见不鲜。列举著名的黑天鹅事件如下：
在1933～1934年，经历过大萧条之后诞生的罗斯福新政，宣布私人持有黄金为非法，规定以每盎司20.67美元将私人黄金上收，然后由国会立法将黄金定价为每盎司35美元，美元很快贬值69%。

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

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

对于乌龙值的事故复盘，触发原因是系统缺陷。策略投资部使用的套利策略系统出现了问题。该策略投资部门系统完全独立于公司其他系统，甚至未置于公司风控系统监控下，因此深层次原因是多级风控体系都未发生作用。

向经验学习的局限性

弗朗西斯·培根就曾经发出这样的警告：当心被我们自己思想的丝线丝丝束缚。

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

蝴蝶效应

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

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

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

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

• 非预期error
• 非预期的调用抖动
• 极少数场景下的规则未被正确处理
• 错误的优惠处理逻辑
• 未正确设置的营销活动
• ……

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

墨菲定律

“墨菲定律”是一种心理学效应，是由爱德华·墨菲（Edward A. Murphy）提出的。
主要内容：
一、任何事都没有表面看起来那么简单；
二、所有的事都会比你预计的时间长；
三、会出错的事总会出错；

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

墨菲定律的原句是这样的：如果有两种或两种以上的方式去做某件事情，而其中一种选择方式将导致灾难，则必定有人会做出这种选择。

墨菲定律在生活中屡见不鲜。比如关键时刻掉链子（哪些驾考被教练最看好的精英们，往往会多补考2次），你出去买爆米花的时候，银幕上偏偏就出现了精彩镜头。

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

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

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

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

由于人类认识的局限性、骄傲心态、问题域的复杂性、不可把握性等因素，导致软件从业人员在处理软件质量稳定性方面如履薄冰，你今天志得意满，明天就可能伤心欲绝。那么软件质量问题的棘手主要有那些因素导致的呢，且看下一章节。

---

作者简介

于君泽，蚂蚁金服高级技术专家、支付核算技术部负责人、成都研发中心技术团队创建者之一，先后负责或参与过转账类业务、账单类业务、社区支付、开放平台、支付平台、资金核算平台、类营销类支付工具的建设；之前有数年电信业务研发经验，涉及BSS|OSS|针对性营销等平台。

推荐一下本文作者的公众号，一个认真、有内涵、但更新不太频繁的技术公众号：

TheoryPractice

作者同时也是中生代技术（微信公众号：freshmantechnology）发起人。