HelloWorld 故障注入教程

做 HelloWorld 故障注入，先把目标和假设写清楚，限定影响范围并准备回滚方案，搭建可观测的监控与日志，先做小规模试验再放大，按顺序注入网络延迟、丢包、CPU/内存占用、磁盘故障与进程崩溃等，持续记录指标与用户感知，恢复后整理复盘与改进清单。

为什么要在 HelloWorld 上做故障注入

听起来像是在故意找麻烦，但其实目的很简单：验证系统在真坏掉的时候会怎样反应。HelloWorld 是最小可运行的示例，适合快速验证注入手法、度量采集链路和回滚流程，避免在生产环境直接试错。

先讲清楚几个关键概念（费曼式解释）

• 故障注入（Fault Injection）：有计划地在系统中制造错误或异常，以观察系统行为和验证弹性。
• 假设（Hypothesis）：在实验前先写出预期，例如“10% 丢包会导致请求超时增长但不致崩溃”。
• 观测（Observability）：用指标、日志和追踪来衡量注入前后的变化。
• Blast radius（影响范围）：故障影响的范围，越小越安全，实验初期应尽量最小化。
• 回滚与安全阀：能自动或手动撤销注入并恢复服务，是必须的保障。

准备工作：环境与工具

先说最少需要准备的东西：

• 一个可运行的 HelloWorld 服务（可以是一个简单的 HTTP 服务）。
• 测试客户端，用来发请求并记录响应时间与状态码。
• 监控系统（例如 Prometheus + Grafana）和日志系统（如 ELK 或 Loki），至少能看到请求率、错误率、延迟分布和主机/容器指标。
• 故障注入工具：可选项很多，下表简单对比常用工具，帮你选适合场景的。

HelloWorld 实战：从零到一的故障注入流程

下面用一个最简单的场景来讲清楚流程：本地或测试集群有一个 HelloWorld HTTP 服务，端点 /hello 返回 200 和固定延迟。目标是验证服务在网络延迟和 CPU 占用上如何表现。

第一步：写好实验假设

• 假设 A：在 100ms 恒定网络延迟下，P95 响应时间 <= 300ms，错误率 < 1%。
• 假设 B：CPU 占用 80% 时，吞吐量下降不超过 20%。

第二步：采 Baseline（基线）数据

不要跳过这步。先运行负载测试 5-10 分钟，收集：

• 请求率（RPS）、响应时间分位（P50/P95/P99）、错误率。
• 主机或容器的 CPU/内存/磁盘指标。
• 应用日志和追踪样本。

记录这些数值，作为判断故障影响的参考线。

第三步：小范围注入（网络延迟示例）

如果是在单机或 VM，可以用 tc（Linux traffic control）来注入延迟。示例命令：

注：以下命令需以 root 或 sudo 执行，操作前确认目标机器与网络接口（如 eth0）。

设置 100ms 延迟并加 10ms 抖动：

tc qdisc add dev eth0 root netem delay 100ms 10ms

取消规则：

tc qdisc del dev eth0 root netem

步骤建议：

• 先在单个测试实例上执行，观察客户端请求变化。
• 如果服务部署为容器，先进入容器内部执行 tc；或者对宿主机接口做流量控制并用 iptables 限定目标端口。
• 记录注入前后指标，比较与假设。

第四步：注入 CPU/内存压力示例

最简单的 CPU 占用方式是在目标容器或主机上运行一个紧密循环程序。示例（单核占用）：

yes > /dev/null &（注意这个会占用一个 CPU 核心）

更可控的办法是用 stress 或 stress-ng：

stress -c 2 -t 60s（占用 2 个逻辑 CPU，持续 60 秒）

观察期间：

• 关注响应时间曲线是否出现尾部延迟上升。
• 监控错误率和请求超时。
• 如果系统有自动伸缩（autoscaling），观察扩缩容触发条件与速度。

第五步：在 Kubernetes 上的做法

