编程语言研究书库
DevOps 驱动开发

韧性工程与混沌测试 — 给系统打疫苗,而不是祈祷不生病

韧性工程与混沌测试 — 给系统打疫苗,而不是祈祷不生病

这一章讲什么: 系统一定会坏。传统思路是努力不坏(可靠性), 本章的思路是坏了也没事(韧性)——并且通过主动注入故障(混沌测试) 来验证「坏了也没事」是不是真的。 这一章是全书从「交付」转向「运行」的枢纽:前面讲的日志、CI/CD、部署策略, 到这里接受实战检验。

1. 主线例子:一次有剧本的「搞破坏」

本章的主线例子,是一次完整执行的混沌实验——按原书五阶段流程走。

实验对象:支付服务。假设:随机杀掉一个 Pod,流量自动切走,用户无感。

  第 1 步 定义稳态:正常时长这样——P95 延迟 180ms,错误率 0.2%,每分钟 3000 单
  第 2 步 提假设:「杀掉一个支付 Pod,30 秒内流量自动重路由,
          错误率不升过 0.5%,无用户可见错误」
  第 3 步 注入故障:LitmusChaos 的 pod-delete 实验,
          每 10 秒删一个 Pod,持续 60 秒(FORCE=false,优雅删除)
  第 4 步 观察:Prometheus 看错误率和延迟;Jaeger 看请求是否绕开被杀的 Pod;
          Grafana 仪表盘对照稳态基线
  第 5 步 学习与改进:如果恢复用了 90 秒、超了假设——
          发现是就绪探针太慢,修探针,改天重跑

  图说:混沌实验 = 有假设、有对照、有安全绳的实验,不是随机搞破坏。
  稳态数值是为演示编的(原书流程相同,未给具体基线数字);实验参数沿原书 YAML 示例。

下面五节展开:§2 韧性是什么(与可靠性的区分),§3 为什么要主动注入故障 (传统测试的盲区),§4 两代混沌工具,§5 优雅降级的七种设计模式, §6 把这一切嵌进流水线。

2. 韧性 vs 可靠性:从「不生病」到「病了能扛」

可靠性(reliability):在给定时间内无故障运行的能力——防故障。 韧性(resilience):出故障后恢复并维持可接受性能的能力——扛故障。 原书一句话钉死区别:「可靠性是理想条件下的稳定;韧性是混乱中的生存。」1

维度可靠性韧性
关注点防止故障从故障中恢复
方法防御(躲避)适应(响应)
目标持续在线持续可用(功能保住)
例子代码零缺陷服务挂了自动 failover

为什么韧性才是正解:不管多少测试和冗余,分布式系统总会坏——硬件会坏、API 会超时、 网络会分区。承认这个现实并为之设计,才是工程2。

韧性的七大原则(原书清单)3:预期故障(提前注入测试、依赖分析、容量规划)、 优雅降级(核心功能保住,砍掉次要功能)、冗余与多样性(没有单点,且冗余件不会 因同一原因一起坏)、隔离与遏制(局部故障不扩散——容器、微服务边界、熔断器; K8s 里每个 Pod/节点都是一个隔离故障域)、可观测与反馈、快速恢复与自愈 (K8s 自动重排 Pod 是经典例子)、从事故持续学习(无指责复盘,更新 runbook)。

四支柱生命周期:抵抗(扛住压力)→ 吸收(故障来了接住)→ 恢复(功能还原)→ 适应(从教训中进化)——循环往复,韧性是过程不是属性4。

为故障而设计:把原则落到代码上的五条实践

