软件系统的稳定性，高悬于空中的达摩克利斯之剑(上)

公众号后台回复：管理，免费下载本月推荐精品管理类图书

公众号后台回复：人文历史，免费下载本月推荐精品人文历史类图书

【导读】当今企业所面临的IT环境越来越复杂, 线上业务创新和业务开发的快速迭代已经成为企业保持增长的主要推动力量。随着业务发展的深入，企业的IT系统也日益复杂。系统中尤其是软件应用系统之间错综的关联关系，使得软件系统的稳定性越来越差，IT管理和运维人员面对复杂运维体系带来的新问题尤为重视。

用户日常中经常遇到应用系统速度慢、服务资源调配难于管理，系统资源服务中断等问题，在庞大的体系中无法快速准确地定位问题根源，让企业数据中心的管理和维护面临前所未有的挑战。AIops的出现和运用，帮助软件系统解决悬于稳定性头上的达摩克利斯之剑。

01 

云系统要求：

软件稳定性达到99.95%，数据稳定性达到99.99%

稳定性是评价软件质量的一个重要目标。

下图是典型的软件招标中的评分标准：

我一直十分好奇，这个标准怎么评价呢？唯一的可能性就是自说自话了。

我说我的软件稳定就是稳定了，反正你也无法证伪。

但是，这不科学啊！

科学是一个不断证伪的过程，但招标又无法有足够的时间来证伪。

前段时间，去ZF的一个系统作信息采集，经历的事情就让人十分的尴尬。北京是一个著名的堵城，早上6点起床，历经2个多小时的游历车河后，终于赶到采集点，一看，天哪，怎么这么长的队伍。罢了，排队吧。可排了半个多小时，只是完成了一个单位的采集。怎么这么慢呢，上去一问才知道，系统总是上传不了数据，采集一个人要反复好多次。行，那就慢慢的排队吧。可是怪事出来了，这之后就再没有一家单位完成采集了。然后，所有人被告知，今天可能无法采集了，系统不工作了。

想骂娘，不敢！这是管你的婆婆单位啊。另外，人家的态度十分的好，你愿意继续尝试采集，人家义无反顾、毫无怨言的帮你持续的尝试。但是，没有结果啊，基本上是百试百败！于是只好继续悻悻然的开车游车河打道回府。

第二天再去，依然如故！

这成了一个运气的活了，运气好一次成功；运气不好，来回折腾！

当时就想，这是国家的一个某金工程，怎么会这样呢？去网上查了承建单位的软件系统，发现他们对自己软件的宣传是稳定性、可靠性等都是很好的。

我不死心，很好的稳定性，怎么个好法，为什么我的现场感受是很不好呢？

我过去做IT基础设施的，一般我们单个服务器、或路由器、或防火墙等标称的稳定性至少是四个9，也就是99.99%以上，甚至是五个9的，所以整个系统的稳定性好像怎么也大于0.9999n。比如系统由10个单元组成，那么系统的稳定性就是0.999910=0.999，也就是99.9%的稳定性，实际上，我多年的体会是系统的稳定性在这样一个10单元的系统中是很低的。

软件系统就更加的不稳定了！

软件系统的稳定性涉及的内容很多，它其实比我们熟悉的服务器、路由器等硬件的要求高的多，除了软件本身，硬件、网络、运营商等都需要考虑。

比如云系统，他的稳定性一般有两个十分重要的要求：

1、软件的稳定性

2、数据的稳定性

通常，云系统要求：软件稳定性达到99.95%，数据稳定性达到99.99%。

过去做IT系统的人看到这个指标觉得好像要求不高。其实仔细算算，这些要求其实都不低。

例如，按照我的这次碰到信息采集系统案例来说，我等了一周，一周后，采集系统稳定了，我也顺利的完成了采集。那么这套系统的稳定性是多少？最多也就是90%了。

90%？这是什么概念？

02

软件系统稳定性除了测试，

还有什么可以证伪？

90%稳定性：如果一个软件稳定性是90%，那么意味着这个软件一年中有5个星期是不能用的，这种质量基本当然是不能接受的。

99%稳定性：99%的稳定性，说明软件在一年中最多只有3、4天无法运行。

注意了，3、4天，不是3、4个工作日，如果软件在晚上、周末、节假日发生故障，那么3、4天几乎是转眼即逝的效果。所以，99%的稳定性也不是所有的公司的软件都能达到的。

99.9%稳定性：说明一年365天当中，允许软件失败的时间总长只有8个多小时。

对于很多公司来说，8个小时都不够晚上升级软件使用的，因此99.9%对于他们来说几乎是不可能完成的任务。

