在线服务的稳定性保障一直是运维和技术部门的核心工作之一。但时至今日，这个方向实际仍然有很多基本的概念都没有对齐。今天这篇文章就罗列下那些混淆不清的概念，期望有一天大家沟通时不是鸡同鸭讲，各说各话。
核心要点摘要
- 服务可用性不是一个孤立的百分比，必须同时说明统计口径、算法和业务含义。
- 故障不是所有异常的统称，需要和事件、异常、事故等概念区分，并形成量化标准。
- 根本原因适合用于复盘，但如果没有约定追溯边界，很容易变成无法达成共识的责任归因。
- 故障处理中优先目标是止损和恢复服务，不应一开始就陷入技术细节里的“根因定位”。
- 业务监控面向业务负责人关心的健康状态，不等同于应用监控、模块监控或研发团队关心的技术指标。
五个误解总览
| 容易混淆的概念 | 常见误解 | 更准确的理解 | 直接影响 |
|---|---|---|---|
| 服务可用性 | 只报 99.9xx% 就能说明稳定性 |
必须说明基于时间还是基于请求，以及停机、部分可用、用户影响面的计算方法 | 影响稳定性目标是否可解释、可比较 |
| 故障 | 任何异常都叫故障 | 故障应有明确量化边界，并和事件、异常、事故区分 | 影响告警分级、响应压力和恢复效率 |
| 根本原因 | 所有事故都能找到一个被所有人接受的根因 | 根因分析需要先约定追溯深度和责任边界 | 影响复盘质量和组织共识 |
| 根因定位 | 故障处理中要优先找到底层 bug | 故障处理优先止损，应先定位影响范围、关键事件和可执行预案 | 影响 MTTR 和跨团队协同 |
| 业务监控 | 研发关心的接口、日志、延迟就是业务监控 | 业务监控应面向业务健康，如在线用户数、订单量、GMV、在线商品量等 | 影响业务方是否能理解和使用监控 |
误解一：服务可用性不是一个脱离算法的百分比
听过很多技术分享，看过很多平台的承诺，上来都是讲我们的服务稳定性 99.9xx%，但似乎都“忘记”了提供这个稳定性的具体算法和解读。如果没有明确的定义，这个数值其实毫无意义。
术语解释：什么是服务可用性
服务可用性通常用来描述在线服务在一段时间内对用户是否可用、是否能成功完成请求或核心流程。但这个概念不是天然统一的指标，它依赖统计方法。
原文提到，Google SRE Book 中至少有两类算法：
- 基于时间的可用性：
可用性 = 系统正常运行时间 /（系统正常运行时间 + 停机时间） - 合计可用性：
可用性 = 成功请求数 / 总请求数
使用哪种统计算法，很可能因业务类型不同而不同，例如电商服务、打车服务；也可能因服务类型不同而不同，例如请求类服务、存储类服务；甚至还可能因公司的传统和文化不同而不同。
为什么只报百分比会误导
以上两种算法本身就存在很多不明确的地方。
以基于时间的可用性为例，哪些时间适合算到停机时间里？服务还部分可用算不算？只影响了 10% 的用户算不算？如果只统计完全停机的时间，那即使是非常严重的事故，也可能统计不到停机时间里，这显然是不合理的。
合计可用性也一样。通常这种方式会在接入网关上对请求日志做统计，但故障时很可能出现两种情况：
- 后端异常了，用户大量重试，导致统计到的流量和错误量都暴涨。
- 核心流程故障了，或端上故障了，网关上或统计点上根本就没有了流量。
这些因素都会导致统计错误，并且数据修正非常困难。
国内各家公司的可用性统计方法五花八门，可能基于以上方法做了各种变形和补充，因此相互之间并没有可比性。各公司内部也只有在统计算法不变的情况下，和历史去对比才能看出价值。
更严谨的表达方式
所以，当提到服务可用性目标时，比较严谨的说法是：
我们的服务可用性从
99.xxx%提高到了99.yyy%，它的算法是什么，这个算法意味着什么。
这句话的重点不只是数值提高了，而是稳定性指标背后的统计口径清楚、业务含义清楚、历史对比关系清楚。
误解二：故障不是所有异常的统称
什么样的异常算故障？
笔者在做运维的早期第一次听到这个问题时，有种被击中了的感觉。因为我们天天大谈故障，甚至 KPI 里都有故障相关的任务，但都只是凭感觉，却没有对它做过定义和量化。
入口模块的一两个请求失败算不算故障？1% 的请求失败算不算故障？到什么程度算故障？
为什么需要定义“故障”
故障，直观上大家的理解是比较严重的异常。只是一般的异常和严重的异常如果不加区分，可能会带来几种后果：
- 让稳定性保障的同学们时刻紧张，疲于奔命。笔者开始做运维的那个年代，只要短信报警响起，大家半夜都能直接蹦起来，所有报警都如此，压力可想而知。
- “重要”的报警太多，最后变得都不重要。
- 异常的严重程度对应的处理方法其实有重大不同，不加区分可能影响故障恢复时间，这点在后面的“根因定位”会进一步说明。
建议区分：事件、异常、故障、事故
完善的服务稳定性保障，建议对这些概念进行量化定义：事件、异常、故障、事故。
笔者认为，这几个概念的范围是从大到小，影响程度逐级递增：
| 概念 | 理解重点 |
|---|---|
| 事件 | 系统或业务中发生的状态变化，不一定代表问题 |
| 异常 | 偏离预期的状态或指标，需要观察或处理 |
| 故障 | 已对服务可用性、核心流程或用户体验产生明确影响的异常 |
| 事故 | 影响范围、严重程度或组织后果更高的一类故障 |
这些定义不一定全行业统一，但在一个公司或团队内部应该统一。
更进一步，值得用一个专门的系统来对这些概念做量化和报警。这样，当大家提到“故障”时，或收到“故障”的报警时，它在大家脑子里的严重程度都是一个量级的。
误解三：根本原因不是天然能达成共识的词
什么是根本原因？
在过往的故障复盘经验中，我发现故障的直接原因、重要原因、触发原因、主要原因，这些原因都是相对能够确定并被接受的。但唯独根本原因，如果深究起来，并不太容易形成共识。
并且，“根本原因”是一个很沉重的词，很多团队潜意识里不太想承担这个原因对应的责任。
一个变更故障的例子
比如，一个新用户上线变更，没有好好检查导致了服务故障。这个事故很可能有几类原因：
| 原因类型 | 可能的解释 |
|---|---|
| 直接原因 | 上线变更导致服务故障 |
| 触发原因 | 程序中的某个 bug 被触发 |
| 重要原因 | 没有按要求做好变更检查 |
但根本原因是什么？
因为“根本”两个字就要寻根究底。假设从重要原因出发，这位同学没有按要求做好检查，那为什么他不按要求做检查？导师没有培训过？团队没有做好变更意识的培训？平台为什么没有做好变更拦截？他自己一时大意，但针对这种重要变更，为什么没有 double check 机制？
如果继续深究，那根因最终会归因到笔者前公司的一个口号：一切责任都是管理者的责任！
但任何故障的根因如果都是这个，那以后也就不必分析根因了，因为结论都一样。这也是为什么只要出现事故，管理者一般都会跟着被处罚的原因，因为他们的管理责任就是“根本原因”。
使用“根本原因”前先约定边界
所以，如果提及这个原因，希望你们的公司或团队对它的定义和深究程度已经是明确的。
根本原因分析不是不能做，而是要先回答几个问题：
- 根因追溯到技术实现、流程制度，还是组织管理？
- 复盘的目标是恢复事实、改进机制，还是分配责任？
- 同一个事故中，直接原因、触发原因、重要原因和根本原因是否允许并存？
这些边界不清楚，“根本原因”就容易变成各说各话。
误解四：故障处理中不应一上来就做“根因定位”
故障处理中往往会提到“根因定位”这个概念。
这个场景下，大家自然不会像复盘时那样联想到去找管理上的、流程上的根因。但它仍然可能将一些人引导到错误的故障定位方向上去：比如一开始就对个别报警前后分析，深入代码去寻找 bug，或深陷在技术的追根溯源上。
这个做法对不对呢？在问题排查中是对的，但在故障处理场景中是不对的！
故障处理的第一原则是止损
为什么？
因为故障处理时的第一原则是止损，是尽快恢复服务的核心流程和核心体验。
要做到这一点，我们应该寻找尽可能高效的方法。比如，多活服务中的一个单元异常了，这时候只要确认其它单元的服务正常、容量充足，做一个简单的流量调度即可完成止损，最多再锁定变更，这个故障处理过程就结束了。
再比如，服务故障时优先查看有没有核心模块的变更。如果有，尽快回滚，很可能服务就恢复了。
更准确的说法：故障定位、故障定界、故障分析
故障处理的过程，其实是一个将故障整体的关键特征、关键事件和有效预案连接起来的过程，也是一个多团队协同的过程。
把它叫做根因定位，从表意上就不准确，而且隐含一种错误的引导：让处理人员在这个场景下优先去寻找 bug，寻找异常在技术上的深层原因。
上来就从前往后 trace、debug，最终可能也能解决问题，但应该是在首先分析全局故障特征和关键事件后，发现没有有效办法或预案时再去做。
所以，故障处理中不建议提根因定位。叫故障定位、故障定界、故障分析这类词，都会比“根因定位”产生的误导少。
误解五：业务监控不等于研发团队关心的技术指标
运维或基础技术团队通常离真正的“业务方”比较远，最常打交道的是业务研发团队。技术部门里，业务研发团队是经常和“业务方”打交道的团队。因此在运维和基础技术团队看来，业务研发团队可能就被代表了“业务方”。
基于这个认定，通常在监控划分时，会出现把业务研发团队提的需求或关心的指标归类为业务监控的情况，如错误日志、模块流量、接口延迟等。
但实际上，真正站在业务负责人或公司的角度，业务肯定不是指业务研发团队。业务研发团队只是直接支撑业务的团队之一，还有运营团队、产品团队、销售团队等等。
业务监控应该监控什么
业务监控对应的指标，应该是业务负责人和这些团队共同关心的指标，甚至是运营、产品、销售这些团队更为关心的指标。
这类指标包括在线用户数、订单量、GMV、在线商品量等，也包括这些指标衍生出来的观察维度，例如分地域、分人群、分时段、分渠道观察这些指标。
你或许想到了，这些指标通常可能已经存在于公司的 BI 系统里。老板们用它们来观察分析业务的发展情况，运营们用它们来分析营销效果。
如果严格定义业务监控，应该是对这类指标做监控展示，并实时报警，这才叫业务监控。
当然，在具体的指标采集上，有可能一个业务监控指标和其他监控指标是同一个指标。比如，一个关键模块的流量，或从模块日志中提取出来的特定流量，可能就可以代表这个业务的订单量。
如何判断一个监控是不是业务监控
可以从以下几个方面判断一个监控到底是不是属于业务监控：
- 监控的目的：业务监控应该用于报告整个业务的健康状态，而不是用于发现某个模块、组件或基础设施的异常。
- 指标的含义：业务监控指标的含义，是一个非技术人员也很容易理解，甚至是非技术团队更容易理解的概念。
- 指标的重要性：如果你告诉老板这个指标异常了，他会立马理解并重视。
- 技术无关性：无论研发采用何种架构、如何划分服务模块、如何重构服务，除了采集方法，这些业务监控指标的含义都不会也不需要变化。
- 指标形态：业务监控“通常”是一个“量”相关的指标，如在线用户数、下单量等，而不是成功率，但这点并不是绝对的。
如果细分故障处理过程，业务监控是发现故障的重要手段。但很多企业或业务要么没有业务监控，要么实际是把其它监控混杂在了“业务监控”的概念里，如应用监控、模块监控，也没有明确这些监控应该面向的真正对象。
这个做法的后果是业务监控得不到应有的重视，发挥不了应有的价值。
FAQ
服务可用性为什么不能直接比较百分比？
因为不同团队可能采用不同算法。有人按时间统计，有人按成功请求数统计；有人只统计完全停机，有人会考虑部分可用、用户影响面和核心流程故障。没有算法和口径，99.9xx% 之间没有严格可比性。
故障和异常的区别是什么？
异常是偏离预期的状态，故障是已经对服务可用性、核心流程或用户体验产生明确影响的异常。一个团队需要通过量化定义，把事件、异常、故障、事故区分开，否则告警和响应都会失焦。
为什么故障处理中不建议说“根因定位”？
因为故障处理的第一原则是止损。此时更需要判断影响范围、关键事件、可执行预案和恢复路径，而不是一开始就深入代码追 bug。根因可以在复盘或后续排查中继续分析。
业务监控和应用监控怎么区分？
业务监控面向业务健康，指标应让业务负责人、运营、产品、销售也能理解，例如在线用户数、订单量、GMV、在线商品量。应用监控更偏技术视角，例如错误日志、模块流量、接口延迟。
总结
《服务稳定性保障的五大误解》讨论的是稳定性保障中常被混淆的五个概念：服务可用性、故障、根本原因、根因定位和业务监控。
这些概念的共同问题，不是名字不好听，而是定义、边界和使用场景没有对齐。稳定性保障要真正发挥作用，首先要让团队在同一套语言里讨论问题：指标要有算法，故障要有分级，根因要有追溯边界，处理过程要优先止损，业务监控要服务真正的业务健康。
可能还有更多概念未被清晰定义，希望以此为鉴，大家一起推动服务保障领域的标准化、量化和最佳实践。后面还将谈谈稳定性保障中常见的错误做法，敬请期待，也欢迎交流探讨。
