应用集成服务管理方案.docx

应用集成服务管理方案.docx

《应用集成服务管理方案.docx》由会员分享，可在线阅读，更多相关《应用集成服务管理方案.docx（14页珍藏版）》请在冰豆网上搜索。

应用集成服务管理方案

湖南烟草商业系统应用集成

服务管理规范

北京中软国际信息技术有限公司

1.1前言

伴随着湖南烟草信息技术的快速发展，信息化浪潮正在并必将继续对每个人的思想观念和生活方式产生深远的影响。

湖南烟草已经认识到，将信息化战略融入其总体发展战略对于提升其业务运作层次和综合竞争能力是极其重要的。

事实上，从湖南信息化发展的情况来看，要使信息技术能够真正地优化业务运作，除了要有先进的设备和技术外，还必须要有良好的配套服务保证和业务实现最大程度的整合。

只有这样，才能让信息化发挥真正的效益。

当然服务水平的提高不能一蹴而就，需要我们和湖南烟草配合和调整，持续改进服务，是一个循序渐进、不断完善的过程。

随着我们服务发展，需要逐步量化服务内容和服务衡量标准，实现服务水平的管理。

1.2服务组织管理

1.2.1组织结构

1.2.2人员要求

Ø运维技术小组应有至少一名管理负责人，负责管理运维技术小组工作，同时

也是与用户的固定接口人，这样便于用户任务的下达、落实和工作中的问题协调；

Ø运维技术小组至少要有一名技术负责人要全面掌握集成工作，在小组成员缺

席的情况下，仍能够解决问题，确保系统正常运行；推荐技术负责人与管理负责人为同一人，便于协调管理；

Ø运维技术小组成员要有独立完成某项技术工作的能力，要有工作经验。

技术

能力主要体现在Web应用服务器方面、数据库方面、集成中间件产品方面、以及烟草业务与企业管理方面；另外，技术能力应有侧重，最好具有其中某个方面的技术认证；但是，三人又要具有三个方面的基本知识，能胜任日常的运维工作；

Ø运维技术小组成员要能够使用IBMTivoli系统监控工具，通过Tivoli监控

系统实现系统关键指标预警、完成日常检查、做出系统运行情况分析、提出系统调优方法、扩容建议等；

1.3集成服务内容

1.3.1建立主机档案

建立平台主机档案，对平台主机进行编号，记录平台主机以及其上的集成产品的基本信息，便于查询和管理。

1.3.2日常监测与维护服务

业务系统与集成环境的运行监测检查是应用集成运维管理的基础性的日常工作。

具体监测检查对象包括湖南省烟草公司及其下属14家分市公司的数据库系统、应用服务器系统和集成平台中间件产品。

运维技术小组每日对检查对象进行例行检查，一日四次，检查各种技术指标。

检查工作是通过IBMTivoli工具完成的。

该工具可以实时、准确的监测到平台主机、及其上层的应用系统和数据库系统的运行状况。

这样不仅可以避免直接接触主机系统而且可以实现全省的集中管理。

1.3.3巡查服务

巡检是将问题和故障消灭在萌芽期的主要手段，事实上90%以上的故障都是有前兆的，能否尽早及时发现这些故障的前兆，是提高维护效率的主要途径，通过巡检，将被动服务转为主动服务。

1.3.4值班服务

因为烟草业务在节假日期间不休息，考虑到节假日期间的系统需要照常运转，所以运维技术小组要提供值班服务。

值班工作主要是沿用“日常监测与维护服务”，遇到系统出现问题将转入“问题响应服务流程”。

1.3.5现场技术支持服务

运维技术小组负责向省烟草公司及其下属分市公司信息中心解答关于应用集成方面的技术架构问题、接口实现问题、软件部署问题，以及关于集成标准规范方面的问题。

1.3.6软件升级与系统安装服务

运维技术小组要在烟草公司信息中心的授权下，负责安装平台主机和测试主机上的集成平台产品、数据库系统和应用服务器系统的补丁包程序以及升级产品；负责湖南烟草业务系统的部署和参数配置。

1.3.7参与主机系统重建服务

平台主机系统是湖南烟草核心业务的运行平台，平台主机的重建工作需要一个严格的管理过程。

运维技术小组必须在用户的许可下，配合系统集成商，完成平台主机的重建工作，具体包括安装WEB应用服务器、数据库系统和应用集成平台产品，部署业务系统；