最成熟的组织不坐等故障,而是照着故障来设计系统——韧性从第一天就建进去, 不是上线后补的补丁5。原书给了五条实践,逐条按 「解决什么问题 → 怎么做 → 为什么有效 → 边界」看:

  1. 无状态服务(stateless):服务不依赖本地状态——不往自己的磁盘或内存里 存只有它自己知道的数据。 解决什么问题:实例被杀、被迁移、扩缩时,本地状态跟着丢, 流量切到一个新实例上,用户的数据就断了。 为什么有效:任何一个实例挂了,起一个干净的就能顶上;扩容直接加实例, 不用先搬数据。 边界:会话、缓存这类「不得不存」的东西要外置到共享存储(数据库、Redis), 原书没展开怎么外置。
  2. 优雅退出(graceful shutdown):应用收到 SIGTERM(容器平台发来的 「请你退出」信号)后,把手里进行中的事务做完再退出。 解决什么问题:平台删实例只给几秒宽限,应用不处理这个信号就等于被拔电源, 正在处理的请求拦腰砍断,用户看到一半的成功。 为什么有效:平台先发 SIGTERM、停派新流量,等存量请求处理完才真正杀进程, 退出从「事故」变成「流程」。 边界:宽限不是无限的(K8s 默认约 30 秒,补充,不在原文里), 拖更久的请求照样被强杀——超时设置要跟它配套。
  3. 超时与重试:每个外部调用都带明确的超时和退避重试。 解决什么问题:下游变慢时,不设超时的调用会一直挂着占满连接, 故障顺着调用链一层层上传,最后拖垮调用方。 为什么有效:超时给故障画边界,重试兜住网络抖动这类转瞬即过的故障。 边界:与 §5 的模式 3 是同一枚硬币,书在两处都讲了;重试必须指数退避, 否则重试本身变成流量放大器。
  4. 健康检查与探针:K8s 的 liveness 探针(这个容器还活着吗, 不活着就重启)和 readiness 探针(它能接流量吗,不能就从负载均衡里 摘出去)让不健康的容器自动重启、自动摘流。 解决什么问题:进程没退出不等于没病——死锁、堆内存耗尽时进程还在, 平台却「看不见」。 为什么有效:探针把「进程活着」这个粗判断换成「应用真的能干活」, K8s 的自愈(第 08 章)才真正闭环。 边界:原书只提了这两种;startup probe(启动探针,管启动慢的应用 被误判不健康而误杀,补充,不在原文里)是 K8s 后来补的第三种,书里没有。
  5. 故障转移(failover):关键服务跨可用区或跨集群再复制一份,用 active-active(两份都接流量)或 active-passive(一份主用, 另一份待命,主挂了切过去)配置。 解决什么问题:单个可用区整体出事的概率不为零——这正是 Chaos Gorilla 在模拟的场景(§4)。 为什么有效:出事的流量有地方去;而且平时被反复演练过的切换路径, 真出事时才敢用、会用。 边界:active-active 两边同时写的数据一致性是硬骨头,原书一句带过, 没给方案。

原书的收尾一句值得记住:这些模式不只提高可用性,还让系统更好维护—— 一个随时等着组件出故障的系统,演进起来反而从容5。

度量韧性用 SRE 的那套:SLO/SLI/错误预算,加 MTTF(平均故障间隔)、 MTTR(平均恢复时长)、可用率、错误率;目标不是零停机,而是 快检测、自动恢复、用户影响最小6。

案例(电商,原书数字):两小时结账大事故后,上韧性组合拳——数据库双活、 熔断器、K8s 自动扩缩、每周 LitmusChaos 模拟 Pod 终止——MTTR 从 35 分钟 降到 5 分钟以内,用户可见停机降 80%7。

3. 混沌测试:传统测试补不上的那一块

传统测试(单元/集成/E2E)验证「事情对的时候系统行为正确」,有四个盲区: 静态假设(测试假设网络稳、依赖在线,生产里都不是)、缺真实世界条件 (流量尖峰、DNS 挂了、依赖变慢——级联故障在隔离测试里复现不了)、 依赖行为盲区(第三方 API 的故障几乎没人模拟)、覆盖率错觉 (100% 代码覆盖 ≠ 100% 韧性)8。

混沌测试(chaos engineering):在生产环境上实验、建立「系统扛得住动荡」的信心的学科。

它要达成五项目标(原书清单)9:

目标(原书措辞)说的是什么
Expose weaknesses before they become incidents在出事前暴露架构弱点:该有而没的重试、不当的 failover、没处理的异常
Build confidence in system behavior反复观察到系统优雅恢复,才敢相信部署安全和生产就绪
Validate auto-healing mechanisms验证 K8s 重启 Pod、自动扩缩这类自愈手段真的触发、真的完成
Enhance observability and monitoring受控故障下检视指标和告警的表现,找出监控盲区、收敛告警精度
Foster a culture of learning and resilience事故管理从救火变预习:故障是反馈机制,不是灾难

