几乎所有网络服务合同里都有一个数字：可用性 99.9%。它能用来验收、能用来问责，却几乎无法用来运维——它不告诉你哪个站点在劣化、哪一段链路在丢包、离"不达标"还剩多少余量，更不会告诉你现在该不该冻结变更。这份指南讲的就是如何把这个孤零零的数字，展开成一套能真正驱动日常运维的指标体系。

一、SD-WAN 运维难在哪

SD-WAN 把多条链路、多个站点、多云入口编织成一张逻辑网，运维复杂度也随之上升。困难集中在三处：

• 控制台割裂。分支、云、边缘、安全设备常分属不同管理体系，每一次排障都是跨系统的人工拼接——在多个平台之间导出数据、对时间戳、猜关联。

• 链路质量动态变化。Overlay 隧道跑在互联网、专线、4G/5G 之上，底层质量本身在波动。"通不通"已不足以描述状态，真正要看的是"体验好不好"。

• 指标失焦。合同只有一个笼统的可用性数字，体验劣化时无法下钻到具体维度，也无法归因到哪一段链路。数字达标、用户照样投诉，是这类场景的常态。

这三件事叠加的结果是：故障处理高度依赖资深工程师的经验与手工排查，时间难以收敛，且经验很难沉淀成组织能力。

二、把一个数字展开成指标体系

业界成熟的做法来自站点可靠性工程（SRE）：用 SLI（服务级别指标）、SLO（服务级别目标）与错误预算三层结构，替代单一的可用性承诺。

 _{图 1　SLI / SLO / 错误预算的三层结构}

先看清楚：可用性数字到底意味着什么

把百分比折算成时间，感受会直观得多。以 30 天月度为例：

一个常被忽略的量级差：99.9% 与 99.99% 在纸面上只差 0.09%，但允许的月度中断从约 43 分钟压缩到约 4 分钟——这意味着后者根本不可能靠人工响应达成，必须依赖自动切换。承诺哪个数字，决定的是要建什么样的运维体系，而不只是签哪份合同。

SLI：先定义"测什么"

SLI 应面向体验而非设备状态，且可下钻到站点、链路与应用维度。SD-WAN 场景的常用 SLI 包括：隧道可用性、端到端时延、丢包率、抖动、链路利用率，以及关键业务的应用级可用性。

SLO：再定义"达到多少算达标"

SLO 应按业务重要性分级设定，而非全网一刀切。例如核心站点与一般站点采用不同的可用性目标，实时业务（音视频、收银）与批量业务（备份、同步）采用不同的时延与丢包目标。分级的意义在于把有限的运维资源投在真正重要的地方。

错误预算：判断"还能坏多久"

错误预算是 100% 减去 SLO 得到的失败额度，它把可靠性从"是非题"变成"资源分配题"：预算充足时可以更激进地发布变更；预算即将耗尽时应冻结变更、优先稳定性。这是让运维与业务之间形成理性对话的关键机制——不再是"能不能上线"的争执，而是"预算还剩多少"的事实判断。

三、可观测性：四类信号

要让上述指标体系落地，前提是数据能被采集与关联。业界通常把可观测信号分为四类：

四类信号单独看价值有限，关键在于能否按时间与拓扑关联起来——用户报障的那一刻，能否在同一界面看到当时的链路指标、切换事件与路径变化。这决定了故障定界是几分钟还是几小时。

选型提示：可观测能力很容易在演示中显得完美。较可靠的验证方式是在 PoC 中人为制造故障（拔链路、注入丢包、变更策略），观察告警是否触发、能否定界到具体段落、能否下钻到路径与时段。能被复现验证的才是能力。

四、告警分级：让告警值得被看

告警泛滥会直接摧毁告警的价值——当每天几百条告警时，真正重要的那条一定会被淹没。建议按处置动作分级，而非按技术严重度分级：

分级的判据是"收到这条告警后要做什么"。如果一条告警不对应任何动作，它就不该以告警形式出现——降级为记录即可。

五、故障处理闭环

 _{图 2　把 MTTR 拆成五段来压缩}

修复时间（MTTR）不是一个整体，而是由发现、定界、定位、恢复、复盘五段构成。多数团队的瓶颈并不在"修得慢"，而在"发现晚"和"定界难"——用户先于监控发现问题，然后在多个团队之间来回定界。因此压缩 MTTR 的性价比顺序通常是：先补可观测（缩短发现与定界），再谈自动化修复。