要想达到这种稳定性，除了冗余设计之外，自动检测和自动切换系统也是必要的，否则要想做到99.9%的稳定性几乎是不可能的。

99.99%稳定性：四个9的稳定性，就真的很难了，它意味着一年只允许50多分钟失败。

上次百度移动搜索失败，一下子无法服务几十分钟，所以我们大概可以判断百度的软件稳定性应该是低于4个9的，要知道这只是一次失败的累积时间。

99.999% 和99.9999%稳定性：这种稳定性我没有见到过。五个9意味着失效时间是5、6分钟，而6个9则是几十秒。

要做到这一点，除了软件本身，要做的太多了，包括：

软件设计、系统软件设计、数据库设计、监控设计、硬件冗余设计、电源设计、数据备份设计、网络设计、自动切换设计、跨区域冗余设计、冷却系统设计、备用电源设计......

大概只有军工才会不计成本地做到这一点。

但是，能不能做到，是一个问题！

研究到这里，我其实也明白了，为什么我们做基础设施硬件的时候，一直都在强调我们系统的热备份、自动迁移、自动切换、冗余设计、自动监测、自动告警、老化测试、压力测试等等环节了，这都是系统稳定性的基本保障啊。

至此，其实应该比较容易判断了。在招标时无法证伪的过程中，要判断软件系统的稳定性也是有招可使的。比如：软件系统的测试环境、备份环境、冗余设计、对运行环境的兼容性设计、数据安全策略等等，从这些方面可以对稳定性有一个基本的比较。

看了上面这些，大家可以自己想一下，那些号称很稳定的软件公司是不是真正做到这一点了呢？很多我熟悉的软件公司，其内部连一个可靠的测试环境都没有，它号称的稳定性你基本就可以认为是忽悠了！

比如，我在论坛中经常可以看到这样的对话，这类软件你觉得他的稳定性能达到多少个9呢？

03

今天还志得意满

明天就伤心欲绝

从上图可以看到，如此著名的企业也难以避免系统不稳定带来的噩梦。我们再来分析一下几个案例。

案例一：看似无关紧要的代码片段可能会带来整体软件系统的崩溃

《Release It!》一书中,作者给出了如下的Java代码片段:

package com.example.cf.flightsearch; //... public class FlightSearch implements SessionBean { private MonitoredDataSource connectionPool; public List lookupByCity(. . .) throws SQLException, RemoteException { Connection conn = null; Statement stmt = null; try { conn = connectionPool.getConnection(); stmt = conn.createStatement(); // Do the lookup logic // return a list of results } finally { if (stmt != null) { stmt.close(); } if (conn != null) { conn.close(); } } }}

正是这一小段代码，是造成Airline系统崩溃的罪魁祸首。

程序员充分地考虑了资源的释放，但在这段代码中他却没有对多个资源的释放给予足够的重视，而是以释放单资源的做法去处理多资源。在finally语句块中，如果释放Statement资源的操作失败了，就可能抛出异常,因为在finally中并没有捕获这种异常，就会导致后面的conn.close()语句没有执行，从而导致Connection资源未能及时释放。最终导致连接池中存放了大量未能及时释放的Connection资源，却不能得到使用,直到连接池满。当后续请求lookupByCity()时，就会在调用connectionPool.getConnection()方法时被阻塞。这些被阻塞的请求会越来越多，最后导致资源耗尽,整个系统崩溃。

软件系统的稳定性，主要决定于整体的系统架构设计，然而也不可忽略编程的细节，一旦考虑不周，看似无关紧要的代码片段可能会带来整体软件系统的崩溃。

案例二：不知道的事比知道的事更有意义

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

媒体将此次事件称为“光大证券乌龙指事件”。

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

弗朗西斯·培根就曾经发出这样的警告：当心被我们自己思想的丝线丝丝束缚。无论是“光大证券乌龙指事件，还是泰坦尼克的沉没，如果业态没有类似的案例，其学习的参考是脆弱的，无从学起。即使有业界案例，不同组织，不同公司未必拥有相应的处置经验，那么其实“自己的思想”，“自己的经验”也是非常有局限性的。

我们把自己知道的东西太当回事了，而不知道的事比知道的事更有意义。只有反常地思考一切，才有可能发现更多“不知道的事”。

对复杂系统而言，对于非预期的事或者不太知道的事很多，比如：

• 非预期error

• 非预期的调用抖动

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

• 错误的优惠处理逻辑

• 未正确设置的营销活动

• ……

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

案例三：会出错的事总会出错

墨菲定律告诉我们：

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

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

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

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

举个例子，前公司有一个非常古老的系统，一直活得好好的。但是由于RPC调用中有重试机制，在网络异常的情况可能下会被触发。而该系统对于重复请求的机制处理不是很好，导致如果重复了，就需要一个处理机制。而该系统的处理机制在95%的情况下是有效的，而网络重发的概率经过经验测算是一亿分之一。

