引言
ISO/IEC 20000-1:2018 第8章”运行”是整个标准的核心，占据了最多的条款数和最复杂的审核工作量。与ISO 9001第8章（运行控制）不同，20000-1第8章以”服务”为主线，细分为7个过程域：运行策划与控制、服务组合、关系与协议、供给与需求、解决、服务保障、服务交付。第三方审核员只有深入理解每个过程域的审核要点，才能有效评估ITSMS的运行有效性。
一、第8章整体框架
20000-1:2018 第8章的结构如下，审核员在现场应按”过程方法”逐一追溯证据：
| 条款 | 过程域 | 审核核心 |
|---|---|---|
| 8.1 | 运行策划与控制 | 是否按计划运行？变更是否受控？ |
| 8.2 | 服务组合 | 服务目录是否完整、是否定期评审？ |
| 8.3 | 关系与协议 | 客户协议、供应商协议是否覆盖所有风险？ |
| 8.4 | 供给与需求 | 供需双方的服务请求和供方管理是否规范？ |
| 8.5 | 解决 | 事件管理、服务请求管理是否有效？ |
| 8.6 | 服务保障 | 可用性、容量、连续性、信息安全是否有保障？ |
| 8.7 | 服务交付 | SLA管理、服务报告、服务连续性是否达成？ |
审核时应避免”逐条打勾”，而是选择1-2个真实服务，沿”协议→交付→保障→改进”全流程追溯，这样更容易发现系统性问题。
二、8.1 运行策划与控制
本条款要求组织策划并实施服务交付所需的运行过程，包括变更管理、配置管理、发布管理。
审核核心问题：
1. 变更管理：抽查3个变更记录（含1个紧急变更），验证是否有风险评估、回退计划、变更后评审？
2. 配置管理：配置管理数据库（CMDB）是否覆盖关键服务组件？配置项变更是否与变更记录关联？
3. 发布管理：发布计划是否包含回滚方案？发布后是否验证服务正常？
| 常见不符合 | 审核方法 |
|---|---|
| 紧急变更事后补审批 | 抽查紧急变更记录，看是否在24小时内补充了评审记录 |
| CMDB数据过时 | 随机抽查3个配置项，与实际情况核对 |
| 发布无回滚方案 | 查看最近3次发布的发布计划文档 |
⚠️ 审核技巧
变更管理最容易出问题的不是”流程有没有”，而是”紧急变更是否真紧急”。审核员应追问：这次紧急变更的事由是什么？如果类似情况每月都发生，说明变更分类有问题。
三、8.2 服务组合
服务组合是20000-1的特色概念，包括组织提供的所有服务（在用、在开发、已退役）。审核员应检查：
- 是否有完整的服务目录（Service Catalogue）？
- 服务目录是否对客户可见（至少是与客户相关的部分）？
- 服务退役是否有正式流程？
典型问题： 组织有20个IT服务，但服务目录只列了12个——漏掉的服务往往是” shadow IT”（影子IT），属于SMS覆盖范围不完整的严重问题。
四、8.3 关系与协议
本条款覆盖客户关系管理、供应商关系管理，以及对应的协议管理（SLA、OLA、UC）。
审核时务必检查的三类协议：
| 协议类型 | 签署方 | 审核要点 |
|---|---|---|
| SLA（服务级别协议） | 服务提供方 ↔ 客户 | 指标是否可测量？报告频率？违约责任？ |
| OLA（运营级别协议） | 内部部门之间 | 是否支撑SLA？指标是否与SLA对齐？ |
| UC（支撑合同） | 服务提供方 ↔ 供应商 | 供应商SLA是否不低于对客户承诺？ |
审核提问示例：
– “请展示一份SLA，其中的可用性指标99.9%是如何测量和报告的？”
– “如果供应商没有达到UC中的SLA，你们的追责流程是什么？”
五、8.4 供给与需求
本条款覆盖服务请求管理和供方管理（供应商管理）。
服务请求管理审核要点：
– 服务请求是否有统一入口（如服务台）？
– 标准服务请求（如账号开通）是否有预定义的审批流程和SLA？
– 服务请求完成情况是否记录并可用于服务改进？
供方管理审核要点：
– 关键供应商（影响服务交付的）是否都签署了UC？
– 供应商绩效是否定期评价（至少每年一次）？
– 供应商退出是否有过渡计划（Transition Plan）？
六、8.5 解决过程（核心）
8.5包含事件管理和服务请求管理两个子过程，是20000-1审核中证据最丰富的领域。
事件管理审核思路：
| 审核步骤 | 具体操作 |
|---|---|
| 1. 查事件分类 | 事件是否按影响度和紧急度分类（P1-P4）？ |
| 2. 查响应时效 | 抽查3个P1/P2事件，验证是否在约定时间内响应？ |
| 3. 查升级机制 | 事件超时是否自动升级？升级路径是否清晰？ |
| 4. 查根本原因分析 | 重大事件是否进行了RCA？纠正措施是否落实？ |
| 5. 查知识库 | 重复事件是否有知识库文章支撑快速解决？ |
常见不符合： 事件管理系统中有大量”未分类”事件；P1事件响应时间远超SLA约定但无升级记录；重大事件没有根本原因分析记录。
💡 审核员提醒
服务请求（Service Request）和事件（Incident）在20000-1中是两个不同的过程！服务请求是”用户的正常需求”（如改密码、开权限），事件是”计划外的服务中断或质量下降”。审核员应分别抽查两类记录。
七、8.6 服务保障
本条款覆盖服务的可用性、容量、连续性、信息安全保障——这是ITSMS与ISO 27001有交叉的部分。
| 保障领域 | 20000-1要求 | 与ISO 27001的关系 |
|---|---|---|
| 可用性管理 | 确保服务可用性满足SLA | 与27001 A.8.14（信息处理设施的可用性）对应 |
| 容量管理 | 确保服务容量满足当前和未来需求 | 27001无直接对应，但涉及资源管理 |
| 服务连续性 | 确保在中断后恢复服务（通常与BCP联动） | 与27001 A.5.30（业务连续性）对应 |
| 信息安全 | 确保服务交付中的信息安全风险受控 | 与27001附录A高度重叠，可整合审核 |
审核技巧： 如果组织同时通过了ISO 27001认证，8.6的审核可以与27001整合进行，避免重复审核。
八、8.7 服务交付
这是第8章的收尾条款，要求组织按约定的服务级别交付服务，并向客户提供服务报告。
审核检查点：
– 服务级别是否定期测量（至少每月）？
– 服务报告是否按时发给客户？客户是否确认收到？
– 服务级别未达标时，是否有改进行动计划？
典型不符合： 组织每月生成了服务报告，但从未发送给客户——服务报告只存在内部系统里，客户完全不知情。这属于8.7的严重不符合。
从审核员的持续成长角度来看，每完成一次审核都应当进行自我复盘：这次审核中哪些环节做得好？哪些问题问得不够深入？哪条证据收集得不充分？将复盘结果记录下来，形成自己的审核案例库。久而久之，你会形成一套独特的审核方法论和判断直觉。审核是一项实践性极强的工作，理论知识只是基础，真正的成长来自每一次现场审核的积累。无论是质量管理还是信息安全领域的审核员，坚持学习和实践永远是提升专业能力的不二法门。希望本文的分享能够对正在学习和从事审核工作的同行有所帮助。在实际工作中遇到疑难问题时，不妨回到标准原文，对照本文梳理的要点逐一排查。