ISO20000管理体系培训(实操篇).ppt

信息安全管理 ISO20000与ISO27001要求异同 专注于IT服务管理 ISO20000中有信息安全管理要求 故障管理、资源管理和业务连续性管理实施的互补加强 Description of the contents 相同 不同 ISO20000 ISO27001 专注点 适用范围 侧重点 以流程为核心，注重流程目标 通常为IT服务部门 IT服务管理 以具体控制点和控制措施为主 整个企业 信息安全管理 信息安全管理 ISO20000的信息安全要求 管理 控制 变更与事件 安全方针 安全目标 风险评估 风险审计 回顾和改进 物理控制 管理控制 技术控制 信息资产访问 新增服务或者变更服务时的风险 信息安全事故的风险 现有安全方针和控制措施的潜在风险 ISO27000信息安全管理体系标准都提供了详细的指南，可作为ISO20000信息安全管理部分的加强规范。 信息安全管理 ISO20000要求的信息安全管理内容大体符合ISO27001信息安全管理的要求，但是在一般运行中，更多的偏重于员工的信息安全、资产识别和管理，风险识别和事故处理等环节。 模版：（1）资产识别和风险评估 （2）员工信息安全手册 容量管理（能力管理） ISO20000要求： 与资源管理的区别 资源管理是要为服务管理体系PDCA提供资源支撑，特别是在人力资源方面。（更多关注内部资源需求） 容量管理关注提供的资源是否满足客户业务当前和未来的需求。（更多关注外部资源需求） 容量管理（能力管理） 容量计划应该包含的内容 容量监控 容量报告应该包含的内容 我们日常已经对网络IP、网络流量、人力资源调度、机房机架数量等进行用量监控。 我们还需要一张容量总图，来对整体的服务提供能力进行整合，把孤立的资源进行整合 对容量计划的内容进行实际情况考核 对资源不足或者过剩资源进行补充话处理 关注成本、预算和实际费用的差距 制定和调整下一周期容量计划 事件和服务请求管理 ISO20000要求： 要有一套常规事件管理的程序：记录、优先级分配、分类、记录更新、升级、解决、关闭 紧急事件和重大事件流程的制定 对事件处理KPI的定义和考核 事件和服务请求管理 我们的现状？ 达标了吗？ 我们的问题在哪里？ 我们有一套事件和服务请求管理流程，并且已经固化到IDC业务运营平台上 我们有对事件和服务请求进行数据分析，对故障有解决方案和故障处理报告 我们的运维人员对这一流程已经相当了解 平台事件模块帮到我们运维人员提高故障响应和处理故障的效率了吗？ 在平台走事件的时候所有人员都按照规则办事了吗？ 我们的流程有没有严格的KPI限制，达不到KPI要求有没有追责到人？ 事件和服务请求管理 我们需要有什么改进？ 事件和服务请求流程文件的修改。目前该流程已经不适用于现状，对服务和运维人员的指导作用不明显。事件和服务请求流程和故障处理流程可以整合为一个流程，也可以将事件流程和分服务请求流程分开为两个流程，虽然流程总体框架是一样的，但是这两个流程的具体活动和要求是不一样的 流程KPI的落地。KPI不能只是做展示，还要设置KPI阈值，对超出阈值进行整改或和改进。 加强对平台的规范使用，尽量减少人为对流程的影响。平台的记录必须详细完整，同时要做好平台的规范培训，使流程固化，无论换了什么人操作，都能使流程顺利进行。 问题管理 ISO20000要求： 要有一套常规事件管理的程序：识别、记录、优先级分配、分类、记录更新、升级、解决、关闭 问题管理与知识库 知识库的分类 ●Know-what(知道是什么的知识),是指关于项目组织架构、维护内容的知识 ●Know-why(知道为什么的知识),是指提供服务的原理和规律 ●Know-how(知道怎样做的知识),是指做某些事情的技术和能力 ●Know-who(知道是谁的知识),是指在工作过程中,知道如果出现了问题应该请教谁 员工知识:员工个人技能、知识潜力、工作经验、工作记录; 流程知识:将知识嵌入业务流程之中,在关键环节能有专家知识支持; 案例库记录 业务知识 外部文献引入 知识分类方法 两种方法可以整合使用 知识颗粒度可以通过知识树、分类、链接、归并等方式, 将小颗粒度的内容整合成中颗粒度、大颗粒度 配置管理 ISO20000要求： 配置管理 配置管理流程与角色 配置管理 CI属性划分 变更/发布管理流程与CMDB更新之间的关系 配置管理 变更管理 ISO20000要求： 必须要做到： 变更实施前必须进行风险评估和审批 变更方案必须有回退和变更失败时应采取的措施 变更成功后，要更新CMDB 需要定期对变更进行回顾，纳入服务改进计划 变更管理 发布管理 ISO20000要求： 发布计划 回滚计划 发布验证 必须要做到： 发布前需要做测试和制定回退计划 可以定期打包发布，