1、 大学 IT 运维 综合管理 平台 建设 方案 【 参考方案 】 版本历史 版本号 版本日期 修订人 说明 文件名 版权声明和保密须知 本文件中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属 信息技术 （ 上海 ） 有限公司 所有，受到有关产权及版权法保护。任何个人、机构未经 信息技术 （ 上海 ） 有限公司 的书面授权许可，不得以任何方式复制或引用本文件的任何片断。 Copyright 2012信息技术 （ 上 海 ） 有限公司 版权所有 目 录 第一章 概述 .7 1. 项目目标 7 2. 设计原则 8 第二章 大学运维体系建设方案 10 1. 大学运
2、维管理体系建设思路 10 2. 大学运维管理体系建设原则 10 3. 大学运维管理体系建设方法 11 3.1. 以运维所服务客户的需求为导向 13 3.2. 以运维团队日常业务场景为中心 15 3.3. 以七位一体流程可执行性为基础 16 3.4. 基于落地执行的流程表单化设计 18 3.5. 关注推进障碍的分阶段推进方式 19 4. 大学运维管理体系建设流程 21 4.1. 项目启动规划 21 4.2. 宣贯和认知培训 24 4.3. 现状评估 .26 4.4. 体系和流程设计 29 4.5. 体系试运行阶段 51 4.6. 认证 .53 第三章 大学 IT 服务管理系统建设方案 .56 1
3、.1. 方案架构 .56 1.1.1. 总体架构 .56 1.1.2. 软件实现 .58 1.1.3. 系统接口 .59 1.1.4. 架构特点 .60 1.2. 统一门户子系统 61 1.2.1. 信息主管领导内容展示 62 1.2.2. 运维人员内容展现 62 1.2.3. 一般用户内容展现 62 1.3. IT 运行监控子系统 .63 1.3.1. 基础平台功能 63 1.3.2. 网络设备管理 65 1.3.3. 服务器监控管理 68 1.3.4. 存储监控管理 70 1.3.5. 数据库监控管理 . 71 1.3.6. 中间件监控管理 . 71 1.3.7. web 与应用监控管理
4、.73 1.3.8. 虚拟化监控管理 73 1.3.9. IP 地址管理管理 . 74 1.3.10. 信息点管理 76 1.3.11. 告警监控管理与转发处理 . 77 1.3.12. 综合监控管理 78 1.3.13. 综合报表管理 79 1.4. IT 服务管理子系统 .80 1.4.1. 功能特点 .80 1.4.2. 服务台管理 83 1.4.3. 服务目录管理 84 1.4.4. 服务请求管理 84 1.4.5. 事件管理 .85 1.4.6. 问题管理 .85 1.4.7. 变更管理 .86 1.4.8. 作业计划 .86 1.4.9. 值班管理 . 87 1.4.10. 知识库
5、管理 . 88 1.4.11. 公告管理 .90 1.4.12. IT 运维报告 .90 1.4.13. 用户管理 .90 1.5. 平台安全及自身管理 91 1.5.1. 系统安全管理 91 1.5.2. 自身日志管理 93 1.5.3. 系统自身运行管理 93 第四章 培训方案 . 错误 !未定义书签。 1. IT 运维体系建设咨询方向培训 错误 !未定义书签。 1.1. 培训安排 . 错误 !未定义书签。 1.2. 知识及标准培训 错误 !未定义书签。 1.3. 其他增值培 训 错误 !未定义书签。 2. IT 服务管理系统工具培训 错误 !未定义书签。 2.1. 培训对象面向各类用户
6、错误 !未定义书签。 2.2. 培训课程 . 错误 !未定义书签。 2.3. 制定完善的系统培训计划 错误 !未定义书签。 第五章 项目管理 . 错误 !未定义书签。 1. 实施策略原则 错误 !未定义书签。 2. 沟通管理机制 错误 !未定义书签。 2.1. 交流文档与交流的流程： 错误 !未定义书签。 2.2. 形式： . 错误 !未定义书签。 2.3. 沟通计划： 错误 !未定义书签。 3. 详细进度管理 错误 !未定义书签。 4. 项目组织管理 错误 !未定义书签。 5. 项目风险管理 错误 !未定义书签。 6. 质量管理 错误 !未定义书签。 7. 质量保证 错误 !未定义书签。 7
7、.1. 问题管理 . 错误 !未定义书签。 7.2. 变更管理 . 错误 !未定义书签。 7.3. 成本控制 . 错误 !未定义书签。 8. 技术支撑资源保障 错误 !未定义书签。 8.1. IT 服务管理技术平台研发中心 错误 !未定义书签。 8.2. IT 服务管理技术专家 错误 !未定义书签。 第六章 知识转移 .94 1. IT 服务管理体系建设咨询方面的知识转移 94 1.1. 知识转移的对象 94 1.2. 知识转移的形式 94 1.3. 大学职责 96 2. IT 服务管理体系工具方面的知识转移 97 2.1. 项目主要技术文档 97 2.2. 项目技术文档管理规范 98 2.3
8、. 文档移交 .99 第七章 项目验收 100 1. IT 服务管理体系建设项目咨询方面验收 错误 !未定义书签。 1.1. 培训服务验收 错误 !未定义书签。 1.2. 咨询服务验收 错误 !未定义书签。 1.3. 咨询整体验收 错误 !未定义书签。 1.4. 质量保证 . 错误 !未定义书签。 2. IT 服务管理体系建设项目工具方面的验收 . 101 2.1. 系统测试 101 2.2. 移交测试 101 2.3. 系统初验 .102 2.4. 系统试运行 . 103 2.5. 系统终验 103 2.6. 交接 104 2.7. 收尾 106 第八章 售后服务 . 错误 !未定义书签。
9、1. IT 服务管理体系建设咨询方面售后服务 错误 !未定义书签。 2. IT 服务管理体系建设工具方面售后服务 错误 !未定义书签。 2.1. 服务范围与期限 错误 !未定义书签。 2.2. 售后服务方式与标准 错误 !未定义书签。 2.3. 售后服务内容 错误 !未定义书签。 2.4. 售后服务流程 错误 !未定义书签。 3. 技术支持方式 错误 !未 定义书签。 第九章 实验室介绍 错误 !未定义书签。 1. 联合研发中心 错误 !未定义书签。 2. 实验室 错误 !未定义书签。 3. 荣誉资质 错误 !未定义书签。 4. 关注 错误 !未定义书签。 第一章 概述 1. 项目 目标 加强
10、信息资源的维护平台建设，提高信息资源的运行管理水平，通过运维体系的建设，结合构建集中式的服务热线、运维流程、系统监控和综合展示系统，通过系统联动，及时、准确、全面反映与掌握信息系统的运行状态，保障各业务系统的正常运行，应达成如下目标： (1) 强化主动监控，实现集中管理。 以 IT 资源可用性监控为主线，构建统一集成的 IT 资源及应用服务监控平台，能够主动、及时地发现问题，并调度资源解决问题，形成 IT 运维管理主动服务的新局面。 (2) 帮助定位故障，快速恢复系统运行。 建立集中的告警分析及展现平台，提供灵活、自动化的事件处理能力。当故障产生时，可以进行故障的快速定位，发现故障原因，调度资
11、源快速恢复系统服务，从而缩短故障解决时间，降低维护成本，提高系统整体可用性。 (3) 掌握运行质量与效率，合理利用资源。 建立 IT 运维平台后，可以实时了解全部 IT 资源的负载与使用情况，根据需要从整体角度考虑资源的使用，同时可以根据业务高峰期的不同来调剂业务系统对资源的使用。 (4) 规范运行管理，有序开展维护。 参照 ITIL 规范，对运维管理工作进行优化，对服务管理进行改善，将管理数据电子化，管理过程规范 化。根据相关制度进行运行维护管理，对内完善流程，对外提高服务，加强管理，使流程更规范更合理，使技术人员具备更高的工作效率，提高业务技术能力和解决实际问题的能力。 (5) 共享运维经
12、验，完善知识库。 把运维过程中产生的丰富经验进行积累和总结，形成有效的知识库，建立知识的共享机制，提供信息共享和交流的平台，提高运维人员的工作效率。 2. 设计原则 IT 运维 平台作为信息中心 未来 运维工作的核心支撑系统， 需要系统 本身具有 高 可靠、易 扩展、易维护等特点，并且在 系统 功能应用上要具备一定的 技术 先进性和实用性 。所以 ， 本次项目的 方案设计遵循 以 下设计原则： (6) 先进实用 平台注重先进性和实用性的统一，以实用为目的，合理选用各类成熟、先进技术。在体系结构、功能算法等诸多方面都采用先进计算机技术和理论，应用功能体现实用性。 (7) 可靠性 在系统结构、设计
13、方案、设备选择、技术服务等方面综合考虑，保证系统能够 7*24 安全无故障运行，系统有很好的容错功能；对 IT 资源的监测应保证不影响相关设备和系统的正常良好运行，并实现最好的响应效率及最小的资源占用。 (8) 安全性 注重安全方面的设计，确保 IT 运维监控管理平台的稳定、安全运行。系统要保证数据的安全，不会增加现有应用系统的复 杂性，更不会降低现有应用系统的稳定性。 (9) 开放性 采用符合国际国内标准的通用协议，为实现与其他系统监控软硬件互联或接入本系统进行监控提供接口，支持各种主流计算机平台、操作系统以及数据库厂商的各类软硬件产品。 (10) 可扩展、易集成 系统需具备很好的扩展性，能
14、适应不断发展的业务需求。随着 IT 资源种类和数量的扩大，系统也应能适应新的系统的对 IT 运维管理的需求。系统具备高度集成性，可以和第三方产品进行集成，进行功能扩展。系统提供开发工具和接口，方便其他监控系统集成和统一管理。 第二章 大学运维体系建设方案 1. 大学运维管理 体系建设思路 将按照如下的整体思路来构建 大学的运维管理体系： IT 运维管理理论、方法和标准，结合中心实际和建设需要，遵循立足需求、统一规划、保障重点、分步实施、务求实效的原则，建立一套融合组织、制度、流程、人员、技术的 IT 运维管理体系，建立组织机构，制定规章制度，规范管理流程，明确职责分工，强化技术支撑，实现对网络
15、及信息系统的综合管理监控和日常技术支持，快速响应和及时解决信息系统运行过程中出现的各种问题和故障，确保所维护网络及信息系统正常、稳定、高效运行。 2. 大学运维管理体系建设原则 根据 大学 IT 运维管理现状，在 IT 服务管理系统建设过程中，遵循以下原则： 1) 先进性原则 构建运维 的 管理体系 应具有一定的先进性和前瞻性，既能够满足当前运行 管理的需要，同时 又能够满足未来 3 到 5 年时间内运维 维护管理工作的需要 ，为网络和信息系统提供有效的安全服务保障。 2) 整体性原则 从宏观的、整体的角度出发，系统地建设 大学 的运维管理 体系，从 组织体系、规范体系、技术体系 建立全面有效
16、的运行保障体系。 3) 实用性原则 建立运维管理体系，必须针对 大学的运维管理特点，在现状分析和风险评估的基础上有的放矢地进行，不简单地照抄 照搬其它的运维 管理体系方案 。同时，运维管理体系中的所有内容，都被用来指导 大学网络和 信息系统的 运维 维护等 等实际工作，因此必须坚持可操作性和实用性原则，避免空洞和歧义现象。 4) 标准性原则 尽可能遵循现有的与信息安全相关的国际标准、国内标准、行业标准，包括在技术框架中与具体的信息安全技术相关的标准，以及在管理框架中与安全管理相关的标准。标准性原则从根本上保证了信息安全的信息安全体系建设具有良好的全面性、标准性、和开放性。 3. 大学运维管理体
17、系建设 方法 做为 IT 服务整体管理解决方案的咨询服务提供商，基于 多年的实践经验，结合全球领先的 IT 服务管理相关标准及最佳实践，提出基于“整合”、“落地”的 IT 服务管理实方法 论 （ 参见下图）。 该框架从公司 IT 服务需求、期望及 IT 战略出发，以日常 IT 服务工作中的各种服务场景为核心和出发点，结合 ITIL 服务管理标准库及 ISO20000-1 的服务过程最佳实践和要求，通过这些服务过程按照目标机方向、工作流程、管理制度、工作指南、人员组织、绩效测量、支撑工作等 7 个方面（简称 7P） 对 IT 服务的过程和“服务场景”进行规划和落地执 行，最终提升 IT 服务的质
18、量和管理水平，进而提升客户或用户对 IT 服务满意度的全面提升。 在运维管理体系建设过程中的核心方法论，包括但不限于如下内容； 将以客户需求（最终结果）为导向的管理目标作为核心设计思想 以客户需求为导向， 设定管理体系最终达成的目标； 基于成熟模型的持续改进框架； 基于生命周期的管理框架； 关注推进障碍的分阶段推进方式； 基于业务场景的流程设计； 全方位关注管理要求落地的 7P 模式； 基于落实考虑的流程表单化设计。 方法论的优势和特点 1) 以实际的 IT 服务场景为出发点，符合最终以 ITIL 最佳实践落地执行的理念； 2) 规范日常管理的习惯和思维，通过“ 7P”实现流程运行有效落地，部
19、门及个人完全理解和明确运维工作的要点，做好可预期的管理和有效性测量； 3) 有利于不同管理标准以及技术标准的融合，包括多种 ISO27001/ISO13335 等安全标准以及 CMMI/ISO9001/BS25999 等其他管理标准的融合； 4) 有利于与运维及其他应用和管理平台的需求融合，通过“服务场景设计”，充分满足系统从规划设计、需求转换上线、服务支持和服务改进的全生命周期，充分做到从业务角度出发，针对服务支持和服务提供来实现流 程自动化和电子化； 5) 有利于与工作岗位的匹配，使得在流程管理措施落地时，能够和工作岗位和职责相融合； 6) 有利于管理在一定时间段内的稳定，不会应为标准要求
20、发生变化（或岗位调整），而需要大规模调整。 3.1. 以运维所服务客户的需求为导向 随着企业的信息系统种类、数量越来越多，客户 /用户方的要求也越来越高，传统的 IT管理模式已经不能满足现有信息部门的需要，原本的“救火式管理”及“被动式管理”也越来越不被客户 /用户方认可。 将“以运维所服务客户的需求为导向”作为运维管理体系设计规划的核心理论，通过多年的运维管理体系建设经 验，将运维管理体系所服务的客户的需求分为基本需求、扩展需求、专业需求、无干扰需求、成功需求 5 个层次和方面（参见下图）。 基 本 需 求扩 展 需 求专业需求无 干 扰 需 求 成 功 需 求服 务 简 便 性 需 求服
21、务 及 时 性 需 求 提 升 业 务 价 值 需 求服 务 态 度 需 求服 务 专 业 化 需 求服 务 标 准 化 需 求数 据 安 全 需 求系 统 稳 定 需 求象 投 资 生 产 线 一 样 ， 考 虑 I T 系 统 的 投 资管 理 层 面像 星 级 酒 店 一 样 提 供 标 准 化 、 专 业 化 的 服 务 ， 打 造 良 好 的 服 务 形 象治 理 层 面运维服务管理体系的需求层次 为满足客户的不断发展的服务需求， 提出了“基于成熟模型的持续改进框架”，能使客户明确自身处于成熟度模型的哪一个阶段，与客户需求的存在哪些差距， 以更明确自身的改进目标，提升自己的 IT 服
22、务管理水平。 将客户的运维服务能力按照成熟度模型分为 5 个级别：“救火式管理”、“被动式管理”、“主动式管理”、“系统式管理”、“价值式管理”，客户的需求与运维管理目 前所处的状态和阶段进行比较，发现目前所存在的差距，为运维管理提供了努力方向。 事件管理 变更管理主动式管理系统式管理价值式管理 流程不清晰 责任不明确 组织较离散 问题管理 配置管理 监视管理 巡检管理 服务级别管理 可用性管理 连续性管理 容量管理 安全管理 业务 （ 战略 ） 管理 财务 （ 成本 ） 管理基本需求 扩展需求 专业需求 专业需求 专业需求客户需求服务能力运维服务能力与客户需求的对应分析模型 3.2. 以运维
23、团队日常业务场景为中心 为确保所所规划设计的流程、将来能够确实的得到落地、执行，必须考虑运维团对日常的实际工作内容和场景。 将运维团对日常的工作场景按照 IT 服务的生命周期归纳和梳理出来，形成服务场景库。服务场景库是对 IT 服务部门日常服务工作的各种场景的真实再现，所有的流程设计和实施，均以场景为基础和源头，组合需要的服务过程和 执行方法。从而避免了以标准过程为基础导致执行时不知如何应用的问题。 以下是一个典型客户的场景库示图框架： 在服务前期（系统 上线 交接后 ） 明细服务目标 和 要求， 根据 服务目标 和要求，规划 所需 的人员和资源以及应执行的运维 管理 活动， 然后 根据所规划
24、的 责任 分工 提供 运行维护服务， 并 顶起 对运行维护的结果和效果进行评价。 综合管理系统监视事件管理故障客户申告事件变更管理变更变更问题管理变更服务前期 （ 上线 / 交接 ）配置管理运维规划运维规划管理评审节点服务报告运维 （ 服务 ) 规划 日常运行 定期分析 / 评审满意度调查 客户投诉管理预核算 管理开始服务级别管理 服务目录 服务级别 XX 系统运维管理规定系统评估可用性管理容量 管理安全管理供应商管理连续性管理容灾应急场景库框架示例 咨询在实际实施过程中， 在业务 场景框架的基础 上， 形成场景库， 以便 日常工作的执行 ， 下图是场景 库 的示例。 场景库示例 3.3. 以
25、七位一体 流 程可执行性为基础 为了使每个服务过程的设计都能够落地和执行， 提出 7P 的方法来设计和规划每一个服务过程。 7P 模式包括包括： 目标与方向（ POLICY:确定服务过程管理的主要目标与方向）、工作流程（ PROCEDUREs:制定工作流程 /程序）、工作指南（ PRACTICEs:提供必要的工作指导）、 管理 制度 （ PRESCRIPTs） 配合必要的管理制度、 人员组织（ PEOPLE:安排合理的人员 ） 、绩效 与测量（ PROOF：辅以必要的测量 和 绩效考核） 、支撑工具（ PRODUCTs：配备合适的支撑工具）， 形成组织体系、规范体系、技术 体系 。 如下图所示
26、： 以 7 位一体作为流程设计基础 1) 目标及方向（ Policy） 通过制定 IT 服务过程的目标和方向，为该过程的设计规划及执行指明方向和重点。 2) 工作流程（ Procedures） 制定 IT 服务管理过程的具体程序文件，要求流程图清晰明确，且易执行。 示例：事件管理程序及工作流程（详见第 6 章服务过程介绍） 3) 管理制度（ Prescript） 制定每个服务过程的相关管理制度，更好地保证 服务过程得到贯彻执行。 示例： 变更管理制度、 IT 服务管理制度汇编文件 4) 工作指南（ Practice） 在管理制度和流程制度好的前提下，明确各岗位的职责和角色，编写详细的工作指南，
27、明确工作任务和分工，为今后工作和绩效考核提供便利。 示例：如服务台礼仪规范服务台工作规范等。 5) 人员与组织（ People） 完善服务过程的职责、角色和人员，通过明确的 RACI 模型确定服务人员及组织。 示例：热线技术团队构成及职责、调度协调团队构成及职责 6) 绩效与测量（ Proof） 通过对服务过程的人员绩效、 KPI 及体系运转等情况 ，进行周期性的检查和考核，确保流程及 KPI 的良好运转和适应度。 示例：事件过程有效性测量办法、 IT 服务体系绩效考核办法 7) 支撑工具（ Products） 结合公司目前的 ITSM 系统和监控系统，对现有流程提出改进优化建议，对未实现流程
28、进行二次开发指导，并进行工程监理工作，保障公司流程电子化能够转换成功。 示例：事件流程电子化实施方案， IT 服务管理系统实施方案。 3.4. 基于落地执行的流程表单化设计 推出的“基于落实考虑的流程表单化设计”，能够帮助客户基于自己的实际业务情况来定义具体的内容，更贴近于实际情况，以使流程 更好落地。 很多的表单的设计初衷就是为了固化流程，一旦表单的内容确立，后期的工具字段、内容也就确立。 流程表单化设计示例 3.5. 关注推进障碍的分阶段推进方式 对于咨询业务来说，尤其是项目中的体系规划部分，是整个项目的核心，且咨询与客户双方沟通频繁，设计好的成果容易变更，容易暴露项目因沟通频繁而产生延期
29、的风险。 从流程的设计到流程实施分为四个子阶段：需求、设计、试运行和优化发布。每一个流程的设计都需要完成这四个阶段，才能通过，并开始设计下一阶段。 提出了“阶段迭代式推进”这一思路，每设计完一个流程，及进入该 流程的试运行阶段，同时开始下一流程的需求分析能够将项目的周期更加有效的在实施中得到控制。 关注推进障碍的分阶段推进方式 4. 大学运维管理体系建设流程 根据多家客户的实施经验，总结出了“先固化、后优化、再 E 化，整体规划、分布实施”的咨询实施方法，同时结合“原型迭代”法，确保项目周期可控，效果有保障。参见下图。 1 ) 项目启动2 ) 基本调研流程改进 （ 1 ）1 ) 体系框架2 )
30、 安全策略3 ) 服务级别管理4 ) 服务目录 1 ) 发布实施2 ) 后期培训1 ) 内部审核2 ) 管理评审3 ) 认证申请4 ) 文件审核5 ) 现场初访6 ) 初次审核流程改进 （ 2 ）1 ) 事件管理2 ) 问题管理3 ) 配置管理4 ) 变更管理5 ) 发布管理流程改进 （ 3 ）1 ) 可用性管理2 ) 连续性管理3 ) 容量管理4 ) 信息安全管理流程改进 （ 4 ）1 ) IT 服务财务管理2 ) 业务关系管理3 ) 供应商管理4 ) 服务报告1 ) 前期培训2 ) 现状调研3 ) 差距分析平台工具实施与上线项目管理转变管理 （ 持续沟通 + 培训 ）4.1. 项目启动规划
31、 4.1.1. 阶段目标 此活动是项目启动阶段的策划活动，是项目操作的基础和起点。项目正式启动之前，人员、资源、资料、方案等都应该 到位或确定，准备工作的充分与否，决定着项目后期的发展和最终的成败结果。 4.1.2. 工作思路及重点 ISO/IEC 20000 把 IT 运维日常的工作内容划分为 13 个管理过程，为保证管理过程的持续有限运行并对过程的绩效进行监视，需要为每一个过程定义相应的责任人。而一般的 IT 运维部门都是按照职能划分的，如网络组、前段组、应用组、主机组等。这要求在项目启动阶段解决智能型和 ISO/IEC 20000 的矩阵型的架构融合，而有效、合理的人员职责分配是项目和后
32、续运行成功的基础。 因此 首先指导公司建立合理的项目组织及职责分配，这是项 目成功的基础和组织保证。 同时， 将于公司主要人员一起，对公司的 对业务目标进行分析，并依此制订相应的 IT 服务管理方针，为后面流程的实施提供依据。 4.1.3. 主要工作内容及资源分配 序号 工作内容 资源配置计划 交付物 验收标准 /方式 公司 贵校 0 项目准备 0.1 确定业务要求 项目经理 项目负责人 参与交流 0.2 初步职责分配 项目经理 项目负责人 IT 服务项目组成员名单 双方认可 公司管理层 IT 服务负责人 咨询 专家 顾问 参与人员 确定业务要求 初步职责分配 制定项目计划与章程 任务 业务目
33、标 项目组构成 项目计划与章程 输出 评审组织方针 与业务目标 评审初步 调查结果 序号 工作内容 资源配置计划 交付物 验收标准 /方式 公司 贵校 参与讨论 0.3 项目 整体计划 项目经理 项目负责人 参与讨论 项目计划 /项目章程 双方认可 4.2. 宣贯和认知培训 4.2.1. 阶段目标 在项目启动及准备阶段， 标准宣贯和认知培训是必不可少的。根据项目的实际需求，制定培训方案，准备培训材料，向公司领导及相关人员提供项目实施所需的基本知识，包括进行风险评估等活动所应掌握的技能和方法。 4.2.2. 工作思路及重点 由于 基于 ISO20000 的 IT 服务管理体系，服务理念由以前的“
34、被动的、以技术为中心”的服务模式 转向了 “主动地、以 业务需求为中心 ”的服务模式 。 所以 IT 服务理念的转变是非常重要的。本阶段的培训将以此为重 点，以大量案例为主线，深入浅出地让大家接受全新的 IT 服务管理理念，统一认识。 4.2.3. 主要工作内容及资源分配 序号 工作内容 资源配置计划 交付物 验收标准 公司管理层 IT 服务负责人 咨询 专家 顾问 参与人员 管理理念导入 意识及基础知识培训 ISO20000 标准培训 任务 意识与知识准备 输出 评审组织方针 与业务目标 评审初步 调查结果 公司 贵校 /方式 1 项目启动及导入培训 1.1 项目启动 大会 专家顾问 主导
35、项目组人员 参与 启动大会 PPT 1.2 IT 服务管理意识培训 专家顾问 主导 项目组人员 参与 培训课件 PPT 培 训 满 意 度高于80% 1.3 ISO20000 基 础 知识培训 专家顾问 主导 项目组人员 参与 培训课件 PPT 培 训 满 意 度高于80% 1.4 ISO20000 标 准 培训 专家顾问 主导 项目组人员 参与 ISO20000 标准 培训课件 PPT 培 训 满 意 度高于80% 1.5 阶段小结 项目经理 项目负责人 4.3. 现状评估 4.3.1. 阶段目标 针对公司 IT 环境、运维体系和相关机构进行充分的调研，并进行差距分析，同时在对现状做全面诊断
36、和评估的基础上，完善和确定 ISO20000 咨询范围和实施计划。 4.3.2. 工作思路及重点 客观准确地评估 IT 服务管理现状、进行差距分析、明确流程成熟度是改善 IT 服务管理的 基础。而以业界公认的最佳实践 ITIL 以及服务管理标准 ISO/IEC 20000 为参照，从客户 IT 组织的业务目标出发，以风险管理和业务影响为准绳，提供定制的 IT 管理评估方案，综合评价 IT 组织的服务管理流程与服务质量控制体系，将为 ISO/IEC 20000 流程的实施提供坚实的基础。 现状评估及差距分析的过程图如下： 现状评估和差距分析 针对 ISO/IEC20000 符合性的预评估是一项针
37、对提供 IT 服务的相关 IT 人员、流程和技术的评估，运用业界最佳实践 的管理原则，确定管理流程的成熟度，以及与 IT 服务负责人 IT 技术人员 咨询顾问 主要参与人员 技术评估，确定工具和技术 差距分析 确定需要改善和实施的流程 确定实施策略 任务 差距分析报告 实施策略 输出 评审差距分析报告 评审实施策略 ISO/IEC20000 规范的差距。目的是对 IT 服务管理（ ITSM）流程各方面标识出需要改进和提高的领域。 4.3.3. 主要工作内容及资源分配 咨询团队以 ISO20000 作为衡量标准，采取高层访谈、员工访谈、外包团队访谈，以及对管理制度文档、记录阅读评估等方式，从规范
38、和执行两个纬度，识别出信息中心现有运维工作的优点及风险点，有针对性的提出了改进课题以及改进所需的资源。 具体工作内容、资源分配及交付物如下表： 序号 工作内容 资源配置计划 交付物 验收标准 /方式 公司 贵校 2 现状调研与差距分析 2.1 差距分析 (现状调查 ) 高级顾问 主导 项目组人员 参与 调研问卷 项目方确认 2.2 技术评估 (确定 现有工具和技术 现状 ) 高级顾问 主导 项目组人员 参与 现状调研报告 项目方确认 2.3 现状评估报告编写讨论 高级顾问 主导 项目组人员 参与 2.5 确定文件架构和模 高级顾问 项目组人员 文件架构和模 项目方确认 板 主导 参与 板格式建
39、议 2.6 现状调研报告 项目经理 现状调研报告 项目方确认 2.7 修订并改进实施计划 及咨询范围确认 4.4. 体系和流程设计 4.4.1. 阶段目标 根据 ISO20000 标准及公司的业务需求，规划和设计 IT 服务流程，建立缺失的流程内容、完善不符合 ISO20000 标准的流程内容，并且辅导完成相应的与流程相支撑的各种文档资料的规划的编写工作。同时将服务支持的主要流程转化为 IT 运维工具的开发配置需求，指导管理体系上线的测试和运行。 4.4.2. 工作思路及重点 流程的改善和实施应该说是整个生命周期当中，耗时最长，也是最为困难的部分。根据 ITSM 的要求，如果组织希望获得 IS
40、O/IEC 20000 的认证，则需要向认证机构展 示具有管理和实施标准所要求的 13 个过程的能力。因此，所有过程都不得删除，并在认证时需要展示所有过程实施和管理的相关证据。为保证流程的改善和实施的有序有效进行， 13 个流程将分四个阶段来 规划、设计并优化改进 。 现状调查与差距分析服 务 级 别 管 理事 件 管 理问 题 管 理Q u i c kW i n s变 更 管 理发 布 管 理可 用 性 管 理I T 服 务连 续 性 管 理容 量 管 理业 务 关 系 管 理I T 预 决 算 管 理供 应 商 管 理配 置 管 理服 务 报 告信 息 安 全 管 理改进和提高(内部审核）
41、改进和提高（外部认证）项 目 启 动流 程 改 进 - I流 程 改 进 - I I I 流 程 改 进 - I V流 程 改 进 - I I持 续 改 进1 周 x 周 x 周 x 周 x 周 x 周 x 周体 系 框 架 要 求分步实施法 在服务级别管理的设计中，需要以客户的应用系统为对象，分别对系统的服务交付与服务支持进行定义，这些定义需要以合同作为基础，进而明确 SLA 指标，这些量化的指标，既能够满足客户 /用户的业务需求，又能够作为内部量化及考量的指标要求。 理想中的服 务目录，如同餐厅菜单，最终可以形成服务产品化。因此服务目录需要满足“可以方便的让客户选择所需服务”、“可以方便的计算服务成本”及“可以方便的基于服务来安排相应的资源”。 在实施中，我们必须注意到流程之间是相互关联的，并且一定要注意，这些流程的走向，并且最终要将这些流程融入到日常工作中： 企业通过监视 /巡检信息系统来主动发现故障 (事况管理 )，通过服务台来受理故障（事件管理），对于一些重大的故障需要执行（重大事件管理），对于需要系统升级或调整才能解决的故障执行（变更 /发布管理），处理故障时，需要通过（配置管理） 来获取技术信息，在故障解决后，如果要分析根本原因，则需要执行（问题管理）。故障
