稳定性保障，是一切技术工作的出发点和落脚点，也是 IT 工作最核心的价值体现。当然，它也是技术人员最容易“翻车”的地方。真正有效的稳定性建设，不是堆工具、喊口号，而是把目标、观测、定位、止损、架构和变更治理串成一套可重复执行的机制。
本文整理 8 个稳定性保障锦囊，适合 SRE、运维、研发负责人和一线工程师在可靠性建设、故障响应、可观测性体系设计和架构评审中择机使用。
核心要点摘要
- 稳定性目标必须可量化、可被业务理解，最好能从用户视角定义“北极星指标”，作为故障发现和可用性度量的共同语言。
- 故障处理要形成可重复执行的发现、定位、止损路径，把排查经验、关键数据和止损动作固化到平台与流程中。
- 核心服务要有冗余和切换预案，非核心功能要能降级、熔断，避免小模块拖垮主流程。
- 有状态服务故障恢复优先关注限流，无状态服务故障恢复优先关注弹性伸缩，二者的恢复抓手不同。
- 灰度发布和云托管服务的正确使用，可以把变更风险、容量风险和基础设施运维负担控制在更小范围内。
8 个稳定性保障实践总览
| 实践 | 解决的问题 | 关键动作 | 常见应用场景 |
|---|---|---|---|
| 设定可用性目标 | 稳定性缺少统一度量 | 定义业务可理解的北极星指标和可用性目标 | SLO 设计、故障定级、年度稳定性复盘 |
| 固化发现、定位、止损路径 | 故障响应依赖个人经验 | 将排查路径、观测数据、止损动作平台化 | 故障应急响应、故障定位、复盘改进 |
| 核心服务冗余与切换 | 单点故障影响主流程 | 识别关键节点，设计冗余、容灾和从零恢复预案 | 多活、多集群、核心链路保障 |
| 非核心功能降级熔断 | 非主流程故障引发雪崩 | 为非核心依赖配置开关、降级和熔断能力 | 微服务调用、第三方依赖、活动流量 |
| 有状态服务限流 | 故障时无法快速扩容 | 明确容量上限，优先使用全局限流 | 数据库、缓存、消息队列等有状态模块 |
| 无状态服务弹性伸缩 | 计算层容量不足 | 将计算层无状态化并微服务化 | Web 服务、API 服务、计算服务 |
| 严格灰度发布 | 变更影响面过大 | 小流量灰度、环境一致、逐步放量 | 发布、配置、开关、数据库和网络变更 |
| 善用云服务 | 自建基础设施复杂且成本高 | 优先使用多 AZ、对象存储、云托管服务和无状态服务器 | 云原生架构、存储治理、运维减负 |
1. 设定可量化、业务可理解的可用性目标
没有度量就没有改进。Google SRE 曾在工程实践中引入针对服务可靠性的预算机制，也就是“Budget”的概念。技术团队和业务团队围绕服务不可用时长的额度制定合理目标，进而在技术投资、稳定性保障和业务发展之间寻找全局最优解。
技术方制定稳定性度量指标时，有一个关键出发点：业务方要听得懂。如果稳定性指标只停留在 CPU、内存、磁盘、P99 延迟、错误率这些系统内部指标上，业务团队很难判断真实影响。更好的做法，是从外部用户视角和内部系统视角同时看待整体可用性。
这里可以把从外部用户视角衡量系统可用性的指标称为“北极星指标”。北极星指标的价值在于：它从用户视角整体观察复杂系统稳定性，让技术团队和业务团队都能理解核心业务是否正在受损。
常见业务可以这样定义北极星指标：
| 业务类型 | 可参考的北极星指标 |
|---|---|
| 在线会议业务 | 1 分钟内参与会议的方数 |
| 电商业务 | 1 分钟内的交易笔数 |
| 游戏业务 | 1 分钟内的同时在线游戏人数 |
| 出行业务 | 1 分钟内的呼叫次数、1 分钟内处于行程中的订单数 |
| 直播业务 | 1 分钟内的主播在线数、观众在线数、打赏总金额 |
从故障发现和定位的角度看，一旦这些北极星指标出现异常波动，就意味着核心业务可能已经受到影响。这个事件应该第一时间被响应并上升，故障应急小组要快速就位，相关支撑系统的工程师也要及时参与。
北极星指标还有一个长期价值：经过一段时间运行后，它的异常时间和正常时间本身就是衡量系统是否稳定的客观依据。稳定性好与坏，不应该只由技术团队自说自话，而应该尽可能从外部用户视角，用北极星指标的统计结果和业务方沟通。
2. 建立可重复执行的发现、定位、止损路径
故障发现、定位、止损，是稳定性保障闭环中最紧迫、最关键的环节。大多数故障处理中，技术人员本质上都在从不同维度收集信息，以辅助判断和决策。
故障定位时，通常要快速回答这些问题：
- 哪些功能和系统受到了影响，影响程度有多大？
- 受影响的是哪个单元？如果存在多活、多集群或多云架构，要先定位到具体单元。
- 故障前后是否存在相关变更、发布、配置调整或开关操作？
- 系统容量是否过载，流量、延迟、成功率是否出现异常？
- 是否存在基础设施故障，例如网络、机房、云服务或底层资源异常？
- 从端上向后端追踪 Trace 和日志，异常源自哪个环节？
- 全局日志和指标的统计数据呈现出什么故障特征？
- 是否还有其他维度的数据或定位工具可以交叉验证判断？
这个环节建议重点加强三件事：
- 将问题排查路径固化在平台上，形成可复用的故障处理套路，并通过每次复盘持续完善。
- 将排查过程中需要的数据、信息尽量透明化，减少工程师在不同工具和平台之间跳转的时间。
- 将最有经验工程师的专家经验沉淀到平台和流程里，让个人经验变成团队能力。
故障紧急止损的手段通常也相对固定：
| 止损手段 | 适用方向 |
|---|---|
| 变更回滚 | 发布、配置、开关、数据库或网络变更引发的问题 |
| 流量调度 | 单元、机房、集群或区域异常时的流量迁移 |
| 服务降级 | 保主流程，牺牲非核心体验 |
| 接口限流 | 控制进入故障模块的请求量 |
| 弹性伸缩 | 无状态计算层容量不足 |
| 机器重启 | 单机资源或运行状态异常 |
| 服务重启 | 进程级异常、连接堆积或短期恢复 |
| 单点切换 | 主备、主从、主节点异常时切换 |
因此，故障处理的关键不是临场想办法，而是能否把故障排查结论和固定止损手段快速关联起来。这个关联速度，直接决定本次故障处理速度，也会影响最终故障级别。
3. 确保核心服务有冗余、可切换
在架构设计过程中，“面向失败设计架构”非常重要。任何系统、模块、链路都有失效概率，稳定性保障不能建立在“它应该不会坏”的假设上。
核心服务治理要重点关注四件事：
- 梳理和识别业务主流程上的关键节点。
- 定期 review 主流程关键节点，避免随着业务迭代出现遗漏。
- 为关键模块制定冗余方案，以及对应的容灾切换方案。
- 在极端情况下，为核心模块准备“从零恢复”的预案。
这里的关键是先识别主流程。只有明确哪些节点影响核心业务，才能判断哪些模块必须冗余、哪些模块必须可切换、哪些模块需要更高优先级的监控和应急预案。
4. 确保非核心功能可降级、可熔断
现代软件架构下，系统模块多、实例多、调用链复杂。很多故障并不是核心链路本身先坏，而是“非主流程”的模块故障阻塞了“主流程”，最终引发雪崩。
因此，在识别主流程关键节点之外，所有非核心功能都应该具备可降级、可熔断的能力。降级和熔断的目标不是让系统完美运行，而是在故障时保住最重要的业务链路。
需要重点关注两点：
- 能查看核心模块的依赖列表，并清楚呈现每个依赖接口的流量、成功率、延迟等黄金指标；如果条件允许，建议增加 Tracing 覆盖率。
- 在非核心功能层面提供开关能力，可以一键熔断和降级；这类场景推荐使用 feature flags 技术。
稳定性保障里，降级和熔断不是“可选项”。只要一个非核心依赖有可能拖慢或阻塞主流程，就应该提前设计对应的开关、阈值和回退策略。
5. 有状态服务：限流是恢复故障的关键抓手
有状态服务在故障时通常很难短时间扩容，因为扩容往往涉及数据迁移和再平衡。数据迁移又会加重系统负载、降低系统性能，导致故障变得更严重。很多雪崩现象，就是在这种情况下被放大的。
因此，针对有状态服务，故障时最有效的恢复手段通常是限流。限流的本质，是先让系统从过载状态中恢复，再逐步恢复服务能力。
限流过程中要关注三点：
- 限流阈值优先考虑设置为“全局限流”阈值。实例数量很多时，全局限流比单实例限流更容易得到准确控制。
- 平时要摸清某个模块的容量上限，并按照流量、延迟、成功率进行量化。
- 在雪崩严重的情况下，为了让相关模块快速恢复，推荐的限流操作顺序是：先拒绝所有流量，然后逐步提升限流阈值，给系统恢复时间和空间。
对数据库、缓存、消息队列等有状态模块来说，盲目扩容和迁移可能让故障更复杂。先限流、再恢复、再放量，通常比一开始就扩大请求入口更稳妥。
6. 无状态服务：弹性伸缩是恢复故障的关键抓手
无状态服务和有状态服务的恢复抓手不同。无状态计算层不依赖本地持久化数据，更适合通过弹性伸缩增加处理能力。
在系统架构设计上，应尽可能将服务设计为无状态架构，把有状态的部分更多转移到数据库、对象存储、消息队列等服务中。这样做的好处是，计算层可以更容易扩容、替换、重启和迁移。
实践上有两个重点：
- 尽可能设计无状态服务架构，把状态从计算层剥离出去。
- 将计算层微服务化，有助于更好地进行弹性伸缩。
当服务可以随时新增实例、移除实例、重启实例，而不会丢失关键业务数据时，弹性伸缩才能真正成为故障恢复抓手。
7. 严格执行灰度发布，把影响面控制在小流量阶段
从稳定性实践看，只要有变更，就有较大概率引发故障。这里保留一个经验判断：70% 的故障都和变更相关。这些变更包括：
- 线上发布新版本。
- 配置变更。
- 开关变更，也就是 feature flags。
- 数据库变更。
- 网络变更。
降低变更故障影响面的核心办法，是把问题暴露在小流量阶段，而不是等到全量流量后才发现。
建议重点做好两件事：
- 严格执行灰度发布流程，将发布、配置、开关等变更逐步放量，把问题尽早暴露在小流量阶段。
- 尽可能保持开发、预发布、线上环境一致，减少环境差异导致的问题延后暴露。
灰度发布不是流程负担，而是稳定性保障的一道关键闸门。它的价值在于，即使变更有问题，也尽量把影响面控制在可承受范围内。
8. 善用云服务
云服务的价值，不只是减少机器采购和机房维护。更重要的是，公有云已经把很多扩展、容错和可用性能力内置在服务里。研发和运维团队要做的，是在合适的位置使用这些能力，而不是把所有基础设施都重新自建一遍。
用多 AZ 胜过用多云
多 AZ 基本可以保障云基础设施的可用性。相比之下，多云往往会给业务系统设计带来更高复杂度，从而引入更多稳定性风险点。
这并不是说多云一定不可用，而是要先问清楚：多云解决的具体风险是什么？它新增的架构复杂度、运维复杂度、数据一致性问题和故障定位成本，是否真的小于收益？在多数场景下，优先把多 AZ 用好，是更直接的选择。
用对象存储管理静态文件
静态文件适合放在对象存储中，而不是直接存放在服务器上。对象存储的优势包括：
| 维度 | 对象存储的稳定性价值 |
|---|---|
| 成本优化 | 按量付费，不需要提前预制大量长期闲置空间，存储形式丰富，单价通常低于块存储 |
| 容错能力 | 一般具备多副本能力，可做版本管理，优于单机或普通块存储 |
| 性能 | 作为公有云全托管服务，单用户请求可能逊于块存储设备，但在多用户和海量场景下更有保障 |
| 安全性 | 具备丰富安全策略，日常维护由公有云保障，使用方重点关注正确选择和配置 |
| 扩展性 | 空间接近无限制，研发人员无需过度猜测容量需求 |
| 开发优势 | 基于 API 的公开服务，方便多个服务共享使用，是很好的解耦渠道 |
尽量使用云托管服务
云托管服务指由公有云完全托管管理的服务。客户不关心具体服务器细节，只通过接口使用服务，并通过公有云控制台、API、SDK 管理服务。扩展、容错能力和可用性通常内置在服务中。
在团队实践中，可以鼓励研发人员选用托管服务：
- 给研发人员一定的托管服务权限。
- 给研发人员提 case 的权限，以应对托管服务问题。
- 让 TAM 直接服务研发人员。
同时，运维要管住自己的手：
- 尽量不自建各种开源服务。
- 拒绝任何维护非业务代码服务的要求。
- 可以购买商业 SaaS，替代公有云没有的托管服务。
这背后的原则很简单：稳定性建设要把工程能力用在业务系统和关键链路上，而不是消耗在大量非业务基础设施维护上。
数据不要存在服务器上
如果希望服务器可以随时替换、重启、扩容和销毁，就不要把关键数据存放在服务器本地。推荐做法包括：
- 日志存 S3，或者打入 ELK 等外部服务中。
- 配置文件通过外部服务或环境变量获取；外部服务可以是 Parameter Store 或其他配置中心，环境变量可以通过 EC2 启动时的用户数据或 Pod 启动时环境变量注入。
- HTTPS 证书使用 ACM 和相关服务解耦，或者参照配置文件的方式获取。
- 密钥通过外部服务或环境变量获取，例如 Parameter Store。
- 业务数据进入 S3 或数据库。
- 应用之间的中间数据送往消息队列进行解耦处理。
- 所有脚本和配置由代码库统一管理，部署按照 CI/CD 管理。
- 服务器开机后，应用服务自动启动。
- 将程序设计成无状态、无共享、可以随时终止。
当服务器不再承载不可替代的数据，它就只是可替换的计算资源。这样的架构更适合弹性伸缩、自动恢复和故障隔离。
注：“善用云服务”部分节选自《云原生王四条》。
FAQ
稳定性保障应该先从哪里开始？
先从业务可理解的可用性目标开始。没有统一目标，监控、告警、故障响应和架构治理都容易各说各话。建议先定义核心业务的北极星指标，再围绕这个指标建设可观测性、应急响应和复盘机制。
北极星指标和系统监控指标有什么区别？
北极星指标从外部用户视角衡量核心业务是否正常，例如交易笔数、会议参与方数、在线人数等。系统监控指标从内部系统视角观察资源和服务状态，例如流量、延迟、成功率、CPU、内存、磁盘等。稳定性保障需要两类指标结合使用。
为什么故障处理要强调“发现、定位、止损”闭环？
因为故障发生后，最重要的不是一次性找到完美根因，而是先确认影响面、定位关键异常、快速止损，防止故障扩大。根因分析可以在复盘阶段深入展开，但应急阶段必须优先让业务恢复。
有状态服务和无状态服务的故障恢复为什么不同？
有状态服务扩容往往涉及数据迁移和再平衡，故障时盲目扩容可能进一步加重负载，因此限流是关键抓手。无状态服务不依赖本地持久化数据，更适合通过弹性伸缩增加处理能力。
灰度发布为什么是稳定性保障的一部分？
变更是故障高发来源。灰度发布可以把新版本、配置、开关、数据库和网络变更先暴露在小流量阶段，减少全量故障风险。它不是发布流程上的形式，而是控制故障影响面的稳定性机制。
结论
稳定性保障不是单点能力，而是一套闭环：用业务可理解的指标定义目标，用可观测性发现问题，用固化路径定位和止损，用冗余、降级、限流、弹性伸缩和灰度发布控制风险，再通过云托管服务减少不必要的基础设施复杂度。
真正可靠的系统，不是永远不出故障，而是在故障出现时能够被及时发现、快速定位、有效止损，并在复盘后把经验沉淀为下一次更快恢复的能力。
