一、稳定性分析概述
做系统架构这么多年，我越来越觉得「稳定性」这个词被说烂了。很多人一开口就是「高可用」「容灾」「多活」，但真要问他：你的系统到底稳不稳？ 往往答不上来。
说白了，稳定性不是靠口号喊出来的。它是一套可度量、可控制、可恢复的工程能力。今天这一章，我们就先把地基打牢。
1.1 什么是系统稳定性
先给个定义：系统稳定性，是指系统在持续运行过程中，能够正确、及时地处理请求，并在异常发生时具备自我恢复的能力。
注意两个关键词——「正确」和「及时」。光正确不够，响应慢了也算不稳定。光及时也不行，数据错了更糟糕。
我遇到过不少团队，把「没宕机」等同于「稳定」。其实不然。你想想看，一个接口虽然没挂，但每次响应都要 5 秒，用户早就跑了。这种「假稳定」比真宕机更可怕。
1.2 稳定性分析的价值
为什么要花精力做稳定性分析？三个字：省成本。
- 省运维成本： 一个稳定的系统，半夜不需要人起来救火。
- 省业务成本： 每宕机 1 分钟，可能损失几十万甚至上百万。
- 省信任成本： 用户对产品的信任，建立起来很慢，崩塌却很快。
我记得有一次做电商大促压测，发现一个隐藏的慢查询。当时 DBA 说「问题不大，线上流量没那么高」。结果双十一当天，这个查询直接把主库打挂了。恢复用了 40 分钟，损失了将近 200 万的 GMV。从那以后，我养成了一个习惯——任何线上问题，都要追问一句：如果流量翻 10 倍，它会不会变成事故？
1.3 稳定性分析的三大支柱
稳定性分析不是玄学。它有三个实实在在的支柱：可观测性、可控制性、可恢复性。这三者缺一不可。
1.3.1 可观测性
可观测性，就是你能「看见」系统在干什么。没有可观测性，稳定性分析就是盲人摸象。
它包含三个层面：
| 层面 | 说明 | 常见工具 |
|---|---|---|
| 日志 | 记录系统发生了什么 | ELK、Loki |
| 指标 | 量化系统的状态 | Prometheus、Grafana |
| 链路追踪 | 还原请求的完整路径 | Jaeger、Zipkin |
我见过最典型的反面教材：线上出了故障，运维说「CPU 飙高了」，开发说「不知道哪个接口引起的」。为什么？因为没有链路追踪。你只能看到症状，看不到病因。
1.3.2 可控制性
光能看见还不够，你还得能「管住」它。可控制性，就是系统在异常时，你能及时干预。
常见的控制手段包括：
- 限流： 防止流量冲垮系统
- 降级： 牺牲非核心功能，保住核心功能
- 熔断： 快速失败，防止雪崩
- 动态配置： 不改代码，调整行为
举个例子。有一次线上出现慢 SQL，数据库连接池被占满。如果当时有熔断机制，就能快速切断异常流量，保住正常请求。可惜没有。结果就是——一个慢查询拖垮了整个服务。
1.3.3 可恢复性
最后，也是最容易被忽视的——可恢复性。系统一定会出问题，关键是出了问题能不能快速恢复。
可恢复性包含：
- 数据恢复： 备份是否完整？恢复速度够不够快？
- 服务恢复： 重启后能否自动回归正常状态？
- 流量恢复： 切流后，新节点能否承接流量？
我记得有一次做容灾演练，模拟机房断电。结果发现，虽然数据备份是完整的，但恢复脚本有 bug，花了 3 个小时才把服务拉起来。这 3 个小时，就是可恢复性没做好的代价。
1.4 三大支柱的关系
这三者不是孤立的。它们的关系可以用一张图来概括：
你看，这三个支柱形成了一个闭环：先观测到问题，再通过控制手段干预，最后恢复系统正常状态。恢复之后，继续观测，看看干预是否有效。这个循环转得越快，系统就越稳定。
1.5 本章小结
这一章我们聊了三个核心问题：
- 什么是稳定性： 正确 + 及时 + 可恢复
- 为什么做稳定性分析： 省成本、保业务、赢信任
- 三大支柱是什么： 可观测性、可控制性、可恢复性
嗯，地基打好了。后面的章节，我们会逐一深入每个支柱，看看具体怎么落地。记住一句话：稳定性不是结果，是过程。