ISO20000里“可用性管理”到底管什么？别再只盯着流程图了！

可用性不是“系统不宕机”这么简单

很多人一看到ISO/IEC 20000里的“可用性管理（Availability Management）”，第一反应是：“哦，就是保证服务器别挂、APP能打开。”其实真没这么浅。它管的不是某一次故障修没修好，而是——业务关键时段，服务必须按约定水平“稳稳在线”的能力。比如电商大促那3小时，订单系统可用率要达99.99%，这个数字背后，是容量预估、冗余设计、变更控制、甚至备份恢复演练的整套闭环。九蚂蚁在帮客户做认证准备时，常发现：技术团队很熟监控告警，但对“SLA怎么拆解成可用性指标”“历史故障数据如何反哺改进计划”，反而卡壳。

它要你“提前算账”，而不是“事后补漏”

可用性管理最反直觉的一点：它不鼓励“救火式优化”。标准明确要求组织建立可用性计划（Availability Plan）——不是写完放抽屉，而是每年和业务方一起对齐：明年哪些服务要支撑新业务上线？峰值负载预计涨多少？现有架构能否扛住？有没有单点风险？我们陪某家区域银行做差距分析时，就发现他们核心账务系统的RTO（恢复时间目标）写着“2小时”，但灾备切换实测要3小时17分。问题不在技术，而在没人把“计划值”和“实测值”定期拉通复盘。ISO20000要的，正是这种“用数据说话”的较真劲儿。

别让文档成了“影子流程”

很多企业提交的可用性管理文档，漂亮得像教科书：定义清晰、角色明确、流程完整……可一问运维同事，“你们日常改配置前，真会查这份可用性影响评估表吗？”答案常常是沉默。九蚂蚁特别看重“活的流程”——比如把可用性检查点嵌入CI/CD流水线，或在变更审批系统里强制关联可用性风险等级。文档不是终点，而是让每个动作都留下可用性思考痕迹的起点。

说白了，可用性管理不是加一道审批，而是给IT服务装上“业务罗盘”：知道为什么而稳，为谁而稳，稳到什么程度才算真正达标。