1.3.8系统问题响应服务

监测、巡查等运维工作是为了预防系统出现问题，而一旦出现问题快速响应服务就成为运维工作的一项重要内容。

1.4服务流程

1.4.1接收问题流程图

1.4.2商品信息维护流程图

1.4.3组织信息维护流程图

1.4.4人员信息维护

1.5服务管理

1.5.1事故管理

事故是任何不符合标准操作且已经引起或可能引起服务中断和服务质量下降的事件。

对用户而言，事故包含任何不能顺利使用门户的事件，甚至包括那些由于用户自己原因造成的事件。

事故管理的目的就是在出现事故的时候，能够尽可能快地恢复服务的正常运作，避免业务中断，以确保最佳的服务可用性级别。

对业务部门而言，一是减少了事故对业务的影响，提高了效率，二是化被动为主动，改进了业务系统，三是获得更多的有用的管理信息，加强了管理。

对我们服务提供方而言，实施事故管理既提高了对员工绩效评价的准确性，又提高了服务人员的工作效率，最终提高了湖南烟草用户的满意度，真正做到了变“被动”为“主动”。

1）查明和记录事故：

记录用户的一些基本信息，如姓名、工作地点和电话号码、事故发生的时间、受事故影响的服务等。

这样做的目的一是便于确认事故影响，二是问题管理可以根据这些信息查找事故原因，三是密切跟踪事故进展。

事故管理记录一些基本的事故分析信息（时间、症状、位置、用户、应用系统开发商和受影响的服务、硬件等）。

事故管理需要判断事故是否严重，如果严重就先向管理层报告并告知用户有关情况，再采取进一步行动，如果不严重就直接进入下一步的事故初步归类和支持。

2）初步归类和支持

这里强调“初步”的目的是为了能够尽可能快地恢复用户的正常工作，尽量避免或者减少事故对IT服务质量的影响。

“初步”包含两层含义：

一是根据已有的知识和经验对事故的性质进行大概的划分，以便采取相应的措施，二是这里采取的措施和行动不以根本上解决事故为目标，主要目的是维持用户的持续运作。

归类是发现事故原因以便采取相应行动。

一般来说，许多事故是重复出现的，因此，当某个事故再次出现时，只需根据已有的经验和措施采取行动即可。

3）区分事故优先级

优先级是根据影响程度和紧急程度而制定的处理事故和问题的先后顺序。

优先级=影响度×紧迫性。

影响度、紧迫性和优先级三者之间的关系如下图所示。

如同时处理多个事故但受时间、资源和人力等的限制而无法实现时，事故受理人员就要排定处理的先后次序，即确定每个事故的优先级,事故受理人员根据一些量化的指标来决定优先级，使用户感到公平，又便于组织安排有关的人力和物力。

4）事故升级

当事故受理人在规定的时间内不能解决或没有解决某个事故时，就需将这个事故的处理任务交给更有经验和（或）省烟草项目组的支持人员。

事故升级是根据事故优先级和事故解决时间确定的。

升级方式通常有两种。

一种是技术升级，另一种是管理升级。

技术升级是指安排更多的技术人员或专家以解决事故。

5）解决事故和恢复服务

一旦事故被分派给某个支持人或某个应用开发商，他们应当确认接受了事故处理任务，同时指定有关日期和时间；尽可能快地把发现的权宜措施提供给移交人或客户；参考知名错误、问题、解决方案、计划的变更和知识库等对事故进行评审；必要时要求服务台根据协议的服务级别，重新评价事故影响度和优先级，并在必要时对它们进行调整；记录所有相关信息；把事故处理责任反馈移交人以让其终止此事故。

在分析和调查事故后，支持小组根据更新后的事故信息、提议的权益措施和解决方案以及有关的变更请求，解决事故并恢复服务，同时更新有关事故信息。

6）事故终止

解决事故和恢复服务后，就到事故终止阶段了。

在这个阶段的输入是上一阶段更新后的事故记录和已解决的事故，采取的行动主要是和用户一起确认事故解决是否成功，输出的结果为更新的事故信息和事故记录。

1.5.2问题管理

事故管理并不负责查找事件产生的潜在原因，其强调的是速度。

调查和分析和查找事故产生的根本原因是“问题管理”的职责。

