由高铁故障谈软件缺陷管理和危机应对

1.引言

         2021年的五一假期，是一个不平凡的假期；由于疫情，好多人都没有出行；2021年的五一，北京西站迎来了大规模的人流。然而，不幸的是，在北京西站候车的人发现，北京西站发生了大规模高铁延误，很多人怎么也进不了北京西站。最后，人们发现：由于一块地膜导致高铁通信故障，从而导致高铁大规模晚点。

        由此可见，一个重要系统的故障，会引起重大危机。笔者本职工作是软件开发，并长期从事软件项目管理工作，想趁机谈一谈软件缺陷管理和危机应对。

2.软件缺陷管理

2.1 系统论、风险和脆弱性

        系统论的基本思想方法，就是把所研究和处理的对象，当作一个系统，分析系统的结构和功能，研究系统、要素、环境三者的相互关系和变动的规律性，并优化系统观点看问题，世界上任何事物都可以看成是一个系统，系统是普遍存在的。大至渺茫的宇宙，小至微观的原子，一粒种子、一群蜜蜂、一台机器、一个工厂、一个学会团体、……都是系统，整个世界就是系统的集合。

       系统论的思想古已有之。但真正形成科学，应该是从美籍奥地利人、理论生物学家L.V.贝塔朗菲（L.Von.Bertalanffy）开始。系统论的任务，不仅在于认识系统的特点和规律，更重要地还在于利用这些特点和规律去控制、管理、改造或创造一系统，使它的存在与发展合乎人的目的需要。也就是说，研究系统的目的在于调整系统结构，各要素关系，使系统达到优化目标。

       风险是指在某一特定环境下，在某一特定时间段内，某种损失发生的可能性。风险是由风险因素、风险事故和风险损失等要素组成。换句话说，是在某一个特定时间段里，人们所期望达到的目标与实际出现的结果之间产生的距离称之为风险。风险有两种定义：一种定义强调了风险表现为不确定性；而另一种定义则强调风险表现为损失的不确定性。 风险具有普遍性、客观性、损失性、不确定性和社会性。在对风险的管理中，让不确定性更可控，避免损失或让损失可控，是一个很重要的事情。

       另一个重要的概念是“脆弱性”。脆弱性概念最早起源于自然灾害领域, 20世纪70年代以后, 脆弱性研究开始延伸至生态系统、社会科学、地学与可持续科学领域等[1-3], 特别是20世纪90年代后期, 资源枯竭和环境恶化情况愈演愈重, 脆弱性评价在区域规划、可持续发展以及全球环境现状和发展趋势等研究领域越来越重要.最初自然系统脆弱性定义与“风险”概念相似, 是指系统暴露于不利影响或遭受损害的可能性[22-23]。随着脆弱性研究渗透到社会经济领域, 脆弱性概念加入人文驱动因素[24]。目前, 脆弱性内涵包含四层含义[19, 25]：①脆弱性表现为系统内部和外部的共同影响, 系统内部和外部要素之间存在相互作用；②研究脆弱性应针对特定类型的扰动, 不同扰动情况下, 系统表现出不同的脆弱性；③脆弱性表明系统内部的不稳定性, 在遭受扰动时会造成损失和伤害, 且具有不可恢复性[26]；④系统对外界干扰和影响比较敏感。国内外比较权威的是IPCC(2001)报告中的脆弱性定义, “系统易受或没有能力应对气候变化的扰动, 包括变率和极端事件而产生不利影响的程度, 是气候变异特征、变化幅度和速率以及系统敏感性和适应能力的函数”。

       由以上观点出发，整个工程管理可以定义为：基于系统论观念，对工程进行风险管理和管控，避免脆弱性问题的综合管理行为。当然，软件工程会侧重在软件身上。

2.2 关键事件和重大事件

       在项目进度管理中，关键事件是指最慢的事件。但在项目危机管理（风险管理中），关键事件是指具有决定项目成败的事件。在项目中，关键事件通常不仅仅有一件，而且，随着时间和条件变化，关键事件会不断变化。

      重大事件是指，在整个项目中，会对整体产生重大影响的事件。重大事件的判断具有一定主观性，并随时间和条件变化而变化。同时，重大事件对未来发展具有重要影响。

      在进行缺陷管理的时候，应该首先区分关键事件和重大事件，并进行记录和登记。

