HP的IT系统运维管理流程构建方法(精)

第一篇：HP的IT系统运维管理流程构建方法(精)

HP IT系统运维管理流程构建方法

本文档包含准备及组织与客户有关人员进行研讨并最终为客户构建 IT 系统运维流程方法的详细论述,基于 HP 的 IT Service Management(ITSM 咨询方法论。而进行此类研讨则确保了运维流程设计的准 确性,并保证所设计流程能够顺利地在 IT 部门内得以实施。

1.0 简介

在新的 IT 系统得以成功的应用之前, IT 部门内必须完成针对新的业 务系统环境的运行管理流程的设计。为了正确地设计相应的流程,在 客户现场进行的相关研讨会将是获取客户相应需求的重要手段。

有效地控制此类研讨会的时间长度是确保与会人员集中精力的重要手 段。由客户相关领导在会前强调此类会议重要性的讲话通常会确保与 会者对会议给予高度重视。

本文档分两部分: 1.研讨会中用于设计运行维护管理流程的方法 第 1 页 HP Consulting Confidential 2.研讨会的成果(逻辑运行维护管理流程图,工作流程描述,物理 运行维护管理流程图,运行管理工作流程指导

2.0 运维流程的设计 2.1 研讨会前期的准备

每一个项目都是由不同的各个阶段组成的,在实质性的运行维护管理 流程设计工作进行之前,一个前期的准备工作是必不可少的。在本项 目中,前期的准备工作应包括: 1.创建用于“最佳成功范例”研讨所用文档

2.将流程设计及实施过程中的“策略性关键决策问题”列表

3.组织客户相应员工进行 ITSM 相关培训,以期使他们在运行管理 流程实施前对 ITSM 流程有基本的认识。

4.将需进行的研讨会日期进行列表,同时确定 HP 及客户双方应参 加研讨会的人员名单。有些项目相关人员会参加多个研讨会。

2.2 研讨会的具体内容

要进行的研讨会应被划成两个阶段: 逻辑设计阶段: 第一部分:回答策略性关键决策问题 讨论 ITIL 最佳成功范例

第二部分:设计逻辑运行维护管理流程 物理设计阶段: 第 2 页 HP Consulting Confidential 第一部分:设计物理运行维护管理流程

第二部分:创建运行管理工作流程指导

研讨会阶段性工作的结果将在本文档中的第三部分给予详细的解释。为了成功地完成本阶段工作,每一次研讨会的进度需要被严格地监 控。在进行本阶段工作时, 80/20规则应被广泛采纳,即在运行管理 流程的开发和设计过程中,当一个设计方案或答案已经被 80%的参 加讨论人员认可,则我们可以认为该方案或答案已满足要求而不需进 一步改进。运行管理流程的设计过程可以通过一些开放式的讨论来进 行。在讨论的过程中,所有参加讨论的人员可以将其想法罗列出来, 而后由讨论的组织者将它们分别按逻辑分组归类。

如果在研讨的过程中出现了在一定时间内无法解决的问题,应由组织 者将其记录在案。对于上述的每一个问题,应由一个研讨参加者负责 于第二天给出相应的答案或解释。在此再次强调,研讨的时间控制是 本步骤中非常重要的一个环节。研讨会结束后,应产生出如下的结 果: − 运行维护管理流程的任务范围 − 图形化的逻辑运行维护管理流程 − 图形化的物理运行维护管理流程

− 物理运行维护管理流程中每一步的详细说明 − 针对应用“ ITIL 最佳成功范例”研讨的答案 − 针对于策略性关键决策问题研讨的答案 − 运行维护管理各流程间的依赖关系 − 工作职责描述 第 3 页 HP Consulting

Confidential − 无法解决问题文档

本文档的下一部分将针对以上各项内容做具体的描述 第 4 页 HP Consulting Confidential 运行维护管理流程的任务范围

必须对每一个运行维护管理流程提供相应的任务范围描述。本文档为客户管理人员 了每一个流程所涉及工作范围的清晰描述,并为每一名与流程执行相关的员工充分 了解各流程的作用提供了学习的依据。

图形化的逻辑运行维护管理流程

逻辑运行维护管理流程描述了每一个流程从开始至结束所包含的每一个步骤及所牵 涉的客户相关工作人员。同时包涵与流程相关的其它各方面因素。

逻辑运行维护管理流程对所需流程的一个高层次的描述。本流程中的每一步骤代表 或可以被分解为若干个物理运行维护管理流程。相关逻辑运行维护管理流程请参见 “ 附录一 ”。

图形化的物理运行维护管理流程

物理运行维护管理流程详细地描述了流程从起始至结束的每一步。具体物理运行维 护管理流程需根据研讨会讨论结果结合客户大集中的实际情况进行客户化设计。

物理运行维护管理流程的详细说明

物理运行维护管理流程的详细说明包含了如何执行各流程中每一个步骤的说明。例 如,本说明中应包含对需使用工具所进行的每一步操作的说明。对各步骤的描述方 法应采用统一、标准的语言格式。同时应建立对本文档的审核流程。例如,对每一 个流程的说明文档,在其被最终采用以前应被至少三名员工审核。每一次审核应着 重于不同的角度,例如,技术上的正确性、功能上的正确性、及文档总体上的正确

性。第 5 页 HP Consulting Confidential 针对应用“ ITIL 最佳成功范例”的答案

一个相对独立的文档罗列出 ITIL 所总结出的“最佳成功范例”。研讨会后一个非 常重要的文档即哪些成功范例可以被客户所采纳。本文档亦会描述哪些设计好的流 程与 ITIL 提供的成功范例所不符,及造成该种局面的特殊原因。特别需要说明的 是,所有设计好的逻辑及物理流程均需考虑其与 ITIL 最佳成功范例的一致性。从 另一个角度,最佳成功范例亦可为各种流程设计的合理性提供具有建设性的建议及 依据。

有关 ITIL 最佳成功范例的详细信息请参见 “ 附录 二 ” 针对于策略性关键决策问题的答案

在研讨会后生成的另一个至关重要的文档既“针对于策略性关键决策问题的答 案”。具体策略性关键决策问题,请参见 “ 附录三 ” 运行维护管理各流程间的依赖关系

在运行维护管理流程的设计过程中,不可避免的会造成有些流程间会产生依赖关 系。次类依赖关系应当被文档化,特别是当相应的流程是由客户内不同的部门设计 的时候。作为本咨询服务中一个可选的项目, HP 会为客户提供次文档。

工作职责描述 第 6 页 HP Consulting 每一个在工作流程中涉及到的客户内部的工作岗位都必须有工作职责描述。具体由 ITIL 建议的各种工作职责描述,请参见 “ 附录四 ” 无法解决问题文档

在研讨会后,不可避免的会存在一些悬而未决的问题,为了避免在此类问题上过多 纠缠导致整个项目计划被拖延,需要将该类问题在于记录在案。

第 7 页 HP Consulting 2.3 研讨会中各种角色

一个研讨会需要 HP 及客户相关人员参加,在讨论过程中每一个人应担负不 同的角色。典型的五种被定义如下: 1.IT运维管理咨询顾问

每一个研讨会的领导者, IT 运维管理咨询顾问需从总体上把握研讨会的进 度,在某些情况下为研讨会的讨论结果作出最终决定,同时对研讨会的 最终结果负责

2.业务专家

业务专家需由客户 IT 部门中负债相应流程执行的人员担任。该员工需具 有与要建立的流程相关的专业知识。例如,帮助台的经理应作为建立突 发事件管理流程的主要成员。

3.咨询顾问

咨询顾问应具有设计的流程相关的专业知识及相关的工作经验。如果在 流程运行过程中应用到工具,则该专家应具备使用该工具的专业知识。技术专家应在流程设计起到决定性的作用。

4.会务

会务的主要责任在于确保相关于各种流程讨论的研讨会能够按计划得以 进行,为了成功地完成任务,该人应对要设计的流程相关的业务领域具

第 8 页 HP Consulting 有充分的专业知识。同时会务应负责准备研讨会所需要的各种设施(会 议室、白板、投影仪等。

5.会议记录员

会议记录员负责记录各研讨会的讨论成果,如运行维护管理流程图、讨 论中无法解决的问题、及流程各步骤的详细说明等,并最终为客户提供 与所设计流程相关的全部文档资料。鉴于以上要求,会议记录员应掌握 IT 运维管理流程设计的基础知识,并能够熟练使用 MS-Word、MS-Excel、及一种流程图设计工具(如 Visio 或 ABC-flowchart。

第 9 页 HP Consulting

在各种讨论的过程中应尽量保证相对较少的参加人数,同时保证所作出的结论是在 经过充分的讨论、论证后得以通过。要充分重视各研讨会的时间安排及会前计划的 制定。在各研讨会进行的过程中,要充分利用 80/20规则和无法解决问题文档来确 认研讨会的顺利进行,并确其保按进度完成。

2.4 研讨会后期的工作

在各研讨会进行的过程中,各工作流程详细描述文档会被指派给相关人员负责但并 不会有充裕的时间进行细化及整理归档。上述工作应留待研讨会后完成。

检查各研讨会所总结出的流程及结果并确保其一致性和连贯性同样非常重要,因为 很多流程所产生的结果通常会被其它相关流程作为创建初期必须考虑的因素。

第 10 页 HP Consulting 第 11 页 HP Consulting

附录一 逻辑运行维护管理流程设计

本文档通过提供逻辑流程的示例流程 , 用于帮助客户设计适应 ” 大集 中 ” 信息化需要的逻辑流程.这些示例流程可以被用于和客户信息化领 导部门讨论特定运维流程的设计.通过收集客户对一系列策略性关键 决策问题与针对 IT 部门的 ” 最佳成功范例 ” 的探讨的结果 , 可以作为逻 辑流程的信息输入.同时 , 在逻辑流程的设计阶段 , 对于客户现有组织 机构中存在的流程也必须加以分析.在这之后 , 示例的逻辑流程可以被 有选择地特定地应用.下述示例流程图中的编号可以根据需要更改.图中的一些链接连至 IT 服务管理模型中的其他流程 , 共同构成一个统一的整体.100开头 : 配置管理流程组 200开头 : 突发事件管理流程组 300开头 : 问题管理流程组 400开头 : 变更管理流程组 500开头 : 服务级别管理流程组

流程的工作流中应用到以下符号: = 工具 = 流程 = 决策 = 联接点

第 12 页 HP Consulting 事件请求管理示例

第 13 页 HP Consulting 第 14 页 HP Consulting

应急事件管理示例

第 15 页 HP Consulting 第 16 页 HP Consulting

问题管理流程示例

第 17 页 HP Consulting 变更管理流程示例

第 18 页 HP Consulting 配置管理流程示例

第 19 页 HP Consulting 服务级别管理流程示例

第 20 页 HP Consulting 附录二 最佳成功范例

ITIL 的最佳成功范例可以被应用于建立 IT 运行维护管理所需要的各 个流程。在客户建立运行维护管理流程的过程中充分应用本文档中所 提供的最佳成功范例将是非常重要的一个步骤。

帮助台管理最佳成功范例

范例 # 101 突发事件管理流程的控制者在企业中的级别应足够高

范例 # 102 除 “SLA” 中规定的内容,任何 IT 部门要解决的问题不应 绕过帮助台来解决

范例 # 103 所有需解决的突发事件要通过帮助台向 IT 部门提交 , 由 服务供应商提供针对应用及技术方面的支持

范例 # 104 所有最终用户的服务请求应由统一的系统记录在案 , 并 由该系统负责 IT 部门内的工作分派,纪效跟踪,问题 升级管理,和质量管理

范例 # 105 帮助台所使用的系统工具应能够将问题管理、变更管 理、及配置管理紧密结合在一起

范例 # 106 帮助台应包涵对问题处理进行跟踪及监控的流程 第 21 页 HP Consulting Confidential 范例 # 107 帮助台的员工应尽最大可能在一线解决用户的问题(80%的问题应在帮助台得以解决

范例 # 108 对所有问题的解决方法应在帮助台所使用的系统工具中 存档 范例 # 109 应采用配置管理数据库

范例 # 110 应及时向提交问题的最终用户通报问题的处理情况.通 过主动式服务所处理问题的进度和情况也应由帮助台员 工与最终用户进行沟通

范例 # 111 帮助台应作为 IT 与业务部门沟通问题处理情况 , 系统变 更状态 , 系统可用性等情况的接口

范例 # 112 必须建立一个针对 IT 运行维护管理的问题升级处理流 程 范例 # 113 变更的状态 , 时间 , 及突发事件造成后果的严重程度应被 综合的考虑以决定是否采用问题升级处理流程

范例 # 114 可以采用电子化手段与客户进行问题处理情况的初步沟 通

范例 # 115 帮助台应全面了解 IT 内部变更的情况 , 包括近期完成的 变更及变更计划的安排

第 22 页 HP Consulting Confidential 范例 # 116 帮助台有责任通知最终用户变更的计划及变更实施的详 细情况 范例 # 117 IT 部门内部资源的分配应基于突发事件对日常业务运 作的影响程度

范例 # 118 应确定最终用户对突发事件解决方案的满意程度 范例 # 119 在帮助台工作的员工应具有良好的与人沟通的能力

范例 # 120 在帮助台工作的员工应具有支持多种操作系统平台的经 验(HP-UX, NT, Windows95,etc.范例 # 121 在条件允许的情况下,帮助台系统工具应能够自动地接 收系统监测工具提供的警告信息

范例 # 122 帮助台应具备识别已知问题的能力,及完善的与问题管 理功能衔接的接口

范例 # 123 完整的描述当前 IT 为其它部门所提供的服务、服务级 别、产品、流程的文档

范例 # 124 当帮助台的经理不在岗位时,应有相应人员代理执行其 职责 范例 # 125 应建为所有最终用户服务的电子信息布告栏 第 23 页

HP Consulting Confidential 图

范例 # 127 应为帮助台员工建立突发事件归类准则 问题管理最佳成功范例

范例 # 201 ITIL 强烈推荐 IT 部门应用电子化的问题管理工具

范例 # 202 为了有效地支持 IT 与业务部门之间的服务级别协议应 具有完善的问题升级处理流程

范例 # 203 针对造成 IT 系统的每一个问题,应找到其根本原因

范例 # 204 应记录,利用,及分析所发生问题的历史记录并将相关 信息存档 范例 # 205 对每一个已发生问题的解决方案应记录在案

范例 # 206 应将发生的问题归类并找出造成各种问题的根本原因

范例 # 207 在问题升级管理流程中应规定何时将问题处理情况通报 给最终用户 范例 # 208 针对问题的解决方法应在争得最终用户同意的前提下实 施,在需要时与变更管理流程紧密结合

第 24 页 HP Consulting Confidential 需人力资源

范例 # 210 应将问题分类,并为各类问题定义代码 配置管理最佳成功范例

范例 # 301 鉴于配置管理的重要性,建议由 CIO 或 IT 经理直接做 配置管理流程的负责人

范例 # 302 配置管理数据库中信息的详细程度应取决于维持当前信 息所需费用的多少

范例 # 303 配置管理数据库应与资产管理系统和变更管理系统紧密 地结合在一起使用

范例 # 304 针对所有需要管理的资产应定义配置规则,使配置管理 数据库能够为变更管理提供良好的基础

范例 # 305 配置管理数据库将为所有 IT 运行及维护管理流程提供 所需信息,特别是针对问题和变更管理流程

范例 # 306 所有配置的变更应在获得授权的前提下得以实施,同时 必须保证具体实施由指定的专人负责

第 25 页 HP Consulting Confidential 范例 # 307 IT 部门内所有的物理设备及软件的清单必须保存于一个 数据库管理系统中

范例 # 308 应设计确认物理设备序列号的流程 变更管理最佳成功范例

范例 # 401 IT 部门内应指定级别足够高的相应人员负责变更管 理。作为 IT 部门内变更的管理者,该经理应负责制订 变更计划,监督变更实施等工作

范例 # 402 IT 部门内应具有单一的变更管理功能,负责控制 IT 运 行及维护过程中会发生的变化

范例 # 403 变更管理和问题管理应从工具和流程两个层面紧密地结 合在一起 范例 # 404 配置管理应能够帮助确定与 IT 基础结构中与产生变化 CI 相关的其他部分

范例 # 405 任何 IT 所接受的变更需求应交变更管理控制小组讨论 并确定其实施计划

范例 # 406 在一个变更得以实施之后,配置管理流程应负责更新配 置管理数据库

第 26 页 HP Consulting Confidential 范例 # 407 变更管理者应确保帮助台能清楚、及时地获得所有 IT 运行及维护过程中所涉及到的于变更相关的信息

范例 # 408 除特殊的紧急情况外,任何与解决软件问题相关的变更 应提交正式的变更需求

范例 # 409 所有与 IT 运行及维护相关的变更均应在得到变更管理 者授权的前提下才可实施

范例 # 410 所有变更的需求都应在提交给变更管理控制小组审核前 被授予相应的优先级

范例 # 411 企业的 IT 部门应承担全部与变更管理相关的责任,包 括 IT 部门内已外包的部分

范例 # 412 企业内应成立变更管理控制小组

范例 # 413 变更管理控制小组应包括所有 IT 部门内的负责人,及 需 IT 支持的业务部门的负责人(或由其指定的代表

范例 # 414 变更需求的受理和实施应受到配置管理系统的严格控制

范例 # 415 对 IT 部门的变更带给其它业务部门造成影响的评估应 充分利用配置管理所提供的信息

范例 # 416 变更流程的批准及相关工作进度安排应及时与有关部门 及人员进行沟通

第 27 页 HP Consulting Confidential 范例 # 417 在安排变更计划时应充分利用配置管理数据库,及历史 变更记录 范例 # 418 作为存档资料,变更历史记录应与问题管理,配置管理 及突发事件管理(帮助台紧密地结合在一起使用

范例 # 419 变更实施后的分析及分析后产生的变更管理报告应被视 为改进变更管理流程的重要工具

范例 # 420 应根据企业的具体需求每周或每月向负责变更实施的员 工及受变更影响的最终用户通报被批准实施的变更请求 及计划实施的项目

范例 # 421 变更管理的负责人应负责定期组织变更管理控制小组会 议

范例 # 422 初少数紧急特例,任何变更在发生在生产系统环境前都 要经过测试 范例 # 423 应为需进行的测试提供所需的测试环境

范例 # 424 任何变更在发生在生产系统环境之前都需要得到变更管 理者的授权 范例 # 425 应为帮助台员工在新的软件投入使用前提供相关的培训

范例 # 426 应设计单独的处理紧急变更需求,但应尽量把此类需求 控制在最小的范围内

第 28 页 HP Consulting Confidential 第 29 页 HP Consulting Confidential 范例 # 427 应选用适当的软件来支持和管理变更管理流程 服务级别管理最佳成功范例

范例 # 500 服务级别负责人应负责 IT 部门内服务级别的计划和实 施 范例 # 501 服务级别管理应负责协调 IT 与其它业务部门的关系

范例 # 502 与客户的服务级别协议的建立主要依赖于对 IT 系统可 用性 , 系统能力 , 及发生意外可能性的精确分析.范例 # 503 服务级别协议中应包括帮助台为最终用户提供的服务级 别

范例 # 504 服务级别管理的负责人应坚持以服务级别协议为准则 , 尽量将对服务质量的影响减少到最低

范例 # 505 服务级别管理的负责人应参加评估变更对服务质量产生 的影响(分别包括计划变更阶段的影响和变更实施阶段 的影响.范例 #506 应将服务级别管理的目的 , 好处 , 及需求及时地与最终用 户进行沟通

范例 # 507 在全面考虑不同级别业务需求的前提下 , IT部门为用户 提供服务的优先级应被提前定义好

第 30 页 HP Consulting Confidential 范例 #508 必须计划及考虑与第三方厂商的服务合同 , 其内容必须 能够支持 IT 部门与最终用户规定的服务级别协议

范例 # 509 必须保证 IT 系统平台的处理能力能够满足最终用户对 服务级别的需求

范例 # 510 至少每三个月应评估服务级别管理工作的效力 第 31 页 HP Consulting 附录四 职位及职责

为了帮助客户清楚地了解要建立的流程中对人员的需求,我们以逻辑 流程图中所需职位为例,列出了相关职位及任务,以供客户有关领导 参考。

帮助台相关职位及职责 : 帮助台员工

− 登录服务请求(突发事件,变更需求,一组负责在系统中登录 服务请求员工中的一员

− 将服务请求分派给适当的服务台员工

− 与服务请求的提交者或其其他相关用户进行直接的沟通,通报问 题的处理情况

− 跟踪服务请求的处理过程以确保在规定的时间内解决问题,同时 在帮助台系统里更新相应信息

− 问题解决后,在系统内关闭该请求之前要确认服务请求的提交者 对解决方法是否满意

− 在需要时将疑难问题通过升级处理流程提交给后台专家 支持专家

− 在规定的时间内解决服务请求(突发事件,变更需求 − 在需要时将问题提交给管理层相关人员 针对突发事件 : − 为帮助台员工提供及时的问题状况通报 第 32 页 HP Consulting − 对利用“ workarounds" 解决的服务需求,在资源及时间允许时 应找到问题根源

− 将服务请求分派给响应的支持小组或专家 − 将问题的解决步骤文档化,并录入帮助台系统 − 在需要时及时利用其它资源帮最终用户解决问题

− 问题解决后,在系统内关闭该请求之前要确认服务请求的提交 者对解决方法是否满意

− 判断以解决的突发事件有无可能再发生,同时决定是否启用问 题管理流程提交一个问题

问题管理相关的职务及职责 问题管理经理

− 为一线人员解决疑难问题

− 发现并消除需长时间解决的问题。利用最终用户调查及其它资源 发现问题 − 根据帮助台提供的信息找出发生频率高的问题,由用户人为失误 造成的问题,及 IT 系统基础平台中存在的技术问题

− 选择并控制对企业日常运行影响很大的问题

− 发现造成问题的根本原因,将问题分派给有能力将其解决的 IT 职 能部门 − 跟踪问题解决的过程

− R 将关键问题的解决状态及时地通报给相应的 IT 及业务部门 支持专家

− 找出造成问题的根本原因,测试解决方案,同时确保问题得以解 决 − 通常会是某一方面的技术负责人,或某一应用软件专家

第 33 页 HP Consulting − 在需要时请其它技术专家介入,以确保问题得以及时解决 变更管理相关的职务及职责

变更请求者

− 发现变更需求,并判断哪些需提交给变更管理领导小组 变更管理经理

− 管理及协调 IT 部门内所有与变更需求提交、变更控制、跟踪、及 解决相关的行为

− 分派具体任务给变更的执行者

− 与变更执行者沟通整体变更的执行情况 变更执行者

− 计划、执行、测试相应的变更 − 参与变更的评估,回顾会议 变更实施者

− 负责文档资料的更新工作

− 参与变更的评估,回顾会议。帮助建立变更后系统环境的支持结 构 变更管理领导小组

− 解决并消除变更需求及变更之间的冲突

− 从各个部门及业务整体角度出发 − 从合法性的角度审核变更需求 − 确定变更需求是否会被批准实施 第 34 页 HP Consulting − 确定被批准的变更需求的优先级 − 决定变更实施的计划安排 − 提供变更评估大纲

第 35 页 HP Consulting 配置管理相关的职务及职责 置管理经理 − 为 IT 运行维护管理提供 − 审批对配置管理数据库库结构的变更 − 定义变量域的使用方法 − 定义配置项的类别 − 建立对配置管理数据库的安全控制手段 − 审核新的配置项与其它部分的关系及结构 − 定义标准报告格式及分发渠道 − 定义配置管理数据库的建立策略、目标及考核标准 数据库管理员--配置管理数据库 − 监测及确保数据库的完整性和性能 − 完成标准报告 − 监测自动数据传输 配置管理员 − 数据录入 − 生成配置管理经理所需要的报告 − 通过手工操作增加及更改配置项 网络/系统经理 − 负责 IT 物理环境的维护 − 确保 IT 基础结构有效运转 − 负责一部分应用或 IT 基础结构的维护 第 36 页 HP Consulting Confidential 服务级别管理相关的职务及职责 关键用户 − 向 IT 部门提出业务需求的业务部门经理 − 有权向 IT 提出业务需求 − 每一种 IT 向业务部门提供的服务应对应一个“关键用户” 服务管理经理 − 负责一或多项 IT 要提供给业务部门的日常服务（应用系统）− 负责监测与衡量 IT 提供的服务是否满足与最终用户商定的服务级 别，同时确保 IT 相关人员与业务部门定期进行研讨，以确保最终 用户满意度 业务经理 − 负责业务部门的日常运作管理 − 提交 IT 服务提供状态报告 系统平台管理员 − 从系

统平台的角度确保一或几个部分 IT 基础结构的可用性能满足 服务级别的需求 服务级别管理流程负责人 − 从企业全局的角度维护服务级别管理流程 − 负责处理最终用户的投诉 第 37 页 HP Consulting Confidential 附录五 客户运维流程构建三年规划图 IT运行与维护流程构建三年规划 集中实施阶段 第一年 IT规模管理 服务级别管理 投入运行 帮 助 台/突发事件管理 系统的集中 运行与维护 可用性管理 实施与测试 问题管理 成本管理 变更管理 制 订IT服务发展计划 配置管理 业务与IT战略整合 制 订IT战 略 第二年 第三年 业务评估 客户管理 第 38 页 HP Consulting Confidential

第二篇：运维管理系统建设

ITIL提升中国电信运维管理系统建设

ZDNet CIO频道 更新时间：2008-01-25 作者： 来源：CSDN 本文关键词： 中国电信 ITIL 运维管理

运维管理是电信运营商主要的生产和管理活动之一。运维管理系统建设和运营的好坏直接影响到电信运营的整体成本、管理水平和服务水平。因此，近两年来，各大电信运营商纷纷对现有的运维系统进行改造。

中国在电信领域的增长速度超过了其GDP增长的速度。正是电信快速的增长，推动了运维系统的发展。如何更有效地利用现有的资源，提高运营维护的工作效率，提高整体服务质量是目前各大运营商面临的普遍问题。毫无疑问，中国电信在运营维护方面，也面临相同的问题。建设新一代中国电信运维管理系统，成为解决目前运维管理问题的唯一方案。

根据我们长期在电信领域的实践，下面的几点经验，值得我们在中国电信运维系统的建设中更加关注。

一、采用ITIL作为运维系统的方法论

IT基础架构库（ITIL-ITInfrastructureLibrary），被誉为IT服务管理的圣经，其中包含了总结国际大公司在IT服务管理中的经验并得到证明的IT服务计划和运营的最佳实践框架。

ITIL已经为《财富》500强的一些企业所采用，并取得了预期的效果。加特纳（Gartner）和国际数据集团（IDC）等世界权威研究机构的调查研究表明，企业通过在IT部门实施最佳服务管理实践，将因重复呼叫、不当的变更等引起的延误时间减少了79%，每年每个终端用户平均节约800美元的成本，同时每项新服务推出的时间也缩短一半。

要成为国际一流的企业，就要吸取国际一流企业的成功管理经验，借鉴其管理手段。因此，中国电信在运维管理系统的建设，也应确立ITIL在系统建设过程中的方法论地位，吸取ITIL中的成功经验。

作为众多国际大型企业成功实践的积累，ITIL使我们找到了解决运维流程规范的方式和方法。可是，如何更好地运用ITIL这一经典的方法论呢？我们认为应该注意两点：

1)ITIL是从实践中得来的精髓，不是僵化的教条，应该结合实际情况去运用ITIL，建立更加适合中国电信的流程规范，而不是照抄照搬。

2)由于ITIL理论博大精深，不可能在短期内在企业中全面实施。应该根据实际情况，选取实施重点，逐步实施，逐步完善。

在中国电信运维系统建设中，应该深入理解ITIL的核心理念，结合电信运维的现状，解决核心和关键问题，逐步实现对运维的科学管理。

二、ITIL理论与实际情况相结合，注重工作流程细节的设计和优化，是系统建设的关键

理顺工作流程、提高服务效率是新运维系统建设的主要内容之一。

在工作流程的制定过程中，容易陷入以下两个极端。

1．盲目照搬流程。作为方法论的ITIL，本身含有大量的成功实践框架。但是，正如前面所说的，ITIL是从实践中得来的精髓，不是僵化的教条，盲目照搬，只能使得工作流程不切合实际，并流于形式，对系统的贯彻和执行产生不好的影响。

2．完全遵照现有流程，实现其电子化。虽然这样更符合目前的工作习惯，可能容易为运维人员所接受，但是，仍然解决不了目前运维所存在的一些问题。例如，我们在项目实施中曾遇到“工单在部门之间的重派”的问题。在当前手工作业的工作模式中，各单位将不属于本单位处理范围的工单，或部门需要其他部门配合的工单，均提交给故障处理的负责人，由该负责人向其他单位进行转派和重派。这种处理方式，主要便于手工作业条件下负责人及时了解项目处理状况。在建立运维系统后，负责人可以通过运维系统随时了解到故障的处理状况，每次重派和转派之前，对负责人的回复变成了一种无效的工作，大大降低了事件的处理效率。如果仅仅将目前的手工作业电子化，那么故障处理的效率仍然没有得到有效的提高。

因此，将ITIL理论与实际情况相结合，注重工作流程细节的设计和优化，是系统建设的关键。

三、树立主动服务观念

在现行的运维工作中，我们经常遇到这样的情况：一方面是运维部门疲于应付各种突发事件，加班加点处理各种重复事件，工作繁重，身心疲惫；一方面是客户代表不断抱怨和投诉“技术人员服务水平太低”。二者不可调和的矛盾，是新运维系统要解决的重要问题。

传统的运维方式给人的印象是：故障发生前，维护人员似乎无所事事；故障发生后，则是手忙脚乱。这就是被动服务给人们留下的印象，运维人员是在被动地等待故障的发生。在新的运维系统中，我们必须改变原有的运维方式，变被动服务为主动服务。

在主动服务模式下，运维人员主动地监控系统的变化，对日常工作及故障处理完成后主动进行问题分析，对系统的变更风险进行评估。在新系统中，可以通过种种技术措施，使得运维工作从被动服务转移到主动服务，如：增加变更管理流程以防范变更风险。

在日常运维工作中，变更工作是在所难免的。例如，新的系统安全漏洞被公布，为了保证系统安全，就需要安全系统补丁，而这种变更给系统带来的风险则是难以估计的。例如在安装补丁后，有时会产生大量莫名其妙的问题。这么一个简单的例子已经可以说明，如果没有很好的风险防范手段，系统变更将给我们的日常运维工作带来大量的问题，后果往往是难以想象的。在新系统中，我们可增加变更管理流程。在变更管理流程中，变更方案需提交变更经理，由变更经理组织由专家组成的变更顾问委员会（CAB）对变更进行风险评估，在评估通过后才能够进入变更的实施过程。变更管理是防范变更风险的最好办法。

当然，主动服务是一种理念，在这种理念下，我们可以定义更多的流程，如问题管理流程，对系统中存在的隐患问题进行挖掘，防患于未然。总之，我们应该树立这样一个理念，在各流程的定义中进行运用，主动地提早发现系统存在的风险和隐患，减少突发事件的发生。

四、从平台到业务的全面管理

网络管理是运维系统的组成部分。对系统的监控也是运维的主要业务之一。以往网管系统实现了对平台的监控，可是在实际运维工作中，平台往往只有少数的几个系统管理员负责，大多数业务人员更多地是面对业务系统。对于业务的监控和管理，是业务人员更加关心的问题。因此，在网管系统中，应加入业务监控的内容。

需要注意的是，业务是建立在平台的基础之上的，而不是孤立存在的。因此，监控中，应强调业务监控与平台监控密不可分的联系，从业务的角度出发，建立平台与业务的关联关系。在故障发生时，应能够即时描述对业务的影响程度，能够描述故障的影响范围。

例如：采集源的某台交换机产生异常，除了可以看到交换机告警外，我们还应该能够在业务拓扑图中直观看到，采集系统受到影响，同时采集、预处理、分拣等相关业务也不同程度受到影响。其影响程度，能够通过不同的颜色直观地展示出来。

只有这样才能够更加直观而全面地反映系统的运行状态，反映业务的运行情况。能够帮助运维人员在故障发生时，快速修复关键部件，减少故障带来的损失。

五、建立科学的激励与监督机制

多年来，系统的使用和推广问题成为系统能否得到良好运用的一个重要问题。

假设：我们制定了变更管理流程，但是，变更管理没有被很好地执行，而只是流于形式，则风险的防范也只能是停留在理论上的空谈。

在运维系统建设过程中，建立了一整套科学的考核制度，以激励运维人员更有效地提高服务质量和服务水平，是至关重要的。

对运维人员的考核，并不能就管理论管理，应该从客户服务的角度出发，以客户满意为前提，进行考核。例如，根据每个部门的服务水平，制定了服务时限。假设，某个用户投诉，需要多个部门协同进行处理。在处理过程中，各部门互相推托，虽然工单在各部门的停留时间没有超过部门承诺的时限，而整体处理时间已经超过了运营商对该用户承诺的处理时间。为了杜绝这种现象的出现，我们应该从用户的角度出发，进行各部门处理时间的分段计算。计算结果将反映在每月故障处理情况的统计报告中，而这些报告直接与各部门、各单位的绩效考核挂钩。

通过这样的考核机制，形成对员工日常工作的科学评价，既调动了员工积极性，又提高了工作效率和服务质量。

第三篇：运维管理系统方案

运维管理系统方案

概述

伴随着企事业网络规模的不断扩大，企事业服务器的增多，企事业管理的信息化，企事业网络管理也变的越来越重要。一旦网络、服务器、数据库、各种应用出现问题，常常会给企事业造成很大的损失。怎样能7x24小时检测网络系统的运行情况，避免各种故障的发生，改进传统的网络管理方式来适企事业信息化发展的需要？

因此，运维管理系统就有他的必要性。一个完备的运维管理系统能够提供7x24小时检测网络、服务器、数据库、各种应用系统，及时发现将要出现的问题，并通过短信、Email、声音报告给运维管理人员。运维管理人员就可以及时排除故障，避免造成重大损失。

        运维管理系统的功能：

故障发现与警报；

记录日常运维日志信息； 服务器故障统计；

服务器软硬件信息统计； 服务进程管理；

将数据信息存储到数据库，并使用图形方式直观的展示出来； 权限、密码管理； 将数据生成报表。运维管理系统的特点：        邮件和短信实时故障报警；

B/S结构，能够通过web对远程服务器下达指令；

监控服务器和被监控服务器之间通过python socket来发送信息； 统计日常故障处理，以便下次出现同样故障时能够更快的解决问题； 实现自动化管理和自动化监控； 安全管理服务器性能； 操作流程统计与管理。

第四篇：运维管理各个流程

综合所学习的ITIL的相关知识，请从人员角度上进行分析，以事件管理、变更管理、配置管理和问题管理为例说说各管理流程中的人员角色及其职能。

答：1.事件管理流程

（1）服务台人员：负责接收所有的事件，对事件进行初步的处理，并根据实际情况将事件分派到合适的一线支持工程师。

职能：①在指定的响应时间内响应所有服务台热线电话、邮件、工单等事件报告；

②完整记录所有接收的事件信息，包括：记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等；

③为事件进行适当的分类、为事件分配优先级等属性；

④尝试使用知识库、初步诊断、分析相关信息等方式解决事件；

⑤如果服务台不能解决事件，应当将事件分配给最合适的一线支持小组或来处理； ⑥检查事件记录的处理进度，保持与用户的联系，适时通知事件处理进展；

⑦在事件处理过程中，催办事件处理进度

⑧与用户确认事件解决方案及用户满意度反馈，关闭事件。

（2）一线支持人员：负责对服务台无法解决的事件进行快速有效的分析，提出解决方案以尽快恢复服务，并在必要时提供现场支持。

职能:①决定需要采取何种措施恢复服务并实施有效的行动

②必要时提供现场支持

③根据优先级提供有效的解决方案

④更新事件解决信息，已解决的事件转回服务台，由服务台关闭事件

⑤如果一线不能解决这个事件，应当决定选择最合适的二线支持小组/人员来处理

（3）二线支持人员：负责提供对一线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。

职能：①进行事件的深入调查研究

②根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动③必要时引入供应商的支持

④及时提供有效解决方案

⑤与其他二线小组合作，确定解决方案

⑥已解决的事件转回服务台，由服务台关闭事件

（4）三线支持人员：

职能：①从研发的角度进行事件的研究

②根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动，如发布临时补丁等

③及时提供有效解决方案

④已解决的事件转回服务台，由服务台关闭事件

（5）事件经理：负责事件解决过程中的协调和监控，以及事件升级的判断以及具体执行。职能：①负责对重大、紧急事件的解决协调资源，保证故障的最终排除

②当事件优先级为高或者事件将超过规定的时限，负责按照升级方法对事件进行处理确保有效协调资源，促进各类角色小组（如一线支持、二线支持）快速恢复正常服务

③确保和问题管理流程经理的有效合作

④确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题

（6）流程负责人：事件管理流程负责人从宏观上监控流程，确保事件流程在信息技术中心范围内被正确的执行。当流程不能够适应长期发展需要时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。

职能：①确定管理流程的衡量指标

②确保事件流程能够取得管理层的参与和支持

③确保事件流程符合企业实际状况和公司IT发展战略

④总体上管理和监控流程，建立事件流程实施、评估和持续优化机制

⑤确保事件流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行分析、找出缺陷、进行改进(假如增加或合并流程的角色)，从而实现可持续提高

2.变更管理流程

步骤：（1）启动、接受和分类：记录变更信息；鉴别变更影响；提交变更请求表格（RFC）

（2）评估和审批：从IT和业务观点上作出变更的评估和审批；批准或拒绝RFC

（3）计划和分派：建立变更计划；确定变更的实施日期；将变更分派到技术人员

（4）实施：最后实施的评估和审评/拒绝；根据变更计划实施；成功实施后作出记录；如果失败作出回撤

（5）关闭变更：检查实施是否成功；关闭FRC

（6）处理例外的变更

变更管理角色：

（1）变更管理流程负责人：变更管理流程解决方案的负责人，对于整个变更流程方案的结果承担责任，并有相应的权限

（2）变更经理：协调变更管理步骤的日常操作；

负责变更管理的质量，也是流程执行过程中的协调人，负责协调相关的资

源、作为变更流程与其他流程经理之间沟通的桥梁；

管理变更的日程安排

（3）变更请求者：表达变更的要求。提供初步的信息。验证变更的结构和提交RFC。

（4）变更受理者：变更请求的责任人，负责构建、测试变更，并制定实施计划、恢复计划等。(班组长或是部门经理)

（5）变更实施者：变更实施者，负责按照计划实施变更的内容（包括必要时的恢复步骤）。

（6）变更审批者：根据冲击评估，批准或拒绝RFC

3.配置管理角色：

（1）配置管理流程负责人 ：是整个配置管理流程的责任人，对整个流程的成果负责，并拥有相应的权限.（2）配置经理 ：协调配置管理的日常操作活动，负责整个流程的质量和完整性。也是与其他流程经理的交流界面。

（3）配置管理员：负责配置管理数据的完整性和准确性，确保为其他操作管理提供准确的信息。

（4）配置报表负责人：基于标准的和特定的需求开发配置数据报表，并为配置管理的客户产生相关报表。

4.问题管理角色：

（1）问题记录人员：问题记录和分类将问题与现有事件关联并记录下来，以帮助划分问题解决方法的优先级。记录问题后，评估对业务的影响并确定解决方案的紧急程度。此评估确定问题的分类

（2）问题审查人员：问题调查和诊断，此过程处理问题的调查和对根本原因的诊断。根据数据来帮助问题管理团队评估解决问题的根本原因所需的资源和技能，包括对需要额外的规划、协调、资源和通信

（3）问题控制人员：问题的错误控制，更改 IT 组件或过程，解决影响 IT 基础结构的已知

错误，从而防止事件再次发生

（4）问题反馈人员：将问题最终解决方案反馈给服务台，并进行记录

第五篇：系统运维管理-IT基础设施运维管理规范

IT 基础设施运维管理规范 文件编号：运维-002-V1.0

目录

运维管理规范--------------4 1.目的------------------------4 2.适用范围------------------4 3.规范性引用及参考-----4 4.本文术语，定义和缩略语---------------------------5 5.基本要求------------------6

5.1运维管理原则-----6 5.2制度和流程管理6 5.5供应商管理--------7 5.6督促检查-----------7 6.运行维护------------------8

6.1日常操作及监控分析--------------------------8 6.2 数据与介质管理-8 6.3机房管理-----------9 6.4 网络管理----------9 6.5 弱电管理---------10 6.6桌面维护----------10 6.7服务器及系统变更----------------------------11

6.8 配置管理---------12 6.9 事件与问题管理 12 7.应急管理-----------------12

7.1应急准备----------12 7.2应急处置----------13

运维管理规范

1.目的

为规范公司运维工作，使相关工作具有持续改善及相互协作性，同时加强计算机设备的管理及维护，确保维修工作的及时性，降低计算机设备的报修率，实现业务与技术的融合，将业务部门与IT 部门紧密结合在一起，根据公司管理要求及计算机应用的需要，由运维部制定。

2.适用范围

本规范规定了运维管理工作的要求。

本规范适用于维信理财集团(中国)总部，包括全国各分部及门店。

3.规范性引用及参考

◆ IT 服务管理国际标准ISO/IEC 20000 ◆ 企业获得ISO/IEC 20000认证的权威指南 ◆ 全球著名IT 服务管理书库（ITSM Library）◆ IT 服务质量管理原则

◆ 理解ISO/IEC 20000在IT 服务中的地位 ◆ ISO/IEC 20000规范和实践准则 ◆ IT 服务管理国际标准ISO/IEC 20000 ◆ GB/T 20269—2006 信息安全技术 信息系统安全管理要求

◆ ISO 31000:2009 风险管理 原则和指南（Risk management--Principles and guidelines）

◆ JR-T 0060—2010 金融信息系统安全等级保护基本要求 ◆ JR/T 0074-2012 金融IT 服务管理基本规范 ◆ 中国金融标准化报告（2011）

4.本文术语，定义和缩略语

1、IT： Information Technology 信息技术

2、DNS： Domain Name Service 域名服务

3、DHCP： Dynamic Host Configuration Protocol 动态主机配置协议

4、VPN： Virtual Private Network 虚拟专用网

5、OA： Office Automation 办公自动化系统

6、ISO： International Organization for Standardization 国际标准化组织 编订日期：30.7.2014 批准日期: 生效日期：

7、故障： IT设备或系统丧失规定的功能，导致服务中断或降质，或对正常运行造成潜在威胁。

8、异常： IT设备或系统的状态发生超出预期的变化或性能指标参数超出正常范围，有可能引发或已经引发故障，需要引起运维人员关注或处理。

9、资料： IT设备或系统的运行记录，包括IT 设备或系统的配置、故障历史记录、软硬件扩容或调整记录、权限变更申请记录等。

10、运行维护：本规范中的运行维护包括IT 基础设施维护、IT 应用系统运维维护、安全管理、网络接入、内容信息以及综合管理等。

5.基本要求

5.1运维管理原则

公司按集中与分散相结合的原则，设立机房、各部门配备电脑。计算机系统本着“总体规划、分步建设”的方式实施建立。

计算机系统建设应综合考虑成本、费用、效率、效果、先进性及适用性，选择最优技术、经济方案。

5.2制度和流程管理

运维管理制度应包括但不限于机房管理、网络与系统管理、数据和介质管理、配置管理、安全管理、监控管理、文档管理、设备和软件管理、供应商管理等制度。

运维操作流程应包括但不限于日常操作、事件处理、问题处理、系统变更、应急处置等流程。

5.3 文档管理

对运维过程中涉及的各类文档进行管理，可按照制度文档、技术文档、合同文档、审批记录、日志记录等进行分类，并妥善保存。5.3.2 对文档的版本应当进行控制。

文档在使用时应能读取、使用较新版本，防止作废文件的逾期使用。

5.4设备和软件管理

建立计算机相关设备和软件管理制度，对设备和软件的使用、安装、维修（升级）等进行规范。明确设备和软件管理责任人。对设备进行标识，标识应放在设备明显位置。

规定设备和软件的使用年限，定期进行盘点，并对设备状态进行评估和更新。

对外送设备的维修进行严格管理，防止数据泄露。

对拟下线和拟报废设备的存储介质中的全部信息进行清除或销毁。对正式下线设备和软件交指定部门统一管理、保存或处置，并保留相应记录。设备和软件报废应符合公司现行资产管理规定。

5.5供应商管理

对供应商支持运维服务的相关活动进行统一管理。

在与供应商签订的合同中明确其应承担的责任、义务，并约定服务要求和范围等内容。

应定期收集、更新供应商信息，组织对供应商的服务质量、履约情况、人员工作情况等内容进行评价，并跟踪和记录供应商改进情况。加强运维外包服务管理，主要包括：

a)明确外包公司应当承担的责任及追究方式；

b)明确界定外包人员的工作职责、活动范围、操作权限； c)对外包人员工作情况进行监督和检查，并留存相应记录； d)对驻场外包人员的入场和离场进行管理； e)定期评估外包的服务质量； f)制定外包服务意外终止的应急措施。

