简介：《ISO/IEC 20000-1:2018中文版》PDF面向IT服务管理人员、内审员、认证审核人员及准备转版或建立服务管理体系（SMS）的组织，帮助读者理解新版标准在服务设计、交付、关系与绩效管理等方面的要求，也适用于内审员培训、体系文件编制和认证审核前的条款梳理。文件共1个PDF，约551KB，由北京中大华远认证中心翻译，中文表述便于国内读者快速查阅，正文按范围、规范性引用文件、术语和定义、组织背景、领导力、规划、支持、运行、绩效评估与改进等章节展开，目录完整，便于按条款检索。已有4376人学习下载，可作为SMS实施、内部审核和认证审核的条款对照参考；其中服务组合、关系和协议、供需、服务设计构建与转换、解决和履行等内容，能帮助读者把标准要求落到流程与审核检查点，并对照2011版理解新版变化。

1. 知识地图：先看清 4 到 10 这条主干，再钻条款

刚碰信息技术服务管理体系的人，最常见的动作是从第 8 章那些流程名背起：事件管理、问题管理、变更管理、容量管理。背完一轮发现还是不会用，因为这份标准的重点不在流程清单上。2018 版把结构整体换成了管理体系通用的高阶结构，条款 4 到 10 是一条从“组织为什么做”到“做完怎么改”的主线：4 组织背景、5 领导力、6 规划、7 支持、8 运行、9 绩效评估、10 改进。第 8 章只是主干上最粗的一段。从 2011 版转版过来的人、准备认证审核的人、做 ITSM 落地的人，读法完全不同：前两种要能从 8 的每条流程倒推回 4 到 7 的证据，后一种要顺着 4 到 10 往下推。这份笔记按倒推的读法整理。

2. 体系骨架：条款 4 到 7 的四块地基怎么打

条款 4 到 7 是标准的“通用骨架”，跟 ISO 9001、ISO/IEC 27001 共用同一套高阶结构，所以很多人会下意识跳过去，觉得“这些是套话”。实际情况正好相反：认证审核里最容易被追问的恰恰是这四章，因为它们决定了第 8 章那些流程到底是不是为一个明确的组织、明确的范围服务的。骨架没打牢，后面的流程做得再漂亮，也只是一堆没有出处的表格。

2.1 组织背景与 SMS 范围：4.1 到 4.4 的四个动作

4.1 要求组织确定与其宗旨相关、并影响服务管理体系预期结果的内外部因素；4.2 要求确定相关方，以及这些相关方与服务管理体系相关的要求。这两条合在一起，本质上是让组织先把“谁在看我、我怕什么”写清楚。相关方在标准里的范围比直觉宽：客户、用户、外部供方、内部供方、监管机构、组织内 SMS 范围之外的部门都算。

4.3 确定范围，是整份文件里最该花时间的地方。范围声明要回答四件事：覆盖哪些服务、覆盖哪些组织单元与场所、覆盖哪些支撑流程、与范围之外的部分怎么接口。范围写宽了，审核时会被要求为每个角落拿出证据；范围写窄了，等于把能证明体系有效运转的部分切出去。1.2 把这条线划得很硬：条款 4 到条款 10 中的任何要求都不允许以“排除条款”的方式剔掉。

4.4 要求建立、实施、保持和持续改进 SMS，并确定体系所需的过程及其相互作用。落地时最实用的做法不是画一张漂亮的流程图，而是做一张“过程—所有者—输入—输出—接口”的表，这张表后面会反复用到：6.1 的风险从这里找，8.1 的控制对象是这里，9.1 的监视对象还是这里。

2.2 领导力：5.1 到 5.3 里真正会被查的三件事

5.1 领导和承诺，要求最高管理者对 SMS 的有效性负责；5.2 方针，要求方针与组织宗旨相适应、包含满足适用要求的承诺和持续改进的承诺、形成成文信息、在组织内沟通并可被相关方获取；5.3 角色、责任和权限，要求分配职责与权限并形成成文信息。

被查得最多的是三样东西。一是管理者参与的痕迹：管理评审的主持记录、方针的发布与内部宣贯记录、资源投入的依据。二是职责分配的颗粒度：写“IT 部门负责服务管理”基本等于没写，要写到“谁批准变更、谁接受风险、谁签服务级别协议、谁对外部供方绩效负责”这一层。三是方针与服务管理目标是否对得上，5.2 的承诺在 6.2 里必须有对应的可测量目标，否则就是两张皮。

