运维管理体系要点分析.ppt

配置管理--CMDB 配置与其它流程的关系 配置管理常规策略 只有配置经理和配置管理员有权修改配置信息； IT组件对应的配置项信息的修订由配置管理流程控制； 所有在配置管理范围之内的IT组件的变更都应该由变更管理流程来迚行。 每年定期进行配置项审计，审核和验证CI、CI属性、CI关系等信息，确保CMDB的正确性和完整性；配置项审计由配置经理负责实施。建议在每年的资产盘点后，配置管理人员根据资产盘点结果做配置项审计。 CMDB—拓扑展现 配置库生命周期 事件管理 一约束（SLA)、一中心(CMDB) 事件管理—请求管理流程 事件测量过程 一年之中只能宕机20个小时 客户不会充许你在同一个时间里把20小时用完 宕机是一级故障 一级故障的解决时间是1小时 会强制把20个小时分散到全年之中，以减少对业务的冲击 如按时解决率等等这些事实是用于服务管理 站在客户方的立场而言有了这些指标就足够约束服务商 可用性与解决时间的关系 事件测量过程 事件的测量过程-----等于对SLA的测量 解决时间这一指标横跨整个事件 在服务人员处理事件时，当创建的那一刻开始倒计时以约束并加快处理进程 运维人员的接单需要考虑事件等级与解决时间剩余。 开单时间、接单时间、 首次解决、完成时间、 关单时间 挂起（例外因素如：因客户或第三方造成的等待时间） OLA进行体系内各岗位对运维的工作支撑 按排适合的人处理相关事件成为策略关键 事件管理 SLA的实施是需要不断完善及量化的过程 知识 问题 变更/发布 配置CMDB 减少 帮助 约束 完善 产 生 产生 问题管理 问题管理过程 识别，记录与归类 评审与分派 调查与诊断 问题解决 问题关闭 问题确定 问题解决 创建问题单 收集问题信息 设定等级、分类 问题经理分析问题对业务的影响并确定是否进行调查工作 分派问题给技术专家 问题专家决定是否接受分派 确定并记录问题的根本原因 鉴别已经错误 调查问题或技术专家，确定已知错误 确定参与解决的人员(厂商，内部人员） 有需要提交RFC 验证 更新知识库 问题管理—关键点 问题来源 问题确认 问题解决 质量控制 事件升级 事件主动分析 巡检发现 事件的分析 多部门参与 协调资源 问题的确定 多部门参与 方案确定 技术保障 变更的执行 产生新的潜在问题 避免新问题产生 变更及发布 变更及发布 变更及发布---关键点 变更来源 变更准备 变更实施 质量控制 事件升级 问题解决 新需求 多部门参与 审核与启动 复核与确认 审批与排程 方案与测试 多部门参与 按计划执行 安全保障 技术保障 变更验证 变更回顾 变更成功率 避免新问题产生 变更及发布---标准化流程 实施变更管理的难点和重点并不是工具，而是流程 变更发生的时候，有一个标准化的流程去执行，能够预测到这个变更 对整个系统管理产生的影 响，并对这些影响进行评估和控制。 而变更管理流程自动化的实现关键就是CMDB * * * * * * * * * * * * * * * * * * 运维管理体系 目录 1 运维的理解及定位 2 运维管理体系及要点 运维的理解－－什么是运维 1 2 3 项目 运维 运维与项目 在约定的时间内完成约定的事情，达到预期的目标。 项目的建设达到相定时期的必然产物。 运维是对实施项目的继承，本身也是一个项目，更多是长期为项目提供业务及技术支撑。 运维的建设定位----运维即服务+运营 建设定位 业务驱动，服务运营 规范管控，实时监控 固化流程，强化控制 梯队建设，协同综效 由“技术驱动”向“业务驱动”转变，主动的服务提供者向客户（业务部门）提供赖以支撑组织业务运作的IT服务，促进业务成熟度的提升，达成精细化的运营管理。 以工具、流程为着力点，实现运维的规范管理；以管控为支撑，提供运维过程的实时监控。 利用标准化手段，固化流程，强化关键控制点，提高风险管控能力，达成客户满意度 初、中、高级运维技术梯队，协同处理，及时分配，高效运转 协议清晰，职责明确 服务形式、服务目录、SLA（客户协议）、OLA（内部协议）、UC（伙伴协议）。 目录 1 运维的理解及定位 2 运维管理体系及要点 运维管理体系----个人认证 ITIL： IT基础架构库(Information Technology Infrastructure Library, ITIL，信息技术基础架构库)由英国政府部门CCTA在20世纪80年代末制订，现由英国商务部OGC负责管理，主要适用于IT服务管理（ITSM）。ITIL为企业的IT服务管理实践提供了一个客观、严谨、可量化的标准和规范。旨在提高IT资源的利用效率和质量，帮助企业组织改善他们的IT服务管理。 最佳实践指南 运维管理体系----企业认证 ISO20000： 面向