看起来论据很充分了，真心是小概率事件。

但是随着业务的发展，以及某些未预期的因素（比如某应用超时的几率）增大，则重发的概率也将增大，导致后来这样的问题连续几周都出现了，最后，不得不下决心从根本上解决这个问题。

04

高悬于空中的

达摩克利斯之剑

黑天鹅告诉我们要走出经验主义，不要把自己知道的东西太当回事了，而不知道的事比知道的事更有意义。

蝴蝶效应告诉我们要及时感知问题，止损和熔断，避免问题范围扩大包括传染到其它相关领域。

墨菲定律告诉我们，你知道的但是忽略的漏掉的终会出问题！

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

       从程序猿来讲：

一方面是程序员对代码质量的追求不够，在项目进度的压力下，只考虑了功能实现，而不用过多的追求质量属性；

另一方面是对编程语言的正确编码方式不够了解，不知如何有效而正确的编码；

再则是知识量的不足，在编程时没有意识到实现会对哪些因素造成影响。

       从业务本身来讲：

1、业务高速发展带来的变化导致“飞机飞行中换引擎”

软件平台随业务能力发展在不断发展，为了实现业务价值是软件的天职，于是就有了“飞机飞行中换引擎”这样的事情。满足需求为先，新特性也好只能在业务发展的过程中摸着石头过河了，边运行边做。

可能的状态是：从分析到设计阶段的缺失，到代码、测试、发布这些阶段都一如既往的缺失了；有些系统已经复杂到只有个别人才能搞懂其中的部分了，系统拆分和治理也成了麻烦事。

2、技术债问题

技术债务是指当我们有意或无意地做了错误的或不理想的技术决策所累积的债务。它和金融债务非常相似。如能定期还款，那么所积累的债务是可接受的，也不会产生进一步的问题。但是，如果不还款，利息就是一种惩罚，并随着不还款次数的增加而迅速增加。长期不能支付任何款项的话，利息会使得债务更难以偿还。极端情况下，不得不宣布自己破产。

经常采用简单粗暴的“临时方案”是我们快速承接的交付手段。“临时方案”的毛病不在于几个月被临时了，而在于临时上线之后，就再无人管了。一年如果做几个临时方案，就等于欠了几笔债务。欠债并不可怕，怕的是没有偿还计划，或者借口没有时间，或者借口等业务不那么高速发展的时候。

诡异的是：优良的业务一定是永远都没有时间的，而低劣的业务确实也不用发展了。所以，如果高速发展的业务，不能及时更换临时方案去偿还债务，那么，欠的债迟早要还的。

3、人、流程、文档的博弈

面对复杂的问题域，人类有简单化思考的倾向。存在3年以上的产品，当新人来到的时候，他们总会问：某某产品为什么采取这样的技术啊；进入慢、一点文档都没有；只能看代码，代码写得还不咋的。当新人成了老人，他们对更新的新人解答的时候，会说：“我们当年更惨，只有看代码是靠谱的。对了，某某是非常了解某一块的，有问题找他，比看文档有用。”

写多少文档，如何维护一直是一个大问题。

4、采用新工具、新语言、新开源产品

技术人员都喜欢采用新的工具和语言等。随着业务一直的变化，就形成了一种技术混乱......

5、组织架构、业务架构和技术架构息息相关

服务梳理这块主要靠科技，业务参与程度太低，业务部门只管各自的一亩三分地...

6、复杂的问题域

可用性的诉求随业务的发展也越来越高。从曾经的单机房部署、演变成同城异机房、又发展到异地机房。于是路由复杂度就增加了，在开发环境、线下测试环境要模拟几种部署的情况也越来越复杂。

6、质量意识

超过70%的故障都是人为引起的，其本质是未遵循规定动作。比如修改几行代码、升级了某个系统等等。似乎这些日常的简单操作，咋看都不会出错。

但是，IT运维实践证明一个问题被遗留到线上，往往有3个以上的质量防线措施会失守了。

7、侥幸心理，忽视风险意识

随着运行经历的增加，许多风险程序显得啰嗦、许多检查显得多余、常规检测又是那么麻烦，以至于越运行相关风险程序越少、越简化，且不把规章当回事......

小结：这些问题就是达摩克利斯之剑，它高悬于空中。你不注意它，它就会在某一天，在你毫无预备的情况下降落。

（未完待续）

注意啦，现在

IT圈最有料的“ICT销售和大客户联盟”（微信ID：ICT-League）

绝对让你站在IT鄙视链的顶端

分享是一种美德，转载请注明来源和出处！