提示：5.3 里“权限”二字常被忽略。有责无权是最常见的组织缺陷，尤其在变更授权和服务连续性决策上，一线团队被要求对结果负责，却不具备停机窗口的决策权。

2.3 规划：风险与机会、服务管理目标怎么写成可查的

6.1 应对风险和机会的行动，要求组织在规划 SMS 时考虑 4.1 提到的因素和 4.2 提到的要求，确定需要应对的风险和机会，并规划应对措施、如何整合进过程、如何评价有效性。这一条是 2018 版转版时的重点变化之一：风险不再是某个单独流程的事，而是贯穿整个体系。

6.2 服务管理目标的规划，要求目标与服务管理方针一致、可测量、考虑适用的要求、可监视、可沟通、适时更新，并保留成文信息。写目标时最容易翻车的是“可测量”这一项：把“提升客户满意度”写成目标不算违规，但要能回答“用什么量、多久量一次、达到多少算达成”。真正可查的写法是“服务可用性 ≥ 99.5%，按月统计，超标即触发纠正措施”。

2018 版在前言里明确说到新增了关于知识和规划服务的内容，所以 6.2 不只管体系层面的目标，还要管到具体服务的规划。这里给一个实用的对齐方式：方针一句话 → 目标三到五条 → 每条目标挂一到两个第 8 章的过程 → 每个过程挂一个 9.1 的度量。链条断了的地方，就是审核时会被问住的地方。

2.4 支持：7.1 到 7.6 里最容易被做薄的两块

7.1 资源、7.2 能力、7.3 意识、7.4 沟通都是常规动作：确定并提供所需资源、确定岗位所需能力并采取措施获得、让相关人员意识到方针与自身贡献、确定内外部沟通的内容与时机与对象。这些条款不难，难在证据的连续性。

真正的重点在 7.5 成文信息和 7.6 知识。7.5 要求体系的成文信息包括本标准要求的成文信息和组织为体系有效性所必需的成文信息，还要控制创建与更新、控制分发与访问、存储与防护、更改控制、保留与处置。2018 版的一个明确取向是最小化保留成文信息的要求，只保留关键的，比如服务管理计划。但“最小化”不等于“可以没有要求”，这点在第 5 章会单独拆开讲。

7.6 知识是 2018 版新增的条款，要求组织确定运行和交付服务所需的知识，保持并在需要的范围内可获取。它的实际含义是：某个资深工程师离职后，那些“只有他知道”的判断依据不能变成黑匣子。最低限度的做法是把知识条目和配置项、服务目录条目关联起来，让知识有归属、有更新触发条件。

3. 运行上半场：服务组合、关系和协议、供需三条线的落地要点

第 8 章是全文最长的一章，也是把 4 到 7 兑现成日常动作的地方。它前半段（8.1 到 8.4）管的是“有什么服务、跟谁签了什么、钱和需求怎么走”，后半段（8.5 到 8.7）管的是“改、修、保”。先看前半段，因为后半段所有流程的输入都来自这里。

3.1 运行的规划和控制：8.1 不是一句废话

8.1 要求组织规划、实施和控制满足要求所需的过程，实施 6.1 确定的措施，保持成文信息以确信过程按策划进行；对策划的变更进行控制并评审非预期变更的后果，必要时采取措施降低不利影响；确保外包的过程受控。

这条之所以常被当成废话，是因为它读起来没有任何具体流程名。但它是唯一一条把“计划”和“实际”绑在一起的要求：变更控制的真正源头在这里，不在 8.5。很多组织 8.5 的变更流程做得很规范，8.1 的“非预期变更后果评审”却是空的，一被问到“上个月那次临时扩容有没有评估对其他服务的影响”就答不上来。

3.2 服务组合：服务交付、服务计划、服务目录、资产与配置

8.2 是一组关系极密的子条款。服务交付要求按服务级别协议交付服务；服务计划要求为服务建立计划，写清服务内容、服务级别目标、依赖的服务组件与相关方；对涉及服务生命周期各方的控制，要求对其他方提供的服务、服务组件或过程进行管控，明确角色、职责、权限和接口；服务目录管理要求建立并保持服务目录，且服务目录是需要控制的成文信息；资产管理要求识别资产并记录其价值、风险与生命周期；配置管理要求识别配置项、记录配置信息、维护配置项之间的关系与基线。

