论文部分内容阅读
关键字：ＩＴ服务管理 项目实施 银行
借助监控中心，光大银行有了顺风耳和千里眼，做到了故障的及时发现和事前防范。
武林高手大都有自己得心应手的武器，剑、刀、棍等十八般武器选其一，选择结果因人而异。在ITSM的人员、流程、技术三大要素中，技术类似高手手中的武器，在整个ITSM实施过程中是整合人员、实现流程自动化、发挥ITSM威力的关键。
目前，ITSM的软件工具已经有了可选择的余地。这些工具，比如惠普的OpenView、CA的Unicenter，以及IBM的Tivoli等，大都提供了比较灵活的客户个性化功能，能结合客户需求来做定制化修改，也具有较好的集成性。
企业选择工具的决定因素因企业的需求而异，有些企业强调产品价格，有些强调实施商提供的资质及以解决方案的合理性，还有一些则是强调产品供应商的品牌和支持力度等。当然，技术也是一个重要的参考因素。系统平台、数据库、应用平台和各种通讯协议构成了企业的IT环境，有了这样的环境约定，ITSM系统的选择也就有了参考。
关于ITSM产品的选型，光大银行信息科技部运行处处长史晨阳表示，选择不同平台的结果区别很大。光大银行信息科技部开始引进理想公司的iEAI产品时，提出了一系列的需求和操作思路，理想科技据此对产品进行了定制化的开发，实现了光大银行需要的功能，而如果选择其它产品的话，就不一定能实现这样的功能。
对系统监控产品的选型，其最大的影响因素就是光大银行的平台。由于光大银行总行的主机大部分是惠普的产品，所以史晨阳认为至少在操作系统这个层面，惠普的监控系统就比较权威；但是在数据库方面，惠普的OpenView就不一定具有权威性，所以需要寻求别的东西做补充，比如VERITAS I3（Insight Indepth Inform，数据库性能分析系统），作为辅助监控和调优工具。
光大银行的ITSM项目主要引进了四个产品：惠普的OpenView系统、惠普的服务台系统、理想公司的iEAI（作业控制台系统）和VERITAS I3。这四个产品在整个ITSM项目中起到了各不相同的重要作用。
借助ｉＥＡＩ控制关键流程
谈到引进的iEAI，史晨阳用带闹钟的手表打了个比喻，认为iEAI的引入给操作人员带了一个带闹钟的手表，及时提醒操作的流程、状态和时间。1990年以前，银行的批处理操作、备份操作等都是通过人工记在本子上来实现。随着银行业务的快速发展，业务系统越来越多，关系也越来越复杂，彼此相互牵制。人工处理的方式已经无法适应业务发展需要，每年都会出现因员工的误操作而引发的风险。而这可能给银行的金融系统带来致命的隐患。
基于这样的矛盾，光大银行想通过iEAI梳理各系统关系，把不同系统之间的数据、和功能通过流程和接口互相协调、整合在一起，通过iEAI的流程控制来自动完成。
在这个层面之上，光大银行更加关注的另外一个重要问题就是，怎么实现系统资源和人力资源的整合，把业务和管理流程中涉及到的人力资源也在流程中统一管理起来。而这正好是iEAI的强项，因此光大银行最终选择了iEAI。
结合光大银行生产环境的具体应用，我们用图1来看光大银行如何借用iEAI系统软件来解决关键流程控制问题。如图1所示：箭头表示操作的先后循序，前一操作顺利完成后（打√表示已顺利完成），进入“并发开始_9”进程，需要并行处理的两个操作SAP_60和SAP_70，由于SAP_70操作失败，所以图1中的“并发结束_10”没有打“√”，表示SAP_60和SAP_70的并发没有结束。
基于iEAI，光大银行定义了所有的操作任务，以及任务之间的关系。这样，根据操作规章，操作员关于机房任何一项操作工作，都不能游离在iEAI监控台之外，系统管理员可以随时查询操作员正在进行的工作状态。
如图2所示，每一个操作工作在iEAI监控台上显示为四个状态之一：首先是准备（Ready）状态，即按照预计的时间某项任务应该操作了；如果由于不具备一个前提条件，现在还不能做，则该任务会在监控台上处于等待（Waiting）状态；等到前提条件就绪了，操作员才可以接管这项任务，一旦接管，任务变成进行（Running）状态；待操作完成后，这个任务便从显示屏上消失。如果在任务处理过程中，出现了错误，操作员可以把这种状态设成失败（Fail）状态，可以找相关人员来解决故障。
通过这样的管理方式，任何人都可以在线看到，哪些工作在做，哪些工作是在等，在等谁，处于什么状态。
在上iEAI系统前，光大银行的操作员是24小时三班倒，操作人员在交接班的过程中，都是凭大脑记忆交接未完成系统批处理的任务，这就容易发生遗漏，类似的误操作事故在光大银行每年都会发生4到5起。上iEAI系统之后，基于Web的管理方式使双方交接的任务一目了然。从2005年8月至今，光大银行尚未发生因为操作员遗忘或误操作的事故。
同时，以前各项操作都需要脑子记，或者是用Excel画一个月的工作表，完成一个打一个勾，而现在基于定制化的界面，一目了然。特别是基于iEAI，系统生成的日志文件也是电子的，记录工作是谁做的，过程中有没有出现故障，外部审计时，从数据库中直接调用日志文件出来就行。
借助服务台攻坚运维管理
光大银行的运行维护管理涉及的内容较多，初期主要是系统的变更、内容故障管理、问题供应单的流转和管理、知识库的积累以及CMDB（Configuration Management Database，配置管理数据库）。
今后，光大银行还将进一步挖掘系统功能。例如，变更管理不仅是运行维护的变更、系统层面的变更、硬件设备更新配件、系统软件变更参数、磁盘扩容等，将来还将扩展到业务需求变更、修改应用程序等。
为支撑运维管理，光大银行引入了惠普的服务台产品，以实现故障管理、变更管理和一部分的CMDB的管理。目前，光大银行做了一些初步的尝试，变更管理主要在硬件设备的变更，仅仅是在系统升级、打补丁方面，这些变更更多是由IT部门提出的，通过这个流程进行登记和审核。如果变更涉及到业务部门时，则需要就变更事项通知业务部门。
光大银行对运维管理采用了逐步推进的灵活处理方式。比如对CMDB的管理，先是对组件的管理，对介质保管，再逐步把主机的管理也融入进来。在推行实施阶段，光大银行首先让系统管理员去熟悉、习惯在这个平台上实现运维管理，比如必须严格地按规范记录变更管理等。
借助ＯｐｅｎＶｉｅｗ实现系统监控
系统监控是运行维护的重点，这包括实时监控和资源使用的中长期监控。
实时监控方面，光大银行采用OpenView对总行的十几套主要的生产系统实行监控；操作系统和Oracle数据库是监控重点，其中数据库有81个指标，通过一些阀值的设定实现监控；同时，光大银行还将30个分行的前置机全部部署了监控。实时监控支撑了光大银行的故障管理，在主动发现、预防错误方面起了很好的作用。
资源使用的中长期监控对光大银行的能力管理流程起了基础的支撑作用。ITIL（信息技术基础架构库）的能力管理流程包括三个子流程：业务能力管理、服务能力管理和资源能力管理。三个子流程的侧重点各有不同，资源能力管理子流程主要关注IT基础设施中每个组件的能力和使用情况，并确保IT基础架构的能力足以支持服务级别目标的实现。
光大银行的资源使用的中长期监控，就是通过监控系统中的资源性能管理工具，监控整个系统资源的CPU、内存、存储等方面的消耗，实时预警，形成定期资源中长期报告。系统可以通过一些历史数据的分析，对今后的资源增长情况做出预测，便于提前对系统实施做出一些扩容的操作，不用等到问题出现后，才提出申请。比如某个系统CPU的使用率长期处于80%～90%，虽然暂时没有影响到业务，但也需要考虑加一个CPU，不能等到CPU已经达到100%才开始申报，这就涉及到周期的问题。
借助灾难备份支撑ＩＴ服务持续性管理
根据美国Gartner公司的研究报告，约有85%的全球性企业对信息系统和IT基础设施实施了灾难恢复计划，但是仅有15%具备完善的业务连续性计划，包括应急、业务恢复、危机处理等方面流程以及相应的行动方案。
在IT服务管理的10个流程中，IT服务持续性管理是组织业务持续性计划的一个重要组成部分。IT服务持续性管理需要确保组织在发生灾难后有足够的技术、财务和管理资源来确保IT服务的持续性。
灾难恢复的演练已经成为光大银行信息科技部每年为保障业务连续性而必须做的工作。目前，光大银行以北京的两大中心分别担负着50%的系统运行工作。两个中心互为同城热备份状态，可以随时把任何一个中心的系统切换到另外一个中心，切换后在灾备系统上运行的时间可以是一天、一个星期、一个月，或者更长时间。为了保证灾难备份切换的成功，光大银行每年都要安排一次双向的切换演习，验证光大银行的切换流程和灾难备份系统的可用性。
光大银行正是以灾难备份系统为核心，在IT服务的持续性管理方面实实在在地投入了人力、财力、物力，在全国银行业的灾难备份方面处于领先地位。在现有的同城备份的基础上，光大银行信息科技部把异地灾难备份中心的建立列为了今年计划实施的项目之一，争取在股份制商业银行里率先实现异地灾难备份。光大银行异地灾难备份的思路是外包，但是国内目前还没有比较成熟的第三方服务。
光大银行信息科技部总经理李坚和史晨阳均表示，ITSM是一个持续改进的过程。光大银行的ITSM项目取得了一些阶段性的成果，但ITSM的持续改进还远没有结束。光大银行希望能够把ITSM扩展到整个银行，这是一个挑战。但李坚和史晨阳坚信，实施ITSM是一件正确的事情，能够解决IT系统安全稳定运行的问题，实现既定的目标。
借助监控中心，光大银行有了顺风耳和千里眼，做到了故障的及时发现和事前防范。
武林高手大都有自己得心应手的武器，剑、刀、棍等十八般武器选其一，选择结果因人而异。在ITSM的人员、流程、技术三大要素中，技术类似高手手中的武器，在整个ITSM实施过程中是整合人员、实现流程自动化、发挥ITSM威力的关键。
目前，ITSM的软件工具已经有了可选择的余地。这些工具，比如惠普的OpenView、CA的Unicenter，以及IBM的Tivoli等，大都提供了比较灵活的客户个性化功能，能结合客户需求来做定制化修改，也具有较好的集成性。
企业选择工具的决定因素因企业的需求而异，有些企业强调产品价格，有些强调实施商提供的资质及以解决方案的合理性，还有一些则是强调产品供应商的品牌和支持力度等。当然，技术也是一个重要的参考因素。系统平台、数据库、应用平台和各种通讯协议构成了企业的IT环境，有了这样的环境约定，ITSM系统的选择也就有了参考。
关于ITSM产品的选型，光大银行信息科技部运行处处长史晨阳表示，选择不同平台的结果区别很大。光大银行信息科技部开始引进理想公司的iEAI产品时，提出了一系列的需求和操作思路，理想科技据此对产品进行了定制化的开发，实现了光大银行需要的功能，而如果选择其它产品的话，就不一定能实现这样的功能。
对系统监控产品的选型，其最大的影响因素就是光大银行的平台。由于光大银行总行的主机大部分是惠普的产品，所以史晨阳认为至少在操作系统这个层面，惠普的监控系统就比较权威；但是在数据库方面，惠普的OpenView就不一定具有权威性，所以需要寻求别的东西做补充，比如VERITAS I3（Insight Indepth Inform，数据库性能分析系统），作为辅助监控和调优工具。
光大银行的ITSM项目主要引进了四个产品：惠普的OpenView系统、惠普的服务台系统、理想公司的iEAI（作业控制台系统）和VERITAS I3。这四个产品在整个ITSM项目中起到了各不相同的重要作用。
借助ｉＥＡＩ控制关键流程
谈到引进的iEAI，史晨阳用带闹钟的手表打了个比喻，认为iEAI的引入给操作人员带了一个带闹钟的手表，及时提醒操作的流程、状态和时间。1990年以前，银行的批处理操作、备份操作等都是通过人工记在本子上来实现。随着银行业务的快速发展，业务系统越来越多，关系也越来越复杂，彼此相互牵制。人工处理的方式已经无法适应业务发展需要，每年都会出现因员工的误操作而引发的风险。而这可能给银行的金融系统带来致命的隐患。
基于这样的矛盾，光大银行想通过iEAI梳理各系统关系，把不同系统之间的数据、和功能通过流程和接口互相协调、整合在一起，通过iEAI的流程控制来自动完成。
在这个层面之上，光大银行更加关注的另外一个重要问题就是，怎么实现系统资源和人力资源的整合，把业务和管理流程中涉及到的人力资源也在流程中统一管理起来。而这正好是iEAI的强项，因此光大银行最终选择了iEAI。
结合光大银行生产环境的具体应用，我们用图1来看光大银行如何借用iEAI系统软件来解决关键流程控制问题。如图1所示：箭头表示操作的先后循序，前一操作顺利完成后（打√表示已顺利完成），进入“并发开始_9”进程，需要并行处理的两个操作SAP_60和SAP_70，由于SAP_70操作失败，所以图1中的“并发结束_10”没有打“√”，表示SAP_60和SAP_70的并发没有结束。
基于iEAI，光大银行定义了所有的操作任务，以及任务之间的关系。这样，根据操作规章，操作员关于机房任何一项操作工作，都不能游离在iEAI监控台之外，系统管理员可以随时查询操作员正在进行的工作状态。
如图2所示，每一个操作工作在iEAI监控台上显示为四个状态之一：首先是准备（Ready）状态，即按照预计的时间某项任务应该操作了；如果由于不具备一个前提条件，现在还不能做，则该任务会在监控台上处于等待（Waiting）状态；等到前提条件就绪了，操作员才可以接管这项任务，一旦接管，任务变成进行（Running）状态；待操作完成后，这个任务便从显示屏上消失。如果在任务处理过程中，出现了错误，操作员可以把这种状态设成失败（Fail）状态，可以找相关人员来解决故障。
通过这样的管理方式，任何人都可以在线看到，哪些工作在做，哪些工作是在等，在等谁，处于什么状态。
在上iEAI系统前，光大银行的操作员是24小时三班倒，操作人员在交接班的过程中，都是凭大脑记忆交接未完成系统批处理的任务，这就容易发生遗漏，类似的误操作事故在光大银行每年都会发生4到5起。上iEAI系统之后，基于Web的管理方式使双方交接的任务一目了然。从2005年8月至今，光大银行尚未发生因为操作员遗忘或误操作的事故。
同时，以前各项操作都需要脑子记，或者是用Excel画一个月的工作表，完成一个打一个勾，而现在基于定制化的界面，一目了然。特别是基于iEAI，系统生成的日志文件也是电子的，记录工作是谁做的，过程中有没有出现故障，外部审计时，从数据库中直接调用日志文件出来就行。
借助服务台攻坚运维管理
光大银行的运行维护管理涉及的内容较多，初期主要是系统的变更、内容故障管理、问题供应单的流转和管理、知识库的积累以及CMDB（Configuration Management Database，配置管理数据库）。
今后，光大银行还将进一步挖掘系统功能。例如，变更管理不仅是运行维护的变更、系统层面的变更、硬件设备更新配件、系统软件变更参数、磁盘扩容等，将来还将扩展到业务需求变更、修改应用程序等。
为支撑运维管理，光大银行引入了惠普的服务台产品，以实现故障管理、变更管理和一部分的CMDB的管理。目前，光大银行做了一些初步的尝试，变更管理主要在硬件设备的变更，仅仅是在系统升级、打补丁方面，这些变更更多是由IT部门提出的，通过这个流程进行登记和审核。如果变更涉及到业务部门时，则需要就变更事项通知业务部门。
光大银行对运维管理采用了逐步推进的灵活处理方式。比如对CMDB的管理，先是对组件的管理，对介质保管，再逐步把主机的管理也融入进来。在推行实施阶段，光大银行首先让系统管理员去熟悉、习惯在这个平台上实现运维管理，比如必须严格地按规范记录变更管理等。
借助ＯｐｅｎＶｉｅｗ实现系统监控
系统监控是运行维护的重点，这包括实时监控和资源使用的中长期监控。
实时监控方面，光大银行采用OpenView对总行的十几套主要的生产系统实行监控；操作系统和Oracle数据库是监控重点，其中数据库有81个指标，通过一些阀值的设定实现监控；同时，光大银行还将30个分行的前置机全部部署了监控。实时监控支撑了光大银行的故障管理，在主动发现、预防错误方面起了很好的作用。
资源使用的中长期监控对光大银行的能力管理流程起了基础的支撑作用。ITIL（信息技术基础架构库）的能力管理流程包括三个子流程：业务能力管理、服务能力管理和资源能力管理。三个子流程的侧重点各有不同，资源能力管理子流程主要关注IT基础设施中每个组件的能力和使用情况，并确保IT基础架构的能力足以支持服务级别目标的实现。
光大银行的资源使用的中长期监控，就是通过监控系统中的资源性能管理工具，监控整个系统资源的CPU、内存、存储等方面的消耗，实时预警，形成定期资源中长期报告。系统可以通过一些历史数据的分析，对今后的资源增长情况做出预测，便于提前对系统实施做出一些扩容的操作，不用等到问题出现后，才提出申请。比如某个系统CPU的使用率长期处于80%～90%，虽然暂时没有影响到业务，但也需要考虑加一个CPU，不能等到CPU已经达到100%才开始申报，这就涉及到周期的问题。
借助灾难备份支撑ＩＴ服务持续性管理
根据美国Gartner公司的研究报告，约有85%的全球性企业对信息系统和IT基础设施实施了灾难恢复计划，但是仅有15%具备完善的业务连续性计划，包括应急、业务恢复、危机处理等方面流程以及相应的行动方案。
在IT服务管理的10个流程中，IT服务持续性管理是组织业务持续性计划的一个重要组成部分。IT服务持续性管理需要确保组织在发生灾难后有足够的技术、财务和管理资源来确保IT服务的持续性。
灾难恢复的演练已经成为光大银行信息科技部每年为保障业务连续性而必须做的工作。目前，光大银行以北京的两大中心分别担负着50%的系统运行工作。两个中心互为同城热备份状态，可以随时把任何一个中心的系统切换到另外一个中心，切换后在灾备系统上运行的时间可以是一天、一个星期、一个月，或者更长时间。为了保证灾难备份切换的成功，光大银行每年都要安排一次双向的切换演习，验证光大银行的切换流程和灾难备份系统的可用性。
光大银行正是以灾难备份系统为核心，在IT服务的持续性管理方面实实在在地投入了人力、财力、物力，在全国银行业的灾难备份方面处于领先地位。在现有的同城备份的基础上，光大银行信息科技部把异地灾难备份中心的建立列为了今年计划实施的项目之一，争取在股份制商业银行里率先实现异地灾难备份。光大银行异地灾难备份的思路是外包，但是国内目前还没有比较成熟的第三方服务。
光大银行信息科技部总经理李坚和史晨阳均表示，ITSM是一个持续改进的过程。光大银行的ITSM项目取得了一些阶段性的成果，但ITSM的持续改进还远没有结束。光大银行希望能够把ITSM扩展到整个银行，这是一个挑战。但李坚和史晨阳坚信，实施ITSM是一件正确的事情，能够解决IT系统安全稳定运行的问题，实现既定的目标。