第五，从SOA架构整体运行来看，并不能在拥堵发生时，发现在某个系统内发生的是系统故障还是系统过载，而对于这两种情况，运维人员完全会采取不同的处理方式。对于系统故障，应该采用系统隔离和故障修复的方式，而对于系统过载，是可以采用降低压力和过载分流来进行处理。而在目前状况下，这两种情况是难以区分的。
第六，没有结合故障隔离机制，也就是在系统故障发生时，需要将堵塞的服务请求进行隔离，避免影响正常的用户访问，而且单点所造成的系统堵塞很容易扩散到整个SOA架构中的相关系统中，导致所有的服务请求受到影响。
多系统监控难题
部署SOA后，原本不完善的系统监控和预警机制可能会暴露出更多的问题。
第一，原有的应用系统自身都带有监控管理，监控功能是作为系统的一个附加组件来进行部署的，而没有统一集中到一个管理和操作平台上。
第二，随着系统之间的关联性不断增强，在运维人员的监控平台上，就需要同时打开多个监视界面才能及时跟踪系统的运行状况，需要操作者烦琐地登录多个不同的界面来进行操作和分析，从而造成了很多问题并不能够及时地被发现和解决。
第三，即使在单一系统内，监控数据来源的方式也是多种多样的。为了便捷，有的通过UNIX的SHELL脚本来进行监控，有的采取直接跟踪系统日志文件的方法，对于那些基于中间件的系统，也可以通过Weblogic或者Websphere的监控界面，而通过系统自身整合的IE界面来进行系统监控的方式已经算是凤毛麟角了。因此，运维人员就要深入了解系统内部的状况，当发生问题时，需要查询几处日志或者打开几个监控界面之后才能定位问题，这大大降低了工作效率。
在SOA架构建立起来之后，SOA系统不只是简单将各个系统技术平台进行整合，还存在大量业务整合和运维管理问题。一个服务流程的处理会涉及到多个业务处理主体，涉及到多个部门的统一配合和业务协作。
从上面的问题分析中，笔者发现银行SOA系统运维中的问题，大多并不是发生在正常运行的情况下，而是发生在系统堵塞和故障时，而这些特殊状况是难以进行预期和评估的，所以需要在实际工作中不断总结和完善。
对运维管理的关注是在系统SOA部署之后的重点，但值得银行科技部注意的是：运维管理体系的创建只有被提前到SOA项目的规划、建模和工程实施的时候，才能确保未来部署的服务和组合应用能够被真正地管理。运维管理涉及到的系统有3类，1．服务工程规范有效性度量体系：服务计分卡、服务重用评价、一致性度量、交付效率等；2．基础设施运行度量体系：服务水平协议 (SLA) 、审计信息、服务使用率、异常及失败、服务消费能力；3．业务流程度量体系：业务活动监控、SLA目标、异常及失败统计监控。
在SOA的部署过程中，旧的业务流程要优化、旧的系统要调整、旧的管理制度要废除，那么运维管理当然也不能固步自封，需要在新的体系下，制定新的规范、部署新的人员，建设新的监控预警平台。
总而言之，SOA将会让现有的IT系统发生改变，带来系统互连互通的优势。在SOA架构下，IT运维部门再也不能只从单系统角度去考虑运维问题，而需要从整个架构的宏观管理层面去改变旧有的工作模式。银行科技部门只有让改变后的系统能够正常和稳定地运行，才能将SOA的优势落到实处，才能让银行真正的在架构优化调整中受益。（责任编辑：崔平）
<<上一页
1
2
