与"稳定性"的区别
稳定性/可靠性（Reliability）：系统在预期条件下持续正常工作的能力。
韧性（Resilience）：系统在意外条件下——组件失效、流量激增、依赖故障、人为错误——维持核心功能并恢复的能力。
类比：
- 稳定性是"不容易坏"；
- 韧性是"坏了也能撑住，还能快速恢复"。
关键洞察：复杂系统的失效是不可避免的。因此，除了"减少失效"（稳定性），还需要"在失效中生存"（韧性）。
韧性的四个支柱
一、冗余（Redundancy）
没有单点故障：
- 多实例、多可用区、多地域；
- 数据的多副本；
- 网络的多路径。
注意：冗余不等于韧性——冗余组件必须在需要时真的能用（需要故障转移机制 + 定期验证）。
一个"从没被测试过的备份实例"，其价值接近于零。
二、隔离（Isolation）
防止故障扩散：
- 舱壁模式（Bulkhead）：像船的隔水舱——一个舱进水不会沉船。在系统里表现为资源隔离（线程池隔离、连接池隔离、按租户隔离）；
- 熔断（Circuit Breaker）：下游故障时快速失败，而不是等待超时耗尽资源；
- 限流（前文提到过）；
- 网络分段（前文提到过）。
三、优雅降级（Graceful Degradation）
核心功能优先。
当某些依赖不可用时：
- 关闭非核心功能（如推荐、评论、个性化）；
- 用缓存的、陈旧的数据（而非报错）；
- 返回简化的响应。
例子：电商大促时，可以暂时关闭"推荐"和"评价"功能，保证"浏览—加购—下单—支付"主链路可用。
这需要预先设计——明确定义哪些是核心功能，哪些可以牺牲。这是产品决策，不只是技术决策。
四、快速恢复（Recovery）
- 自动化故障转移；
- 快速回滚（前文提到过）；
- 幂等性和重试（前文提到过）；
- 状态的可重建性（无状态服务 + 外部化状态）。
韧性工程的人文视角
这个领域有一个重要的认识转变：韧性不只是技术属性，也是组织和人的属性。
关键观点：
系统在日常运行中之所以不崩溃，很大程度上依赖人（运维、开发）的持续适应和调整——他们填补了设计和现实之间的缝隙。
因此，韧性工程关注：
一、人如何处理意外
一线工程师在面对从没见过的情况时，是如何判断和应对的？他们依赖什么信息？有什么工具？
二、让系统的边界可见
好的系统能让操作者知道：
- 当前状态是什么；
- 我做的操作会有什么后果；
- 系统正在接近什么极限。
可观测性（前文提到过）在这里不只是"技术监控"，而是"让人的判断成为可能"。
三、从成功中学习，而不只从失败中学习
传统的事故分析只看失败。韧性工程认为：日常的成功同样值得研究——因为成功的背后往往有人员的临场调整，而这些调整正是系统韧性的来源。
适应力（Adaptive Capacity）
一个核心概念：组织在面对未曾预料的情况时，调整自身以适应的能力。
如何增强：
- 决策权的下放：一线人员有权在紧急情况下做决定（如是否立即回滚、是否降级）；
- 人员的多样性和经验：不同视角能识别出更多可能性；
- 演练和心理准备：模拟意外情境，让人熟悉"不确定性中的决策"；
- 信息的流通：让需要决策的人能获得完整信息。
与 SRE 的关系
SRE（站点可靠性工程）提供了大量韧性工程的技术实践：SLO、错误预算、混沌工程、无指责复盘。
韧性工程则提供了理解这些实践为什么有效的框架——把系统视为技术 + 人 + 组织的复合体。
一句话
韧性工程的核心认识是：你无法预见所有故障，所以你应该建设一个"在意外发生时仍能运作"的系统和组织——而不只是一个"设计上不会失败"的系统。
说明：本文为可靠性工程的知识整理。