5.6督促检查

定期检查审计，对运维制度的执行情况和运维工作开展情况定期进行检查和审计，以督促运维工作持续改进。

指定人员负责对日常操作执行情况进行检查，确保运维管理制度和操作流程的有效执行。对检查和审计结果采取纠正、预防措施。

6.运行维护

6.1日常操作及监控分析

未经许可，任何人不得随便使用电脑及相关设备。不得更换电脑硬件和软件，拒绝使用来历不明的软件和移动设备。

电脑发生故障时，使用者作简易处理仍不能排除的，应立即报告IT，非专业管理人员不得擅自拆开机箱或调换设备配件。

计算机及其相关设备的报废需经过IT 部门或专职人员鉴定，确认不符合使用要求后方可申请报废。

运维应采取各种监控措施，配备视频、语音、系统监控和报警工具，对影响信息系统正常运行的关键对象，包括机房环境、网络、通信线路、主机、存储、数据库、核心交易业务相关的应用系统、安全设备等进行监控。

主要监控指标具体如下：

a)机房：电力状态、空调运行状态、消防设施状态、温湿度、漏水、人员及设备进出等；

b)网络与通信：设备运行状态、中央处理器使用率、通信连接状态、网络流量、核心节点间网络

延时、丢包率等；

c)主机：设备运行状态、中央处理器使用率、内存利用率、磁盘空间利用率、通信端口状态等；