起源:Netflix 的 Chaos Monkey(2010 年起)——工作时间随机杀生产实例, 逼冗余和恢复机制每天被真验一次。后来把它扩成一整套故障模拟工具, 合称 Simian Army(猿猴军团,Netflix 自造的叫法)10: Latency Monkey 模拟网络延迟;Conformity Monkey 检查配置是否符合运维标准; Security Monkey 抓安全配置错误;Chaos Gorilla 模拟整个可用区挂掉; Doctor Monkey 盯着运行中实例的健康。五个一起,Netflix 把环境做到了 「故障是日常、恢复是自动」——书里的原话是 engineered chaos(工程化的混沌)1110。

五阶段实验流程(§1 主线例子的骨架)12:定稳态 → 提假设 → 注入故障 → 观察 → 学习。 核心纪律:假设驱动、范围受限、可回滚——混沌测试的目的不是制造混乱,是通过学习管理混乱13。

五类实验(原书表 11.2)14:

类型干什么例子
基础设施层模拟硬件/虚机故障关 EC2 实例、删 K8s 节点
网络混沌延迟、丢包、分区注入 200ms 延迟、封端口
应用层打断服务或进程杀 Pod、让 API 限流
状态混沌数据损坏/不可用塞满磁盘、数据库不可用
依赖混沌外部服务出错下游 API 返回 500 或变慢

安全绳五条(原书)15:先小后大(非关键环境起步)、特性开关随时停、 自动回滚、SLO 破线即停、每次实验当迷你事故复盘。

4. 两代工具:Chaos Monkey 与 LitmusChaos

Chaos Monkey(Netflix,2010)机制简单直接:后台服务持续扫描实例, 按概率随机杀。原书配置例子(照抄):terminate_probability: 0.15、 cron 每天中午跑一次、exclusions: ["database", "billing"]—— 约 15% 的前端实例被终止,关键系统永不触碰16。流程五步: 发现实例 → 过滤排除名单 → 随机选 → 杀 → 观察恢复17。

现代环境里的集成:K8s 上用 CronJob 定时删 Pod、AWS Lambda 按需注入、 Jenkins 接进流水线18。按环境选集成方式(原书表 11.3)19:

环境集成机制典型用途
AWS EC2EC2 API、Auto Scaling Group(自动扩缩组)验 failover 和扩缩策略
Kuberneteskubectl 命令、删 Pod验 Pod 重启和负载均衡
Docker SwarmDocker API验容器自动恢复
On-prem(自建机房,不用云)自定义脚本走 SSH模拟 VM 重启或断网

四种环境的共同点是「平台给什么接口,就用什么接口杀」:有云 API 用 API, 只有 SSH 就写脚本——混沌工具本身不挑环境,挑的是集成方式19。

LitmusChaos(CNCF 项目):K8s 原生的声明式混沌框架,实验就是 YAML, 天然进 GitOps20。架构五件:

组件干什么
Chaos operatorK8s 控制器,解读 ChaosEngine 定义
Chaos experiments可复用的故障模板(pod-delete、network-latency、CPU-hog)
Chaos engineCRD:把应用绑定到实验,定参数
Chaos runner以 K8s Job 实际执行实验
可观测原生接 Prometheus/Grafana

配置例子(照抄):ChaosEngine 里 TOTAL_CHAOS_DURATION: "60"、 CHAOS_INTERVAL: "10"、FORCE: "false"(优雅删除)21。 实验目录覆盖五层:节点重启、网络延迟/丢包、Pod 删除/CPU 打满、磁盘填充、 容器杀——还能用 Argo Workflows 编排成复杂场景22。

对照(原书表 11.5)23:Chaos Monkey 管 VM 层冗余与扩缩验证, JSON/脚本配置,靠外部监控;LitmusChaos 管 K8s 集群级故障耐受, YAML 声明式,原生可观测。两代工具互补,不互替。

5. 优雅降级:七种设计模式

优雅降级(graceful degradation):部分组件坏了,系统不退回错误页, 而是提供「有限但有用」的服务。视频站降清晰度不停播;电商在数据库故障时 关掉推荐和评论、保住浏览与下单——用户遇到的是不便,不是中断; 从商业看,「降级是把停机变成有限服务」24。

七种模式(原书清单,每种都给了机制)25:

模式机制原书例子
1 核心功能分级事先定义「哪些是命脉」,故障时只保命脉网银:余额查询/转账/认证是命脉,分析报表和贷款广告可停
2 熔断器连续失败超阈值就「跳闸」停调下游,冷却后再放试探流量if failure_count > threshold: circuit.open()
3 超时 + 指数退避重试每次重试等更久:1s → 2s → 4s,防重试风暴三次后仍失败走 fallback
4 Fallback兜底:缓存数据/静态响应/备用服务/诚实提示四种类型见原书表 11.6:静态兜底、降级模式、备用服务、坦诚文案
5 舱壁隔离借自船舱设计:每个服务独立线程池/连接池/配额,一舱进水不沉全船K8s namespace + 资源限额;推荐引擎卡死不影响播放
6 消息队列解耦同步调用改异步:消费者挂了消息存着,恢复后接着处理订单服务发事件到队列;库存服务离线消息不丢
7 降级状态可观测盯住「距离 SLO 破线还有多近」「多少请求走了兜底」「延迟热图」Grafana 上把降级画出来,故障升级前预警

案例(旅游预订平台,原书数字):推荐 API 超时曾让整个下单流程卡死; 改造——推荐调用加熔断、搜索结果加缓存兜底、支付服务给专属计算资源、 加降级告警——部分故障期间交易成功率升 40%,MTTR 25 → 5 分钟, 大区域可用性 99.98%26。

UX 也要配套:降级时给用户看得懂的说明(「部分功能暂时不可用」), 绝不在用户面前吐原始报错和堆栈;交互连续性——用户操作先排队,恢复后补交27。

判断(我们的,不是书里的): 七种模式里,熔断器和舱壁是最值得单独记住的 两个,因为它们的共同本质是给故障划边界:熔断器按时间维度断流 (这下游现在病了,别再去问),舱壁按空间维度隔离(这舱进水,别淹别的舱)。 其余五种(分级、退避、fallback、队列、观测)都是在边界之内的缓冲手段。 没有边界的系统,缓冲越多,崩溃时炸得越均匀——重试风暴就是反例。 如果错,会错在: 在高度异步、背压(backpressure,下游反压上游限流) 机制完善的系统里,「边界」可以由流量控制动态形成,静态熔断阈值反而显得笨重; 但即便在那里,「明确故障域」这个思想依然成立,只是实现换了形式。

6. 韧性进 CI/CD 流水线:每次提交都过一次鬼门关

韧性验证传统上靠年度灾备演练,微服务时代每天上百次部署,根本追不上。 解法:把韧性测试作为 CI/CD 流水线的一个正式阶段,插在部署与晋升之间28:

  CI/CD 的 Build → Deploy(预发)→ 【韧性测试】→ 监控与恢复验证 → 晋升生产
                          ↑
              跑混沌实验:pod-delete / 网络延迟 / 节点故障
              注入后盯 Prometheus:延迟、可用率、错误率
              恢复超阈值 → 流水线自动停、自动回滚

  图说:只有「活着走出模拟故障」的构建才配晋升生产。

GitHub Actions 集成例子(照原书):单测 → 部署预发 → litmusctl-action 触发 pod-delete → check_health.sh 验证恢复29。

可观测集成是这条流水线的眼睛(原书四条)30: 没有它,韧性验证就是瞎验——注入了故障却拿不出证据说「系统扛住了」。

做法干什么
Dashboards(Grafana/Kibana)把部署前后的性能趋势画在同一张图上,肉眼看偏差
分布式追踪(Jaeger/OpenTelemetry)跟踪混沌测试期间的服务间调用,看请求死在哪一跳
Alerting(Prometheus/Datadog 阈值)恢复慢、错误率高就报警,流水线据此判停
Event correlation(事件关联)把混沌事件和对应的性能变化对上号,量出真正的韧性

第四条值得单独说。前三条回答「系统现在怎么样」,event correlation 回答的是 「这次注入的故障到底造成了多大影响」:把每个混沌事件的时间戳和当时的 延迟、错误率曲线叠在同一张图上,才能区分「这个故障确实没事」和 「监控根本没看见」——后者比前者危险得多。没有这条,验证退化成 「没报警就算过」30。