这里最容易忽略的是“服务目录”和“配置信息”不是一回事。服务目录是给客户看的（他能申请什么），配置信息是给运维看的（它由什么组成、谁依赖谁）。两个东西混成一个表，最后两边都不好用。

# 配置信息记录（8.2.6）：重点不是用什么数据库存，而是这条记录能不能回答影响分析 ci_id: CI-APP-0142 name: 订单服务（生产环境） type: 应用系统 service: 订单受理服务 # 指回 8.2.4 服务目录条目 owner_role: 应用负责人 # 写责任角色，不写具体人员 relationships: - type: depends_on target: CI-DB-0031 # 数据库实例 - type: depends_on target: CI-NET-0007 # 负载均衡 - type: provides_to target: CI-APP-0143 # 下游结算服务 baseline: version: v3.4.1 applied_at: "2025-03-11" change_ref: CHG-2025-0219 # 变更编号，形成可追溯链 asset_ref: AST-0098 # 对应资产记录，可以为空

这段记录的每个字段都对应一条要求：service把配置项挂回服务目录，relationships支撑影响分析与事件处理，baseline加上change_ref让变更与配置形成闭环。特别注意asset_ref允许为空，因为 3.2.1 的注释说得很清楚：资产可以是配置项，但某些配置项可能不是资产，两者不是一一映射，硬凑成一张表迟早出错。

3.3 关系和协议：商务关系、服务等级、供应商三条链

商务关系管理（8.3.1）处理的是与客户的日常关系，包括沟通机制、投诉处理、满意度收集、服务评审这类动作，它的产出是服务的改进输入。服务等级管理（8.3.2）处理的是服务级别协议与其中的服务级别目标：签署、监视、报告、评审、更新。供应商管理（8.3.3）处理的是外部供方：合同、绩效监视、变更与终止，以及对分包供方的可见性。

这三条链的关系可以用一句话概括：商务关系管“客户还愿不愿意合作”，服务等级管“答应的指标有没有做到”，供应商管“上游掉链子时有没有兜底”。三者的接口是同一份服务级别目标，所以指标口径必须一致——服务级别协议里写“可用性 99.5%，按月”，供应商合同里就不能写“可用性 99.9%，按季度”，否则中间那段差值没人负责。

3.4 供应和需求：预算核算与需求管理的配合

服务的预算和核算（8.4.1）要求对服务进行预算、核算与成本分析，让服务的成本可被看见；需求管理（8.4.2）要求识别、预测并管理对服务的需求，并与服务组合、容量等过程联动。这两条在实务中经常被做成分开的两个表格，其实它们是一件事的两面：需求预测决定预算盘子，成本核算反过来约束需求承诺。

一个可复现的做法是把需求做成带时间轴的量：按服务、按业务线、按季度列出当前用量与预测量，再挂上单服务的成本项。这样在客户提出“下季度业务量翻一倍”时，能立刻给出两句话的回答——容量需要增加多少、预算需要追加多少。缺了这层联动，需求管理就退化成收集愿望清单。

4. 运行下半场：设计转换、解决履行与服务保证的复习重点

如果条款 4 到 7 是地基、8.1 到 8.4 是账本，那么 8.5 到 8.7 就是真正每天在跑的机器。这一段的难点不在流程多少，而在边界：变更和发布怎么分、事件和服务请求怎么分、问题和已知错误怎么分。分不清，后面的指标全是糊的。

4.1 服务设计、构建和转换：变更、设计转换、发布部署

变更管理（8.5.1）要求对变更进行分类、记录变更请求、评估影响与风险、授权、实施、评审结果，并对紧急变更设定专门的处理路径。服务设计和转换（8.5.2）要求对新建、变更或退役的服务进行设计与转换，包括确定服务要求、设计服务组件与度量、制定验收准则、规划转换活动。发布和部署管理（8.5.3）要求定义发布的类型与频率，并规划、验证、部署发布。

这里有个 2018 版的实质变化值得记住：旧版要求有“发布策略”文件，新版改为要求定义发布的类型和频率。文件可以不叫策略、可以只有一页，但“我们有哪些发布类型、多久发一次、谁能批准例外”这些问题必须有答案。这是典型的“要求还在、载体放宽”。

变更和发布的分界线也可以一句话说清：变更管的是“这个改动该不该做、谁批准”，发布管的是“这批改动怎么装进去、装完怎么验”。混在一起的表现是变更单里写着“已于当晚发布完成”，但没有任何验收结论，出了事故无从回溯。