d)存储：设备运行状态、数据交换延时、存储电池状态等；

e)安全设备：设备运行状态、中央处理器使用率、内存利用率、端口状态、数据流量、并发连接数、安全事件记录情况等；

6.2 数据与介质管理

配合数据应用部，对核心业务数据进行周备份，并每季度进行恢复性测试。

对设备和人员出入进行管理。进入机房应限制和监控其活动范围，并有专人陪同；未经批准不得接入生产环境。

6.3机房管理

对机房环境、供电、空调、消防、安防等基础设施的运行维护、设备和人员出入、机房工作人员等进行规范管理。

应指定机房管理负责人。确保机房环境整洁和安全，包括：

a)应定期检查防水、防雷、防火、防潮、防尘、防鼠、防静电等措施的有效性；

b)应保持机房环境卫生，设备摆放合理，归类； c)不得随意出入机房。

d)未经审批不得接入其它用电设备。

6.4 网络管理

确保网络、系统的正常运行。网络管理应包括： a)绘制网络拓扑图，并保持更新；

b)应保持网络设备的可用性，及时维修、更换故障设备； c)应负责网络系统的参数配置、调优； d)应定期对系统容量进行检查和评估；

e)应定期检查网络设备的用户、口令及权限设置的正确性；

f)应定期对整个网络连接进行检查，确保所有交换机端口处于受控状态； g)应对网络信息点进行管理，编制信息点使用表，并及时维护和更新，确保与实际情况一致。计

