（2）问题管理
问题是指导致事件产生的原因，许多事件往往是由同一个问题引起的。问题的来源主要有以下几种：
①已经处理的事件，经过回顾分析后，可能形成一个问题；
②重大事件， 虽然经过紧急处理恢复服务， 但未找到根本原因， 也形成一个问题；
③对于趋势性事件的分析，并形成问题。
问题管理流程可以按照不同领域的问题（如网络、主机、中间件、数据库、应用等）由相关领域的技术支持专家来处理。原则上这些专家可以是二线支持专家，他们在负责接受来自一线支持人员的支持请求的同时， 也负责对以往事件进行分析，找出事件产生的根本原因，从而确定解决方案，消除这些根本原因，最终使此类事件不再发生；另一方面，也要从发生的事件中找出事件的发展趋势或潜在可能发生的问题，主动提供预防性措施，提高系统可靠性，降低运维成本。
问题管理流程着重于消除事件或减少事件发生，确定事件的根本原因，其流程如下：首先，定期分析事件，找出潜在问题，调查问题以找出其原因，制定解决方案、变通方法或提出预防性措施，以消除产生原因，或在重发时使其影响力最小化。其次，记录解决方案、变通方法、预防性措施，根据需要添加到知识库中。再次，提出变更请求，对问题的解决方案进行评估，通过提出变更请求以对该方案进行测试和实施。最后，问题必须进行事后回顾以找出改进机会或总结预防性措施，包括改进事件监测、找出技能差距和文档资料改进等。
（3）变更管理
变更请求通常由于问题的解决方案中需要对生产环境进行某些改变而产生， 变更请求来源于问题管理环节或由用户提交。 变更管理通过一个单一的职能流程来控制和管理整个信息系统运行环境中的一切变更，范围可包括软件，硬件，网络设备和文档等的变更，其流程如下。
①由用户或问题管理环节的维护人员提出变更申请， 由运维负责人检查和完善其内容，并进行风险等级、优先级的初步评估。
②通过分类，确定是否为重大变更、紧急变更，如果是常规变更请求，则由运维负责人安排实施； 如果是风险等级为“重大”的变更请求， 则应上报变更管理小组。
③根据特定的变更请求成立特定的变更管理小组， 成员包括对该变更申请有批准权的人员、对该变更的评估和批准提供参考意见的技术人员和管理人员。评估内容包括变更的技术可行性、对系统性能的影响、对现有服务的影响、对资源的需求等。
④变更管理小组评估后决定是否批准变更申请。变更请求得到批准后，运维负责人安排相应资源进行变更的计划、测试，并制定实施方案，确定实施时间表，分配相应资源，通知请求人。
⑤相应岗位实施变更，运维负责人监视实施过程，并在必要时进行协调。
⑥定期回顾变更管理流程以提高效率和效能，在实施变更流程不久之后，可以进行第一次回顾，以确保流程得到正确实施并达到预期目的。对发现的问题必须追根溯源并尽快解决，之后可以定期举行回顾。
（4）配置管理
配置管理是服务管理的一个核心流程，能确保应用系统及其运行环境中所有 IT设备/系统及其配置信息得到有效完整的记录和维护， 包括各 IT 设备/系统之间的物理和逻辑关系，从而为实现有效服务管理奠定基础。
配置管理流程着重于管理生产环境中所有必须控制的组成元素， 并为其他相关流程（如事件管理等）提供信息，使这些流程更有效地运行，从而确保应用系统环境的完整性和稳定性，其主要流程内容如下。
①识别和维护配置元素：确定需要进行配置管理的元素及所有必需的配置属性，并指明与生产环境中其他配置元素之间的关系。 对配置管理数据库提供日常维护。
②配置状态汇总：根据需要定期产生配置管理报表，并能使相关人员进行相关配置的提取、查询，定期产生配置项的状态报告，并能反映配置项的版本和变动历史。
③审计和确认：定期审核全部或部分配置数据库中的配置项，确认其和物理环境的一致性，从而确保配置信息的完整性。
④计划、回顾和改进：定期制定计划（如半年），以明确下阶段配置管理工作；定期回顾流程和审核结果，找出需要改进的配置项。
⑤配置管理数据库（CMDB）：配置管理数据库由配置识别活动来定义，配置识别活动不但要定义配置项，还需定义配置结构及配置项的相互关系。
项目管理模块主要管理 IT 项目整个生命周期从立项准备、立项、采购、实施、验收、 收尾各个阶段的任务和参与人。从功能上理解项目管理类似于发布管理流程， 即总行部署的应用系统分行仅需要展开实施和验收工作即可，而分行自建项目是一个完整的项目管理流程。
（1）系统开发。开发管理流程需要进一步完善和标准化，特别是文档管理、测试和版本管理方面需加强。同时，加强开发计划管理，在《开发项目管理规范》中明确要求：根据立项内容进行系统、全面的需求调研，提出短期和长期的开发计划，并编写需求分析报告。根据需求分析报告对系统进行可行性分析，包括经济可行性分析、技术可行性分析和操作可行性分析三个方面，并在此基础上编写可行性报告。 根据需求分析报告进行系统设计， 同时根据系统设计进行系统实施。
（2）系统测试。 首先， 应制定出详细的测试计划和方案及测试数据和测试案例，并形成测试大纲。 其次， 根据测试大纲对系统反复进行测试并做详细的测试记录。为确保系统的正确无误，应对系统进行实地试运行，试运行应选择多个环境且需求比较复杂的机构进行， 应比照设计方案对新应用软件系统的功能和性能进行彻底测试和考核，并形成量化的运行报告。
（3）外部资源管理。 外部资源的合理利用是推动分行信息技术的发展重要因素，分行的外部资源主要包括设备供应商、软件供应商等。
5. 运维知识库系统
运维知识经验的总结、维护和共享是提高员工运维技能水平、增强单位凝聚力的重要手段，也是把宝贵的经验教训从支持人员头脑逐步沉淀、固化的重要方式。知识维护既要鼓励员工积极提交知识，防止知识库变成“空库”；同时又要及时进行审核和维护，防止知识库变为“垃圾库”。
（1）知识来源主要有以下几个方面：一是各级运维支持人员日常工作中积累的经验；二是知识管理员总结、导入的经验。知识管理员研究、获取外部的知识和经验后，定期或随时整理这些知识，导入到知识库中，供所有用户共享。知识的获取、维护是信息网络管理员的重要职责之一。
（2）知识提交审核。各个系统管理员提交知识到知识库之后，需要经过知识管理员的审查、修正，才变为正式发布状态，以减少知识中的谬误和差错。知识管理员定期（每季度一次）检查所有的正式知识，逐条进行核实、修正和优化。修正和维护操作与审核新提交知识草案过程相同。
（3）知识检索和使用。在知识变为正式的发布状态之后，可以供各类用户随时检索引用。用户可以研究学习这些知识，也可以在解决问题的过程中有目的地检索。 知识记录维护用户阅读次数和用户引用解决问题次数的计数器，引用和阅读次数越多，该知识的价值越大。
6. 运行维护队伍建设
（1）队伍组建。针对目前信息系统 IT 资源现状以及对技术支持的需求，组成各类别维护人员的专家队伍，集中的开展运行维护工作。
（2）人员管理。对各级运行维护人员尤其是高级运行维护人员的管理，应制定一套切实可行的管理办法，包括人员配置、职责划分、人才库建立、人员培训、人员考核、人员待遇等。通过科学的管理办法和有效的激励机制，充分调动各级运行维护人员的工作积极性和责任心，为做好信息系统运行维护工作打好基础。
7. 运行维护制度建立
为确保运行维护工作正常、有序、高效地进行，必须针对运行维护的管理流程和内容，制定相应的运行维护管理制度，实现各项工作的规范化管理。运行维护管理制度可分为以下几个方面。
（1）网络管理制度：包括网络的准入管理制度、网络的配置管理制度、网络的运行/监控管理制度等。
（2）系统和应用管理制度：包括对主机、数据库、中间件、应用系统的配置管理制度、运行/监控管理制度、数据管理制度等。
（3）安全管理制度：包括网络、主机、数据库、中间件、应用软件、数据的安全管理制度及安全事故应急处理制度。
（4）存储备份管理制度：包括备份数据的管理制度和备份设备的管理制度。
（5）故障管理制度：包括对故障处理过程的管理制度、故障处理流程的变更管理制度、故障信息利用的管理制度及重大故障的应急管理制度等。
（6）技术支持工具管理制度：包括对日常运行维护平台、响应中心、运维流程管理平台、运行维护知识库、运维辅助分析系统等的使用、维护的有关制度。
（7）人员管理制度：包括对运行维护人员的能级管理制度、奖惩制度、考核制度、某银行系统外部人力资源使用的管理制度等。
（8）质量考核制度：制定相关制度，对以上各类制度的执行情况进行考核。随着整个
信息化应用内容的不断发展， 一些旧的运行管理制度势必不能适应新发展的要求，必须进行不断的改进，并制定相适应的新的管理制度，逐步完善管理机制。
本文为授权转载文章，任何人未经原授权方同意，不得复制、转载、摘编等任何方式进行使用，e-works不承担由此而产生的任何法律责任! 如有异议请及时告之，以便进行及时处理。联系方式：editor@e-works.net.cn tel：027-87592219/20/21。
需求中心
AI助手
联系我们
返回顶部