基于ITIL的运维体系架构设计方案

1、1.1. 运维架构设计基于ITIL的运维管理体系的建立是企业在发展路程的一个阶段。而一个良好的运维管理系统，需要有一个清晰的运维流程来支撑。建设运维管理平台是一个长期的、持续的过程。基于ITIL的运维服务体系建设应包含运维服务制度、流程、组织、队伍、技术和对象等方面的内容。同时结合业务特色，整合运维服务资源，规范运维行为，确保服务质效，形成统一管理、集约高效的一体化运维体系，从而保障数据集中条件下网络和应用系统安全、稳定、高效、持续运行。1.1.1. 基于ITIL运维服务管理机制基于ITIL建立运维服务管理体系的过程分为以下7个步骤：理念导入、评估现状、确定目标及范围、流程设计、工具实施、上线

2、试运行、持续改进。理念导入理念导入是ITSM项目实施的第一步，也是决定项目能够成功实施的关键一步。理念导入主要是学习、研讨、灌输基于ITIL最佳实践运维管理体系框架，包括ITIL的基本知识和实施理念，有共同的语言和目标，并明确运维服务管理的愿景，在组织内进行宣导。培训课程可以采用提问和研讨的方式，让运维人员成为主角。评估现状完成理念导入并建立愿景后，需要评估组织当前的服务管理流程成熟度及运维服务管理的现状，并查找分析差距，进一步明确目标和范围。现状评估就是要通过定性和定量的分析、恰当的研究方法(包括调查问卷和现场访谈、观摩等)全面了解组织的运维服务状况，及其与理想状态之间的差距，并撰写评估报告

3、。这是后面确定运维管理范围、工具实施的基础。确定目标、范围根据现状评估结果，制定近期运维服务管理的目标与范围。在不同评估现状下，制定的目标也不同，随着体系的不断改进完善，目标也在不断提升，迭代式地实现已制定的愿景。梳理并固化服务流程，优化服务模式，通过系统实施和推广优化逐步提升运维服务管理能力，防范运维管理的风险，基于ITIL构建初步的运维服务管理体系。包括：(1)基于ITIL思想梳理并固化运维服务管理流程；(2)实现统一的运维服务台，建立集中的运维知识库；(3)完成事件、问题、配置和变更发布流程的实施；(4)构建统一的配置数据库，为运维服务提供精确化的数据支持。流程设计有了目标与范围，就需要

4、制定和实施运维服务管理方案，主要包括管理体系的梳理、流程设计的选型等环节。流程设计可以遵从先事件、服务台、问题、知识、服务级别后变更、发布、配置管理等顺序。流程设计包括流程研讨、流程详细设计、评审确认3个环节。其要点是保证运维人员、管理层的参与度，由咨询顾问带领企业人员共同设计，关键点是要做好评审确认，让运维人员和管理层尽可能达成一致。评审确认会一般有两轮或多轮才能完成。工具实施管理体系的设计、流程的制定、流程中相关指标的确立，都需要结合选择的工具以辅助体系实施，从而提高实施的效率。为了更好地符合企业自身的特点，本文采用在某成熟供应商的成熟产品基础上定制化开发，实现功能相对简单且能满足使用要求

5、的运维服务管理平台。运维服务管理平台共包含事件管理、自助服务管理、服务请求管理、问题管理、知识管理、变更管理、发布管理、配置资产管理、计划作业(含任务管理)、服务水平管理、报表管理等11个功能模块，其逻辑框架图。本文重点阐述已实施的事件管理、自助服务管理、变更管理、配置及资产管理等模块。(1)事件管理事件管理又称故障管理(IncidentManagement),其主要目标是尽可能快地恢复到正常的服务运营，将事故对业务运营的负面影响减小到最低，并确保可以维持服务质量和可用性的最高水平。事故管理的关键环节是：事件检测与记录、事件分类与初步支持、事件调查与诊断、事件解决与恢复、事件关闭、事件跟踪回顾

