ITIL的IT服务管理培训(pdf 27页).pdf

IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路 S P O R T Service Process Organization Resource Technology 上海信息化培训中心上海信息化培训中心 欢迎联络 欢迎联络 021 62123473 training leader MSN verymark 1 Dedicated to ITer to be a world class CIO 基于 ITIL 的 IT 服务管理之路 基于 ITIL 的 IT 服务管理之路 v 1 0 2003 年 4 月 上海信息化培训中心 IT 管理培训部上海信息化培训中心 IT 管理培训部 整理发布 培训 服务 发展 整理发布 培训 服务 发展 IT management training leader 地址 地址 中国中国 上海上海 华山路华山路 1076 号号 网址 网址 电话 021 62123473 传真 021 62123450 电邮 training leader IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路 S P O R T Service Process Organization Resource Technology 上海信息化培训中心上海信息化培训中心 欢迎联络 欢迎联络 021 62123473 training leader MSN verymark 2 目录 目录 1 1 建设理想的 IT 组织的十条建议 1 2 IT 管理 事半功倍之路 1 3 建构企业 IT 营运管理方法论 ITIL 2 1 建构企业 IT 的变更管理 2 2 变更管理的重要关键 3 1 建构企业 IT 的配置管理流程 3 2 配置管理成功关键 4 1 建构企业 IT 的版本的发行与控管 4 2 发表管理的流程与步骤 5 如何架构企业 IT 的 Service Desk 功能 6 企业 IT 服务的可用度管理 7 容量管理流程 8 企业如何做好 IT 的问题管理 9 IT 服务的持续性管理流程 10 上海信息化培训中心 ITIL 认证的 IT 服务管理培训介绍 11 上海信息化培训中心国际热门认证 IT 管理培训时间表 1 1 建设理想的 IT 组织的十条建议 1 2 IT 管理 事半功倍之路 1 3 建构企业 IT 营运管理方法论 ITIL 2 1 建构企业 IT 的变更管理 2 2 变更管理的重要关键 3 1 建构企业 IT 的配置管理流程 3 2 配置管理成功关键 4 1 建构企业 IT 的版本的发行与控管 4 2 发表管理的流程与步骤 5 如何架构企业 IT 的 Service Desk 功能 6 企业 IT 服务的可用度管理 7 容量管理流程 8 企业如何做好 IT 的问题管理 9 IT 服务的持续性管理流程 10 上海信息化培训中心 ITIL 认证的 IT 服务管理培训介绍 11 上海信息化培训中心国际热门认证 IT 管理培训时间表 IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路 S P O R T Service Process Organization Resource Technology 上海信息化培训中心上海信息化培训中心 欢迎联络 欢迎联络 021 62123473 training leader MSN verymark 3 1 1 建设世界级 IT 组织的十条建议 1 1 建设世界级 IT 组织的十条建议 1 你应该更多关注关键使命 mission critical 系统 2 你应该将 IT 与业务整合 3 你应该在企业内部和外部建立和培养各种关系 4 你应该建立一个有竞争优势的架构 5 你应该关注客户 6 你应该善于利用经过时间检验的教训 包括标准 流程等 7 你应该将 IT 的价值展示和传递给整个企业 8 你应该建立和支持一套共同价值观 9 你应该在重视技术和发展的同时 给组织 人员和流程以同等的关 注 10 你应该善于开玩笑 1 2 1 2 IT 管理 事半功倍之路 IT 管理 事半功倍之路 2003 年 CIO 们将面临很多挑战 他们必须提高 ROI 投资报酬率 提高服 务水准 并加强安全性 而低预算和人力资源不足的情况却依然没有变 在目前的种种局限下 CIO 们如何能够达到这些目标呢 你可以透过 IT 管理 IT governance 对 IT 部门的运做方式进行根本性的改变 这个名词你可能在最 近已经时常耳闻 为什么这个新概念正是你正在寻找 而且能够在不增加费用下 提高流程的方法呢 定义 IT 管理 定义 IT 管理 从最基本的层次上来说 IT 管理就是一套 IT 所支持之外的事件策略 流程和 程序 组成 IT 管理的一些原则是改变管理 问题管理 发布管理 可用性管理和 服务层管理 IT 管理并不像最新的技术革新一样迷人 没有厂商动用上亿美元的市场费用 来销售它 但是 IT 管理起码和基础架构的任何部分 或者任何应用同样重要 甚 至更重要 尤其在这样一个要求 CIO 以稀少资源处理复杂事务的环境里 对于 IT 管理的需求 对于 IT 管理的需求 由于企业应用 电子商务和 Y2K 问题 IT 组织从 1995 年到 2000 年一直处于 战斗状态 重点在于完成的速度上 即使这可能会危及到工作质量 例如 不能按 IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路 S P O R T Service Process Organization Resource Technology 上海信息化培训中心上海信息化培训中心 欢迎联络 欢迎联络 021 62123473 training leader MSN verymark 4 期完成项目 费用超支 非预期的当机以及安全问题 IT管理旨在找出并纠正这些上述可能出现的问题 以及IT运作的不恰当程序 透过 IT 管理可建立高质量 清楚定义和可重复流程的工作基础 更具体的说 管 理简明地定义策略 精化程序 需要谨慎的文件化管理 并建立长期改善计划 恰当的模型 恰当的模型 以下有几种很好的 IT 管理模型 最流行的是 IT Infrastructure Library ITIL 它是由 CCTA Central Computing and Telecommunications Agency 为英国政府所 制订的 现在属于 OGC Office of Government Commerce ITIL 在欧洲得到了广 泛的支持 在北美也在逐渐流行起来 ITIL 用 24 条原则定义了一套最好的实践步 骤 另一个 IT 管理架构是 CobiT Control Objectives for Information and Related Technology CobiT 根据商业目标 质量标准 财务控制 安全需求来安排 IT 资 源和流程 CobiT 由四个要素组成 计划和组织 获得和执行 交付和支持 监测 惊人的投资报酬率 惊人的投资报酬率 很多组织采用了 ITIL 和 CobiT 并获得可观的成果 Proctor Gamble 于 1997 年采用 ITIL 模型 它宣称在过去的四年里 透过 ITIL 节省超过 5 亿美金的预算 对于 Procter Gamble 内部财务和 IT 部门的调查显示 其运作费用降低 6 8 而技术人员的人数减少 15 20 Morton Cohen Proctor Gamble 的全球服务 管理经理表示 如果一个公司的 IT 工作经常由 5 000 人来完成 服务管理的节省 作用就非常可观 加拿大的安大略省政府也采用了 ITIL 安大略需要提高对其位于 1 000 个不同 地方的 25 000 名用户的服务水准 透过采用 ITIL 该政府建立一个虚拟服务台 不仅提高响应时间 服务水准 还可减少 40 的费用 CobiT 也有不少成功案例 堪萨斯州把 CobiT 标准作为虚拟政府策略的一部 分 用它来保持较低的成本 并为它的客户和委托人提供一定的服务质量 戴尔 把 CobiT 作为它的 CSA Control Self Assessment 策略的一部分 设计一套审计 检查和平衡方法以帮助公司保持一贯的高质量水准 建立 IT 管理 建立 IT 管理 来自知名组织的结果明确显示出 IT 管理是值得投资的 但是起步总是最困 难的 下面是进行 IT 管理时的小建议 专注于解决最大的问题 对于任何一个 IT 组织来说 采用整套的 ITIL 或者 CobiT 模式都是不可能的 相反地 应该从最大的问题开始 比如 如果你的 IT 组织觉得支持大型分布式组织有困难 则建议采用安大略的办法 采取 ITIL 辅助 支持系统 help desk processes 先完成培训再进行组织变化 并在单一领域内 如 培训经验 获得一定成绩后 再转向其它有问题的领域 记住在你开始项目管理 工作之前 评估一下目前的环境 这样你就能够测量出进展的效果 从执行管理和IT员工身上获得成效 虽然IT管理是用来提高效率和商业响应 它仍包括一些正式的流程改变作业 这可能在组织内引起摩擦和不适应 高级管 理人员必须领导这场转变 并且让企业内部都明白任何短期的改变都是为了整个 IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路 S P O R T Service Process Organization Resource Technology 上海信息化培训中心上海信息化培训中心 欢迎联络 欢迎联络 021 62123473 training leader MSN verymark 5 组织长期利益而进行的投资 CIO 必须为改变做好准备 而 IT 奖金部分则由整个 方法所带来的效益和节省下的费用决定 一旦 IT 管理的标准确立 专家们认为你 应该在六个月内看到长远的效果 寻找合作伙伴 ITIL 的费用从 90 150 美元不等 实施期间将对培训 流程创 造而言是非常有价值的 而找寻恰当的合作伙伴 将发挥更大的效用 惠普采用 ITIL 有很长的一段历史 而 IBM 全球服务也进行了 IT 管理行动 加拿大的 Pink Elephant 和新英格兰的 Treadstone71 也是 IT 管理专家 现在就踏上高报酬之路 现在就踏上高报酬之路 CIO 们不能够再维持原状 有许多人已经开始采取行动 因为他们已经被这 种减少人力而降低费用的惊人成效所吸引 像 ITIL 和 CobiT 这样的 IT 管理标准显然可以帮助提高服务质量并降低费用 Proctor Gamble 安大略政府 堪萨斯州和戴尔以及其它的一些组织 已经透过 采用 IT 管理发掘其可观的成效 这就是为什么 CIO 们应该从小地方做起 然后逐 步扩大并找到服务伙伴来进行管理流程 1 3 1 3 建构企业 IT 营运管理方法论 ITIL 建构企业 IT 营运管理方法论 ITIL 现今的企业为了强化自己在这个新世纪的竞争力 导入了林林总总的系统 无论企业建置的是 ERP 系统 供应链系统 CRM 系统 决策支持系统 知识管理 系统等等 这些系统最后都要进到企业的 IT 营运体系中 当我们透视解决方案生 命周期时 我们可以看到 所有的解决方案最后都要进到企业的 IT 营运体系中 为企业员工所使用 如果 IT 的整个营运管理做得不好 那这些花大钱建置起来的系统再好功能再 强也没有用 因为使用者根本无法顺利地使用它们 曾与国内某家大型电子公司 的信息处处长谈到公司内一共有多少个系统 他回答我共有四十多个 而当我问 他 他认为哪一个系统是最重要的呢 他回答我 IT 的营运与管理最重要 唯有 好的 IT 营运管理 才能让公司上上下下好好的用每一个系统 这个见解实在是 一针见血 既然 IT 营运管理非常重要 那么如何提供好的 IT 服务 对 IT 主管或 CIO 而 言当然是非常重要的课题 答案是采用更新的技术或添购功能更强的设备吗 在 1999 及 2000 年 Gartner Group 广泛访问企业 CIO 有关服务或应用程序无法使用 downtime 的原因 结果大家最常认定会出问题的技术或产品 包括硬件 软件 网络 电力失常及天灾等 其实只占了 20 那么占大宗的是什么呢 我想你已 经猜到了 作业程序 Process 失误就占了 40 另外作业人员 People 疏失也 占了 40 作业流程失误包括变更管理 Change Management 没有做好 超载 没有测试等等程序上的错误或不完整 作业人员疏失包括忘了做某些事情 训练 不足 备份错误或安全疏忽等等 Gartner Group 这份访查结果正是 80 20 法则的再次印证 我们常想要把系统的 可用度提高 当然就是要花大钱购买标榜可提高可用度的硬件或软件 孰不知这 个部分事实上只占了系统停机原因的 20 如何做好 IT 服务管理 首要工作当然 是加强流程和作业人员管理 因为那才是造成系统无法使用的主要原因 两个 原因加起来共占 80 我们常听人家说大型主机 Mainframe 的系统比较稳定可靠 所以经过了这 IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路 S P O R T Service Process Organization Resource Technology 上海信息化培训中心上海信息化培训中心 欢迎联络 欢迎联络 021 62123473 training leader MSN verymark 6 么多年还是有许多企业愿意花大钱继续一年年采用 其实真的是它的系统软硬件 更好吗 恐怕并不尽然 我们知道 大型主机系统有着一套完整清楚的系统运作 规范可遵循 人员在训练时花在运作程序方面的心力绝对不亚于系统软硬件 甚 至是更多 有了严谨的程序 加上完整的人员训练 自然就可以把那 80 的系统 停机风险降到最低 那么是否有方法论 可以用来建构企业内 IT 服务管理而且是主要 IT 厂商都支 持的呢 有的 ITIL Information Technology Infrastructure Library 是一套由英 国政府的 CCTA 部门 现已改名为 OGC CCTA 是 Central Communication and Telecom Agency 的简称 OGC 是 Office of Government Commerce 的简称 于 1980 年代后期所开发出来的 IT 服务方法论 ITIL 最初是一套多达 60 本书的论述 内 容描述的是 IT 部门应该包含的各个工作程序 Process 的定义 以及各个工作程 序之间的相互关系 ITIL 它并不是一套理论模式 它所根据的是最佳的实际经验 其中的许多经 验不但广为人知 而且有无数的 IT 机构都是采用它来提升 IT 服务的效率及加强 IT 部门间的横向沟通 这套方法论历经了十数年的考验 证明它是最被 IT 业界广 为接受的一套经营 IT 经验指南 等于是 IT 管理的业界标准 ITIL 在 2000 年到 2001 年间有一次最新的改版 通称为 ITIL v2 它新加入了主从架构与 Web 系统的工作 过程定义 使它更能符合知识经济时代的信息系统潮流 ITIL 将 IT 的工作分为两大类 Service Support 和 Service Delivery Service Support 针对的是一般系统的运作部分 目的是让使用者可以顺利存取到 IT 服务 其中包括 Service Desk 事件处理与追踪 问题处理与追踪 系统变更 系统配置 设定的记录与维护 以及版本的发行与控管 第二大类 Service Delivery 则是针对 IT 部门对客户提供信息服务时应有的工作程序 其中包括服务层级的约定与管理 IT 服务的财务管理 系统可用度管理 系统容量的测量与未来规划 灾难情况的 业务持续运作规划与系统复原 ITIL 将 Service Desk 列为 IT 部门所提供的一种服 务功能 function 其余的 10 个工作则归类为程序 但是为了方便起见 ITIL 常 常通称这 11 个工作为程序 下面将介绍这 11 个 IT 部门工作的定义与流程 IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路 S P O R T Service Process Organization Resource Technology 上海信息化培训中心上海信息化培训中心 欢迎联络 欢迎联络 021 62123473 training leader MSN verymark 7 2 1 2 1 建构企业 IT 的变更管理 建构企业 IT 的变更管理 ITIL Information Technology Infrastructure Library 是一套目前广为 IT 业界认 可的 IT 服务方法论 它内含 11 个程序 Process 那么当企业想导入这样的方法 论做为企业 IT 营运基础时 应该要从何着手呢 或者我们这样问 这 11 个程序如 果要按优先次序来排列 导入的先后顺序应该是什么呢 根据一般对客户的调查 客户觉得最重要也是最急迫要实行的是变更管理 Change Management 最明显的 理由就是它对系统有立即且关键性的影响 为何要做变更管理呢 这里举两个因为变更管理没做好而蒙受重大损失的例 子来说明 2001 年 6 月 NASDAQ 当机长达半天 原因是操作人员做了一个未经 测试的变更动作 结果导致整个系统停机 同样也是在 2001 年 6 月 NYSE 在半 夜做了一个软件变更的变更动作 导致部份系统当机 无法完成股票买卖交易 这两件事都上了报纸及新闻头条 包括华尔街日报 CNN 及 CNBC 等等 这反映 出了变更管理真的很重要 一旦没有做好它 企业的关键任务 Mission Critical 系 统就会受到影响 以银行业为例 只要是 IT 部门当机一小时 其导致的结果可能 是全体员工要花上数倍或甚至是数十倍的时间来补救 而且因为分行里客户大排 长龙 负面报导上了晚间新闻及报纸 企业形象受损的损失更是无法估计 这也 可以说明为何企业 CIO 把变更管理视为第一要务 系统为何需要变更 最常见的是终端使用者提出了请求 其中有些是系统改 进或增加功能的请求 有些是常规变更 例如帮新进人员建立账号 有些则可能 是系统出错 这些在 IT 中通称为事件 Incident 如果是系统出错 就必须要找出 原因及解决步骤 找到后就进到变更管理的第一步 也就是正式提出所谓的 变 更请求 Request for Change 简称 RFC 刚刚提到的这只是其中一个来源 其它的来源还包括外加的一些需求 例如立法的改变 像是股票交易时间延长 或是主动发现问题或提高效率的方法 这常常是来自程序设计师 项目经理等 变更管理的目标就是确保系统所有的变更都能以有效率及快速标准的方法及步骤 来管理 目的就是减少或防止变更对服务产生影响或将事件数减少 希望能在变 更需求与变更所可能造成的影响两者之间取得平衡 我们这边所提的变更管理 指的是 上线系统内的更动 包括软硬件等等 它不包括在开发中项目的需求变更 那是项目变更管理的范围 不过它们之间本 质有些相似 在大型的开发项目中 参与开发的程序人员何其多 任何一项变更 牵涉到什么系统 当然应该通知相关人员 并且等待核准这项改变 如果不这样 做 到时候整合起来当然会有问题 甚至会影响到整个开发系统 如果是上线系 统的变更管理 任一变更 必须知道可能会影响到的范围 要求做过独立及整合 测试 并且由相关人员核准这项改变 RFC 上面应该要有哪些项目呢 通常包括 RFC 编号 问题编号 如果是从问 题而来 有哪些配置项目需要变更 为何要变更的理由 如果不变更可能造成的 影响 最后是请求变更的人员其联络信息 IT 组织中应该有变更管理员 Change Manager 及 CAB 的编制 变更管理员 是全程负责监督 RFC 从提出到结案整个过程的人 CAB 则是 Change Advisory Board 的缩写 代表是变更咨询委员会 CAB 是如何组成的呢 首先将公司内各 式各样的系统或解决方案依性质分类 例如与 Internet 相关者归为一类 与数据库 相关者归在另一类 针对每一类系统指派人员组成一个 CAB CAB 组成可能包括 IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路 S P O R T Service Process Organization Resource Technology 上海信息化培训中心上海信息化培训中心 欢迎联络 欢迎联络 021 62123473 training leader MSN verymark 8 变更管理员 做为整个程序的主席 相关 IT 服务人员 IT 供货商 维护人员 开 发者 终端使用者或客户 专家或技术顾问等 CAB 成员可能不需要每次面对面 的开会 可以用电子邮件沟通 不过偶而的定期会面 比如说半年一次 可加强 彼此间的工作关系 这是有效率的变更评估所必须的 RFC 的提出 表示有人发现到必须在上线系统做某些变更 IT 部门应该要如 何处理响应此变更需求呢 我们下次再来谈之后的处理流程 实际的例子及如何 导入变更管理 2 2 变更管理的重要关键 2 2 变更管理的重要关键 前面提到变更管理的目标就是确保系统所有的变更都能以有效率及快速标准 的方法及步骤来管理 目的就是减少或防止变更对服务产生影响或将事件数减少 希望能在变更需求与变更所可能造成的影响两者之间取得平衡 RFC Request for Change 变更请求 简称 RFC 的提出 表示有人发现到必须在上线系统做某 些变更 IT 部门应该要如何处理响应此变更需求呢 RFC 一开始先送到变更管理员处 由变更管理员先加以过滤 如果是常规变 更 像是新员工账号建立 即可立即核准 其它则加以分类 指定优先等级 然 后根据类别 提到该类的 CAB Change Advisory Board 变更咨询委员会 简称 CAB 等待核准 CAB 审核这些 RFC 并根据公司业务需要建议公司要接受或拒绝变更 考量 因素包括对目前服务的影响 变更的成本 风险等等 最后根据这些因素提出建 议 如果该 RFC 被核准可以执行 就正式通知相关的技术小组来执行这些变更 技术小组所采取的行动可能包括建造一组新的上线模块 Module 建立一版新 的软件 自外面购买设备 或准备硬件 再经过独立测试与整合测试 如果成功 的话 变更管理员就可以安排时间执行该项变更 如果该项变更会干扰到使用者 的工作 就尽量安排在下班后或周末 以避免使用者服务停顿 不管是测试及变更结果成功或不成功 变更管理员都应该准备 变更检讨报 告 Change Review 做为下次 CAB 讨论的主题 通常 CAB 会议的议程会包括 失败或测试不成功的变更请求 新进要审核的变更请求 变更请求执行成功后的 后续追踪 一个成功的变更请求如果经过追踪成效良好 最后变更管理员就可以 结案该变更请求整个程序 在所有过程当中 变更管理员推动并监督整个过程 并记录于 CMDB 中 CMDB 指的是配置管理数据库 稍后我们会再提到它 以上讲的是变更管理这个程序的大致内容 其实公司有大有小 当然不必硬 性规定完全照这样一步一步很死板的进行 下面举几个例子 有一天 A 君到 B 公 司支持某产品 B 公司该项产品的管理员 C 君说最近该产品在使用上发现异状 A 君到 console 上看了看 告诉 C 君说某个设定要改 C 君说 那好 我要填一个 工单 说明这个变更动作的理由 你跟我一起去向主管 D 君解释 在这个过程中 工单就是 RFC 主管 D 君就是 CAB 的唯一成员 最后主管核准了该项变更请求 并安排在下班后执行 又有一次 B 公司的产品管理员 C 君致电 A 君 说系统出了问题 请他去协 助解决 A 君到现场花了半天 终于找出原因了 是该服务器的另一位管理员 F 君更改了一些设定 导致 C 君所负责的系统出了问题 C 君抱怨道 每次改东西 都不先商量一下 真会被他害死 这就是典型的变更管理的问题 F 君没有正式 IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路 S P O R T Service Process Organization Resource Technology 上海信息化培训中心上海信息化培训中心 欢迎联络 欢迎联络 021 62123473 training leader MSN verymark 9 提出 RFC 所以这项变更就没有经过 CAB 的讨论及核准 如果今天 F 君有提出 RFC 则因为 C 君也是该服务器的管理员之一 因此 C 君也会是 CAB 的一员 这 样在 CAB 的讨论过程中 C 君就能评估或说明该变更请求对他所负责的系统所产 生的影响 就不会有系统出问题的情况发生了 那如何才能将变更管理做好呢 首先管理人员要摒除变更管理是障碍的心 态 而应把它视为增进 IT 运作效率的一个契机 第二是要有个准确的 CMDB 配 置管理数据库 做为变更影响的分析 如此 CAB 才能做出正确的审核结果 另 外管理阶层的支持也扮演着重要角色 唯有管理阶层全力支持 才能在 IT 落实这 个变更管理程序 此外在导入变更管理的过程中 RFC 和 CAB 及 CMDB 是重要关键 当管理 人员确定有填 RFC 时 他才会认真思考该变更所可能造成的影响 有了 CAB 这 个组织 所有相关应该被知会的人员才能知道有这个变更需求 事先讨论并对该 项变更提出建议 准确的 CMDB 则可以协助 CAB 成员判断此 RFC 的影响层面 因此这三项要素缺一不可 也许您现在已经认同变更管理的重要性及程序 但是却在烦恼千头万绪不知 从何着手才好 其实像是 RFC 和 CMDB 都有现成的范本可供参考 所以如果你要 为公司建置 RFC 和 CMDB 可以先从这些模板开始着手 再加以些许的修改及自 订化 Customize 以符合或适应公司特有的特性 这将是最事半功倍的做法 IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路 S P O R T Service Process Organization Resource Technology 上海信息化培训中心上海信息化培训中心 欢迎联络 欢迎联络 021 62123473 training leader MSN verymark 10 3 1 建构企业 IT 的配置管理流程 3 1 建构企业 IT 的配置管理流程 在公司内通常都会做所谓的资产管理 Asset Management 也就是把每项公司 资产是何年何月何日购入 哪一个会计科目 负责人是谁等信息记载在数据库中 这是一般传统的资产管理方式 但是实际经验显示 如果用这种方式来管理 IT 相 关资产 包括硬件 软件 网络等等 结果会因为记录的信息太过简化而衍生出 许多问题 IT 资产的管理所必须记录的信息要比一般资产多得多 您可以想象出 要记录一台 PC 这项 IT 资产应该会比记录一张办公椅这种资产复杂得多了 目前有经验的 IT 部门都有一套方式来记录 IT 资产 但是 IT 资产的管理难道 就只是详尽记录它的型号版本等等这些规格信息而已吗 其实这是不够的 还要 包含该项资产所有的配置设定 以及它与其它 IT 资产之间的相互影响关系 这些 配置都会输入到所谓的 配置管理数据库 CMDB Configuration Management Database 中 准确而完整的 CMDB 是相当重要的 ITIL 中几乎所有的程序都会 用到它 例如上节 ITIL 的变更管理 Change Management 中 我们提到当一个 RFC Request for Change 变更请求 进入了变更管理的程序时 CAB Change Advisory Board 变更咨询委员会 或变更管理员 Change Manager 必须要有一个方 法评估这项变更所可能造成的影响 而评估就需要有相关信息 所以必须要有一 个机制来提供这个信息 这个机制就是配置管理 Configuration Management 配置 管理这个程序可存取并提供 IT 资产正确信息和这些资产间的关系 还能提供对系 统的影响及趋势分析 降低未经授权软件的使用情形 以及控制所使用的 IT 资产 版本 首先我们必须解释 CI 及 CMDB 这两个配置管理中最重要的名词 CI 是 Configuration Item 的缩写 IT 环境内使用的所有组件 包括软件 硬件 程序 文件等都可以当做是一个 CI 它可以是整个系统 也可以小到是某个小硬件组件 或软件模块 CI 层级 CI Level 的制定是配置管理程序中相当重要的成功关键因 素 后面我们会提到如何决定它 CMDB 是 Configuration Management Database 的 缩写 里面储存 CI 所有的相关数据 以及 CI 与 CI 之间的关系 从终端使用者提出事件开始 其中可能有些是问题 则进入到问题管理的程 序 如果最后找出原因及解决步骤 则提出 RFC 进入变更管理程序 而从事件 问题 RFC 一直到变更被核准及建置到上线系统中 都是由 CMDB 串连起来 每个 CI 应该要记录哪些信息呢 这就是 CI 的属性 Attribute 其中应该要包 括名称 版本 产品型号 地点 负责部门 供应厂商 RFC 编号 变更代号 事件及问题编号 目前状态 供应日期 指的是自供货商收到的日期 接受日期 指的是通过验收或测试的日期 目前状态等等 CI 状态可能包括订购中 修理中 储存中 丢弃 安装等等 CI 与 CI 间的关系有许多种 包括 parent of part of connect to reside on make use of is copy of is type of parent CI Child CI 等等 举例来说 某个 CI Is Part of 另一个 CI 例如模块软件是程序的一部分 服务器是某个解决方案的 一部分等 这是一种 parent child 关系 还有某个 CI Connect to 另一 CI 例如 桌上计算机连接到局域网络 或是某个 CI Make Use of 另一个 CI 例如某个程 序会使用到另一个程序的某一模块 某个解决方案或系统会用到某台服务器等 这些都是常见的 CI 与 CI 间的关系 实务经验显示 其实 CMDB 中只有 20 是资 IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路 S P O R T Service Process Organization Resource Technology 上海信息化培训中心上海信息化培训中心 欢迎联络 欢迎联络 021 62123473 training leader MSN verymark 11 料 剩下 80 是 CI 间的关系 配置基准 Configuration Baseline 是在某一个时间点的一组相关产品或系统 的设定 它包括其结构组成份子及数据细节 它可以做为未来工作的基准点 例 如假设有一组 CI 因某一 RFC 而修改 但不幸出了差错 可以把配置基准当做是还 原回之前的设定的一个参考点 从事件 问题 RFC 一直到变更被核准及建置到上线系统中 都是由 CMDB 串连起来 下面再来谈如何利用 CMDB 来做好配置管理 实际的例子及如何导入 配置管理 3 2 配置管理成功关键 3 2 配置管理成功关键 上节提到 我们上次提到从事件 问题 RFC Request for Change 变更请求 一直到变更被核准及建置到上线系统中 都是由 CMDB Configuration Management Database 配置管理数据库 串连起来 我们这次主要要来谈如何利用 CMDB 来做 好配置管理 实际的例子及如何导入配置管理 ITIL 的配置管理包括 4 项功能 分别是 识别 Identification 控管 Control 状态结算 Status Accounting 及验证稽核 Verification Audit 识别 Identification 是选定并指明所有的 CI Configuration Item 并贴上标签 以及在 CMDB 中建文件 记录下 CI 的所有信息 包括负责人 与其它 CI 的关系 版本及各相关编号 控管 Control 是确保只有经过授权并且可识别的 CI 才会被 接受 而且从进公司到废弃全程记录 还要确保如果没有经过核准或文件证明 就不能新增 修改 置换或移除 CMDB 中的任何 CI 资料 每个软件 CI 都应该要有授权编号 如有不是这样 公司员工如果被发现在 公司内有非法的软件使用行为 可能会面临赔偿或牢狱之灾 ITIL 的配置管理能 让企业监督及控制软件授权从采购到终止使用为止 目前市面上就有专门的软件 资产工具可以协助这项工作 状态结算 Status Accounting 是定期打印出报表 列出目前及历史 CI 状态 最后验证稽核 Verfication Audit 则是执行稽核 确认 记录与目前环境是否一致 现在我们已经了解配置管理的基本观念 那么在实际进行时应该要注意哪些 关键 才能使配置管理更容易成功呢 第一是 CI 的层级不要设得太高或太低 例 如一台 PC 到底是要把整台 PC 设成是 CI 的最低层级 还是要将 PC 内的屏幕 硬盘 键盘 RAM 等组件分别设成一个个的 CI 呢 最重要的原则是最低层级的 CI 应该是要能独立变更 Independent Change 所以上例的情况就要看 IT 部门决定要如何管理 PC 而定 假如是公司内的 PC 都不会拆开 一定是整套购入 维护 升级 甚至报废 那就可以把整台 PC 设成 是一个 CI 如果是 PC 可能会拆开而针对个别组件维护的情况 那就应该为如硬 盘之类可独立变更的组件设定个别的 CI 第二个关键是配置管理程序的范围 Scope 不要太大也不要太小 一个经验是可以从最重要的关键服务开始进行 第 三个关键是必须要有准确的 CMDB CAB 才能评估变更所可能造成的影响 那如何开始导入配置管理程序呢 可以从最重要最关键的服务中它们所使用 的组件出发 先找出内含的 CI CI 层级过高或过低都不好 我们刚刚提到独立变 更的观念 你可以试问 通常该组件若要独立安装 置换或修改的最小单位是什 么 你追踪该组件时会追踪什么东西 这个数据对事件管理 问题管理 变更管 IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路 S P O R T Service Process Organization Resource Technology 上海信息化培训中心上海信息化培训中心 欢迎联络 欢迎联络 021 62123473 training leader MSN verymark 12 理等程序有没有帮助 我们是否有了未来我们会做的业务判断所需的数据 如果 再进一步分解 所花的人力时间成本与所提高的价值相比值不值得 决定了 CI 之后 接下来是把所有的 CI 放在一个 CMDB 数据库内 定期检查 CI 数据是否正确及 CI 层级是否恰当 有了完善的配置管理程序及准确的 CMDB 下面这些情况就可以派上用场了 举例来说 假设操作人员现在要择期升级服务器 A 可是他不确定服务器 A 上有 些什么应用程序 这时他可以先在 CMDB 数据库中查询 在服务器 A 上有执行哪 些应用程序 找出这些应用程序负责人的联络方式 再与他们连络安排服务器停 机最佳时间 另外 大公司的 IT 部门有个最头痛的问题 就是弄清楚公司内的众多计算机 里面到底装了些什么东西 如果有了完整的 CMDB 它可以协助找出哪一个 Windows 服务器还没有安装 Service Pack 或没有安装某一个 Hotfix 还有一种情况是假设有使用者回报说应用程序 XYZ 有些问题 此时 Service Desk 人员可以先用 CMDB 查出应用程序 XYZ 是在服务器 A 上执行 再从 CMDB 内的变更历史记录查出在服务器 A 上最近做过的相关动作 在说明完毕配置管理的重要性及程序之后 您可能会问 有没有 Template 或 Sample 可以参考 其实 CMDB 基本上是一个数据库设计 CMDB 的 Schema 及范例数据库和程序都有现成的模板 所以如果你要为公司建置 CMDB 可以先 从参考这些模板开始着手 再加以些许的修改及自订化 Customize 以符合或适 应公司特有的特性 建置好一个准确的 CMDB 对公司 IT 的运作各个程序都有莫 大的帮助 IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路 S P O R T Service Process Organization Resource Technology 上海信息化培训中心上海信息化培训中心 欢迎联络 欢迎联络 021 62123473 training leader MSN verymark 13 4 1 建构企业 IT 的版本的发行与控管 4 1 建构企业 IT 的版本的发行与控管 我们上次提到 在变更管理程序中 当 RFC Request for Change 变更请求 被核准后 接下来是建构 Build 测试 最后才实作 implement 到上线系统中 如果是比较大的变更 这一部分的程序会更形复杂 需要把这一部分独立出来 这就称为发表管理 Release Management 另外一般应用程序的新版本或新的解决 方案在建置时 也是经过发表管理才成为上线系统 为何需要发表管理 在现今的分布式环境下 每次硬件及软件的发表可能牵 涉到许多的服务及产品供货商 因此需要透过发表管理 事先做好资源规划 才 能把一个系统成功的推出给使用者 发表管理是以宏观的角度视野 来看 IT 服务 的变更程序 确保发表的所有层面 包括技术及非技术相关事宜 都有全盘考虑 到 发表管理的工作重点就是透过有计划的发表步骤及检核的使用 来保护上线 环境及其服务 如果不是这样的话 使用者便会看到所推出的是不完整或考虑不周详的应用 程序 假设公司未经完善考虑而仓促升级 A 系统 开始上线运作后 却又发现数 据处理有问题 只好再决定回到原来的系统版本 弄得使用者 顾客和 IT 管理人 员怨声载道 这是常常听见的情景 由于发表会直接影响到使用者及公司业务 因此需要事先通盘考虑 确定所有的步骤或所有可能发生的状况都有考虑到 所 有的事前准备工作都完备无误 这样才能增加发表的成功机率 把发表所可能对 业务中断机会降到最低 进而提高 IT 服务品质 发表 Release 这个名词指的是一组经核准的 IT 服务变更所组成的集合 这些通常由一组解决问题的修正程序或加强服务功能的程序模块所组成 发表包括了要执行这些经核准的变更所需要全新的或变更的软硬件 发表 可分为 主要 Major 软件发表及硬件升级 通常会包含许多全新功能或功能大幅 翻新 较小 Minor 软件发表及硬件升级 通常包含较小的修正或加强功能 紧急 Emergency 软件及硬件修正 通常包含几个已知问题的紧急修正 系统发表时通常也是根据这个分类而加以编号 发表编号是由它所代表的 CI Configuration Item 名称 加上版本号码所组成 例如 主要发表 薪资系统 V1 V2 V3 等 较小发表 薪资系统 V1 1 V1 2 V1 3 等 紧急修正发表 薪资系统 V1 1 1 V1 1 2 V1 1 3 等 另外发表也可分为 Full Release Delta Release 及 Package Release Full Release 指的是整个系统重新建构 测试及实作 没有旧版本 CI 夹杂在其中 Delta Release 或 Partial Release 指的是只发表从上次最后的 Full Release 之后 有变动部分的 CI 举例来说 如果要发表的是软件程序 则 Delta Release 只会包括自上次最后 的 Full Release 后有修改到的模块或是新的模块 Package Release 是把几个发表合 在一起执行 以减少发表的频率 IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路IT 管理培训领导者 基于 ITIL 的 IT 服务管理之路 S P O R T Service Process Organization Resource Technology 上海信息化培训中心上海信息化培训中心 欢迎联络 欢迎联络 021 62123473 training leader MSN verymark 14 4 2 发表管理的流程与步骤 4 2 发表管理的流程与步骤 上一篇我们阐述的是发表管理 Release Management 的一些关键术语及概 念 接下来在这一篇的焦点则是着重在发表管理的工作内容 发表管理包含了规划 设计 建构 配置设定及测试将来作为上线环境的这 组发表组件的软硬件 此外发表管理的工作内容还涵盖要发表到多组使用者及地 点时 相关的规划 准备 与时程安排 发表管理的细部工作项目包括 发表方针 policy 及规划 详细制定发表计划 推出计划 Rollout Plan 安装步骤 测试计划及还原 计划 Backout Plan 设计 建构及设定发表组件的配置 发表的验收规格 Acceptance 推展规划 Roll out Plan 根据验收规格执行大量而深度的测试 签字接受 Sign off 此发表版本 安装全新或升级硬件 沟通协调 事前准备与教育训练 正式发表 软件派送与安装 将正式发表版本存放在 DSL DSL 是 Definitive Software Library 的缩写 也就是公司内所有软件的统一安装 来源 它是所有采购进来和内部开发软件的单一逻辑媒体存放区 不过实体上可 以存放多份 而 DHL Definitive Hardware Library 与 DSL 是同样的观念 它是用 来存放备用的硬件 DSL 及 DHL 都是存放实体的 CI 而 CMDB 则是存放它