如果 HelloWorld 部署在 K8s，推荐使用 Chaos Mesh 或 LitmusChaos 来管理混沌实验。以 Chaos Mesh 为例，网络延迟 CRD 可能长这样（示意）：

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
name: hello-network-delay
spec:
action: delay
mode: one
selector:
namespaces: [ "default" ]
labelSelectors: { "app": "hello" }
delay: '100ms'

（实际 CRD 字段请参考你所用版本文档；上面仅示意）

操作流程：

• 先在命名空间中创建实验，验证 CRD 是否被正确接受。
• 应用实验并观察 Pod、Service 的指标。
• 若出现无法接受的问题，删除 CR 并等待恢复。

如何度量与判断结果

度量要分层次：用户层感知、服务层指标、平台层资源。

• 用户层：错误率、请求失败原因、响应时间（特别是 P95/P99）。
• 服务层：应用日志、队列长度、连接数、后端依赖状态。
• 平台层：CPU、内存、网络接口速率、磁盘 I/O 延迟。

把注入前后的曲线放在一起看，重点关注尾部延迟（P95/P99）和错误突增。如果系统出现不可恢复的崩溃，说明假设不成立或容错不足。

安全措施与回滚策略

• 限制 Blast radius：开始时只作用于一个实例或一小部分流量。
• 设置安全阀：例如当错误率超过阈值时自动撤销实验（可用脚本或工具链实现）。
• 备份与快照：在做数据库相关或磁盘注入之前，先做快照或备份。
• 手动回滚：始终保留一组可以快速执行的回滚命令（例如删除 tc 规则、停止 stress 进程、删除 Chaos CR）。

常见故障类型与实践建议

• 网络延迟与丢包：先模拟轻微延迟，观察重试机制与超时设置是否合理。注意客户端的重试不要引发雪崩。
• 依赖服务不可用：把依赖替换为延迟响应或 5xx，观察熔断器与降级逻辑。
• CPU/内存压力：模拟长期高负载，验证资源限制（requests/limits）与自动伸缩行为。
• 磁盘耗尽：用文件写满磁盘来测试日志旋转与持久化策略，注意这类实验风险高，优先在非关键环境进行。
• 时间偏移（时钟漂移）：测试分布式系统对时间依赖的健壮性，例如 token 超时、缓存失效。

示例：一个逐步实验计划（可复制）

• 阶段 0：核对监控与报警是否正常，准备回滚脚本。
• 阶段 1（0-5 分钟）：在一台实例注入 50ms 延迟，观察指标变动。
• 阶段 2（5-15 分钟）：扩大到 20% 实例，监测错误率与响应分布。
• 阶段 3（15-30 分钟）：在流量峰值时段重复上述步骤，观察系统在真实负载下的表现。
• 阶段 4：做一次短时（1 分钟）CPU 压力测试，观察伸缩与降级策略。
• 阶段 5：汇总数据，判断是否满足假设，列出改进项并执行修复计划。

常见问题与排查技巧（边想边写的那种）

• 如果注入后没有任何指标变化，先确认注入命令是否作用在对的网络接口或容器上。
• 如果错误率骤增，优先判断是否触发了级联故障（例如后端数据库负载暴涨）。
• 看到延迟上升但错误率不变，检查客户端超时设置是否过长，可能隐藏了用户感知。
• 实验中出现无法恢复的情况，记录所有操作步骤，尽快回滚并在隔离环境重现定位。

让实验更可信的小技巧

• 多跑几轮，每轮改变一个变量（单因子试验），这样能更清楚地归因变化。
• 使用相同的负载脚本与数据种子，保证不同轮次可比。
• 同时收集应用追踪，找到请求在系统中的被阻塞点。
• 把复现步骤写成文档或自动化脚本，方便复盘与审计。

最后的想法（自然收尾）

做故障注入并不是为了“把系统打坏”，而是为了在可控范围内发现薄弱点并改进。HelloWorld 是最安全的练习场：把复杂的手法拆成小步骤，先验证工具链和观测能力，再把成熟的方法推广到更关键的服务上。做的时候别太追求完美，记录每一次失败和收获，长期下来系统会稳得多。