自动回滚四机制:健康探针脚本、错误阈值(如 5xx 超 10% 或延迟 +200ms)、 版本钉住(存好上个稳定版)、特性开关即时关31。 韧性即代码(resilience as code):恢复策略写进 YAML——健康策略阈值、 恢复工作流脚本、用 OPA 在晋升前强制合规32。

案例(金融科技公司,原书数字):五阶段流水线(构建 → 集成测试 → 混沌注入 → 健康验证 → 错误率超 3% 自动回滚)——MTTR 改善 70%,零停机部署成为常态33。

最佳实践六条:韧性测试在 CI/CD 里左移、全自动化(手工混沌违背初衷)、 实验定义进版本库、SLO 合规持续盯、金丝雀发布观察韧性表现、 实验剧本要轮换更新(跟着架构演进,别测三年前的系统)34。

7. 边界与局限

  1. 「在生产环境做实验」的门槛被低估了: blast radius(爆炸半径)控制、 组织授权、审计合规,书里一句「start small」带过,落地时这才是最难的部分。
  2. 稳态定义只给了指标类型,没有给「怎么选阈值、基线随流量季节性怎么调」的方法论。
  3. 混沌实验的度量闭环缺失:实验发现的问题如何进 backlog、如何验收修复, 五阶段流程到「学习」就停了。
  4. 两代工具的对照停在功能层,没有讲选型决策(已有 K8s 平台直接 LitmusChaos; 异构 VM 遗产系统才需要 Chaos Monkey 式方案)。
  5. 案例数字(-80%、MTTR 35→5 等)无出处。

8. 可带走的

  1. 可靠性防故障,韧性扛故障;目标不是零停机,是快检测、自动恢复、用户无感;
  2. 韧性四支柱:抵抗→吸收→恢复→适应,循环不休;
  3. 为故障而设计五条实践:无状态服务、SIGTERM 优雅退出、超时与退避重试、 liveness/readiness 探针、跨区 failover——等着组件坏的建筑,反而好维护;
  4. 混沌测试五阶段:稳态→假设→注入→观察→学习;实验是科学不是搞破坏;
  5. 100% 代码覆盖 ≠ 100% 韧性;依赖故障几乎从不在传统测试里出现;
  6. 五类实验:基础设施/网络/应用/状态/依赖;安全绳五条,blast radius 先行;
  7. Chaos Monkey 杀 VM 验冗余,LitmusChaos 用 YAML 在 K8s 里做声明式混沌;
  8. 优雅降级七种模式,核心是给故障划边界:熔断按时间断流、舱壁按空间隔离;
  9. 重试必须指数退避,无节制的重试就是请求风暴;
  10. 韧性验证进 CI/CD 流水线:混沌阶段放在部署与晋升之间,恢复超阈值自动回滚;
  11. 实验剧本要随架构轮换更新——别测三年前的系统。

9. 原文地图

