★ FEATURED ARTICLE 简介面向信息技术服务管理体系从业者、内审员与认证审核人员的ISO/IEC 20000-1:2018中文版标准文档适合用于标准条文查阅、体系转版对照和审核准备。文件为北京中大华远认证中心翻译的参考译本正文按范围、规范性引用文件、术语和定义、组织背景、领导力、规划、支持、运行、绩效评估与改进等章节展开并保留服务组合、关系与协议、供需、设计构建转换、解决与履行等过程条款便于快速定位条款、理解新版相对2011版的结构调整。压缩包仅含1个PDF约551KB体积轻便适合在电脑或移动端随时翻阅。该文档已有4376人学习下载可作为组织建立、实施、维护和持续改进服务管理体系的条文依据也能帮助读者梳理审核要点、对照差距并完善文件化信息与知识管理。1. 服务管理体系的一张地图20000-1:2018 把组织切成哪十块不少人第一次翻开这份中文版会觉得它“薄得不像标准”——二十多页正文条款 8 里翻半天也找不到“事件管理到底几步走”。这个反差恰好说明了它的定位它是一份信息技术服务管理体系SMS的要求文件只写“必须达到什么”把“怎么达到”原封不动留给组织。整份标准的地图其实极好记条款 4 组织的背景、5 领导力、6 规划、7 支持、8 运行、9 绩效评估、10 改进。前四章打地基第 8 章是主体服务组合、关系和协议、供需、设计构建转换、解决与履行、服务保证六块后两章收口。第三版 2018 年 9 月发布取消并替代 2011 年的第二版条款结构和术语都动过刀拿旧版记忆去复习最容易在细节上翻车。2. 高阶结构骨架条款 410 与附件 SL 的对应关系2.1 条款顺序来自通用高阶结构而不是服务流程顺序第二版的组织方式更像“服务生命周期”第三版换成了管理体系标准的通用骨架。标准引言里说得很直白条款结构、3.1 的术语以及多项要求都来自 ISO/IEC 导则第一部分的补充规定附件 SL也就是管理体系标准的通用高阶结构HLS。这样做的直接好处是能和其他体系整合——服务管理体系可以和基于 ISO 9001 的质量体系、基于 ISO/IEC 27001 的信息安全体系放在一套文件里跑。所以复习时不要拿“服务战略—服务设计—服务转换—服务运营—持续改进”这条老链条往第 410 章上套会错位。正确的读法是4 定范围、5 定人、6 定目标、7 定资源、8 干活、9 看数、10 改错。重点在这条款 8 之前的每一章都是“为第 8 章服务”的如果复习时把 47 章当背景略过到第 8 章会发现很多要求找不到落脚点比如 8.2 的服务组合要跟 6.2 的服务管理目标对齐8.7 的信息安全管理要跟 7.5 的成文信息对齐。还有一个常被忽略的改动前言 i) 明确写了本次更新删除了原来的图 1 和对 PDCA 的引用因为附件 SL 没有特别使用它而且很多改进方法都能和管理体系标准一起用。这意味着“PDCA 循环图”不再是复习抓手别再拿它当记忆锚点。2.2 1.2 应用能借力的条款和绝对不能借力的条款1.2 是整份标准里最容易被读快、也最容易被判不符合的一条。它把“外包”这件事划成了三段情形标准怎么规定复习抓手条款 4 和条款 5组织应证明自身符合但可以由其他方提供支持支持可以做责任不能转条款 6 至 10 有其他方参与组织应提供承担规定要求责任的证据指向 8.2.3有参与就必须有管控证据其他方承担全部服务、组件或流程责任组织不能声称符合本标准全外包等于没有体系举例说把基础设施组件或服务台运行包括事件管理流程交给外部方本身不违规但组织要拿得出“对涉及服务生命周期各方的管控”的证据。重点在这这条要求同时锁死了两件事——责任主体不能转移管控动作必须留痕。梳理下来会发现很多体系文件写得漂漂亮亮一到这一条就只剩一句“已委托某外部方负责”既没有 8.2.3 的管控证据也说不清剩余责任边界。2.3 第 7 章支持六项里“知识”是新面孔第 7 章支持有六个子条款7.1 资源、7.2 能力、7.3 意识、7.4 沟通、7.5 文件化信息、7.6 知识。前五项在管理体系标准里属于常客7.6 知识是第三版新增的内容之一前言 d) 专门点了“增加了关于知识的要求和规划服务”。把 7.6 和 3.1.6 成文信息放在一起看关系就清楚了成文信息管的是“控制并维护的信息及其载体”知识管的是“组织需要哪些知识、怎么获取、怎么保持可用”。两者的分界线在于——写下来并被控制的是成文信息留在人脑和协作习惯里、但必须有获取途径的是知识。复习时如果只背“7.6 知识”四个字很容易在案例题里答不到“如何确定所需知识、如何保持和获取”这个层面。同时7.5 的成文信息在第三版里是做减法的前言 h) 列得很清楚删除容量管理计划文件的要求替换为容量计划的要求删除可用性计划文件的要求替换为服务可用性要求和目标的文件删除配置管理数据库要求替换为配置信息要求删除发布策略要求替换为定义发布类型和频率的要求取消持续改进策略的要求用确立改进机会的评估标准取代。这五条是全篇最值得单独抄一页纸的内容。“最小化保留成文信息的要求只保留关键的成文信息如服务管理计划”是总原则那么复习时的正确姿势是把“必须有的文件”和“必须有但形式自由的内容”分开记。2.4 条款 2 是空的但引用并没有消失第 2 章规范性引用文件只有一句本标准中没有规范性引用文件。第一次看到会以为印刷缺页其实它是个精确的表述——本标准正文不依赖其他标准的条文才能成立。但引用并没有真的消失只是换了个身份。术语条目里到处是来源标注3.2.6 信息安全、3.2.7 信息安全事件标注来源 ISO/IEC 27000:20183.2.11 程序、3.2.12 记录标注来源 ISO 9000:20153.2.1 资产标注来源 ISO/IEC 19770-5:2015。这些属于定义溯源不是规范性引用。重点在这复习术语时顺着这些来源标注看能省掉大量猜定义的时间——信息安全就是机密性、完整性、可用性三要素和 27000 完全对齐不需要另起一套理解。3. 术语两套账3.1 管理体系词表与 3.2 服务管理词表怎么对上3.1 拆成两本术语表的用意第三版把术语与定义拆成 3.1 管理体系标准专用术语和 3.2 服务管理专用术语两个子条款前言 g) 说明了原因一是基于附件 SL 增加了一些新术语比如目标、方针二是服务管理本身需要一套自己的词比如资产、用户。拆分的实际效果是3.1 那批词审核、能力、符合、持续改进、纠正措施、成文信息、有效性、相关方、管理体系、测量、监视、不符合、目标、组织、外包、绩效、方针、过程、要求、风险、最高管理者负责“体系语言”3.2 那批词资产、配置项、客户、外部供应商、事件、信息安全、内部供应商、已知错误、问题、程序、记录、发布、变更请求、服务、服务可用性、服务目录、服务组件、服务连续性、服务级别协议、服务级别目标、服务管理、服务管理体系、服务提供者负责“业务语言”。重点在这答题和写文件时凡是描述“体系怎么运转”的句子用 3.1 的词凡是描述“服务怎么交付”的句子用 3.2 的词。混着用最典型的翻车现场就是“服务提供方制定了不符合的纠正措施”——2018 版里服务提供方这个词已经不是主用词了。3.2 四处改名带来的连锁反应前言 g) 列了四组关键改名这四组是复习时性价比最高的记忆点第二版用词第三版用词连锁反应服务提供方组织全文叙述主语统一体系文件里的“服务提供方职责”要改成“组织职责”内部小组内部供方与 3.2.4 外部供方形成对称供应链视角更完整供方外部供方凡是说“供方管理”的地方要明确是外部还是内部可用性服务可用性“可用性”让位给信息安全三要素服务侧必须加“服务”二字信息安全与 ISO/IEC 27000 对齐定义直接引用不再自成一派这五处看着是文字游戏落到条款上就不一样了。比如 8.3 关系和协议里的供应商管理管的是 3.2.4 外部供方——与组织签订合同、参与规划、设计、转换、交付或改进服务、服务组件或过程的组织外方注 1 还特别说明“包括指定的主要供方但不包括其分包供方”。而 3.2.8 内部供方指的是大型组织中 SMS 范围之外、签有成文协议的那一部分比如采购、基础设施、财务、人力资源、设备等部门。一个是合同关系一个是同一大型组织内的成文协议关系管控方式完全不同。重点在这把这两类供方混成一锅8.3 的供应商管理就会漏掉内部供方那一半。3.3 五组最容易混的术语对照术语一句话抓手常见混淆事件服务的意外中断以及导致服务质量下降但尚未对客户或用户的服务产生影响的事项当成“用户报障”同义词漏掉“尚未产生影响”这一半问题一个或多个实际或潜在事件的原因当成“严重事件”于是只做事后处理不做原因分析已知错误已识别根本原因或已找到减少、消除其对服务影响的方法的问题以为等于“已关闭”其实它仍是问题的一个状态资产对组织具有潜在或实际价值的元素、事物或实体价值可正可负和配置项画等号配置项需要加以控制以提供服务的元素以为所有配置项都是资产资产和配置项的关系标准写得很清楚资产可以是配置项但某些配置项可能不是资产。反过来有些资产比如声誉、协议根本不进配置管理。这条在 8.2 的服务组合里会直接考到——配置信息要覆盖什么范围取决于“需要加以控制以提供服务”这个判据而不是“值多少钱”。再补两组服务与服务组件。3.2.15 说服务是“通过帮助客户达成其期望的结果而向客户交付价值的手段”3.2.18 说服务组件是“服务的一部分与其他元素组合提供完整的服务”例子包括基础设施、应用程序、文档、许可证、信息、资源或支持性服务。3.2.20 的 SLA 是组织与客户之间定义服务及达成一致服务指标的成文协议注 1 明确“组织与外部供方、内部供方或作为供方的客户之间也可以建立服务级别协议”3.2.21 的服务级别目标则是组织承诺的服务的具体可测量的特性。前者是协议后者是协议里的数字写文件时把这两者当同义词替换是很常见的低级错误。3.4 记不住时用定义关键词反推术语条目背不下来是常态比较省力的办法是记每个定义里的“动词对象”做题时反推。持续改进是“提高绩效的循环活动”所以它一定指向绩效不是指向“多开几次会”不符合是“未满足要求”所以判不符合必须先有明确要求风险是“不确定性的影响”影响可正可负所以风险不等于威胁外包是“安排外部组织承担组织的部分职能或过程”注 1 强调“外部组织不在管理体系覆盖范围内”——这句是判断范围题的钥匙。提示3.1.19 要求有一条注 3说在 SMS 背景下服务要求通常是达成一致并形成文件的要求另外还包括法律法规等隐含或必须履行的要求。复习范围题时这条经常被漏。4. 第 8 章运行拆解六类活动与十八条流程的复习重点4.1 第 8 章六块活动的划分逻辑第 8 章是整份标准最厚的一章从 31 页一直写到 46 页之前分成六块8.1 运营和计划和控制、8.2 服务组合、8.3 关系和协议、8.4 供需、8.5 服务设计构建和转换、8.6 解决和履行、8.7 服务保证。第三版把以前合并在一起的流程做了条款分离——前言 e) 点名了事件管理、服务请求管理、服务连续性管理、服务可用性管理、服务级别管理、服务目录管理、容量管理、需求管理。分离的直接后果是每个流程都能单独找到对应条款复习时可以按条清点不用在一个大条款里翻找。按功能给六块归个类记忆负担会小很多8.2 是“底账”有哪些服务、哪些资产、哪些配置8.3 是“关系”跟客户、跟供方怎么约8.4 是“钱和量”预算核算与需求8.5 是“改”变更、设计转换、发布部署8.6 是“修”事件、请求、问题8.7 是“保”可用性、容量、连续性、信息安全。4.2 服务组合与资产配置底账怎么建8.2 服务组合下面挂着服务交付、服务计划、服务生命周期涉及的相关方的管控、服务目录管理、资产管理、配置管理等内容。这一块的复习重点不是背名字而是搞清楚三本账的关系服务目录3.2.17组织向其客户提供服务的成文信息面向客户视角资产账3.2.1对组织有潜在或实际价值的元素允许包含负债和风险这类负价值项配置信息需要加以控制以提供服务的元素的信息第三版把原来的“配置管理数据库”要求换成了“配置信息”要求形式自由但内容不能少。三本账的颗粒度天然不同服务目录粗到“一项服务一行”配置信息细到“一个组件一行”资产账则要覆盖那些不进配置管理但确有价值的东西。梳理下来会发现很多组织的配置信息只覆盖了硬件和软件把文档、许可证、信息、支持性服务这些 3.2.18 明确列举的服务组件类型漏在外头。8.2 里还有一项容易被略过的内容对涉及服务生命周期各方的管控第二版叫“由其他各方运行的流程治理”前言 f) 说明了改名。1.2 把责任证据指向这里可见它是应对外部方参与的核心条款。重点在这改名之后管控对象从“流程”扩展到“服务、服务组件和流程”复习时如果还按“只管外包流程”理解会少答一半。4.3 关系与协议三层协议怎么分层8.3 关系和协议包含商务关系管理、服务等级管理、供应商管理。这三者对应三种不同方向的约定对客户是 SLA3.2.20对内部供方是成文协议3.2.8对外部供方是合同3.2.4。三层协议的服务级别目标3.2.21必须能串起来——客户侧承诺的可用性不能高于外部供方承诺给你的可用性否则中间那段落差就是自己扛。一个可以直接抄去用的表达方式是把“服务—组件—指标—证据”四层写成结构化文本。标准不规定格式只要求成文信息可控制、可追溯所以用什么载体都合规关键是内容齐。# 服务目录条目对应 3.2.17 服务目录、8.2 服务组合中的服务目录管理 service: id: SVC-001 name: 某内部协同平台 description: 面向内部用户的文档协作与流程审批服务 customer: 某业务部门 # 3.2.3 客户接受一项或多项服务的组织或组织的一部分 service_components: # 3.2.18 服务组件组合起来才构成完整服务 - 应用前端 - 应用服务端 - 数据库集群 - 运行所需许可证 catalogue_status: 在用 owner: 某服务经理 # 8.2 服务组合每项服务要有明确的责任归属这段的作用是把“服务”和“服务组件”拆开摆在纸面上。参数说明customer填的是 3.2.3 意义上的客户可以是组织内部的一个部门service_components只列组合成完整服务所必需的要素许可证、文档这类无形要素也要写进去owner不是装饰字段它对应 8.2 里服务责任的可追溯性。# 服务级别协议片段对应 3.2.20 SLA 与 3.2.21 服务级别目标 sla: service_id: SVC-001 parties: [组织, 某业务部门] targets: - name: 服务可用性 metric: 实际可用时间 / 约定服务时间 # 3.2.16 注 1 给出的比率口径 target: 99.5% window: 每月 evidence: 可用性月报 # 9 绩效评估监测、测量、分析和评估 - name: 事件响应 metric: 从记录到首次响应的时长 target: 30 分钟 window: 服务时段内 review_cycle: 每季度这段的重点在metric和evidence两行。指标口径必须写死3.2.16 的注 1 明确服务可用性可表示为实际可用时间与约定时间的比率或百分比口径不写清“99.5%”就是个玄学数字evidence则直接连到第 9 章没有证据的指标在审核场上等于不存在。4.4 供需预算核算与需求管理不是一回事8.4 供需包含服务的预算和核算、需求管理。这两项放在一起是因为它们共同回答“要花多少钱、要满足多少量”。需求管理在第三版被单独拆条前言 e) 有列它的对象不是“收集用户想要什么”而是服务需求与供给能力之间的匹配关系。复习时容易把它和服务级别管理混起来服务级别管理管的是“承诺什么水平”需求管理管的是“实际需要多少量”。预算和核算这条重点在于“服务的”三个字——它是按服务口径算账而不是按部门口径。梳理下来会发现很多组织财务上算得很细但算不到“某一项服务一年到底花了多少”这样 8.4 的要求就很难拿出证据。4.5 设计构建转换与解决履行改与修要分开8.5 服务设计构建和转换包含变更管理、服务设计和过渡、发布和部署管理。注意发布的定义3.2.13作为一项或多项变更的结果部署到实际运行环境的服务或服务组件以及新服务的一个或多个变更的组合。也就是说变更请求3.2.14是提议发布是落地组合两者不是同义词。前言 h) 提到原来的发布策略要求被替换为“定义发布类型和频率的要求”这意味着不必再写一份策略文件但必须说清楚有哪些发布类型、各自频率如何。8.6 解决和履行包含事件管理、服务请求管理、问题管理。这一块最典型的踩坑是把事件和问题当成一个流程的两个阶段。按 3.2.5 和 3.2.10 的定义事件是现象问题是原因一个事件可以没有对应问题快速恢复即可一个问题也可以对应零个已发生事件潜在事件。已知错误3.2.9是问题的一种状态根因已识别或者已找到减轻、消除影响的方法。重点在这事件管理的目标是恢复服务问题管理的目标是消除原因KPI 不能共用一套。4.6 服务保证四条线的分工8.7 服务保证包含服务可用性管理、容量管理、服务连续性管理、信息安全管理。四条线各管一件事子条款管什么复习时的判据服务可用性管理规定时间或规定时间内提供所要求功能的能力有没有可用性要求和目标有没有按 3.2.16 的口径算容量管理当前与未来的容量需求有没有容量计划不是容量计划文件服务连续性管理不间断提供服务或按约定提供持续可用性的能力3.2.19 注 1 明确它是业务连续性管理的子过程信息安全管理机密性、完整性、可用性定义与 ISO/IEC 27000 对齐别自成一套服务连续性这条的注 1 值得单独记服务连续性管理是业务连续性管理的一个子过程ISO 22301 是业务连续性管理体系的标准。这句话解释了两者的从属关系也解释了为什么连续性方案必须向上对齐业务影响分析而不是 IT 自己拍脑袋定 RTO。5. 转版易漏点五个最容易被判不符合的地方5.1 易漏点一全外包还想声称符合为什么漏不少组织以为“把服务台和基础设施都交给外部方”只是运营模式选择体系文件照旧写“本组织建立并运行服务管理体系”。但 1.2 的表述没有留余地如果由其他方承担提供或运行 SMS 范围内所有服务、服务组件或流程的所有责任组织不能声称符合本标准。怎么补先画一张责任矩阵把每个服务、每个服务组件、每条流程的“决策责任、执行责任、证据责任”三列填满。只要出现某一列整列都是外部方就必须调整范围或调整合同。另外条款 4 和 5 虽然可以由其他方支持但组织自身仍要证明符合这两章不能借力到底。5.2 易漏点二把“删掉文件要求”读成“这件事不用做了”为什么漏前言 h) 一口气删了五项文件要求读快了容易记成“容量管理不用做、可用性不用管、配置数据库不用建、发布策略不用写、改进策略不用定”。怎么补把“文件”和“内容”分开记。删除的是文件形式保留的是内容要求——容量计划要有服务可用性要求和目标要有文件配置信息要有发布类型和频率要定义改进机会的评估标准要确立。复习时用“要求还在载体自由”这八个字过一遍这五条基本不会错。5.3 易漏点三体系文件还在用第二版的名词为什么漏改名这类事在正文里不显眼但在前言 g) 里是成组出现的而且改的恰恰是高频词——服务提供方、内部小组、供方、可用性。怎么补做一次全文检索把这四个词在体系文件里的出现位置全部拉出来逐条判断该换成组织、内部供方、外部供方还是服务可用性。特别是“可用性”这个词在信息安全语境下必须保留在服务语境下必须加“服务”前缀一刀切替换会出新错。5.4 易漏点四事件、问题、已知错误三者的落点没分开为什么漏三个定义挨得很近日常口语里又常混着说“这个事件是个问题”导致文件里三个流程用同一套记录模板、同一套指标。怎么补按定义各设一条判据。事件看“是否造成或可能导致服务中断、质量下降”问题看“是否在找原因”已知错误看“根因是否已识别或是否有缓解方法”。三条判据对应三张不同的记录指标也分开设事件看恢复时长问题看根因关闭率已知错误看知识库命中率。5.5 易漏点五服务报告只在第 9 章找为什么漏一看到“服务报告”就直奔 9 绩效评估忽略了前言 j) 的那句说明——服务报告的详细要求已经从服务报告条款移到服务报告可能产生的条款中。怎么补反向查。把 8.2 到 8.7 每一条里“需要形成成文信息”“需要报告”的表述标出来这些就是服务报告的真实来源条款第 9 章那边主要管监测、测量、分析和评估、内部审核、管理评审这几件事的组织方式。两条线合起来服务报告的内容才完整。6. 复习清单用一张条款—证据对照表查漏补缺复习到最后一公里最有效的动作不是再读一遍标准而是给自己出一张“条款—证据”对照表逐行填。填不出来的那一行就是你的漏洞所在。下面这张表可以照着扩到全部条款条款一句话要求自检问题期望证据4.3确定 SMS 范围范围边界写清楚了吗含哪些服务、哪些供方范围说明文件5.2方针方针是否与组织宗旨一致并被沟通方针文件与传达记录6.1应对风险和机会风险清单是否覆盖服务与体系两侧风险登记与处置记录7.5成文信息该有的有没有该控的控没控文件清单与版本记录7.6知识关键岗位知识是否有获取途径知识库或交接记录8.2服务组合服务目录、资产账、配置信息三本账齐不齐目录、资产清单、配置信息8.3关系和协议客户、内部供方、外部供方三层协议是否串得上SLA 与供方合同8.6解决和履行事件与问题是否分开记录、分开统计事件记录、问题记录8.7服务保证四项保证是否各有目标与证据可用性报告、容量计划10.1不符合和纠正措施每条不符合是否闭环到原因不符合台账表填完再用脚本自动扫一遍覆盖率比人眼翻要稳。下面这段脚本读一份 CSV表头为clause,evidence,owner,status把子条款归到一级条款后检查 410 章有没有空档# 条款证据自检检查 4~10 章每个一级条款是否都有可用证据 import csv from collections import defaultdict REQUIRED [4, 5, 6, 7, 8, 9, 10] def load(path): with open(path, encodingutf-8) as f: return list(csv.DictReader(f)) # 逐行读成字典字段名取自表头 def check(rows): seen defaultdict(list) for r in rows: root r[clause].strip().split(.)[0] # 8.3.2 - 8按一级条款归并 if root in REQUIRED and r[status].strip() ! 缺失: seen[root].append(r[evidence]) for c in REQUIRED: # 空条款往往就是审核时被追问最多的地方 print(f条款 {c}: (f{len(seen[c])} 条证据 if seen[c] else 没有可用证据)) if __name__ __main__: check(load(clause_evidence.csv))参数上只有三个要点clause允许写到三级如 8.3.2脚本会自动归并status只用来标记“缺失/待补”不参与统计evidence写证据的名字而不是路径逼自己用一句话说清这份材料证明了什么。跑完输出里凡是“没有可用证据”的行直接回到对应章节重读那一条。我自己的血泪经验是第一遍复习时我按目录顺序从头读到尾自我感觉良好直到动手填这张表才发现 8.2 的服务组合和 8.3 的关系与协议在我脑子里是糊成一团的配置信息和资产账根本分不开。从那以后我每次复习这套标准都强制先跑一遍这张表和这段脚本再回去读条款——先找洞再补墙比顺着页码读十遍都管用。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
