浅论金融软件的可靠性设计

1、浅论金融软件的可靠性设计笔者注：本文并不是说软件的正确性不重要，相反地，软件的正确性是软件可靠性的基础，只是因为 软件不可能达到100%的正确性的这样一个事实，所以软件正确性无法单独承担起软件可靠 性的历史重任，因而本文从简单的自控理论和系统论来探索软件的可靠性设计问题。在此抛 砖引玉，希望各位同事提出一些更切合实际的设计理念和设计方法，尤其是和我们公司软件 技术的实际结合起来这方面，众人拾柴火焰高，加大避免软件bug给我们ATM软件带来负 面影响的研究力度。引言软件的可靠性是和代码的正确性紧密相依的，代码的正确性诚然会带来软件的高可靠性，代 码的正确性最直接的体现就在于bug的数量。Bug数

2、量少是程序员锲而不舍的追求，也是软 件开发与软件管理的一项重要工作。大部分程序人员在追求代码的正确性上下了不少功夫。然而，无数的经验表明：bug是不可能完全杜绝的，也就是说正确性不可能达到100%。这 已经成为业界的事实。究其原因，就是现在软件开发本身并不是从零开始的特性决定的，任 何一个软件开发平台，由于环境的适应性、范围的许可性、技术的保密性、工程的不精确性、 技术理解的差异性等等各种复杂的因素，有客观的，也有人为的，决定了软件bug存在的客 观性。纵然软件不可避免有bug存在，但是软件还得开发，软件的使用在现阶段还是在大大促进社 会生产力的发展。这个社会对软件的依赖和软件存在bug，这两

3、个事实之间的矛盾，就有待 于解决。Bug是我们的心头大患，一个bug浮现出来，让我们程序员焦头烂额，用一个同事 的话来讲就是：吃啥啥都不香，程序员的生活质量陡然下降。真好像饭碗中的一粒老鼠屎。 更何况那些还没有浮现出来的，随时有可能冒出来的不可计数的其他bug，我们做金融软件 的程序员是不是时时刻刻睡在在一座随时可能爆发的火山口上呢。前车之鉴，后事之师，一 朝被蛇咬，十年怕井绳。阿门，祷告无门。软件的正确性追求无止境，软件的可靠性就不能单以软件的正确性来做为唯一保证，软件的 可靠性就必须还要借助其他技术和方法。如果学过自控专业，对自动控制流程设计中的系统误差补偿控制、反馈控制、噪声控制、信 号

4、放大控制等设计方法比较熟悉。这些方法论可以借用来进行软件的可靠性设计。1自控系统和软件系统的可靠性设计系统可靠性是指从它可是运行(t=0)到某时刻t这段时间内能正常运行的概率，用R(t)表示。 所谓失效率，是指单位时间内失效的原件数与元件总数的比例，用入表示，当入为常数时，可靠性与失效率的关系为R(t)=eA(-Xt)计算机的RAS技术就是指用可靠性R、可用性A和可维护性S三个指标衡量一个计算机系统。自控系统是由若干部件(子系统、元器件)相互有机地组合起来，可以完成某种工作任务的 具有一定输入、输出特性的整体。系统 *分系统子系统：设备 d 部件系统的可靠度决定于两个因素:单元本身的可靠度；各

5、个单元的组合方式。串联系统：各单元之间的失效时间随机变量互为独立时，如果有某一单元发生故障，则引起 系统失效的系统。信号输入处理单元nA结果输出设系统各个子系统的可靠性分别用彘,，氏表示，则系统的可靠性R =*如果系统的各个子系统的失效率分别用 起女来表示，则系统的失效率=如+冬+ +&。系统越多可靠性越差，失效 率越大。对于软件来说，该流程完全吻合软件的执行情况，流程式处理。由于某一元器件失效而不致使系统发生故障，只有当系统中贮备元器件全部发生失效的情况 下，系统才发生故障，这样的系统就称为“工作贮备系统”。并联系统属于工作贮备系统的 一种。贮备系统分为：工作贮备系统和非工作贮备系统纯并联系

6、统，即多个单元完成同一任务的组合。所有单元同时工作，弹其中任何一个单 元都能单独支撑整个系统的运行，只要系统中不是全部单元都失效，系统就可以正常运行。则系统的可靠性衣=1 _（1 _艮）x（l彪）乂乂（1肉）结果输出别用表示，假如所有子系统的失效率均为1,则系统的失效率为m：在并联系统中只有一个子系统是真正需要的，其余n-1个子系统都被称为冗余子系统。 该系统随着冗余子系统数量的增加，其平均无故障时间也会增加。串联就是一个有问题就会瘫痪，并联只要有一个能用就没有问题。对于软件来说，并联系统可以用于容错。假设处理单元1有N1个bug，处理单元2有N2个bug，处理单元n有Nn个bug，就整个软件

