ISO20000标准学习
- 格式：docx
- 大小：35.74 KB
- 文档页数：5
Iso20000 it服务管理标准培训总结
一、ISO20000引入
a) ISO9000是广义的质量管理标准族，ISO20000是IT服务管理的标准，属于质量管理族群。
b) 课程目标
i. 标准的理解
ii. 审核技巧
iii. 落地实施
c) 审核就是帮助审核员建立信息的过程
d) 管理就是对整个生命周期的管理
二、ISO20000标准
1. 变更管理标准
➢ 服务由哪些模块组成的，这就是服务组件，有人，设备，软件，硬件。
➢ 因为CI里面有人、地点等等就是你提供服务的物理场所，只要动CI项就要走变更。
➢ ISO20000里有重大影响的变更在第5章里说明，不走变更。
➢ 变更过程管理是对流程的一个补充，针对于配置项之外的变更都可以包含进去，只要满足变更四要素。
➢ 变更四要素：记录、分类、评估、批准。
➢ 要对变更进行分类
➢ 服务下线是重大变更（标准对变更分类的建议）
➢ 变更应有审批流程，记录，分类，评估的过程
➢ 紧急变更应与客户协商形成控制文件
➢ 变更之前要有变更请求，明确范围
➢
➢ 变更计划
➢ 变更和发布的关系：变更只管这个事情能不能做，而发布是做具体内容的，比如实施
➢ 只要动生产就归变更管
➢
➢ 重大变更后要有事后评价，评价其有效性。
2. 发布管理
➢ 和客户协定发布频率和策略，不能随便发布。 ➢ 紧急发布的定义需要协商并且文件化，由紧急变更触发紧急发布
➢ 发布之前必须要在准生产环境、测试环境中测试。
➢ 发布单里要有验收准则。
➢ 在发布部
➢ 署的时候应该保证软硬件的完整性
➢ 在发布之前要做好回退等计划。
➢ 要对发布的结果做总结，提高以后发布的成功概率。
➢ 明确发布日期，给事件变更服务请求等流程的处理提供依据
➢
3. 事件管理标准
➢ ISO20000定义：非计划的服务中断、服务质量降低、未对服务造成影响（监控由工具和人组成，发现记录处置关闭）（如何管巡检：两人录像或者一个人带个摄像头盔）
➢ ITIL的定义：IT服务意外中断或者IT服务质量下降或尚未影响配置项失效
➢ 事件是针对服务，服务请求针对客户，具体看一个事情算事件还是服务请求是看你对于两个概念定义的范围。
➢ 事件优先级的目的在有限资源内看优先处理哪个问题，分类的目的是找对人去做
➢ 技术升级一般是组内能做完找更资深的工程师，管理升级是协调资源（背责）
➢ 用流程管服务请求的全生命周期
➢ 20000对于事件分级的维度是影响度和紧急度（重要业务中断是紧急的）
➢ 应该向客户通告事件处理的进展，尽量不让客户不满意
➢ 重大事件是与客户协商制定的？要进行分类分级，同时告知最高管理者，确保专人处理重大事件，之后需要回顾重大事件来进行改进。
4. 问题管理标准
➢ 问题与事件的界限：在恢复之前找根本原因是事件，在恢复之后找根本原因是问题
➢ 问题流程的识别：提错了、已知不能解决的问题、不值得找原因。
➢ 问题的定义：频率高、重大事件必须触发问题
➢ 问题的主动分析：按照事件发生的次数趋势来定义。
➢ 已知错误定义：已经记录了根本原因和规避措施的问题
➢ 在没有找出根本原因应给事件提供更有效的解决办法
5. 配置管理 ➢ 配置项：为交付IT服务而需要管理的任何东西
➢ CMDB：有两个CMDB有物理的CMDB和大的CMDB
➢ 标准中a-h是表头
➢ 每一个配置项必须要有唯一标识
➢ 要确保CMDB 可靠性和完整性
➢ 配置的全生命周期管理一定要落到某个制度上
➢ CMDB要摒弃人们的欲望，本质是与变更相关联，这是一个最小级的CMDB
➢ 从业务和服务的视角向下看可以看到所有预期相关的配置项，这个是CMDB的一种描述。换一个角度，CMDB应该有从服务到底层的所有信息（服务、软件、硬件）。
➢ CMDB一定需要关联信息
➢ CMDB与财务资产管理相关联就是其资产编号。
➢ 配置管理三要素：广度、深度、关系
6. 供方管理
➢ 20000里的供方管理只是管理从合同签订到最后评价的全过程，不包括前期谈判等等。
➢ 提供了一个与供方的合同模板
➢ 如果要分包，分包商要把客户的要求提供服务提供者。
➢ 对于供应方的绩效，最好是半年一次。
7．业务关系管理
➢ 服务提供者应该识别服务的客户、用户和相关方，并形成文件，将客户关系梳理清楚
➢ 基于客户要求响应客户需求，按照SLA严格执行，若不能执行应尽快与客户进行协商（采用可以，但是的原则）
➢ 对投诉本身进行定义
➢ 建议与客户的沟通机制，并做满意度调查，识别整体满意度，制定沟通计划
8.服务级别协议管理
➢ 服务和服务组件的依赖关系是某个服务只能由某个组件才能完成，技术服务目录和业务服务目录相关联
➢ 服务级别协议三要素：
➢ 应包含服务目标、工作量特性和例外（不可抗力因素）
➢ 要定期按照SLA与客户进行评审
➢ SLA与服务目录保持一致
➢ 定期对SLA达成情况进行评审
➢ 技术服务目录是运维团队提供的所有服务，前提是客户不可见。
9.服务报告
➢
➢ 标准要求将服务报告发送给客户和管理层。
➢
➢
➢ 服务报告包括：SLA中的绩效有无达成、重大变更与重大事件、工作量、通过趋势识别改进项和风险、客户满意度分析结果
➢ 给领导写报告要将风险告知，因为这个是领导最关心的。
10.信息安全
➢ 关注的是信息的不安全，要识别风险处置不安全因素。
➢ 风险是个中性词，可以对期望有正面和负面的偏离
➢ 风险是对目标不确定性原则
➢ 主要是关注风险评估，具体看范围和风险是否完整
11.服务的可用性和连续性
➢ 20000针对服务的可用性和连续性
➢ 对于99.99%来说可用性管理关注的是0.01%的风险如何避免，列出风险项，然后做个类似于预防措施的东西来控制风险。
➢ 连续性要根据可能的场景写应急预案，确定连续性风险，梳理连续性计划。
➢ 端到端：确定我的服务是从哪端到哪端。
➢ 服务连续性要保证在极端情况下连续性计划、联系人清单、CMDB数据可用。
➢ 应急预案必须经过测试，如做应急演练
➢ 在环境进行变换的时候要重新做可用性和连续性计划。
12.文件管理
➢ 文件的控制：文件模板、命名规则、编号规则、审批路径、版本控制等。
➢ 文件建设：模板、命名、编号、版本、文件架构
➢ 文件发布：审批路径
➢ 文件使用：借阅流程（外部人员来看）
➢ 文件修订：
➢ 文件废止：
➢ 在文件为发布之前，文件编写者对文件内容有保证其不泄露的义务和责任
13.资源管理 ➢ 人力资源管理：培训计划、培训记录、培训总结、人员意识宣贯（可以在每年新员工培训做宣贯）
14.建立和改进服务管理体系
➢ 组织范围：确定人员范围
➢ 地理范围：生产、灾备、同城
➢ 服务范围：服务目录sla
➢ 20000要求要有服务管理计划
➢ 服务管理体系里面含：服务管理目标、服务要求、服务管理的已知限制（因为有限制我的管理范围无法覆盖，如安全由集团公司出管理标准，我们不能覆盖）
➢ 服务管理体系包含：服务管理体系框架、权限职责、完成管理目标所需的人员技术等资源、风险的接受准则、流程接口整体的整合方法、技术支持（流程工具可在总体文件里写明，事件变更在用F5支撑，其余的用表单模板管理）、要对服务管理体系。
➢ 实施：分配资金、评估风险、监视绩效、分配预算、管理人员你和相关资源。
➢ 检查：由内审管审来对体系建设情况进行整改。
15.设计和转换新的或者变更服务
➢ 初衷是解决运维和开发交接的问题，运维前移，20000里说的全都是运维提供的服务
➢ 有潜在重大影响的服务
➢ 识别运维人员的要求，与客户开会识别客户的要求，与客户达成一致
➢ 当有新服务的时候标准需要：人员技术准备、与其他组织的活动、识别评估风险等等
➢ 确定新服务和变更满足服务要求
➢ 新的服务和变更要形成文件化的东西
➢ 首先是运维前移，在与客户开会的时候提出非功能性需求，也就是运维能不能做