算机网络跳线应整齐干净，跳线标识清晰；

h)应制定网络访问控制策略，应合理设置网络隔离设施上的访问控制列表，关闭与业务无关的端口；编制文档并保持更新；访问控制策略的变更应履行审批手续。

权限管理应包括如下要求：

a)权限分配应履行审批手续，权限设置后应复核； b)应按照最小安全访问原则分配用户权限； c)应在用户账户变化时，同时变更或撤销其权限； d)应定期检查权限设置的有效性。

6.5 弱电管理

严格按图纸施工，在保证系统功能质量的前提下，提高工艺标准要求，确保施工质量。质量检查制度，现场管理人员将定期进行质量检查并贯穿到整个施工过程中。统运行验收：当设备安装完毕并调试运行无误后，由公司派现场调试人员进行系统联调，并向上级汇报调试结果。运维对弱电设备的综合管理，包括技术资料、档案的收集。同时，每月一次对弱电设备运行状况进行检查，并及时处理汇报问题。

6.6桌面维护

日常数据注意事项：

a.个人文件（Excel、Word、PDF 等）建议员工不要存放在系统盘（通常为C 盘），可以存放在其它盘符。

b.工程师可通过多种方式或途径来告知员工如何进行日常文件的备份，如：口述、邮件、培训等。

