ISO20000里“可用性计划”不是填完就完事的活儿

你是不是也遇到过：ISO20000认证材料交上去了，审核老师翻到《可用性计划》那一页，轻轻一指：“这个版本是去年Q3的，系统架构都换两轮了，计划还按老样子写？”——当场沉默。

其实啊，ISO/IEC 20000-1:2018标准里压根没写“必须每X个月更新一次”，但它在第8.2.3条（可用性管理）里埋了个关键逻辑：可用性计划必须与当前服务、技术、风险和业务需求保持动态一致。换句话说——它不是一张静态表格，而是一份“活着的运营契约”。

更新不是打卡，而是对齐变化的节奏

新上线了微服务架构？核心数据库从Oracle迁到了云原生PolarDB？客户SLA从99.5%升级到99.95%？这些都不是小改动，而是直接改写了“系统什么时候能扛住、哪里最可能崩、备用方案还灵不灵”的底层假设。这时候还拿旧计划应付，等于拿地图导航却不知道路已改道。我们服务过的某金融客户，就因沿用18个月前的可用性计划，在二阶段审核时被指出“未覆盖容器化故障切换场景”，补材料多花了3周。

实战中，九蚂蚁建议的更新节奏很实在

我们不鼓吹“每月一更”（太折腾），也不接受“三年一版”（太冒险）。结合上百个认证项目经验，多数企业踩得最稳的节奏是：
✅ 重大变更触发即时更新（如架构升级、关键供应商更换、业务峰值期调整）；
✅ 常规复盘每半年一次（结合管理评审或内审节点，同步校准RTO/RPO、测试记录、监控覆盖度）；
✅ 年度认证监督审核前专项刷新（确保与最新服务目录、配置项、应急预案严丝合缝）。

说白了，更新频率不看日历，而看你的业务心跳快不快。

别让“计划”变成“纸面摆设”

很多团队把可用性计划写成技术参数堆砌：CPU阈值、网络带宽、备份周期……但ISO20000真正想看到的是：谁在什么条件下启动哪一步动作？失败了找谁兜底？证据在哪？ 我们帮客户重构计划时，第一件事就是把“责任人+触发条件+验证方式”三列加粗标红——审核老师扫一眼就知道：这计划真有人盯、真能跑、真留痕。

需要一份贴合你当前架构、带检查清单和模板的可用性计划更新指南？九蚂蚁的认证顾问随时在线，帮你把“合规动作”变成“运维抓手”。