恢复阶段有一条实践原则：先止血、后归因。优先用切换或回滚恢复业务，根因分析放到业务恢复之后进行——追求"一次性查清楚再动手"往往会拉长业务受损时间。

复盘则是闭环真正的价值所在：每一次故障的结论都应回流到监控与预案（补一条告警、补一个自动切换策略、补一份处置手册），确保同一个坑不掉第二次。缺了复盘，故障处理就只是重复劳动。

六、五个常见认知误区

• 把"可用性 99.9%"当作运维目标。它是验收与问责用的合同条款，不是运维抓手。运维需要的是面向体验、可下钻的 SLI 与分级 SLO。

• 把"没告警"当作"没问题"。没有覆盖到的维度不会告警。体验劣化常常发生在阈值之下、监控之外。

• 把告警数量当作监控质量。告警泛滥等于没有告警。判断标准是每条告警是否对应明确动作。

• 先上自动化，再补可观测。没有可观测的自动化，是更快的盲飞——自动化会以更快的速度执行错误决策。顺序应当反过来。

• 把运维当成纯技术问题。SLO 分级本质是业务优先级的技术表达，需要业务方参与定义；错误预算也是业务与技术之间的对话机制。

七、运维能力评估清单

1. 统一管控：分支、云、边缘能否在单一平面一致编排策略，而非多控制台并行？

2. SLI 定义：是否面向体验（时延/丢包/抖动/应用可用性），可下钻到站点、链路、应用？

3. SLO 分级：是否按业务重要性分级设定目标，而非全网一刀切？

4. 错误预算：是否可计算、可视化，并与变更发布策略挂钩？

5. 可观测四类信号：指标、事件、日志、链路追踪是否齐备且可按时间与拓扑关联？

6. 告警分级：是否按处置动作分级？每条告警是否对应明确动作？

7. 闭环机制：是否有复盘制度，结论能否回流到监控与预案？

8. 合同条款：MTTR 与赔付细则是否写入合同，而非只约定一个可用性数字？

9. 托管选项：是否提供 7×24 托管，能否补足自身运维人力缺口？

10. 验证方式：能否在 PoC 中人为制造故障，验证告警、定界与定位的真实能力？

八、常见问题（FAQ）

Q：SLO 和"可用性 99.9%"有什么区别？

A：可用性 99.9% 是一个面向合同的总量数字，用于验收与问责。SLO 是面向体验的分级目标，配合 SLI 可下钻到站点、链路与应用，并通过错误预算回答"还能坏多久、现在该不该冻结变更"。前者用来签字，后者用来干活，两者并不冲突，但不能相互替代。

Q：99.9% 和 99.99% 差距真有那么大吗？

A：纸面上差 0.09%，实际差一个量级：按 30 天折算，前者每月允许约 43 分钟中断，后者只有约 4 分钟。4 分钟意味着人工响应基本来不及，必须依赖自动切换。所以这个数字决定的是要建什么样的运维体系，而不只是合同条款。

Q：MTTR 应该压到多少算达标？

A：没有普适答案，取决于业务对中断的容忍度。合理的做法是反推：先定 SLO，再由错误预算倒推可接受的故障时长与频次。比起追一个绝对数字，更值得做的是把 MTTR 拆成发现、定界、定位、恢复四段，找出自己最长的那一段。

Q：为什么监控没告警，用户却说卡？

A：通常是两个原因：一是监控维度没覆盖到（如只监控隧道通断，未监控抖动与应用体验）；二是劣化发生在阈值之下——没到告警线，但用户已有感知。解法是把 SLI 定义在体验层面，并配合错误预算观察趋势，而不是只等阈值触发。

Q：应该先上自动化还是先补可观测？

A：通常建议先补可观测。没有可观测的自动化，等于让系统以更快的速度执行可能错误的决策；而有了可观测之后，哪些环节值得自动化也会自然浮现出来。

Q：AI 运维能解决故障定位吗？

A：有帮助，但需要验证。这类能力在演示中容易显得完美，较可靠的判断方式是在 PoC 中人为制造真实故障，看它能否定位到根因、定位是否准确、以及定位错误时有无人工兜底路径。同时确认是生产环境可用还是仅演示环境。

_{关于本文：SLI / SLO / 错误预算与可观测性四类信号为业界通用工程框架（参见站点可靠性工程相关公开资料）；可用性与中断时长的换算按 30 天月度折算，可自行验算。文中阈值与分级为经验参考，具体目标应结合自身业务容忍度设定，指标以实测与合同 SLA 为准。}