c.未经许可，禁止使用U 盘，移动硬盘，手机或其它外设，如：网盘、邮箱等，盗取公司内部文件。

重装系统前注意事项：

a.询问用户有哪些相关数据需要备份，如桌面、我的文档、收藏夹、邮件等。b.用户Email 的备份：如客户端为Outlook 则导出相关OST 或PST 文件；硬件损坏需更换或维修时，运维人员进行测试，明确是否真实异常，不可随意更换。

关于账号、权限、密码

a.必须严格按照公司制定的IT 策略进行管理，不可私自制定规范。b.禁止私自把个人管理员权限借给他人或告知他人。

c.禁止为他人开设规定以外的权限，如：本地管理员、其他部门目录访问权限、上网权限、电话权限等。

d.更改任何类型用户权限时需得到相关审批层级确认才可执行。e.如电脑无特殊应用需求，则一律为“user”普通权限。

f.人员离职时，总部和分部应及时通过OA 确认，删除离职人员的相关账号与信息。

g.妥善保管自己所知的密码。

6.7服务器及系统变更

不得在服务器上使用带有病毒和木马的软件、光盘和可移动存贮设备，使用上述设备前一定要先做好病毒检测；不得利用服务器从事工作以外的事情，无工作需要不得擅自拆卸服务器零部件，严禁更换服务器配套设备。不得擅自删除、移动、更改服务器数据；不得故意破坏服务器系统；不得擅自修改服务器系统时间。

