一、ISO/IEC 20000-1:2018 8.7 标准原文
条款要求：组织应建立并保持保证类过程，以支持 agreed service requirements 的实现，并降低服务中断、不可用和信息受损的风险。保证类过程通常包括服务可用性管理、服务连续性管理和信息安全管理。
二、标准条款解读说明
2.1 保证类过程结构表
| 子条款 | 关注点 | 目标 |
|---|---|---|
| 8.7.1 服务可用性管理 | 服务在约定时间内可被正常使用 | 减少不可用时间和性能下降 |
| 8.7.2 服务连续性管理 | 重大中断情况下的恢复和持续提供能力 | 降低灾难性中断影响 |
| 8.7.3 信息安全管理 | 保护服务相关信息和处理活动 | 保障机密性、完整性和可用性 |
2.2 核心理解
很多组织将保证类过程理解为“高阶附加项”，实际上它们直接决定客户是否信任服务。服务表面上可以交付，但如果经常不可用、遭遇中断无法恢复、或者因安全问题频繁受影响，那么服务管理体系就没有真正兑现价值。8.7就是用三道防线支撑服务承诺：平时保持可用、极端情况保持可恢复、全过程保持安全。
保证类过程与前面的运行过程并不是并列关系，而是深度耦合关系。变更做得不好，会破坏可用性；容量做得不好，会影响连续性；供应商管理做得不好，会带来安全和恢复风险。因此，8.7不仅是专项保障条款，也是对前面全过程管理成熟度的综合体现。
三、实施要点
3.1 明确服务保证目标
- 按服务重要性定义可用性目标、恢复目标和安全要求。
- 对关键服务设置更高的保障级别和更严格的验证机制。
3.2 把保障要求嵌入运行
- 在设计、变更、发布、容量、供应商和事件处理中体现可用性、连续性和安全要求。
- 不能把保证过程做成与日常运行脱节的独立文档。
3.3 做持续监视和验证
- 通过可用率、演练结果、安全事件、恢复时间等数据评估保证效果。
- 对持续偏差及时补充资源和控制措施。
3.4 做好跨过程联动
- 重大事件复盘应回看可用性和连续性准备是否充分。
- 安全事件和高风险变更应联动更新保障措施。
四、常用工具与实施方法
| 工具/方法 | 用途 | 输出 |
|---|---|---|
| 保障目标矩阵 | 定义不同服务的保障要求 | 保障目标表 |
| 风险评估 | 识别影响可用性、连续性和安全的风险 | 风险清单 |
| 演练和测试 | 验证连续性和恢复能力 | 演练报告 |
| 监控与报告 | 跟踪保障指标 | 可用性和安全报告 |
| 跨过程评审 | 检查保障要求是否落地 | 评审纪要 |
五、典型案例
案例一：只管交付不管保障导致客户流失
某服务商事件处理速度并不慢，但连续几次高峰期间服务不可用，客户最终选择更稳定的供应商。组织重建8.7体系后，从可用性、连续性和安全三个维度定义关键服务保障方案，服务稳定性和客户信任均有所提升。
案例二：保证过程反向拉动前端过程改善
某集团在连续性演练中发现，真正短板不在灾备系统，而在联系人清单过期、回退步骤模糊和供应商响应链条断裂。8.7的演练结果促使组织同步优化沟通、变更、知识和供应商管理，说明保证过程能反向推动体系成熟。
案例三：保障要求成为服务设计的刚性输入
某金融服务团队过去习惯先上线新服务，再逐步补可用性和安全控制，结果每次新业务扩张都会带来一轮不稳定。依据8.7重建保障机制后，组织要求关键服务在设计阶段就明确可用性目标、恢复目标和安全控制要求，并把这些要求写进转换、变更和供应商管理中。这样一来，保障能力不再是事后补课，而成为服务上线前的刚性条件。
很多组织会把可用性、连续性和安全看成三个专业条线，各自有自己的方案和指标。但从服务管理角度看，它们其实共同回答一个问题：客户为什么能够长期信任这项服务。若服务日常可用率不错，但一遇灾难就无法恢复，或者安全控制薄弱导致频繁中断，客户感知到的仍然是不可靠。
这也是为什么8.7不能被理解成“锦上添花”的高级能力。对关键服务来说，保证类过程实际上决定了组织能否稳定兑现前面所有协议和目标。SLA、容量、变更、事件、供应商管理等条款再完整，如果缺少可用性、连续性和安全的底层支撑，服务体系仍可能在关键时刻整体失效。
从管理节奏看，8.7 特别适合用来反向检验前端过程是否扎实。可用性偏差能暴露变更和容量问题，连续性演练能暴露知识、接口和供应商问题，安全事件能暴露权限、审计和流程设计问题。因此，8.7 不只是专项保障条款，也是一面照出体系短板的镜子。
审核8.7时，最重要的不是看组织有没有厚厚的保障文档，而是看目标是否已分配到具体服务、控制是否嵌入到运行过程、演练和监测是否真的产生改进行动。只要保障活动能持续反向推动服务设计、运行和治理优化，说明条款已具有真实生命力。
成熟组织在8.7上的表现往往很清晰：它们不会把保障措施留在文档层，而是通过监控、演练、窗口控制、权限审计、供应商协同和风险评审把保障要求变成日常管理事实。正因为这些事实长期存在，服务才能在压力和异常面前保持更强韧性。
因此，保证类过程不是附加层，而是服务管理体系的可信层。它把“能交付”进一步提升为“能持续可信地交付”，这正是ISO 20000在服务成熟度上的核心追求之一。
从长期经营看，8.7 做得好的组织通常更少依赖运气。它们不会寄希望于“最好别出事”，而是通过保障目标、验证机制和跨过程控制让服务在高峰、异常和风险面前依旧有基本盘。
因此，保证条款成熟的标志，不是偶尔一次表现出色，而是组织能够持续证明自己的服务在平时、坏时和受攻击时都更可控、更可恢复、更可信。
换句话说，8.7 真正保护的，是服务承诺背后的可信度。只要这层可信度长期存在，客户和业务方才更愿意把关键活动建立在这项服务之上。
这也是保证类过程虽然不总在前台出现，却往往决定服务组织能否长期被信任的根本原因。
只要这层底座稳住，前面各项服务承诺才真正站得住。
服务保障越扎实，组织越不怕不确定性。
这会直接增强服务韧性。
也更能稳住客户信任。
这点非常关键。
意义很直接。
六、成文信息管理要求
- 保留服务保障目标、保障方案、演练和测试记录、监测报告和评审记录。
- 保留与可用性、连续性和安全相关的风险评估和改进行动记录。
- 保证过程应与服务级别、容量、变更和事件记录形成关联证据链。
七、常见误区及踩坑提醒
| 误区 | 表现 | 正确做法 |
|---|---|---|
| 保证过程只写方案不验证 | 文件完备，但真正中断时不管用 | 通过监测、演练和复盘持续验证 |
| 保障要求脱离服务分级 | 所有服务一个标准，资源浪费或保障不足 | 按服务重要性分级设计保障措施 |
| 只看技术不看组织接口 | 系统可恢复，但人员和流程跟不上 | 同时管理技术、人员、流程和供应商 |
| 保障条款与前端过程脱节 | 前端变更和发布破坏了保障能力 | 将保障要求嵌入全生命周期过程 |