“飞走的风挡”与BOSS面临的风险

BOSS系统是中国移动的业务运营与支撑系统（Business & Operation Support System）的简称，随着业务的发展和自身的演进，形成了复杂的涉及公司各种运营活动的庞大系统，完成包括客户受理、服务开通/控制、服务使用计费、漫游清算、财务支撑、全网服务等在内的各种功能，并由相关的专业团队负责系统的日常运维工作。BOSS系统支撑着近千个对内对外业务接口，包含百万计的业务规则和千万级的局数据条目，每天需完成数百万次业务交易，每月有近百亿的用户话单的处理。整个系统由几百台高性能小型机、网络设备、存储设备构成。这个复杂、庞大的系统的任何细节出现问题，都会引起严重的运行事故，成千上万的客户因此而投诉并导致满意度下降，给企业带来大量直接或间接的损失。

BOSS系统的风险跟一架客机有什么关系？

飞走的风挡
这是一个不可思议的真实的空难事故：
1990年6月10日，一架机型为BAC-111从英国伯明翰飞往西班牙马拉加的英航5390号班机，载着81名乘客以及6名机组人员，当飞机爬升至17,300呎高度时，突然，位于驾驶室左方正机长位置的挡风玻璃脱落，驾驶室发出巨响，机身立即在高空失压，机长被气压吸出机外，幸亏脚部被缠在控制盘上，才没有飞出机舱。这令他的上半身都在机外，只有双腿仍在驾驶室内。机身瞬间急速下坠，客舱内一片凌乱和恐慌，87名乘客和机组人员的生命危在旦夕。年轻的副机长拼命控制住了飞机，并好不容易在22分钟后紧急成功降落南安普敦机场，乘客和机长奇迹般的生还。这是有史以来最不可思议的航空空难，至今令人难以置信。

事故的直接原因是飞机出事前被更换挡风玻璃，而且被维修部通过。但是，90颗安在挡风玻璃的螺丝钉中的84颗的直径比标准要求的小，其余6颗的长度比标准要求的短。维修工程师以“尽量相似”为准则，没有参考飞机的维修档案，直接将这些螺栓安装到了机舱上。随着飞机的爬升，机舱内外压差增大，挡风玻璃最终承受不了这股气压而导致爆炸减压。

进一步调查发现，更换风挡的工程师责任心非常强。凌晨4点，工程师提前来到工作岗位，开始拆除飞机上的旧风挡，在更换新风挡时，他决定更换新螺栓。他没有在零部件目录中查找所需的零件，而是直接去了备件仓库。在仓库里，他用肉眼对比了一下新螺栓和刚取下来的旧螺栓的尺寸差异。仓库管理员知道他该用哪种螺栓，但工程师没有理会他的建议。在一个昏暗的角落里，他找到了与他所需要的相似的螺栓，但他的目测并不准确，实际上这些螺栓比他要使用的螺栓小了1/100厘米。6点钟下班时，工程师按时完成了任务，可以将飞机交付使用了。但是，一场灾难正在酝酿之中。

工程师为什么要这么做呢？按照标准程序使用计算机查询所需要的备件，所需要的时间会多一倍以上。他们的工作量很大，工作量已经超出了他们合理的承受范围。于是工程师就要想办法节省时间，以完成大量的工作量。否则就要影响飞机的按时起飞。

BOSS面临的风险
支撑系统（BOSS）的功能越来越强大，业务不断的发展和加载，系统变得越来越复杂，问题越来越难以控制。跟英航5390号航班相比，BOSS开发和维护工作与之有许多相似之处。而跟一架客机相比，BOSS很多地方更要不利的多：

不断重复工期与质量的老矛盾。近年来，移动通信领域迅猛发展，业务与市场日新月异，这形成了支撑系统必需“大干快上”的局面。业务需求剧增、客户规模不断加大、客户服务水平要求不断提高、工程建设齐头并进，这些给BOSS带来了巨大的工期压力。按照IT系统的特点，一旦工期要求超过一定限度，系统上线后风险就会显著上升，系统安全边际降低。面临不断建设、改造、升级等演进压力以及来自各个层面的急迫要求，要完成如此众多的工作，很多时候，工程建设完全是按照“倒排工期”的方式进行，没有严格遵循IT系统建设所需的科学过程，一些关键过程能省略则省略，或者工期被压缩。如不如此，就无法保证按期交互，支撑工作本身成了在质量和工期间搞平衡。