使用空闲主机，对服务器系统补丁进行升级测试，运行平稳后，各服务器升级安装补丁，弥补系统漏洞；为服务器系统做好病毒及木马的实时监测，及时升级病毒库。

管理员对管理员账户与口令严格保密、重要数据库，网站，APP 等服务器由研发配合定期修改密码，以保证系统安全，防止对系统的非法入侵。

任何无关人员不得擅自进入主机房，需要进入的须征得服务器管理人员同意。应注意保护机房内的设备和物品，未经允许的非管理人员不得擅自操作机房内设备。

严禁携带易燃易爆和强磁物品及其它与机房工作无关的物品进入机房，机房内严禁吸咽。除管理员外，任何人不得随意改动服务器内系统及环境配置。

除系统管理员或授权参加系统管理的人员外，任何用户不得以任何方式获取（或企图获取）超级用户权限。

6.8 配置管理

明确配置管理负责人。

建立配置文档库，对服务器、存储、网络、安全设备，操作系统、应用软件、数据库等进行管理。

定期对配置进行备份及文档库归类。

及时检查并定期审计，对发现的不一致情况及时纠正修改。

6.9 事件与问题管理

对运维事件的处理进行规范，对发生的所有事件，根据事件的影响程度和影响范围评估事件处理优先级并及时处理。