2.3 软件缺陷的等级和应对 

       软件缺陷，又叫软件Bug，Bug级别定义如下：
1）    一级Bug：致命错误，必须修改。错误一般包括：
（1）常规操作引起的系统崩溃、死机、死循；
（2）造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露；
（3）涉及金钱类的交易，如支付货币，货币计算错误
2）    二级Bug：严重错误。主要类型为：
（1）重要功能不能实现（例如：悦和软件无法实现报事保修功能）；
（2）错误的波及面广，影响到其他重要功能正常实现；
（3）非常规操作导致的程序崩溃、死机、死循环 (非常规操作：用户使用软件时不会进行的操作）；
（4）外观难以接受的缺陷（例如：报事图片完全无法显示）；
（5）密码明文显示。
3）    三级Bug：一般错误。不影响产品的功能，目前不会造成故障，但对产品的外观和下道工序影响较大的错误和缺陷。主要类型有：
（1）次要功能不能正常实现；
（2）操作界面错误（包括数据窗口内列名的定义，含义不一致）；例如：列名与列名下的内容不一致；
（3）查询错误、数据错误显示；
（4）简单的输入限制未放在前端进行控制；（格式显示，如登录和注册中的格式判断可由前端判断）；
（5）删除操作未给出提示。
4）    四级Bug：细微错误，程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误。主要类型有：
（1）界面不规范；
（2）辅助说明描述不清楚；
（3）提示窗口文字未采用行业术语；
（4）界面存在文字错误；
（5）改进意见：可以提高产品质量的建议， 包括新需求和对需求的改进。
Bug处理优先级定义如下：
（1）Immediate：即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。
（2）Urgent：即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。
（3）High：即“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。
（4）Normal：即“正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。
（5）Low：即“低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。
Bug级别和Bug处理优先级对应关系如下：

Bug级别	优先级
一级Bug	Immediate
二级Bug	Urgent/ High
三级Bug	High/ Norma
四级Bug	Normal/ Low

3.软件缺陷应对

        软件缺陷的应对包括两方面：刚性应对和柔性应对。刚性应对主要包括管理措施，柔性应对主要是人方面的努力。

3.1 刚性应对：管理措施

      刚性应对的管理措施主要为：

     1）功能测试，包括多轮测试；

     2）主动异常测试：应对基本的异常情况；

    3）极限测试，包括各种有可能的极端情况下的测试；

    4）面对紧急情况，紧急应对，并确立各种预案和应对方案。

3.1.1 功能测试：多轮测试

       形式上，应该进行多轮测试，注意，功能应该覆盖完全，确保可以实现正确的流程；但与此同时，应该确定错误，并不断保证缺陷尽可能少。

3.1.2 主动异常测试

      应该主动进行异常功能或异常值测试，确保软件系统可以应对各种异常情况。
3.1.3 极限测试

      对网络访问压力、系统最大限制压力等各种极端情况，进行极限测试。极限测试不一定要确定最后系统可以完成极限测试，但一定要摸清楚自己系统可以承受的极限，以及整个系统遇到极限压力的时候的恢复情况。

3.1.4 紧急情况预案和方案

        应该有应对紧急情况的预案和方案。预案和方案应该包括如下：

        1）数据安全预案和方案，包括数据库的备份，以及应急数据库；

        2）网络访问预案和方案，包括如何应对访问压力，以及均衡方案；

        3）应急小组责任人方案：确定应急小组的责任人，以及权力责任。 

3.2 柔性应对：人方面的努力

        始终应该记住，危机管理和缺陷管理，除了把事情做正确，还需要把人做正确。有些危机，确实是完全在已知范围之外。但即使发生了不可控事件，也应该积极应对。作为缺陷管理和危机应对的责任人，不应该推诿，不应该找“背锅侠”，而要诚恳应对，合理并如实向上司、客户和其他相关方确定问题的原因和损失情况，并在最短时间和最小损失的情况下，让缺陷最小化，危机最小化。同时，应该注意对上司、客户以及其他相关方的情绪引导。（PS：我觉得目前的高铁故障追因，有点避重就轻，推诿扯皮，这不是一次好的缺陷管理和危机应对的好方法）

4.总结

         缺陷始终存在，风险不可避免，脆弱性伴随着系统终身，危机始终会有。用制度来应对，同时，进行柔性管理，才是王道。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　2021年05月06日