联调测试终结CIO梦想

　　SOA项目上线前的第一轮测试由各个开发小组独立完成，主要针对本组负责开发的服务进行功能性测试和修改。而第二轮测试才真正算是联合测试。孙维抽调骨干开发人员临时组成联调修改小组和协调小组，同时组织相关业务骨干成立业务测试小组。在第二轮的业务测试通过后，还要再组织技术人员进行第三轮的系统压力测试，验证系统是否能够稳定运行。

　　第一轮测试进展相对顺利，毕竟只是在小组内进行，其间并没有出现什么大差错。但好景不长，进入第二轮测试后，人的问题变得比技术问题更加严重。

　　“还要修改？你们当初是认可我们的设计思路的，可现在都修改四次了为什么还要让我们改？”一位负责修改程序的测试人员大声抱怨着。

　　“我们也没想到程序写出来是这样，当初你们要是再多征求几次我们的意见就不会这么麻烦了。”另一位参与联调测试的业务骨干也毫不示弱。

　　按孙维的说法，第二轮测试经历了“沉默—争吵—再沉默”的一个循环过程。“测试的最开始，大家还都心平气和的，业务人员提出问题，技术人员就修改问题。”但好景不长，随着问题的逐渐增多，开发人员在经历了长时间超负荷工作后开始急躁。有的抱怨业务人员提出的修改要求与过去不同，属于不合理要求；有的抱怨这些问题是老系统就存在的限制，根本不是自己的问题；还有些技术人员认为自己开发的程序已经通过测试，现在的工作不应该自己来干；更有技术人员相互抱怨的情况发生，不同组开发的服务之间有些接口存在问题，彼此之间也经常毫不留情的“大打出口”。

　　“最让我们难以接受的是竟然有业务人员矢口否认我们的设计曾得到过他们的确认。”王立回忆起了这样一幕，“一位部门经理跑来问，为什么我们的业务数据要给别的部门看？还要求我们彻底修改。”

　　由于整个项目的进度从最初的架构设计阶段就落后近50%的进度，联调测试也引起了高层的“特别关注”，多次向孙维和项目组施压，要求系统尽快上线。可这个“特别关注”不但没有起到推动作用，反倒使推卸责任的情况愈演愈烈。“最后所有业务流程走通的时候，大部分人不是高兴，而是一种解脱的感觉。”回忆着难堪的一幕幕，孙维说，“这简直是一次人性的测试。”

　　但是不管怎样，业务流程的测试最终还是在不断的推卸责任和反复修改中完成了。尽管出现了这么多问题，但孙维此时仍然坚信，距离成功仅一步之遥，很快，自己也会从IT主管晋升到日思夜想的CIO。但是第三轮测试还没结束，孙维却主动向集团管理层递交了一份辞职申请。

　　“由于一个业务流程的运行需要编排的服务太多，使硬件系统无法承受由此带来的负载，在一些关键业务的压力测试还远没达到现有业务量的时候，就出现了多次宕机。”尽管孙维对其中的一些服务又进行了调试，甚至是重新开发，但是总体性能仍然达不到保证业务正常运行的要求，甚至比现有系统的效率还低。而早已“透支”的项目周期和资金投入也早就让集团管理层对SOA项目不满了。此时对孙维来说，要想再让集团为此投入更多资金和时间，甚至比做上CIO还要难。“与其说孙维主动辞职，不如说是不得已而为之。”作为方案提供方的顾问，李辉说这都是一意孤行导致的结果。

　　这样的结局大大出乎孙维的意料，甚至与他一起从头至尾奋战过来的“兄弟们”也都很难想象到这种结果。实际上出现这种问题不仅是因为孙维执意采用高精密度服务设计方案导致的，这与新悦集团在SOA项目中没有做好迁移计划也有很大关系。此外，当使用Web Services等Web方式实现松散耦合时，SOA引入了数据处理层，同时也带来了由这些层所影响执行效率问题。而孙维和咨询顾问也都没有考虑到其执行效率上一直存在的问题。结合这些原因，就出现了这么一种递进关系：服务的高精密度设计导致业务流程需要编排更多的服务，更多的服务意味着更多的Web Services和数据处理层工作，更多的Web Services又意味着更大的执行效率问题，最后导致众多压力测试无法通过的结局。正在着手进行新一期SOA项目建设的中外运信息管理部副总经理张思宇对这个问题也是早有“领教”，对此，他建议“简单的程序，没有必要用SOA。”

　　可是说什么都晚了，孙维不仅搞砸了这次的SOA项目，也搞砸了自己的前程。尽管集团领导没有批准他的辞职申请，但是集团CIO的位子也从此变成了孙维的一个奢望。而新悦集团的SOA项目最终也变成了部分数据接口的SOA实现。“我觉得SOA还有很多实质性难题没有解决，就跟ERP一样，多年来一直在喊分步实施，可仍然成功率很低。”孙维语重心长地叹了口气。尽管目前很多SOA方案提供商有一套自己的SOA实施方法指导，可是至今在整个行业内对服务精密度如何把握、服务的注册管理等问题更多的也只是停留在理论阶段。所以SOA能不能成功应用不仅仅是CIO的事，更是一个负责任的方案提供商需要考虑的问题。