与事故管理强调事件恢复的速度不同，问题管理强调的是找出事件产生的根源，从而制定恰当的解决方案或防止其再次发生的预防措施。

在尚未查明事故产生的原因前，事故所对应的潜在原因被称为问题。

问题是存在某个未知的潜在原因的一种状态，这种原因会（或可能会）导致一起或多起事故发生。

问题经常是分析多个呈现相同症状的事故后发现的某种状态。

问题也可从单个重要的事故中确认出来表示一项错误。

这种错误产生的原因虽然未知的，但其产生的影响却可能是非常严重的。

而在找到事故产生的根本原因后，问题就成为一个知名错误。

随后可以提出一个变更请求来消除该知名错误和防止类似事故再次发生。

问题管理流程的运作需要与其他服务管理流程的支持与配合，这主要体现在管理信息的传递和共享方面。

问题管理需要来自其他管理流程的信息的支持，同时，问题管理也会提供一些管理信息。

问题管理流程可分为问题控制和错误控制两大子流程。

问题控制包括确认和记录、分类、分配资源、调查和分析、定义知名错误、终止等步骤。

当发生“事故不能与当前的问题或知名错误相匹配”、“分析发现重复出现的事故”、“分析发现将来可能导致事故发生的潜在问题源”、“具有较大影响，而优先级较高的事件不能被（临时措施）解决，该事故的解决方案必须制定”等情况时，我们将事故确认为“问题”。

与事故归类类似，问题归类依照目录、影响度、紧迫性等优先级对问题进行归类处理。

根据归类的优先级对问题分配相应的资源进行处理。

一旦问题的原因被找到，与问题相关的配置项被确认，可以建立事件和配置项之间的对应关系，此时问题被确认为知名错误。

问题管理就进入错误控制阶段。

错误控制是管理、控制并成功纠正知名错误的过程，它通过变更请求向变项目组（信息中心和有关业务部门）报告需要实施的变更，确保知名错误被完全消除，避免事件再次发生。

错误控制对所有知名错误从其被发现至被解决的全过程进行控制，涉及烟草的许多不同部门和相应的应用开发商。

错误控制的过程主要分为3个阶段，如图所示。

其中跟踪和监督错误活动覆盖问题的整个生命周期。

一旦确定了问题产生的根本原因，问题就转变为一项错误；如果找到对付错误的应急措施，错误又成为知名错误。

错误或知名错误的确定是错误控制过程的开始。

发现和记录错误后，问题记录人员与技术支持人员一道对解决错误的可能方法进行初步评估。

如果他们发现不能消除错误，就通过变更申请向变更管理（项目组）报告有关情况。

变更管理根据错误对业务的影响的紧迫性和严重性确定变更的优先级。

错误控制应该详细记录每个知名错误的解决过程，特别是与知名错误有关的配置项、症状和解决方案（或替代方案），记录的信息可保存于知名错误问题库中。

这些信息可用于事故匹配中，为以后的事故调查和解决提供指南，也可用于管理报告中。

在实施变更以成功消除错误后，可以终止知名错误及其相关的事故和问题，并通过实施后评审确认知名错误的解决效果。

对事故来说，实施后评审也许是简单地打电话询问客户是否满意，但对问题和知名错误来说，实施后评审应该是一个正式和规范的过程。

变更管理流程负责处理变更请求，而错误控制需要对知名错误的解决过程进行监控。

在整个解决过程中，问题管理需要从变更管理获取有关问题和错误解决情况的正规报告。

问题管理还应监控问题和知名错误对用户服务的后续影响。

如果这种影响有不断加强的趋势，则问题管理应当将该问题升级并建议项目组提高该项变更请求的优先级，必要时还应当实施紧急变更以消除这种影响。

事故管理与问题管理相分离：

虽然二者目的看起来一致（恢复服务），但二者的目标往往矛盾（前者是为了尽快恢复服务，常采取临时解决措施，而后者是为了找到事件背后隐藏着的真正原因）。

1.5.3配置管理

配置管理是识别和确认服务管理的配置项，记录和报告配置项状态和变更请求、检验配置项的正确性和完整性等活动构成的过程。

其目的是提供信息基础架构的逻辑模型，支持其它服务管理流程特别是变更管理和发布管理的运作。

1.5.4变更管理

“变更管理”的目的即在“时间”