7、系统来说，不采用冗余设计只有N1个bug （假设处理单元1作为选用模块）； 采用冗余设计，其bug总数为N1+N2+.+Nn。可见bug数目增加了。然而，对于整个软件系统的可靠性计算，假设处理单元1至n异常概率均为0.001，不采用 冗余设计的软件系统的可靠性为0.999，采用三模冗余设计的可靠性性为，则软件系统的可靠性为1-0.0013=0.999999999，得到了 大大提升。可见追求代码越少，虽然软件bug数目会减少，但是软件的可靠性却仍然是个大问题。 设计了冗余模块，虽然bug数目增加了，但是软件的可靠性大大提升。一个软件模块的运行速度对于整个系统的性能几乎没什么影响，尤其是对于非实时

8、系统来 说，除非该软件模块中有大循环事物处理。工作储备系统：r/n表决系统，即要求n个单元组成的并联系统中，至少有r个单元同时正结果输出对于软件来说，工作储备系统采用或表决器可以用于容错，采用与表决器可以提高检错。处理单元1至n实现了相同的功能，比方ATMC的8583报文打包或者8583报文解包。如果 n个程序员编写的n打包函数得到的结果相等，则认为结果正确。显而易见可以更容易发现 某一个程序员编写的bug错误。并且该错误只要其他模块中有一个不出现，该bug就不会给 我们的ATM带来致命的影响，提高了软件运行的正确性，实现了软件的多重保险。对于容错性，采用或表决器，可以进行同样的分析，效果比起

9、没有冗余的系统，有一个较大 的改观。非工作储备系统：系统中某一个或多个处于工作状态，其它单元处于待命状态，当某一单元 出现故障后，处于待命状态的单元通过转换开关将其投入工作状态的系统。理想旁联系统：转换开关为理想开关，可靠度为100%。非理想旁联系统：转换开关为非理想开关。开关对于软件来说，非工作储备系统一般用于软件异常的处理，或者容错的处理。基本可靠性：产品在规定条件下无故障的持续时间和概率。基本可靠性模型是用来估计产品 及组成元件引起的维修及保障要求。它是一个串联模型，即使存在冗余单元，也按串联处理。 系统中任一单元发生故障都需要维修或更换。储备元件越多，系统的基本可靠性越低。任务可靠性：

10、产品在规定的任务剖面内，完成规定功能的能力。任务可靠性模型是用以估计 产品在执行任务过程中规定功能的概率，描述完成任务过程中产品各单元的预定作用，用以 度量工作有效性的模型。储备元件越多，系统的任务可靠性越高。软件追求的一般都是任务可靠性。只要良好的软件冗余设计，就是一质量不是很高的代码， 堆砌起来的软件的可靠性仍然会理想，不亚于一堆质量很高的代码的可靠性效果。当然，代码质量就是我们程序员的从业品牌，是我们的职业追求，是我们的技术境界。锲而 不舍的追求高质量代码，是我们软件维护过程中的基本素质和素养。代码质量的追去无止境， 当时间和投入不允许时，采用冗余设计，是一个不错的方法。至少可以实现我们

11、软件的双保 险，或者多保险。但是，对于我们程序员，必须要具备追求基本可靠性的职业精神和操守。2自助设备软件的可靠性设计对于非现金模块，如安全性设计，易操作性设计等，采用非冗余设计方法。对于关系到现金数量的模块，采用冗余设计方法，有利于提高性价比。对于与第三方软件通信的数据内容，采用双保险机制。对于目前故障最多的软件函数，或者软件模块，采用表决器方式，有利于降低bug带来的负 面影响和几率。比方送钞到出钞口之前，是否比较一下用户输入金额、账面扣除金额、机芯出钞金额这几个 数字是否一致呢。比方取款的同时是否附加上查业务，这样就可以ATMC就可以清晰的知道账面变动情况，更 何况几乎每一个用户在取款之前和取款之后都会在帐户余额进行查询，为了节省网络资源， 提高正确率，取款业务附加上查询业务，并且在每次取款完毕后清晰的向用户显示账面数字 的变化呢。（透露一个小秘密，我们准备在此点上设计一软件专利方案。）比方8583报文在封装之后，是否ATMC试着解包看看8583打包是否正确呢对于8583报文中没用的字段