主题原书章原文位置
韧性 vs 可靠性Principles of resilience engineeringtext/32-fm-principles-of-resilience-engineering.txt:16(搜「survival under chaos」) · text/32-fm-principles-of-resilience-engineering.txt:121(搜「Table 11.1」)
七原则与四支柱同上text/32-fm-principles-of-resilience-engineering.txt:134(搜「Anticipation of failure」) · text/32-fm-principles-of-resilience-engineering.txt:162(搜「Resistance」)
为故障而设计五实践同上text/32-fm-principles-of-resilience-engineering.txt:190(搜「chaos-ready architecture」) · text/32-fm-principles-of-resilience-engineering.txt:197(搜「Stateless microservices」) · text/32-fm-principles-of-resilience-engineering.txt:206(搜「liveness and readiness probes」) · text/32-fm-principles-of-resilience-engineering.txt:209(搜「active-active or active-passive」)
度量指标与电商案例同上text/32-fm-principles-of-resilience-engineering.txt:226(搜「MMTF」) · text/32-fm-principles-of-resilience-engineering.txt:272(搜「35 minutes」)
传统测试盲区Necessity of chaos testingtext/33-fm-necessity-of-chaos-testing.txt:20(搜「Static assumptions」) · text/33-fm-necessity-of-chaos-testing.txt:29(搜「100% code coverage」)
五阶段流程与五类实验同上text/33-fm-necessity-of-chaos-testing.txt:77(搜「steady state」) · text/33-fm-necessity-of-chaos-testing.txt:128(搜「Infrastructure-level chaos」)
安全绳五条同上text/33-fm-necessity-of-chaos-testing.txt:234(搜「Start small」)
Netflix 与 Simian Army同上text/33-fm-necessity-of-chaos-testing.txt:256(搜「randomly terminated」)
混沌测试五项目标同上text/33-fm-necessity-of-chaos-testing.txt:48(搜「Goals of chaos testing」) · text/33-fm-necessity-of-chaos-testing.txt:55(搜「Expose weaknesses before they become incidents」)
Simian Army 成员清单Tools like Chaos Monkey and LitmusChaostext/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:132(搜「Simian Army, which includes」) · text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:139(搜「Conformity Monkey」) · text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:148(搜「Doctor Monkey」)
跨环境集成表(表 11.3)同上text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:238(搜「Docker Swarm」) · text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:261(搜「Custom scripts with SSH」) · text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:274(搜「Table 11.3」)
Chaos Monkey 机制与配置Tools like Chaos Monkey and LitmusChaostext/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:25(搜「random instance termination」) · text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:71(搜「terminate_probability」)
LitmusChaos 架构与 YAML同上text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:293(搜「Chaos operator」) · text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:334(搜「pod-delete-engine」)
两工具对照同上text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:589(搜「Comparison」)
优雅降级七模式Designing systems for graceful degradationtext/35-fm-designing-systems-for-graceful-degradation.txt:114(搜「failure_count」) · text/35-fm-designing-systems-for-graceful-degradation.txt:280(搜「bulkhead」) · text/35-fm-designing-systems-for-graceful-degradation.txt:300(搜「RabbitMQ, Kafka」)
旅游平台案例同上text/35-fm-designing-systems-for-graceful-degradation.txt:332(搜「tightly coupled」) · text/35-fm-designing-systems-for-graceful-degradation.txt:356(搜「40%」)
流水线五阶段与 Actions 例子Building resilience into CI/CD workflowstext/36-fm-building-resilience-into-ci-cd-workflows.txt:54(搜「Stage」) · text/36-fm-building-resilience-into-ci-cd-workflows.txt:189(搜「Resilience Validation Pipeline」)
自动回滚四机制同上text/36-fm-building-resilience-into-ci-cd-workflows.txt:279(搜「Health probes」)
可观测集成四条(event correlation)同上text/36-fm-building-resilience-into-ci-cd-workflows.txt:316(搜「Observability integration in CI/CD」) · text/36-fm-building-resilience-into-ci-cd-workflows.txt:335(搜「Event correlation」)
韧性即代码同上text/36-fm-building-resilience-into-ci-cd-workflows.txt:345(搜「resilience as code」)
金融科技案例(MTTR -70%)同上text/36-fm-building-resilience-into-ci-cd-workflows.txt:393(搜「70%」)