6、等环节。事件管理流程实施得好坏直接关系到项目的成败。主要考虑如下几点： 事件的分类。进行前期的梳理，事件按照类别、子类和条目进行分类。一级分类包括桌面、网络、系统、信息安全、机房环境和应用。 确定事件的优先级。事件的优先级由事件的影响度和紧急度来确定。影响度通常是考虑受影响的数量、部门，某种意义上将影响度往往等同于系统或设备的重要性。紧急度一般等同于事件的严重程度，对于业务系统或核心设备，宕机的紧急度大于性能下降的紧急度，性能下降的紧急度又大于单个非核心功能不可用的紧急度。谁负责关闭事件。事件应由服务台和用户进行确认并关闭，也可以允许用户在自助服务系统中确认并关闭。转派规则的设计。同组可以转派

7、，跨组需要回退到服务台才可以转派，或者特定角色的人才可以跨组转派（如事件经理）。各个环节如何通知相关的角色和责任人。一般是通知受理人即可，但重大事件要第一时间通知事件经理、部门经理等主管领导。对于事件补单的情形，也要通知事件经理。整个事件处理的环节中事件的分派、等待、解决和关闭环节要及时通知用户。 事件是否可以过期自动关闭。事件一般由服务台或者用户自助关闭，对于超过10天未关闭的，系统可以自动实现关闭，并且默认为已经解决。但是对于重大事件，必须由服务台进行关闭 事件满意度的获得。事件的满意度是ITIL中一个重要的考核指标，高满意度是IT部门的一个主要追求。项目中实现了基于系统的自动发送满意度征

8、询邮件，用户可以通过邮件或自助服务模块反馈满意度及意见，对于超期未反馈的，邮件再次提醒，三天之内仍然未反馈的由服务台进行回访。但对于重大事件，事件解决后，服务台第一时间回访满意度。告警升级规则的涉及。服务级别协议(SLA)是指对于供应方在需求方要求下应当完成的活动的清晰描述，一个SLA总是以某种详细程度描述何时、何处以及如何完成这些活动4。由于单位的IT发展还比较弱，信息中心还没有与业务部门签署SLA协议,在这种情况下进行讨论，以一套“预期的”并向业务部门公布作为警告的SLA,并基于此进行升级和告警。表1所示为基于解决时间的事件警告升级规则。其中，首次升级时间指事件的解决时限，即事件从创建开始

9、到当前时间或解决时间，在该时间尚未解决即要升级告警的时间；升级告警对象是升级告警时，从行政或者管理角度的升级告警，即向何种角色或领导升级、告警，以引起重视。(2)自助服务管理自助服务管理即“员工自助服务管理”，主要包含在线申报事件、服务请求、查询工单、访问知识库、对工单解决进行评价、授权与委托等。主要功能是：按服务目录提交服务请求、在线申报事件、查询用户的历史工单、访问知识库、对工单解决进行满意度评价。有效地实施自助服务，增加了业务部门和IT部门的渠道沟通,依靠有效的知识库，简单问题还能由用户自助解决，不但提高了业务部门用户IT技能和知识，也减轻了信息中心的工作量。(3)变更管理变更管理流程通

