一、故障度量概述：什么是单点故障？什么是潜伏故障？为什么需要度量它们？
1.1 从一次线上事故说起
2018年，我负责的一个核心支付系统出了个大问题。凌晨3点，数据库主库宕机，按理说备库应该自动接管。但监控一直没报警，直到业务方反馈用户无法付款，我们才发现——备库的同步进程早在三个月前就挂了，没人知道。
这就是典型的潜伏故障。它一直存在，只是没触发。而那次宕机本身，就是单点故障。两个问题叠加，直接导致系统瘫痪4小时。
从那以后，我养成了一个习惯：任何系统上线前，先问三个问题——哪里会单点？哪里可能潜伏？怎么度量它们？
1.2 什么是单点故障？
单点故障，说白了就是系统里某个组件挂了，整个功能就不可用了。它不一定是单台机器，也可能是某个进程、某个网络链路、甚至某个人。
单点故障的本质： 该组件没有冗余，或者冗余机制失效，导致其成为整个链路的“致命短板”。
我见过最典型的单点：
- 单台数据库——读写全压在一台机器上，挂了就全挂
- 单一负载均衡器——前端只配了一个Nginx，没有备机
- 共享存储——所有节点依赖同一个NAS，NAS一坏全完
- 单点认证服务——LDAP或OAuth只部署了一个实例
你想想看，这些场景是不是很常见？很多团队觉得“先上线再说，后面再补高可用”。结果呢？往往还没来得及补，事故就来了。
3 什么是潜伏故障？
潜伏故障更隐蔽。它没有直接导致系统不可用，但已经埋下了隐患。就像我开头说的那个备库同步进程——系统还在跑，但容错能力已经没了。
常见的潜伏故障包括：
| 类型 | 例子 | 为什么危险 |
|---|---|---|
| 冗余失效 | 备库同步中断、主备切换脚本报错 | 你以为有备份，其实没有 |
| 资源泄漏 | 连接池占满、磁盘空间缓慢增长 | 平时不触发，高峰时突然崩溃 |
| 配置漂移 | 某台机器的防火墙规则被改了 | 跟标准环境不一致，排查极难 |
| 证书过期 | TLS证书还有3天到期 | 到期那一刻，所有加密连接全断 |
| 版本不一致 | 部分节点没升级补丁 | 触发特定bug时才会暴露 |
我曾经踩过的坑： 有一次做容量评估，发现集群里一台机器的内存使用率异常低。查了半天，发现它的健康检查接口返回了错误状态，流量根本没打过去。这台机器已经“潜伏”了两个月，没人发现。如果当时没做全量巡检，这个隐患会一直存在。
1.4 为什么需要度量它们？
度量，不是为了出报表。度量是为了让隐患变得可见。
我个人的经验是：不可度量，就无法管理。你想想看，如果连系统里有多少个单点、潜伏故障的平均存活时间都不知道，你怎么做改进？
度量单点故障和潜伏故障的核心价值：
- 量化风险——把“感觉系统不太稳”变成具体的数字指标
- 定位优先级——哪个单点最危险？哪个潜伏故障最该先修？
- 验证改进效果——做了高可用改造后，单点数量降了多少？
- 驱动自动化——当度量数据足够多，就能自动发现和修复
一个小建议： 刚开始做度量时，别追求完美。先挑3-5个最核心的单点，持续跟踪它们的MTBF（平均故障间隔）和MTTR（平均修复时间）。等团队习惯了，再逐步扩大范围。
1.5 本章知识体系
下面这张图，是我做故障度量时常用的框架。它把单点故障和潜伏故障的关系、度量维度、改进路径串在了一起。
1.6 度量的起点
说了这么多，到底怎么开始？
我的建议是：从“最痛的地方”入手。别想着一步到位建个完整的度量体系，那不现实。
- 先找出最近三个月导致过事故的单点
- 再排查那些“你以为有冗余，实际已失效”的潜伏故障
- 给每个问题打上标签：类型、影响范围、发现难度
- 然后开始记录它们的出现频率和修复时间
记住一句话： 故障度量的终极目标不是零故障，而是让每次故障都有迹可循、有据可查、有法可解。
嗯，这一章就到这里。后面的章节，我会带你深入每个度量指标的具体计算方法、工具链搭建、以及我在实战中总结的避坑指南。