Footnotes

  1. 出处:「Principles of resilience engineering」第 16 段(text/32-fm-principles-of-resilience-engineering.txt:16,搜「survival under chaos」)。 ↩

  2. 出处:「Principles of resilience engineering」第 124 段(text/32-fm-principles-of-resilience-engineering.txt:124,搜「hardware will break」)。 ↩

  3. 出处:「Principles of resilience engineering」第 134–152 段(text/32-fm-principles-of-resilience-engineering.txt:134,搜「Anticipation of failure」;text/32-fm-principles-of-resilience-engineering.txt:140,搜「Redundancy and diversity」)。 ↩

  4. 出处:「Principles of resilience engineering」第 162–171 段(text/32-fm-principles-of-resilience-engineering.txt:162,搜「Resistance」)。 ↩

  5. 出处:「Principles of resilience engineering」第 187–213 段(text/32-fm-principles-of-resilience-engineering.txt:190,搜「chaos-ready architecture」;text/32-fm-principles-of-resilience-engineering.txt:197,搜「Stateless microservices」;text/32-fm-principles-of-resilience-engineering.txt:200,搜「SIGTERM」;text/32-fm-principles-of-resilience-engineering.txt:206,搜「liveness and readiness probes」;text/32-fm-principles-of-resilience-engineering.txt:209,搜「active-active or active-passive」;text/32-fm-principles-of-resilience-engineering.txt:213,搜「easier to maintain and evolve」)。 ↩ ↩2

  6. 出处:「Principles of resilience engineering」第 226–242 段(text/32-fm-principles-of-resilience-engineering.txt:229,搜「MTTR」;text/32-fm-principles-of-resilience-engineering.txt:242,搜「less than 10 minutes」)。 ↩

  7. 出处:「Principles of resilience engineering」第 245–278 段(text/32-fm-principles-of-resilience-engineering.txt:264,搜「LitmusChaos」;text/32-fm-principles-of-resilience-engineering.txt:272,搜「35 minutes」)。 ↩

  8. 出处:「Necessity of chaos testing」第 20–29 段(text/33-fm-necessity-of-chaos-testing.txt:20,搜「Static assumptions」;text/33-fm-necessity-of-chaos-testing.txt:29,搜「100% code coverage」)。 ↩

  9. 出处:「Necessity of chaos testing」第 48–67 段(text/33-fm-necessity-of-chaos-testing.txt:48,搜「Goals of chaos testing」;text/33-fm-necessity-of-chaos-testing.txt:55,搜「Expose weaknesses before they become incidents」;text/33-fm-necessity-of-chaos-testing.txt:58,搜「Build confidence in system behavior」;text/33-fm-necessity-of-chaos-testing.txt:61,搜「Validate auto-healing mechanisms」;text/33-fm-necessity-of-chaos-testing.txt:64,搜「Enhance observability and monitoring」;text/33-fm-necessity-of-chaos-testing.txt:67,搜「Foster a culture of learning」)。 ↩

  10. 出处:「Tools like Chaos Monkey and LitmusChaos」第 132–152 段(text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:132,搜「Simian Army, which includes」;text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:136,搜「Latency Monkey」;text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:139,搜「Conformity Monkey」;text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:142,搜「Security Monkey」;text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:145,搜「Chaos Gorilla」;text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:148,搜「Doctor Monkey」;text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:152,搜「engineered chaos」)。 ↩ ↩2

  11. 出处:「Necessity of chaos testing」第 42 段(text/33-fm-necessity-of-chaos-testing.txt:42,搜「Chaos Monkey」)与第 256–262 段(text/33-fm-necessity-of-chaos-testing.txt:262,搜「Simian Army」)。 ↩

  12. 出处:「Necessity of chaos testing」第 77–89 段(text/33-fm-necessity-of-chaos-testing.txt:77,搜「steady state」)。 ↩

  13. 出处:「Necessity of chaos testing」第 45 段(text/33-fm-necessity-of-chaos-testing.txt:45,搜「manage chaos through learning」)。 ↩

  14. 出处:「Necessity of chaos testing」第 110–218 段(text/33-fm-necessity-of-chaos-testing.txt:128,搜「Infrastructure-level chaos」;text/33-fm-necessity-of-chaos-testing.txt:218,搜「Table 11.2」)。 ↩

  15. 出处:「Necessity of chaos testing」第 234–246 段(text/33-fm-necessity-of-chaos-testing.txt:243,搜「alerting thresholds」)。 ↩

  16. 出处:「Tools like Chaos Monkey and LitmusChaos」第 62–109 段(text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:71,搜「terminate_probability」;text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:80,搜「billing」)。 ↩

  17. 出处:「Tools like Chaos Monkey and LitmusChaos」第 31–43 段(text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:31,搜「Service discovery」)。 ↩

  18. 出处:「Tools like Chaos Monkey and LitmusChaos」第 158–168 段(text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:162,搜「CronJobs」)。 ↩

  19. 出处:「Tools like Chaos Monkey and LitmusChaos」第 184–274 段(表 11.3)(text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:207,搜「EC2 APIs, Auto Scaling Groups」;text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:225,搜「Kubectl commands」;text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:238,搜「Docker Swarm」;text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:243,搜「Docker API」;text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:261,搜「Custom scripts with SSH」;text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:274,搜「Table 11.3」)。 ↩ ↩2

  20. 出处:「Tools like Chaos Monkey and LitmusChaos」第 280–283 段(text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:283,搜「YAML manifests」)。 ↩

  21. 出处:「Tools like Chaos Monkey and LitmusChaos」第 325–408 段(text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:370,搜「TOTAL_CHAOS_DURATION」;text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:382,搜「FORCE」)。 ↩

  22. 出处:「Tools like Chaos Monkey and LitmusChaos」第 426–537 段(text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:449,搜「Node Restart」;text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:537,搜「Argo Workflows」)。 ↩

  23. 出处:「Tools like Chaos Monkey and LitmusChaos」第 589–748 段(text/34-fm-tools-like-chaos-monkey-and-litmuschaos.txt:748,搜「Table 11.5」)。 ↩

  24. 出处:「Designing systems for graceful degradation」第 13–52 段(text/35-fm-designing-systems-for-graceful-degradation.txt:16,搜「reduce playback quality」;text/35-fm-designing-systems-for-graceful-degradation.txt:52,搜「limited uptime」)。 ↩

  25. 出处:「Designing systems for graceful degradation」第 114–326 段(text/35-fm-designing-systems-for-graceful-degradation.txt:114,搜「failure_count」;text/35-fm-designing-systems-for-graceful-degradation.txt:139,搜「Retry 1」;text/35-fm-designing-systems-for-graceful-degradation.txt:280,搜「bulkhead」;text/35-fm-designing-systems-for-graceful-degradation.txt:300,搜「RabbitMQ, Kafka」)。 ↩

  26. 出处:「Designing systems for graceful degradation」第 332–366 段(text/35-fm-designing-systems-for-graceful-degradation.txt:356,搜「40%」;text/35-fm-designing-systems-for-graceful-degradation.txt:362,搜「99.98%」)。 ↩

  27. 出处:「Designing systems for graceful degradation」第 369–391 段(text/35-fm-designing-systems-for-graceful-degradation.txt:385,搜「stack traces」)。 ↩

  28. 出处:「Building resilience into CI/CD workflows」第 54–165 段(text/36-fm-building-resilience-into-ci-cd-workflows.txt:108,搜「Resilience test」)。 ↩

  29. 出处:「Building resilience into CI/CD workflows」第 189–266 段(text/36-fm-building-resilience-into-ci-cd-workflows.txt:234,搜「litmusctl-action」)。 ↩

  30. 出处:「Building resilience into CI/CD workflows」第 316–339 段(text/36-fm-building-resilience-into-ci-cd-workflows.txt:316,搜「Observability integration in CI/CD」;text/36-fm-building-resilience-into-ci-cd-workflows.txt:326,搜「Dashboards」;text/36-fm-building-resilience-into-ci-cd-workflows.txt:329,搜「Distributed tracing」;text/36-fm-building-resilience-into-ci-cd-workflows.txt:332,搜「Alerting」;text/36-fm-building-resilience-into-ci-cd-workflows.txt:335,搜「Event correlation」)。 ↩ ↩2

  31. 出处:「Building resilience into CI/CD workflows」第 275–313 段(text/36-fm-building-resilience-into-ci-cd-workflows.txt:282,搜「Error thresholds」;text/36-fm-building-resilience-into-ci-cd-workflows.txt:288,搜「Feature flags」)。 ↩

  32. 出处:「Building resilience into CI/CD workflows」第 342–362 段(text/36-fm-building-resilience-into-ci-cd-workflows.txt:345,搜「resilience as code」)。 ↩

  33. 出处:「Building resilience into CI/CD workflows」第 365–403 段(text/36-fm-building-resilience-into-ci-cd-workflows.txt:393,搜「70%」)。 ↩

  34. 出处:「Building resilience into CI/CD workflows」第 413–429 段(text/36-fm-building-resilience-into-ci-cd-workflows.txt:413,搜「Shift-left」;text/36-fm-building-resilience-into-ci-cd-workflows.txt:428,搜「rotate experiments」)。 ↩

监控、仪表盘与可观测性 — 让系统自己开口说话

Previous Page

为自己代码值班 — 可持续的待命体系与事故学习

Next Page

On this page

韧性工程与混沌测试 — 给系统打疫苗,而不是祈祷不生病1. 主线例子:一次有剧本的「搞破坏」2. 韧性 vs 可靠性:从「不生病」到「病了能扛」为故障而设计:把原则落到代码上的五条实践3. 混沌测试:传统测试补不上的那一块4. 两代工具:Chaos Monkey 与 LitmusChaos5. 优雅降级:七种设计模式6. 韧性进 CI/CD 流水线:每次提交都过一次鬼门关7. 边界与局限8. 可带走的9. 原文地图Footnotes