10、过可控的方法及步骤来管理所有针对IT生产环境的变更，从而消除或最小化变更对IT服务质量的影响，同时提高日常的运维效率。通过对所有变更的正确评估，可以维护IT环境的完整性；变更和变更实施得到正确记录，并提供审计记录。在变更流程的实施中重点关注两个问题：一是变更类型的定义及审批流程。变更的核心是审批、授权，及其在变更流程中对变更风险的评估。二是变更时如何与配置管理数据库(CMDB衔接，发挥CMDB勺价值。要求所有的变更都要关联CMDB这样既可以精细化定义变更流程，也可以经过长时间的数据记录，从CMDB勺维度查看一个配置项曾经有过的变更请求，有利于提高运维效率，在出现事故时更快地查找原因。另外，在变

11、更完成后，要求在变更流程中强化CMDB勺同步更新和维护。(4)配置及资产管理配置管理的目标是定义IT服务和基础设施的部件，维护与IT部件及利用这些部件提供IT服务有关的记录，并确保这些记录的可靠性；提供准确的信息和文档以支持其他服务的管理过程5。配置管理控制的范围包括硬件、软件、流程、人员以及相关文档，并在CMD酷集中管理。其逻辑模型图。其中记录包含配置对象的详细配置信息、变更历史信息、生命周期信息、配置之间的关联关系信息以及与事件、问题、变更管理的关联关系信息。CMDB勺建设至关重要，主要有以下几点需要重点考虑：CMDEffi置模型的设计、管理的范围和颗粒度的选择。管理的类别，比如主机、网络

12、、存储、应用系统、数据库实例、中间件实例等；管理的层次属性，可以业务系统为视角加以考虑，哪些业务系统及其支撑业务系统的主机、存储、数据库、中间件要纳入CMDBf理的范畴，一般是先实施核心系统后实施外围系统；管理范围的关系，配置项的关联有很多种：连接、依赖、运行、安装部署、父子、主备、等同等，不同类型的配置项之间可能有一种或多种关系。 要高度重视配置项数据的收集和梳理。配置项数据的收集是一项费力费时的工作，但方法恰当，可以事半功倍。建议除网络设备、机房设备（配线架、空调、UPS等）外，以应用系统为维度考虑：应用系统、主机、存储、数据库、中间件等类别的配置项，先应用系统后主机，然后数据库实例、中间

13、件实例、应用实例，最后考虑网络设备、机房设备等。在收集完配置项属性和关系数据并规格化后导入CMDB并建立基线。 构建CMDB勺目的和价值在于运用。在事件、问题等工单的记录中要关联CMDB的配置项，在变更发起和变更计划时要关联CMDB并基于CMDBF估变更风险和影响。 为了保证CMDB勺数据的完整性和准确性，在有效实施变更流程的同时，定期对CMD瞰“盘点”，即定期审计，主要是看配置项的属性和关系是否与生产环境一致，如果不一致要查明原因，并审查流程和制度规范。要考核配置管理数据库如何应用，比如是否有必要和监控系统整合；与事件、问题、变更、发布等流程的关联关系；与资产管理的关系等。既不要高估配置管理

14、的短期价值，但也不要低估配置管理长期的价值。(5)报表基于ITIL的核心KPI考虑，包括事件总数、事件关闭的数量、事件成功关闭的数量/比率、规定时间内解决的事件数量/百分比、超时未解决的事件数量、规定时间内响应的事件数量/百分比、平均解决时间、一次成功解决率、问题总数、已找到根本原因的问题数量、趋势分析问题所占比率、通过变通办法解决的问题数量、问题成功解决率等。上线推广在完成工具实施后，要进行上线测试、试运行和推广。在系统正式上线前，需要组织好相关人员参加培训，掌握流程、制度和工具。由于项目不仅仅涉及到信息部门，自助服务还涉及到业务部门的培训和使用，所以项目中对信息部门先做培训，在应用推广等相

15、对稳定和成熟后，再向业务部门推广自助服务模块。持续改进根据戴明质量环所倡导的PDCA勺管理思想，流程设计应该是一个持续优化和改进的过程。业务在发展、技术在进步、成熟度在提升，运维流程也要不断优化和完善。项目结束后，主要是由流程经理或流程负责人定期或不定期地组织会议、研讨、总结、修订、完善运维流程。1.1.2, 运维服务岗位及职责设置运维服务组织岗位设置如下：图i运维服务组织岗位结构图岗位职责表如下:岗位职责作息时间运维经理1 .执行公司运维管理体系及运维运作机制，负责部门内部的日常管理和整体协调与推进；2 .组织运维项目调研团队，对客户运维需求和系统现状进行调研；3 .跟踪、协调重大事件、紧急

16、故障的处理；4,制定年度培训计划，提高运维的整体技术和管理水平；5 .公司内部沟通协调，协助运维团队现场技术服务所需相关资源；6 .参加客户运维相关例会，跟踪落实客户提出的意见持续改进运维服务的质量；每周5天每天8小时工作岗位职责作息时间7 .协助运维项目经理完成运维方案的编写工作，并参与评审；8 .执行调度命令和指令；9 .完成公司领导卜达的工作任务。10 .编制运维方案并组织相关人员进行评审；11 .协助营销完成运维合同的签订；12 .协调运维所需的相关资源，保障对客户呼叫及时响应和处理；13 .负责与客户运维主管部门领导进行沟通和协调，组织解决运维中存在的问题；14 .编制运维项目的实绩

17、材料向客户进行汇报。客服1 .遵循运维流程，受理客户的报修，并创建事件进行跟踪，事件处理完毕后，进行事件的反馈；2 .管理故障报告书，收集、统计运维过程的实绩数据。每周5天每天8小时工作调度1 .负责故障（或客户投诉）处理时现场生产协调和紧急处置；2 .负责组织编制故障报告书和召集故障分析会；3 .负责设备运行状态、故障情况、预防维护情况信息的收集和传递；4 .负责日常维护、预防维护实施过程的协调、跟踪、检查、整改落实和持续改进；5 .负责调度指令和调度命令的发布；6 .参加客户的生产、设备相关例会；7 .负责故障（或客户投诉）处理时内部协调和外部信息沟通；8 .负责内部信息、外部信息的传递；

18、9 .保持与客户及运维管理部门的信息沟通，执行客户调度命令和指令；10 .发布生产用车辆调度命令和指令。每周5天每天8小时工作系统运维护组组长1 .负责所维护系统及机房的日常管理；2 .负责现场协调和用户间的信息沟通；3 .协助分析故障原因，汇总故障处理信息，负责紧急预案、预防措施的实施和反馈；每周5天每天8小时工作岗位职责作息时间4 .制定岗位操作规程，编制日常点检及维护规程，起草定期预防性维护计划与实绩、年度维护报告；5 .执行调度命令和指令。系统运维护组组员1 .实施系统日常点检及维护；2 .受理、处理并记录运维过程中的事件，发现问题若不能及时处理，需立即报调度，协调技术支持人员处理；3

19、 .按照规程完成系统的日常备份和相关定时任务工作；4 .执行调度命令和指令；5 .执行组长安排的相关工作。每周5天每天8小时工作桌面运维组组长1 .负责所维护桌面终端的日常管理；2 .负责现场协调和用户间的信息沟通；3 .制定岗位操作规程，编制日常点检及维护规程；4 .管理组内成员；5 .执行调度命令和指令。每周5天每天8小时工作桌面运维组组员1 .实施桌面终端日常维护工作；2 .受理、处理并记录运维过程中的事件，发现问题若不能及时处理，需立即上报，协调技术支持人员处理；3 .执行组长安排的相关工作；4 .执行调度命令和指令。每周5天每天8小时工作网络运维护组组长1 .负责网络运维日常管理和安

20、全管理工作；2 .协助完成运维方案、运维技术附件的编制和评审工作；3 .负责现场协调和用户间的信息沟通；4 .协助分析故障原因，汇总故障处理信息，负责紧急预案、预防措施的实施和反馈；5 .制定岗位操作规程，编制日常点检及维护规程，起草定期预防性维护计划与实绩、年度维护报告；6 .执行调度命令和指令；每周5天每天8小时工作岗位职责作息时间网络运行维护组组员1 .实施网络系统日常点检及维护；2 .受理、处理并记录运维过程中的事件，发现问题若不能及时处理，需立即报调度，协调技术支持人员处理；3 .按照规程完成网络系统的日常巡检、监控、备份和相关定时任务工作；4 .执行调度命令和指令；5 .执行组长安

21、排的相关工作。每周5天每天8小时工作应用运维护组组长1 .审核系统预防性维护方案；2 .审核系统改善建议，编制系统改善方案；3 .制定重大事件重大故障处理方案；4 .协助项目经理组建运维项目调研团队、实施团队；5 .参与运维服务级别协议评审、项目计划书评审；6 .执行调度命令和指令。每周5天每天8小时工作应用运行维护组组员1 .提供对事件处理的技术支持；2 .实施问题、义更的处理；3 .编制、审核并完善系统维护规程；4 .编制、完善系统预防性维护方案并组织实施；5 .协助项目经理完成年度维护报告中相关内容；6 .提出系统改善建议；7 .负责对客户的系统现状进行调研，填写运维服务需求分析调研表；

22、8 .协助项目经理完成运维服务级别协议的编制工作，并参与运维服务级别协议评审；9 .参与运维项目计划书的评审；10 .协助项目经理完成运维项目结题文档的编制工作；11 .完善和优化应用系统功能；12 .调整应用系统与其他系统的接口；13 .执行调度命令和指令。每周5天每天8小时工作岗位职责作息时间机房一线1 .事件的录入、受理、处理；2 .日常点检；3 .日常备份；4 .实施一线发布；5 .管理承担运维项目的机房环境及现场各类设备；6 .按交接班制度对工作进行交接；7 .完成组长布置的工作；8 .配合二线人员及其所作相关工作；9 .配合运维交接；10 .按照网络C检计划实施网络C检；11 .对

23、非常规故障建议提出问题并实施跟踪；12 .异常状态及紧急情况下呼出和汇报；13 .熟悉现场生产业务和环境，对危险源能有效辨识；14 .判断故障归属等级及影响范围，把握故障处理进度；15 .执行调度的指令和命令；16 .终端信息安全；17 .项目实施过程中配合项目端工作；18 .PC服务器上的信息安全工作实施（方案二线出，一线实施）19 .安全工作；20 .定修工作（专业维护）；计划编制，定修实施；21 .服务报告编写（一线负责编写内容的部分）；22 .接入层交换机故障处理。倒班模式、三、四线运维支持岗位和职责:岗位职责二线技人支持1 .培训并指导运维项目的一线维护人员和现场二线技术人员；2 .

24、及时响应并处理武钢有限的系统、网络、应用的服务请求；3 .协助一线运行组组长编制日常运维的系统点检、维护规程、定期预防性维护计划与实绩、年度维护报告；4 .协助项目现场二线技术人员完成系统软件、硬件、网络、信息安全的预防性维护工作；5 .协助项目经理完成维护方案的编制工作；6 .执行调度命令和指令。三线技人支持1 .指导武钢有限运维项目二线技术支持人员，提供对重大事件和紧急故障处理的技术支持；2 .审核紧急故障处理方案；3 .审核年度预防维护计划；4 .制定备件策略，编制、审核备件计划；5 .执行调度命令和指令。四线技人支持1 .提供对重大事件和紧急故障处理的原厂商级别技术支持；2 .提供原厂

25、商级别的技术标准和规范。1.1.3, 基于ITIL运维服务体系建设原则运维服务体系建设的原则有以下几个方面。一是以完善的运维服务制度、流程为基础。为保障运行维护工作的质量和效率，应制定相对完善、切实可行的运行维护管理制度和规范，确定各项运维活动的标准流程和相关岗位设置等，使运维人员在制度和流程的规范和约束下协同操作。二是以先进、成熟的运维管理平台为手段。通过建立统一、集成、开放并可扩展的运维管理平台，实现对各类运维事件的全面采集、及时处理与合理分析，实现运行维护工作的智能化和高效率。三是以高素质的运维服务队伍为保障。运维服务的顺利实施离不开高素质的运维服务人员，因此必须不断提高运维服务队伍的专

26、业化水平，才能有效利用技术手段和工具，做好各项运维工作。1.1.4, 基于ITIL运维服务体系的总体架构运维服务体系由运维服务制度、运维服务流程、运维服务组织、运维服务队伍、运维技术服务平台以及运行维护对象六部分组成，涉及制度、人、技术、对象四类因素，其总体架构如下图所示。制度是规范运维管理工作的基本保障，也是流程建立的基础。运维服务组织中的相关人员遵照制度要求和标准化的流程，采用先进的运维管理平台对各类运维对象进行规范化的运行管理和技术操作。变更管理服务提供者服务级别苣理核心流程（应用/硬件件/网培/运营/技术支持）能力管理可用性省理旗在管理财务菅理配置管理发布管理服务台客户和用户事故和同邈

27、管理图2运维服务体系总体架构1.1.4.1, 运维服务制度和流程为确保运维服务工作正常、有序、高效、协调地进行，需要根据管理内容和要求制定一系列管理制度，覆盖各类运维对象，包括从投产管理、日常运维管理到下线管理以及应急处理的各个方面。此外，为实现运维服务工作流程的规范化和标准化，还需要制定流程规范，确定各流程中的岗位设置、职责分工以及流执行过程中的相关约束。1.1.4.2, 运维服务组织和队伍根据运维服务工作的内容和流程确定各项工作中的岗位设置和职责分工，并按照相应岗位的要求配备所需不同专业、不同层次的人员，组成专业分工下高效协作的运维队伍。1.1.4.3, 运维服务工作流程为保障运行维护体系

28、的高效、协调运行，应依据管理环节、管理内容、管理要求制定统一的运行维护工作流程，实现运行维护工作的标准化、规范化。其环节包括事件管理、问题管理、变更管理和配置管理。1.1.4.4, 运维技术服务平台运维技术服务平台包含实施运行维护和技术服务的各种手段和工具，通过技术手段固化标准化的流程、积累和管理运维知识并开展主动性运维工作。1.1.5.运维服务体系建设的内容1.1.5.1, 运维管理制度建设总结现有的运维管理经验，遵照国内外相关运维标准，结合目前的实际情况，统一制定运维管理制度和规范。通过定期和不定期的检查，促进各项制度规范的贯彻落实，从而建立起统一、规范的运行维护管理工作方式。同时，随着信

29、息化建设的不断发展，也要确保各项制度的及时更新。制度体系内容要涵盖机房管理、网络管理、资产管理、主机和应用管理、存储和备份管理、技术服务管理、安全管理、文档管理以及人员管理等类别。各类制度具体内容因需要而定，如网络管理制度需覆盖网络的接入管理、用户管理、配置管理及网络日常运行管理和应急处理等。安全管理制度需覆盖包括机房设施、网络、主机、数据库、中间件、应用软件、数据信息的安全管理、其他机密资源和人员的安全管理以及安全事件的应急处理等。1.1.5.2, 运维技术服务平台运维技术服务平台由运维事件响应中心、运维管理系统、运维知识库和运维辅助分析系统构成，平台采用分布式管理模式。(1)整合监控平台将

30、监控数据交换到运维事件响应中心、运维流程管理系统、运维知识库、运维辅助分析系统，支撑运维体系。(2)运维事件响应中心问题接收分为网络响应和电话响应两种方式，对于响应人员无法当场解决的问题，转发到运维部门的相应岗位，并向用户反馈解决情况。对于运维难以解决的问题，上报并配合进行问题的解决。同时,实现问题库的维护、解决情况的反馈、解决方案的查询等功能。(3)运维服务管理系统运维流程管理系统的建立，可以使日常的运维工作有序化，职责角色清晰化，能够有效地提高解决问题的速度和质量，使运维部门内的相关支持信息更为畅通、透明、完整，实现知识的积累和管理，更好地进行量化管理和设定优化指标，进行持续地服务改进，最

31、终提高整个运维工作的效率和质量。(4)运维知识库建设知识库建设是运维体系的重要组成部分，基于统一的技术支持平台，通过整合合作单位和协作厂商的技术资源和解决方案，实现有效的技术支持工作。运行维护知识库由知识库平台和知识库内容两部分组成。知识库平台包括知识检索、知识维护与管理等，可以通过纯Web方式向服务请求对象提供基于Web的查询服务和检索服务，以完全共享知识库中的知识，在提供Web服务时，还可通过响应中心平台来即时地响应用户请求的服务。(5)运维辅助分析系统以日常监控平台、运维响应中心、运维流程管理系统为基础，通过统计分析，了解运维服务能力与服务质量的现状，并可以进行趋势分析，为运维管理决策提

32、供支持。1.1.5.3,运行维护管理流程为加强对信息系统的运行维护管理，确保运行维护体系高效、协调运行，应依据运维管理环节、管理内容、管理要求制定统一的运行维护工作流程，实现运行维护工作的标准化、规范化和自动化通过建立运维管理流程，可以使日常的运维工作流程化，职责角色更加清晰，从而使解决问题的速度和质量得到有效提高，实现知识积累和知识管理，并可以帮助运维部门进行持续的服务改进，提高服务对象的满意度。运行维护流程包含的环节有事件管理、问题管理、变更管理及配置管理。(1)事件管理所谓事件，是指发生的对体系某一环节运行造成影响的事件，包括系统崩溃、软件故障、任何影响用户业务操作和系统正常运作的故障、

33、以及影响业务流程的情况，事件也包括一个用户的请求。对日常性运维工作中出现的突发事件(即日常运行维护管理平台自动发现并产生的告警事件)和由用户/维护人员报告的事件会转入事件管理流程，事件管理流程如下图所示。事件管理诙程运巷监注到事件nW*事报£理变史普印iE-过戏孔正小计口志图3事件管理流程图5(2)问题管理问题是指导致事件产生的原因，许多事件往往是由同一个问题引起的。问题的来源主要有以下几种：已经处理的事件，经过回顾分析后，可能形成一个问题；重大事件，虽然经过紧急处理恢复服务，但未找到根本原因，也形成一个问题；对于趋势性事件的分析，并形成问题。问题管理流程可以按照不同领域的问题(如网

34、络、主机、中间件、数据库、应用等)由相关领域的技术支持专家来处理。问题管理流程如下图：H题管用傥特或法蟒度的洋茶、故障、l'x：；1k11弋上吗一也X加M题i图4问题管理流程图原则上这些专家可以是二线支持专家，他们在负责接受来自一线支持人员的支持请求的同时，也负责对以往事件进行分析，找出事件产生的根本原因，从而确定解决方案，消除这些根本原因，最终使此类事件不再发生；另一方面，也要从发生的事件中找出事件的发展趋势或潜在可能发生的问题，主动提供预防性措施，提高系统可靠性，降低运维成本。问题管理流程着重于消除事件或减少事件发生，确定事件的根本原因，其流程如下：首先，定期分析事件，找出潜在问题

35、，调查问题以找出其原因，制定解决方案、变通方法或提出预防性措施，以消除产生原因，或在重发时使其影响力最小化。其次，记录解决方案、变通方法、预防性措施，根据需要添加到知识库中。再次，提出变更请求，对问题的解决方案进行评估，通过提出变更请求以对该方案进行测试和实施。最后，问题必须进行事后回顾以找出改进机会或总结预防性措施，包括改进事件监测、找出技能差距和文档资料改进等。(3)变更管理变更请求通常由于问题的解决方案中需要对生产环境进行某些改变而产生，变更请求来源于问题管理环节或由用户提交。变更管理通过一个单一的职能流程来控制和管理整个信息系统运行环境中的一切变更，范围可包括软件，硬件，网络设备和文档

36、等的变更，其流程如下。创沼杳中cm或闻史刖亡工兄先堤卬要号图5变更管理流程图由用户或问题管理环节的维护人员提出变更申请，由运维负责人检查和完善其内容，并进行风险等级、优先级的初步评估。通过分类，确定是否为重大变更、紧急变更，如果是常规变更请求，则由运维负责人安排实施；如果是风险等级为“重大”的变更请求，则应上报变更管理小组。根据特定的变更请求成立特定的变更管理小组，成员包括对该变更申请有批准权的人员、对该变更的评估和批准提供参考意见的技术人员和管理人员。评估内容包括变更的技术可行性、对系统性能的影响、对现有服务的影响、对资源的需求等。变更管理小组评估后决定是否批准变更申请。变更请求得到批准后，

37、运维负责人安排相应资源进行变更的计划、测试，并制定实施方案，确定实施时间表，分配相应资源，通知请求人。相应岗位实施变更，运维负责人监视实施过程，并在必要时进行协调。定期回顾变更管理流程以提高效率和效能，在实施变更流程不久之后，可以进行第一次回顾，以确保流程得到正确实施并达到预期目的。对发现的问题必须追根溯源并尽快解决，之后可以定期举行回顾。(4)配置管理配置管理是服务管理的一个核心流程，能确保应用系统及其运行环境中所有设备/系统及其配置信息得到有效完整的记录和维护，包括各设备/系统之间的物理和逻辑关系，从而为实现有效服务管理奠定基础。配置管理流程着重于管理生产环境中所有必须控制的组成元素，并为

38、其他相关流程(如事件管理等)提供信息，使这些流程更有效地运行，从而确保应用系统环境的完整性和稳定性，其主要流程内容如下。配置於H泞程生理管理的史以.一生见.,照卡视回G中成更师LHUE更新tMIIKWtRMDH状*根蝌来图6配置管理流程图识别和维护配置元素：确定需要进行配置管理的元素及所有必需的配置属性，并指明与生产环境中其他配置元素之间的关系。对配置管理数据库提供日常维护。配置状态汇总：根据需要定期产生配置管理报表，并能使相关人员进行相关配置的提取、查询，定期产生配置项的状态报告，并能反映配置项的版本和变动历史。审计和确认：定期审核全部或部分配置数据库中的配置项，确认其和物理环境的一致性，从

39、而确保配置信息的完整性。计划、回顾和改进：定期制定计划（如半年），以明确下阶段配置管理工作；定期回顾流程和审核结果，找出需要改进的配置项。配置管理数据库(CMDB:配置管理数据库由配置识别活动来定义，配置识别活动不但要定义配置项，还需定义配置结构及配置项的相互关系。1.1.5.4,运维项目管理流程项目管理模块主要管理项目整个生命周期从立项准备、立项、采购、实施、验收、收尾各个阶段的任务和参与人。从功能上理解项目管理类似于发布管理流程。(1)系统开发开发管理流程需要进一步完善和标准化，特别是文档管理、测试和版本管理方面需加强。同时，加强开发计划管理，在开发项目管理规范中明确要求：根据立项内容进行

40、系统、全面的需求调研，提出短期和长期的开发计划，并编写需求分析报告。根据需求分析报告对系统进行可行性分析，包括经济可行性分析、技术可行性分析和操作可行性分析三个方面，并在此基础上编写可行性报告。根据需求分析报告进行系统设计，同时根据系统设计进行系统实施。(2)系统测试首先，应制定出详细的测试计划和方案及测试数据和测试案例，并形成测试大纲。其次，根据测试大纲对系统反复进行测试并做详细的测试记录。为确保系统的正确无误，应对系统进行实地试应比照运行，试运行应选择多个环境且需求比较复杂的机构进行,设计方案对新应用软件系统的功能和性能进行彻底测试和考核，并形成量化的运行报告。(3)外部资源管理外部资源的合理利用是推动信息技术的发展重要因素，外部资源主要包括设