对所有事件响应、处理、结束等过程进行跟踪、监督及检查。对问题进行分析、提出解决方案，通过变更管理审批后部署实施。

7.应急管理

7.1应急准备

明确网络、系统等事件的应急指挥决策机制，负责网络与系统事件的预防预警、应急处置、报告和调查处理工作。

网络与系统应急管理应遵循“谁主管谁负责、谁运行谁负责”、“统一指挥、密

切协同；注重预防、减少风险；科学处置、及时报告；以人为本、公平优先”的原则。

应急准备应符合如下要求：

a)系统管理员、网络管理员、安全管理员等关键岗位应熟练掌握应急预案，能有效处置相关事件；

b)在自身力量不足以满足应急要求的情况下，应与相关供应商签署服务保障协议。协议内容应包

括双方联系人、联系方式、服务内容及范围、应急处理方式等。应定期检查和评估协议的执行情况，确保服务保障措施落实到位，确保在应急处置中相关单位能提供及时有效的技术支持；

c)应建立有效的应急通讯联络系统，确保信息畅通；

7.2应急处置

在发生网络与系统事件后，迅速采取应急措施，尽快恢复信息系统正常运行，如有重要情况应及时上报。

暂时无法确定事件原因、责任和结论的，应先给出事件的初步分析判断，并组织力量尽快查找原因，给出解决方法，采取整改措施。