4.2 解决和履行：事件、服务请求、问题的分界线

事件管理（8.6.1）要求记录、分级、处理、升级、解决和关闭事件，并按需要与问题管理联动。服务请求管理（8.6.2）处理的是预定义的、常规的客户请求，比如权限申请、标准配置发放。问题管理（8.6.3）从实际或潜在事件中识别问题，查明原因，记录已知错误与临时措施，并在需要时提交变更请求。

三个词的定义差别是理解的关键：3.2.5 把事件定义为服务的意外中断，以及导致服务质量下降但尚未对客户或用户的服务产生影响的事项；3.2.9 把已知错误定义为已识别根本原因、或已找到减少或消除其对服务影响的方法的问题；3.2.10 把问题定义为一个或多个实际或潜在事件的原因。也就是说，事件是“症状”，问题是“原因”，已知错误是“被看穿的原因”。

4.3 服务保证：可用性、连续性、容量、信息安全

服务可用性管理（8.7.1）要求确定服务的可用性要求与目标，监视并报告达成情况。服务连续性管理（8.7.2）要求确定连续性要求，制定并测试连续性方案，注意它与业务连续性管理是上下位关系而非同一件事。容量管理（8.7.3）要求确定容量要求、制定容量计划、监视容量与性能、预测未来需求。信息安全管理（8.7.4）要求确定信息安全要求与目标，实施控制措施并管理信息安全事件。

这四个子条款共享一个结构：先定目标和指标，再监视，再触发改进。因此把可用性算准，是把这一组流程做扎实的起点。下面的脚本按照约定的服务时间计算可用性，并反推停机预算——后者比前者有用得多，因为它能直接回答“这个月还能停多久”。

def service_availability(agreed_minutes: int, downtime_minutes: int) -> float: """按 3.2.16 的口径计算服务可用性：实际可用时间 / 约定时间""" if agreed_minutes <= 0: raise ValueError("约定时间必须大于 0") available = agreed_minutes - downtime_minutes return round(available / agreed_minutes * 100, 3) # 假设一个月约定服务时间为 30 天 × 10 小时 agreed = 30 * 10 * 60 # 单位：分钟，共 18000 for down in (60, 180, 420): used = down / agreed * 100 print(f"不可用 {down} 分钟 -> 可用性 {service_availability(agreed, down)}%，已消耗停机预算 {used:.2f}%")

agreed_minutes必须用约定的服务时间，不能用 24×7 的自然时间，否则算出来的数会虚高；downtime_minutes要包含计划外不可用与超过约定窗口的计划停机。把两个参数换成你所在服务的口径，就能得到每月允许的停机分钟数——99.5% 在 18000 分钟里只允许 90 分钟不可用，这个数字一摆出来，很多关于“小停机不算停机”的争论就自然结束了。

4.4 绩效评估与改进：9 和 10 的闭环怎么闭合

第 9 章要求组织确定监视、测量、分析和评估的对象、方法、时机，保留成文信息，并对结果进行评估；要求按计划的间隔开展内部审核，开展管理评审，以及向相关方提供或沟通服务报告。第 10 章要求处理不符合与纠正措施，并持续改进。

2018 版在这一段有两个容易漏掉的变化。其一，标准删除了对 Plan-Do-Check-Act 的引用和相关图示，因为高阶结构没有专门使用它，很多改进方法都能与管理体系一起用——这意味着自评表里那些“因为 PDCA 循环所以……”的表述，不再是条款依据。其二，取消了对持续改进策略的要求，改为要求确立识别改进机会的评估标准。也就是说，不必先把改进战略写得很正式，但必须说清“什么情况会被判定为改进机会”。

闭环是否真的闭上，看一个细节就够了：管理评审的输入里有没有 9 和 8 的具体数据，输出里有没有落成变更请求或改进项的条目。如果评审结论永远是“总体运行良好”，那基本可以判定这个环是断的。

5. 易错点：五个最容易翻车的条款理解与证据缺口

这一段是复习时最该反复过的部分。前面几章是按条款顺序走的，容易理解，也容易记住；但真正扣分的往往不是“不知道有这条要求”，而是“把这条要求理解反了”，或者在旧版模板里抄顺手了，根本没意识到新版已经换了说法。下面五处，按整理过的角度逐条拆开。

5.1 条款理解上的三处易漏

其一：把 8.2.3 对相关方的控制读成“外包出去就不用管了”。