开发与运维工作无法标准化。传统的网络交换系统，所遵循的模式是先标准化使用模型和场景，然后再开发相关的产品并经过入网测试。这期间从标准化到产品化，有一个漫长的过程，并且其最终使用对象的行为，处于产品覆盖的标准的框架内。由于移动通信市场的快速发展，使得业务需求始终处于不断变化之中，业务模型本身，并未形成一套运营标准。作为需求驱动型的BOSS系统，无法得到有效的“疗养生息”的机会。另一方面，BOSS系统是典型的IT系统，产品化程度较低，还不能形成有效的稳定的产品集成，不能象交换网络一样形成插件型的电信级产品。它所要完成的功能是不断变化的业务和市场需求，而并非一个固定的技术标准或协议标准。
没有有效的质检团队。相对“硬产品”而言，作为IT系统的BOSS的软产品，其质量检查更为困难，即使成立了质检团队，也存在无法全面检测和无法标准化检测的风险。每一个环节上的产品质量，与具体需求特性、最终使用用户行为和需求、上下游系统运行情况、特定运行场景等息息相关。这就使得每一个产品环节的质检，只有标准化的检测方法，而没有具体的检查标准。
来自成本、工期、人力资源的限制，很多时候，开发人员和质检人员，不得不重用，这加大了质检有效性风险。

未形成有效的风险评估制度。即使对BOSS系统进行了完善的风险评估，但由于传统上人们认为计算机系统“没有做不到的事情”的观念影响，认为出了问题大不了很快处理，因此，“软产品”的风险认可度大大低于网络设备等“硬产品”的风险认可度。在人们的认识里，对IT系统的运行故障，除了事后指责为何会出现这样那样的问题外，没有仔细去想想问题发生的根源，或者根本就不愿意去听BOSS运维人员的解释。在他们的认识中，“硬”产品比如交换机出现的问题是可以接受的，大不了换个板卡了事，而“软”产品出问题是开发和运维人员本身有问题，是不可饶恕的。

这导致一个后果是对BOSS系统的风险无法引起足够的重视，从而无法促进形成有效的风险评估、风险管理机制。从另一个角度来说，即使建立了制度并有效评估了风险，风险报告也不会引起管理层足够的重视以改变相关的产品生产过程及其所需资源。

BOSS中“飞走的风挡”

我们回头梳理一下发生在英航5390号航班上的这件令人震惊的事故发生的原因：
1、飞机维修工程师工作量超出合理范围，他们的工作量很大，而且通常在夜间完成，为了按时完成维修交付以保证飞机正常起飞，工程师不得不按照工作习惯加快工作进度，节省相关的标准化程序。
2、飞机起飞前，飞机维修工程师按照自己的工作习惯，更换了飞机的风挡，并同时更换了工程师自己看起来一样的新螺栓。没有按照维修标准程序检索所需的备件目录，维修中使用了不合规格的零件。
3、英航的维修程序亦存在缺点：飞机维修完毕后，没有一个独立部门负责检验及确认。
4、伯明翰国际机场管理层，并没有好好监督维修部门的工作手法，没有制定相关的维修质量监督机制。
这四个环节中任何一个环节如果能够及时制止并发现问题，整个空难事故就不会发生。但是，这件令人匪夷所思的空难事故还是发生了。
对比一下英航5390号航班的事故得到的教训，和我们对BOSS系统面临的挑战，我们不禁感到危机重重：BOSS系统比一架客机面临着更高的风险，也意味着更高的故障率，更大的安全挑战。下面是英航5390航班事故原因和BOSS系统风险对比列表。

相比一架机型与备件均固定，可例行化和标准化操作的客机而言，BOSS系统有着长期处于不稳定状态的天然劣势，其任何一个运维工作，都没有一架飞机的运维工作从容。在产品化、标准化程度较低的情况下，质量检测和测试，都远比一架客机的质量测试更难。而对于这其中的风险，我们还缺乏足够的重视，甚至还没有从管理层形成一个有效的风险评估机制和风险管理制度。我们唯一可以确定的是，按照目前的方式，BOSS系统一定会在某个时候、某个环节，出现一块甚至多块“飞走的风挡”。对此，我们还没有足够的准备。