易漏点：认为签了外包合同，责任就随合同转移了。为什么漏：这在日常管理里是顺理成章的直觉，而且不少旧模板是围绕“治理”写的，读起来像是把外包商的流程管好就行。怎么补：把 1.2 的两句话背下来——组织应提供承担本标准规定要求责任的证据，即便相关方参与满足 6 到 10 的要求；如果其他方承担提供或运行 SMS 范围内所有服务、服务组件或流程的所有责任，组织不能声称符合本标准。落地动作是列一张接口清单：每一个外包环节写清输入、输出、责任人、验收方式，这张清单就是 8.2.3 的证据。

其二：把成文信息的“最小化”读成“这也不用写那也不用写”。

易漏点：看到前言里那一串删除项，就以为相关要求消失了。为什么漏：这段是标准的修订说明，读起来像减负清单，很容易被当成“以后不用文件了”。怎么补：分清“要求”和“载体”。容量管理计划的文件要求删掉了，改为容量计划的要求；可用性计划文件的要求删掉了，改为服务可用性要求和目标的文件；配置管理数据库要求删掉了，改为配置信息要求；发布策略要求删掉了，改为定义发布类型和频率的要求；持续改进策略要求取消了，改为确立改进机会的评估标准。要求一条没少，只是不强制用某个文件形态来承载，而服务管理计划这类关键成文信息仍然必须保留。

其三：把事件、服务请求、问题、变更请求当成同一个“工单”。

易漏点：系统里只有一个工单类型，全凭填写人心情选。为什么漏：一线口语里都叫“报修”或“提单”，流程文档也常常只画一条线。怎么补：在记录里加一个必填的“类型判定”字段，并给出判定规则：是否有意外中断或质量下降（事件）、是否是目录内的常规请求（服务请求）、是否在追问原因（问题）、是否要改动服务或组件（变更请求）。类型不是标签，是流向：事件流向问题，问题流向变更，变更回到发布，四者构成一条链，链路一断，统计口径立刻失真。

5.2 术语与证据上的两处易漏

其四：服务报告的要求只在第 9 章找。

易漏点：把服务报告当成 9 里的一个条款，做一张模板就算完成。为什么漏：2011 版把服务报告的详细要求集中写在服务报告条款里，转版惯性会让人继续在那一条附近找。怎么补：2018 版把服务报告的详细要求从服务报告条款移到了可能产生服务报告的各个条款，所以报告里的每个数据项都应该能追到某个流程条款：可用性追到 8.7.1，事件量追到 8.6.1，变更成功率追到 8.5.1，供应商绩效追到 8.3.3。做模板时按这个映射建列，比在 9 里憋一份格式要靠谱得多。

其五：术语换了还在照抄旧模板。

易漏点：文件里到处是旧称谓。为什么漏：模板是老的，替换成本高，而且新旧词在中文语感上差别不大。怎么补：做一张替换对照表，逐条改。标准里明确的变化包括：“服务提供方”被“组织”取代以符合高阶结构的通用描述；“内部小组”被“内部供方”取代；“供方”被“外部供方”取代；“信息安全”的定义与 ISO/IEC 27000 保持一致，因此“可用性”被“服务可用性”取代，以区别于信息安全里使用的“可用性”。另外两组容易混的术语也要回到定义：客户是接受服务的组织或组织的一部分，用户是使用服务的个人或角色，一个人可以既是客户又是用户；资产与配置项不是同义词，资产有独立的价值与生命周期视角。

6. 复习清单：把 4 到 10 压成一张能自检的表

真正复习的时候，不建议再从第一条往下读。用一张空表自检效率高得多：左边写条款，右边只填“证据的名字”，填不出来的格子就是漏点。

这张表还有个用法：把它当成转版自查的对照物。哪一格填不上，就去补哪一格对应的条款，不要一上来就重写全部文件——大部分组织的漏点集中在 8.2.3、8.6.3、9 这三处，把这三处补齐，体系的完整性会明显不一样。

最后说个血泪经验。我最早做这类梳理时，喜欢从第 8 章往里钻，觉得流程做完体系就成了，结果每次被问到“这个流程服务的是哪个范围里的哪条目标”就卡住，只能回头补 4 到 7。从那以后，我每接一份新范围，都强制按 4 到 10 的顺序走一遍这张空表，先把每格填上证据的名字，再谈流程优化和工具选型。这套顺序看起来笨，但它能省掉后面反复返工的时间。希望帮到你。

本文还有配套的精品资源，点击获取