claude-skills 混沌工程实战指南基础设施故障注入的六种核心手段【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills本文是 claude-skills 仓库中 chaos-engineer 技能包的深度拆解聚焦其参考文档 infrastructure-chaos.md 所承载的基础设施层混沌实验能力。你将掌握网络延迟注入、可用区AZ故障模拟、服务器资源耗尽、容器级混沌、DNS 失效与证书过期等六大故障注入手段的完整代码实现与工具选型并能将其纳入混沌实验的安全边界steady state 校验、blast radius 控制、快速回滚中落地执行。一、基础设施混沌实验在整个技能包中的定位在 claude-skills 项目中chaos-engineer 技能版本 v1.1.0领域 devops负责设计混沌实验、构建故障注入框架、组织 game day 演练。它的参考文档体系按故障面拆分为四份参考文档覆盖范围experiment-design.md实验假设、steady state、blast radius、安全机制infrastructure-chaos.md服务器、网络、可用区、地域级故障本文主题kubernetes-chaos.mdPod、节点、Litmus、Chaos Mesh 实验game-days.mdGame Day 规划、执行与复盘chaos-tools.mdChaos Monkey、Gremlin、Pumba、CI/CD 集成从该技能的核心工作流System Analysis → Experiment Design → Execute Chaos → Learn Improve → Automate可以看出基础设施故障注入属于Execute Chaos阶段的具体执行层它解决的是用什么工具、以什么代码/命令在物理机、云环境、容器层面制造故障的问题而实验的假设与安全边界则由 experiment-design.md 约束。因此本文每个工具示例本质上都应嵌套在一个先验稳态、再注入、后回滚的实验流程中运行。二、网络延迟注入Toxiproxy 代理故障注入网络故障延迟、丢包、带宽限制、超时是分布式系统最常被低估的失效模式。Toxiproxy 的思路是在应用与下游依赖之间插入一个 TCP 代理层通过对代理附加toxic毒性来改变流量行为且只影响经过该代理的流量天然具备最小 blast radius。2.1 ToxiproxyClient 客户端封装infrastructure-chaos.md给出了一个可直接落地的 Python 客户端# 使用 toxiproxy 进行网络混沌 import requests from typing import Literal class ToxiproxyClient: def __init__(self, host: str localhost:8474): self.base_url fhttp://{host} def create_proxy(self, name: str, listen: str, upstream: str): 创建代理以注入故障。 response requests.post(f{self.base_url}/proxies, json{ name: name, listen: listen, upstream: upstream, enabled: True }) return response.json() def add_latency(self, proxy: str, latency_ms: int, jitter_ms: int 0): 添加延迟毒性。 return requests.post( f{self.base_url}/proxies/{proxy}/toxics, json{ name: latency, type: latency, attributes: { latency: latency_ms, jitter: jitter_ms } } ) def add_bandwidth_limit(self, proxy: str, rate_kb: int): 限制带宽。 return requests.post( f{self.base_url}/proxies/{proxy}/toxics, json{ name: bandwidth, type: bandwidth, attributes: {rate: rate_kb} } ) def add_timeout(self, proxy: str, timeout_ms: int): 添加连接超时。 return requests.post( f{self.base_url}/proxies/{proxy}/toxics, json{ name: timeout, type: timeout, attributes: {timeout: timeout_ms} } )关键设计点解读listen与upstream分离listen是代理对外监听的地址客户端连接它upstream是真实下游地址代理转发目标。应用无需感知混沌的存在只需将配置中的下游地址指向代理的listen端口。enabled: true代理创建后立即生效可在创建阶段就先建立好所有代理再按实验节奏逐条附加 toxic。type与attributes一一对应latency接受latency基础延迟毫秒与jitter抖动毫秒bandwidth接受rateKB/stimeout接受timeout毫秒。这些即 Toxiproxy HTTP API/proxies/{proxy}/toxics的字段契约。抖动jitter的重要性真实网络延迟不是恒定值加入 jitter 才能复现偶发卡顿而非均匀变慢更贴近真实故障形态。2.2 典型使用流程给数据库注入 200ms 延迟toxiproxy ToxiproxyClient() # 创建指向数据库的代理 toxiproxy.create_proxy( namepostgres, listen0.0.0.0:5433, upstreampostgres:5432 ) # 注入 200ms 延迟 50ms 抖动 toxiproxy.add_latency(postgres, latency_ms200, jitter_ms50)2.3 配套的 CLI 实操路径仓库 SKILL.md 中提供了对应的命令行等价流程便于在无法运行 Python 代码的环境中使用# 启动 toxiproxy 服务与你的服务并行运行 toxiproxy-server # 为下游依赖创建代理 toxiproxy-cli create -l 0.0.0.0:22222 -u downstream-db:5432 db-proxy # 注入 300ms 延迟 10% 抖动 —— blast radius仅该代理 toxiproxy-cli toxic add db-proxy -t latency -a latency300 -a jitter30 # 在此运行你的压测 / 观察指标 ... # 移除 toxic 恢复正常行为 toxiproxy-cli toxic remove db-proxy -n latency_downstream可见 Python API 与 CLI 是同一套 toxic 语义的两种形态CLI 的-l/-u对应create_proxy的listen/upstream-a latency300 -a jitter30对应add_latency的latency_ms/jitter_ms。toxiproxy 同时在 chaos-tools.md 的快速参考表中被列为Network proxy chaos / Docker-API 集成的首选工具。三、AWS 可用区AZ故障模拟云厂商将单一数据中心抽象为可用区AZ 级故障整个可用区网络不可达、电源中断等是云原生架构必须演练的失效模式。infrastructure-chaos.md提供了基于 boto3 的 AWSChaosSimulator通过终止指定 AZ 内实例 从负载均衡摘除该 AZ 目标两步完成模拟。import boto3 from datetime import datetime, timedelta class AWSChaosSimulator: def __init__(self, region: str): self.ec2 boto3.client(ec2, region_nameregion) self.asg boto3.client(autoscaling, region_nameregion) self.elb boto3.client(elbv2, region_nameregion) def simulate_az_failure( self, availability_zone: str, asg_name: str, duration_minutes: int 10 ): 通过终止指定 AZ 中的实例来模拟 AZ 故障。 自动伸缩组会在其他 AZ 中启动替代实例。 # 找到目标 AZ 中的实例 instances self.ec2.describe_instances(Filters[ {Name: tag:aws:autoscaling:groupName, Values: [asg_name]}, {Name: availability-zone, Values: [availability_zone]}, {Name: instance-state-name, Values: [running]} ]) instance_ids [ i[InstanceId] for r in instances[Reservations] for i in r[Instances] ] if not instance_ids: return {status: no_instances, instances: []} # 挂起 AZ 相关的伸缩活动 self.asg.suspend_processes( AutoScalingGroupNameasg_name, ScalingProcesses[AZRebalance] ) # 终止实例以模拟 AZ 故障 self.ec2.terminate_instances(InstanceIdsinstance_ids) return { status: simulated, availability_zone: availability_zone, terminated_instances: instance_ids, recovery_time: datetime.now() timedelta(minutesduration_minutes) } def drain_az_from_load_balancer( self, target_group_arn: str, availability_zone: str ): 从负载均衡移除 AZ模拟区域故障。 # 获取当前目标健康状态 health self.elb.describe_target_health( TargetGroupArntarget_group_arn ) # 找到该 AZ 中的目标 targets_to_deregister [] for target in health[TargetHealthDescriptions]: # 获取实例详情 instance self.ec2.describe_instances( InstanceIds[target[Target][Id]] ) if instance[Reservations][0][Instances][0][Placement][AvailabilityZone] availability_zone: targets_to_deregister.append(target[Target]) # 注销目标 if targets_to_deregister: self.elb.deregister_targets( TargetGroupArntarget_group_arn, Targetstargets_to_deregister ) return { deregistered_targets: len(targets_to_deregister), availability_zone: availability_zone }这段代码背后有三个值得深入理解的工程细节实例发现依赖 ASG 标签tag:aws:autoscaling:groupName是 Auto Scaling 自动打上的标签用它过滤才能精准锁定目标 ASG 的实例同时用availability-zone与instance-state-namerunning双重过滤确保只触碰正在运行的指定 AZ 实例。挂起AZRebalance进程ASG 默认会执行 AZ 再平衡将实例均匀分布到各 AZ。若在注入故障前不挂起该进程ASG 可能立刻在其他 AZ 补位导致故障窗口过短、观察不到真实影响。这是让实验可观察的关键操作。drain_az_from_load_balancer是更安全的替代方案相比于直接 terminate 实例从目标组注销该 AZ 的全部目标可以在不销毁资源的情况下验证流量绕过该 AZ 后系统是否仍正常适合验证读多写少的无状态服务。配套演练场景来自 game-days.md 的 game day 模板通常会设计RDS 主实例强制故障转移脚本作为 AZ 级故障的数据库变体aws rds reboot-db-instance \ --db-instance-identifier staging-primary \ --force-failover并设定故障转移至备用实例 2 分钟、无数据丢失、告警正确触发等成功标准——这与simulate_az_failure返回体中的recovery_time字段形成呼应前者是云 API 层的模拟后者是衡量恢复目标RTO的观测锚点。四、服务器资源耗尽stress-ng 与 iperf3当故障面从网络/区域下沉到单机资源时stress-ng是 Linux 上最常用的压力工具iperf3则用于网络带宽饱和测试。infrastructure-chaos.md给出的脚本覆盖了 CPU、内存、磁盘 I/O 与网络四条资源赛道#!/bin/bash # 使用 stress-ng 进行 CPU 压力测试 # 安装 stress-ng sudo apt-get install -y stress-ng # CPU 压力 - 使用 80% 可用核心持续 5 分钟 stress-ng --cpu $(nproc --all) --cpu-load 80 --timeout 5m # 内存压力 - 消耗可用内存的 70% TOTAL_MEM_MB$(free -m | awk NR2{print $2}) STRESS_MEM_MB$((TOTAL_MEM_MB * 70 / 100)) stress-ng --vm 1 --vm-bytes ${STRESS_MEM_MB}M --timeout 5m # 磁盘 I/O 压力 - 4 个 worker 执行顺序写入 stress-ng --hdd 4 --hdd-bytes 1G --timeout 5m # 网络带宽饱和 # 使用 iperf3 饱和网络 iperf3 -c target-server -t 300 -P 10 # 10 个并行流持续 5 分钟逐条参数解读--cpu $(nproc --all) --cpu-load 80nproc --all动态获取所有逻辑核心数--cpu-load 80让每个 CPU worker 只占用 80% 负载。之所以不写死 100%是因为 100% 负载可能立即触发云监控的宿主机级告警甚至被平台限流且缺乏观察梯度80% 是文档作者验证过的明显压力但可观测的典型值。内存计算表达式free -m | awk NR2{print $2}提取free -m第二行Mem 行的总内存MB再乘以 70% 得到注入量。注意--vm 1表示 1 个虚拟内存 worker配合--vm-bytes XM决定单 worker 占用。--hdd 4 --hdd-bytes 1G4 个 worker 各写 1GB模拟顺序写入型 I/O 压力适合暴露文件系统缓存、存储限流等问题。iperf3 -c target-server -t 300 -P 10客户端模式连接目标服务器-t 300持续 300 秒-P 10开 10 个并行流。target-server需预先以iperf3 -s服务端模式运行。执行纪律与技能包安全清单对齐资源耗尽实验的成功不是看系统是否扛得住而是验证资源接近耗尽时SLO 是否仍被保障、熔断与降级是否如期触发。仓库 SKILL.md 的安全清单明确要求实验前必须定义并验证稳态基线指标如 p99 延迟 200ms、错误率 0.1%、把 blast radius 控制在最小范围、且回滚路径必须 ≤ 30 秒。换言之--timeout 5m的自动过期只是兜底实验设计阶段仍需在 experiment-design.md 中明确最大错误率超过 5% 即自动回滚这类触发条件。五、Docker 容器混沌Pumba 故障注入Pumba 是面向 Docker 的混沌工具可以 kill、暂停、注入网络损伤netem、停止容器。infrastructure-chaos.md给出了五类最常见的容器故障注入命令#!/bin/bash # Pumba - Docker 混沌测试 # 每 30 秒随机 kill 一个容器 pumba --interval 30s kill --signal SIGKILL re2:^myapp # 暂停容器 15 秒后恢复 pumba pause --duration 15s myapp-container # 给容器添加网络延迟 pumba netem \ --duration 5m \ --interface eth0 \ delay \ --time 300 \ --jitter 50 \ myapp-container # 丢包 - 丢弃 20% 的数据包 pumba netem \ --duration 5m \ loss \ --percent 20 \ myapp-container # 限制带宽为 1Mbps pumba netem \ --duration 5m \ rate \ --rate 1mbit \ myapp-container # 停止所有匹配模式的生产容器持续 2 分钟 pumba stop --duration 2m re2:^production-.*各命令的语义与使用要点pumba kill --signal SIGKILL re2:^myapp核心杀手锏。re2:前缀表示使用 RE2 正则匹配容器名--interval 30s让 Pumba 周期性执行实现持续随机击杀的 Chaos Monkey 式行为。SIGKILL 是模拟硬崩溃无优雅退出若想模拟优雅关闭可改--signal SIGTERM或--signal SIGSTOP。pumba pause --duration 15s利用docker pause的 cgroup 冻结机制暂停容器进程但容器依然存活——这能复现进程无响应但端口存活的半死状态与 kill进程消失形成互补。pumba netem ... delay --time 300 --jitter 50直接调用 Linux 内核tc netemNetwork Emulator--time/--jitter单位均为毫秒--interface eth0指定生效网卡。pumba netem ... loss --percent 20模拟丢包。与 toxiproxy 相比netem 在容器网络栈层面生效适合验证服务对丢包的 TCP 重传、超时重试行为而 toxiproxy 在应用与依赖之间更贴近真实客户端视角。二者在 chaos-tools.md 中被列为两种互补的网络混沌手段Toxiproxy代理型Pumba容器 CLI 型。pumba stop --duration 2m re2:^production-.*批量停止一组匹配容器用于模拟整个服务的实例全部下线的故障。容器混沌是 kubernetes-chaos 实验的前置类比Pumba 的kill对应 kubernetes-chaos.md 中 Litmus 的pod-delete实验每 20 秒删除一个 Pod、最多影响 33% 副本netem 对应 Chaos Mesh 的NetworkChaos。单机 Docker 环境下先验证注入手法再迁移到 K8s 环境用声明式 CRD 管理是平滑的能力演进路径。六、DNS 失效模拟故障注入到域名解析层DNS 故障域名解析失败、解析延迟影响所有依赖外部域名的服务调用。infrastructure-chaos.md提供了两条路径基于/etc/hosts的域名封禁以及基于 dnsmasq 的解析延迟。6.1 基于 /etc/hosts 的域名封禁# 使用 dnsmasq 或编辑 /etc/hosts 进行 DNS 混沌 import subprocess import time from contextlib import contextmanager class DNSChaos: staticmethod contextmanager def block_domain(domain: str, duration_seconds: int 60): 通过指向 localhost 来阻止域名的 DNS 解析。 try: # 向 /etc/hosts 添加条目 subprocess.run([ sudo, sh, -c, fecho 127.0.0.1 {domain} /etc/hosts ], checkTrue) print(fBlocked DNS for {domain}) yield finally: # 等待持续时间 time.sleep(duration_seconds) # 从 /etc/hosts 移除条目 subprocess.run([ sudo, sed, -i, f/127.0.0.1 {domain}/d, /etc/hosts ], checkTrue) print(fRestored DNS for {domain}) staticmethod def add_dns_latency(domain: str, latency_ms: int): 使用 dnsmasq 给 DNS 查询添加延迟。 config f # 添加到 /etc/dnsmasq.conf address/{domain}/127.0.0.1 min-cache-ttl0 # 带延迟重启 dnsmasq return config # 使用方式 with DNSChaos.block_domain(api.external-service.com, duration_seconds120): # DNS 被阻断期间运行测试 print(DNS blocked - testing fallback behavior)这段代码有两个值得学习的工程细节contextmanager保证恢复无论yield之后的业务代码是否抛异常finally中的sed -i都会移除/etc/hosts中的注入条目从语法层面保证注入必恢复。这正是混沌实验对回滚纪律的要求——恢复动作不能依赖人工记忆。127.0.0.1的妙用将域名指向 localhost模拟的是域名可解析但连接被拒/超时的场景比让解析直接 NXDOMAIN 更接近真实故障因为多数应用的连接池里已缓存了旧 IP。若想模拟解析失败可改为写入一个不存在的 IP 并关闭本地监听。6.2 基于 dnsmasq 的解析延迟add_dns_latency方法展示了 dnsmasq 配置的要点address/{domain}/127.0.0.1将指定域名固定解析到本地min-cache-ttl0关闭缓存 TTL使每次查询都真实经过解析链路——这样配合流量整形工具如 tc即可构造每次 DNS 查询都变慢的故障。该方法返回的是待写入/etc/dnsmasq.conf的配置片段实际使用需配合 dnsmasq 重启属于配置注入型的辅助手段。注修改/etc/hosts与 dnsmasq 配置均需 root 权限且会影响目标主机上所有进程的 DNS 行为blast radius 是整机级别的。更细粒度的 DNS 故障仅影响指定 Pod应使用 kubernetes-chaos.md 中的 Chaos MeshDNSChaosaction: random随机返回错误、patterns精确匹配域名。七、证书过期模拟构造已过期的 TLS 证书TLS 证书过期是没人主动触发、但一定会在某天发生的经典故障。infrastructure-chaos.md提供了一个零依赖外部证书签发机构的方案用 Pythoncryptography库在本地生成一张回溯时间构造的已过期自签名证书。from datetime import datetime, timedelta from cryptography import x509 from cryptography.x509.oid import NameOID from cryptography.hazmat.primitives import hashes, serialization from cryptography.hazmat.primitives.asymmetric import rsa def create_expired_certificate( common_name: str, expired_days_ago: int 1 ) - tuple[bytes, bytes]: 为混沌测试创建一张已过期的 TLS 证书。 返回 (certificate_pem, private_key_pem) # 生成私钥 private_key rsa.generate_private_key( public_exponent65537, key_size2048 ) # 证书有效期从 365 天前到 expired_days_ago 天前 not_valid_before datetime.utcnow() - timedelta(days365) not_valid_after datetime.utcnow() - timedelta(daysexpired_days_ago) subject issuer x509.Name([ x509.NameAttribute(NameOID.COMMON_NAME, common_name) ]) cert x509.CertificateBuilder().subject_name( subject ).issuer_name( issuer ).public_key( private_key.public_key() ).serial_number( x509.random_serial_number() ).not_valid_before( not_valid_before ).not_valid_after( not_valid_after ).sign(private_key, hashes.SHA256()) # 序列化为 PEM cert_pem cert.public_bytes(serialization.Encoding.PEM) key_pem private_key.private_bytes( encodingserialization.Encoding.PEM, formatserialization.PrivateFormat.PKCS8, encryption_algorithmserialization.NoEncryption() ) return cert_pem, key_pem代码要点时间窗口设计not_valid_before设为 365 天前证书合法签发not_valid_after设为expired_days_ago天前默认 1 天前过期。这样一个看起来内容完全正常的证书恰好处于过期状态可以精准复现生产环境最常见的证书过期事故而不需要真的等待一张证书到期。自签名即可满足测试需求混沌测试关心的是TLS 握手因证书过期失败这一行为服务端或客户端通常只需验证过期状态因此 issuersubject 的自签名证书足够无需内网 CA。返回格式为 PEM 字节对调用方可将cert_pem写入服务器证书路径、key_pem写入私钥路径然后重启目标服务触发握手失败或直接喂给测试中的 TLS 客户端校验逻辑。应用场景把它与 experiment-design.md 中的实验模板结合——例如验证证书过期时告警是否在阈值时间内触发、证书轮换脚本是否自动修复、客户端是否给出可读的错误信息而非无限重试。八、基础设施故障注入速查表infrastructure-chaos.md末尾提供了跨章节的速查表这里原样继承并补充适用场景方便实验设计时快速选型故障类型工具命令/方法注入面推荐使用场景网络延迟toxiproxyadd_latency(proxy, ms)/ CLItoxic add ... -t latency应用↔依赖之间验证超时、重试、熔断丢包toxiproxy / pumbaloss --percent 20代理层 / 容器网络栈验证 TCP 重传与降级逻辑AZ 故障AWS API (boto3)simulate_az_failure(az, asg)/drain_az_from_load_balancer(...)云资源验证多 AZ 冗余与 ASG 自愈CPU 压力stress-ng--cpu N --cpu-load 80主机验证资源配额与弹性伸缩内存耗尽stress-ng--vm 1 --vm-bytes XM主机验证 OOM 行为与内存监控容器击杀pumbakill --signal SIGKILL容器验证容器自愈与编排恢复DNS 故障/etc/hosts / dnsmasq将域名指向 127.0.0.1主机 DNS验证域名解析降级与缓存策略证书过期Python cryptography生成回溯时间的过期证书TLS 层验证证书轮换与过期告警该表与 chaos-tools.md 末尾的工具-场景-集成方式速查表Chaos Monkey→AWS ASG、Gremlin→API/Web UI、Litmus→Kubectl/Helm、Chaos Mesh→CRDs、Toxiproxy→Docker/API、Pumba→Docker CLI形成两张互补的选型视图前者回答注入什么故障后者回答用什么平台工具。九、把故障注入放进安全边界完整实验的执行纪律基础设施混沌的价值不在于把系统弄坏而在于在受控范围内验证系统对故障的可预期反应。因此本文所有工具都应服务于一个由 experiment-design.md 定义、并被仓库 SKILL.md 安全清单强化的执行框架稳态优先Steady state first注入前先确认基线指标错误率 0.1%、P99 延迟 500ms 等达标否则实验结论无效。最小 blast radius优先选择代理层注入toxiproxy 只影响单条链路、单实例/单 AZ、PODS_AFFECTED_PERC式百分比控制在生产环境突破 10% 流量必须同时具备 feature flag 与自动回滚这是 experiment-design.md 中BlastRadiusConfig.validate()硬编码的校验规则。自动化回滚 ≤ 30 秒每个注入手段都要有等价的反操作——toxiproxy 的toxic remove、pumba 的--duration自动恢复、/etc/hosts的sed -i清理、ASG 的进程恢复——并在实验开始前演练一遍回滚路径。单变量原则一次只注入一种故障如只加延迟不改带宽直到系统行为被充分理解。闭环Close the loop每次实验都必须产出书面学习总结与至少一项跟踪改进项可参照 game-days.md 的 Post-Game Report 模板What Went Well / What Didnt / Action Items组织复盘。十、延伸阅读chaos-engineer 技能总览核心工作流、安全清单、Litmus pod-delete 完整实验示例、toxiproxy CLI 示例与 Chaos Monkey 配置。混沌实验设计假设模板、blast radius 分级与自动回滚触发器。混沌工具与自动化Chaos Monkey、Gremlin API 客户端、GitHub Actions / Jenkins 集成。Kubernetes 混沌Litmus、Chaos Mesh、节点 drain 与 HPA 弹性测试。Game Day 规划与执行演练模板、观察记录与复盘报告。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 claude-skills 混沌工程实战指南：基础设施故障注入的六种核心手段
claude-skills 混沌工程实战指南基础设施故障注入的六种核心手段【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills本文是 claude-skills 仓库中 chaos-engineer 技能包的深度拆解聚焦其参考文档 infrastructure-chaos.md 所承载的基础设施层混沌实验能力。你将掌握网络延迟注入、可用区AZ故障模拟、服务器资源耗尽、容器级混沌、DNS 失效与证书过期等六大故障注入手段的完整代码实现与工具选型并能将其纳入混沌实验的安全边界steady state 校验、blast radius 控制、快速回滚中落地执行。一、基础设施混沌实验在整个技能包中的定位在 claude-skills 项目中chaos-engineer 技能版本 v1.1.0领域 devops负责设计混沌实验、构建故障注入框架、组织 game day 演练。它的参考文档体系按故障面拆分为四份参考文档覆盖范围experiment-design.md实验假设、steady state、blast radius、安全机制infrastructure-chaos.md服务器、网络、可用区、地域级故障本文主题kubernetes-chaos.mdPod、节点、Litmus、Chaos Mesh 实验game-days.mdGame Day 规划、执行与复盘chaos-tools.mdChaos Monkey、Gremlin、Pumba、CI/CD 集成从该技能的核心工作流System Analysis → Experiment Design → Execute Chaos → Learn Improve → Automate可以看出基础设施故障注入属于Execute Chaos阶段的具体执行层它解决的是用什么工具、以什么代码/命令在物理机、云环境、容器层面制造故障的问题而实验的假设与安全边界则由 experiment-design.md 约束。因此本文每个工具示例本质上都应嵌套在一个先验稳态、再注入、后回滚的实验流程中运行。二、网络延迟注入Toxiproxy 代理故障注入网络故障延迟、丢包、带宽限制、超时是分布式系统最常被低估的失效模式。Toxiproxy 的思路是在应用与下游依赖之间插入一个 TCP 代理层通过对代理附加toxic毒性来改变流量行为且只影响经过该代理的流量天然具备最小 blast radius。2.1 ToxiproxyClient 客户端封装infrastructure-chaos.md给出了一个可直接落地的 Python 客户端# 使用 toxiproxy 进行网络混沌 import requests from typing import Literal class ToxiproxyClient: def __init__(self, host: str localhost:8474): self.base_url fhttp://{host} def create_proxy(self, name: str, listen: str, upstream: str): 创建代理以注入故障。 response requests.post(f{self.base_url}/proxies, json{ name: name, listen: listen, upstream: upstream, enabled: True }) return response.json() def add_latency(self, proxy: str, latency_ms: int, jitter_ms: int 0): 添加延迟毒性。 return requests.post( f{self.base_url}/proxies/{proxy}/toxics, json{ name: latency, type: latency, attributes: { latency: latency_ms, jitter: jitter_ms } } ) def add_bandwidth_limit(self, proxy: str, rate_kb: int): 限制带宽。 return requests.post( f{self.base_url}/proxies/{proxy}/toxics, json{ name: bandwidth, type: bandwidth, attributes: {rate: rate_kb} } ) def add_timeout(self, proxy: str, timeout_ms: int): 添加连接超时。 return requests.post( f{self.base_url}/proxies/{proxy}/toxics, json{ name: timeout, type: timeout, attributes: {timeout: timeout_ms} } )关键设计点解读listen与upstream分离listen是代理对外监听的地址客户端连接它upstream是真实下游地址代理转发目标。应用无需感知混沌的存在只需将配置中的下游地址指向代理的listen端口。enabled: true代理创建后立即生效可在创建阶段就先建立好所有代理再按实验节奏逐条附加 toxic。type与attributes一一对应latency接受latency基础延迟毫秒与jitter抖动毫秒bandwidth接受rateKB/stimeout接受timeout毫秒。这些即 Toxiproxy HTTP API/proxies/{proxy}/toxics的字段契约。抖动jitter的重要性真实网络延迟不是恒定值加入 jitter 才能复现偶发卡顿而非均匀变慢更贴近真实故障形态。2.2 典型使用流程给数据库注入 200ms 延迟toxiproxy ToxiproxyClient() # 创建指向数据库的代理 toxiproxy.create_proxy( namepostgres, listen0.0.0.0:5433, upstreampostgres:5432 ) # 注入 200ms 延迟 50ms 抖动 toxiproxy.add_latency(postgres, latency_ms200, jitter_ms50)2.3 配套的 CLI 实操路径仓库 SKILL.md 中提供了对应的命令行等价流程便于在无法运行 Python 代码的环境中使用# 启动 toxiproxy 服务与你的服务并行运行 toxiproxy-server # 为下游依赖创建代理 toxiproxy-cli create -l 0.0.0.0:22222 -u downstream-db:5432 db-proxy # 注入 300ms 延迟 10% 抖动 —— blast radius仅该代理 toxiproxy-cli toxic add db-proxy -t latency -a latency300 -a jitter30 # 在此运行你的压测 / 观察指标 ... # 移除 toxic 恢复正常行为 toxiproxy-cli toxic remove db-proxy -n latency_downstream可见 Python API 与 CLI 是同一套 toxic 语义的两种形态CLI 的-l/-u对应create_proxy的listen/upstream-a latency300 -a jitter30对应add_latency的latency_ms/jitter_ms。toxiproxy 同时在 chaos-tools.md 的快速参考表中被列为Network proxy chaos / Docker-API 集成的首选工具。三、AWS 可用区AZ故障模拟云厂商将单一数据中心抽象为可用区AZ 级故障整个可用区网络不可达、电源中断等是云原生架构必须演练的失效模式。infrastructure-chaos.md提供了基于 boto3 的 AWSChaosSimulator通过终止指定 AZ 内实例 从负载均衡摘除该 AZ 目标两步完成模拟。import boto3 from datetime import datetime, timedelta class AWSChaosSimulator: def __init__(self, region: str): self.ec2 boto3.client(ec2, region_nameregion) self.asg boto3.client(autoscaling, region_nameregion) self.elb boto3.client(elbv2, region_nameregion) def simulate_az_failure( self, availability_zone: str, asg_name: str, duration_minutes: int 10 ): 通过终止指定 AZ 中的实例来模拟 AZ 故障。 自动伸缩组会在其他 AZ 中启动替代实例。 # 找到目标 AZ 中的实例 instances self.ec2.describe_instances(Filters[ {Name: tag:aws:autoscaling:groupName, Values: [asg_name]}, {Name: availability-zone, Values: [availability_zone]}, {Name: instance-state-name, Values: [running]} ]) instance_ids [ i[InstanceId] for r in instances[Reservations] for i in r[Instances] ] if not instance_ids: return {status: no_instances, instances: []} # 挂起 AZ 相关的伸缩活动 self.asg.suspend_processes( AutoScalingGroupNameasg_name, ScalingProcesses[AZRebalance] ) # 终止实例以模拟 AZ 故障 self.ec2.terminate_instances(InstanceIdsinstance_ids) return { status: simulated, availability_zone: availability_zone, terminated_instances: instance_ids, recovery_time: datetime.now() timedelta(minutesduration_minutes) } def drain_az_from_load_balancer( self, target_group_arn: str, availability_zone: str ): 从负载均衡移除 AZ模拟区域故障。 # 获取当前目标健康状态 health self.elb.describe_target_health( TargetGroupArntarget_group_arn ) # 找到该 AZ 中的目标 targets_to_deregister [] for target in health[TargetHealthDescriptions]: # 获取实例详情 instance self.ec2.describe_instances( InstanceIds[target[Target][Id]] ) if instance[Reservations][0][Instances][0][Placement][AvailabilityZone] availability_zone: targets_to_deregister.append(target[Target]) # 注销目标 if targets_to_deregister: self.elb.deregister_targets( TargetGroupArntarget_group_arn, Targetstargets_to_deregister ) return { deregistered_targets: len(targets_to_deregister), availability_zone: availability_zone }这段代码背后有三个值得深入理解的工程细节实例发现依赖 ASG 标签tag:aws:autoscaling:groupName是 Auto Scaling 自动打上的标签用它过滤才能精准锁定目标 ASG 的实例同时用availability-zone与instance-state-namerunning双重过滤确保只触碰正在运行的指定 AZ 实例。挂起AZRebalance进程ASG 默认会执行 AZ 再平衡将实例均匀分布到各 AZ。若在注入故障前不挂起该进程ASG 可能立刻在其他 AZ 补位导致故障窗口过短、观察不到真实影响。这是让实验可观察的关键操作。drain_az_from_load_balancer是更安全的替代方案相比于直接 terminate 实例从目标组注销该 AZ 的全部目标可以在不销毁资源的情况下验证流量绕过该 AZ 后系统是否仍正常适合验证读多写少的无状态服务。配套演练场景来自 game-days.md 的 game day 模板通常会设计RDS 主实例强制故障转移脚本作为 AZ 级故障的数据库变体aws rds reboot-db-instance \ --db-instance-identifier staging-primary \ --force-failover并设定故障转移至备用实例 2 分钟、无数据丢失、告警正确触发等成功标准——这与simulate_az_failure返回体中的recovery_time字段形成呼应前者是云 API 层的模拟后者是衡量恢复目标RTO的观测锚点。四、服务器资源耗尽stress-ng 与 iperf3当故障面从网络/区域下沉到单机资源时stress-ng是 Linux 上最常用的压力工具iperf3则用于网络带宽饱和测试。infrastructure-chaos.md给出的脚本覆盖了 CPU、内存、磁盘 I/O 与网络四条资源赛道#!/bin/bash # 使用 stress-ng 进行 CPU 压力测试 # 安装 stress-ng sudo apt-get install -y stress-ng # CPU 压力 - 使用 80% 可用核心持续 5 分钟 stress-ng --cpu $(nproc --all) --cpu-load 80 --timeout 5m # 内存压力 - 消耗可用内存的 70% TOTAL_MEM_MB$(free -m | awk NR2{print $2}) STRESS_MEM_MB$((TOTAL_MEM_MB * 70 / 100)) stress-ng --vm 1 --vm-bytes ${STRESS_MEM_MB}M --timeout 5m # 磁盘 I/O 压力 - 4 个 worker 执行顺序写入 stress-ng --hdd 4 --hdd-bytes 1G --timeout 5m # 网络带宽饱和 # 使用 iperf3 饱和网络 iperf3 -c target-server -t 300 -P 10 # 10 个并行流持续 5 分钟逐条参数解读--cpu $(nproc --all) --cpu-load 80nproc --all动态获取所有逻辑核心数--cpu-load 80让每个 CPU worker 只占用 80% 负载。之所以不写死 100%是因为 100% 负载可能立即触发云监控的宿主机级告警甚至被平台限流且缺乏观察梯度80% 是文档作者验证过的明显压力但可观测的典型值。内存计算表达式free -m | awk NR2{print $2}提取free -m第二行Mem 行的总内存MB再乘以 70% 得到注入量。注意--vm 1表示 1 个虚拟内存 worker配合--vm-bytes XM决定单 worker 占用。--hdd 4 --hdd-bytes 1G4 个 worker 各写 1GB模拟顺序写入型 I/O 压力适合暴露文件系统缓存、存储限流等问题。iperf3 -c target-server -t 300 -P 10客户端模式连接目标服务器-t 300持续 300 秒-P 10开 10 个并行流。target-server需预先以iperf3 -s服务端模式运行。执行纪律与技能包安全清单对齐资源耗尽实验的成功不是看系统是否扛得住而是验证资源接近耗尽时SLO 是否仍被保障、熔断与降级是否如期触发。仓库 SKILL.md 的安全清单明确要求实验前必须定义并验证稳态基线指标如 p99 延迟 200ms、错误率 0.1%、把 blast radius 控制在最小范围、且回滚路径必须 ≤ 30 秒。换言之--timeout 5m的自动过期只是兜底实验设计阶段仍需在 experiment-design.md 中明确最大错误率超过 5% 即自动回滚这类触发条件。五、Docker 容器混沌Pumba 故障注入Pumba 是面向 Docker 的混沌工具可以 kill、暂停、注入网络损伤netem、停止容器。infrastructure-chaos.md给出了五类最常见的容器故障注入命令#!/bin/bash # Pumba - Docker 混沌测试 # 每 30 秒随机 kill 一个容器 pumba --interval 30s kill --signal SIGKILL re2:^myapp # 暂停容器 15 秒后恢复 pumba pause --duration 15s myapp-container # 给容器添加网络延迟 pumba netem \ --duration 5m \ --interface eth0 \ delay \ --time 300 \ --jitter 50 \ myapp-container # 丢包 - 丢弃 20% 的数据包 pumba netem \ --duration 5m \ loss \ --percent 20 \ myapp-container # 限制带宽为 1Mbps pumba netem \ --duration 5m \ rate \ --rate 1mbit \ myapp-container # 停止所有匹配模式的生产容器持续 2 分钟 pumba stop --duration 2m re2:^production-.*各命令的语义与使用要点pumba kill --signal SIGKILL re2:^myapp核心杀手锏。re2:前缀表示使用 RE2 正则匹配容器名--interval 30s让 Pumba 周期性执行实现持续随机击杀的 Chaos Monkey 式行为。SIGKILL 是模拟硬崩溃无优雅退出若想模拟优雅关闭可改--signal SIGTERM或--signal SIGSTOP。pumba pause --duration 15s利用docker pause的 cgroup 冻结机制暂停容器进程但容器依然存活——这能复现进程无响应但端口存活的半死状态与 kill进程消失形成互补。pumba netem ... delay --time 300 --jitter 50直接调用 Linux 内核tc netemNetwork Emulator--time/--jitter单位均为毫秒--interface eth0指定生效网卡。pumba netem ... loss --percent 20模拟丢包。与 toxiproxy 相比netem 在容器网络栈层面生效适合验证服务对丢包的 TCP 重传、超时重试行为而 toxiproxy 在应用与依赖之间更贴近真实客户端视角。二者在 chaos-tools.md 中被列为两种互补的网络混沌手段Toxiproxy代理型Pumba容器 CLI 型。pumba stop --duration 2m re2:^production-.*批量停止一组匹配容器用于模拟整个服务的实例全部下线的故障。容器混沌是 kubernetes-chaos 实验的前置类比Pumba 的kill对应 kubernetes-chaos.md 中 Litmus 的pod-delete实验每 20 秒删除一个 Pod、最多影响 33% 副本netem 对应 Chaos Mesh 的NetworkChaos。单机 Docker 环境下先验证注入手法再迁移到 K8s 环境用声明式 CRD 管理是平滑的能力演进路径。六、DNS 失效模拟故障注入到域名解析层DNS 故障域名解析失败、解析延迟影响所有依赖外部域名的服务调用。infrastructure-chaos.md提供了两条路径基于/etc/hosts的域名封禁以及基于 dnsmasq 的解析延迟。6.1 基于 /etc/hosts 的域名封禁# 使用 dnsmasq 或编辑 /etc/hosts 进行 DNS 混沌 import subprocess import time from contextlib import contextmanager class DNSChaos: staticmethod contextmanager def block_domain(domain: str, duration_seconds: int 60): 通过指向 localhost 来阻止域名的 DNS 解析。 try: # 向 /etc/hosts 添加条目 subprocess.run([ sudo, sh, -c, fecho 127.0.0.1 {domain} /etc/hosts ], checkTrue) print(fBlocked DNS for {domain}) yield finally: # 等待持续时间 time.sleep(duration_seconds) # 从 /etc/hosts 移除条目 subprocess.run([ sudo, sed, -i, f/127.0.0.1 {domain}/d, /etc/hosts ], checkTrue) print(fRestored DNS for {domain}) staticmethod def add_dns_latency(domain: str, latency_ms: int): 使用 dnsmasq 给 DNS 查询添加延迟。 config f # 添加到 /etc/dnsmasq.conf address/{domain}/127.0.0.1 min-cache-ttl0 # 带延迟重启 dnsmasq return config # 使用方式 with DNSChaos.block_domain(api.external-service.com, duration_seconds120): # DNS 被阻断期间运行测试 print(DNS blocked - testing fallback behavior)这段代码有两个值得学习的工程细节contextmanager保证恢复无论yield之后的业务代码是否抛异常finally中的sed -i都会移除/etc/hosts中的注入条目从语法层面保证注入必恢复。这正是混沌实验对回滚纪律的要求——恢复动作不能依赖人工记忆。127.0.0.1的妙用将域名指向 localhost模拟的是域名可解析但连接被拒/超时的场景比让解析直接 NXDOMAIN 更接近真实故障因为多数应用的连接池里已缓存了旧 IP。若想模拟解析失败可改为写入一个不存在的 IP 并关闭本地监听。6.2 基于 dnsmasq 的解析延迟add_dns_latency方法展示了 dnsmasq 配置的要点address/{domain}/127.0.0.1将指定域名固定解析到本地min-cache-ttl0关闭缓存 TTL使每次查询都真实经过解析链路——这样配合流量整形工具如 tc即可构造每次 DNS 查询都变慢的故障。该方法返回的是待写入/etc/dnsmasq.conf的配置片段实际使用需配合 dnsmasq 重启属于配置注入型的辅助手段。注修改/etc/hosts与 dnsmasq 配置均需 root 权限且会影响目标主机上所有进程的 DNS 行为blast radius 是整机级别的。更细粒度的 DNS 故障仅影响指定 Pod应使用 kubernetes-chaos.md 中的 Chaos MeshDNSChaosaction: random随机返回错误、patterns精确匹配域名。七、证书过期模拟构造已过期的 TLS 证书TLS 证书过期是没人主动触发、但一定会在某天发生的经典故障。infrastructure-chaos.md提供了一个零依赖外部证书签发机构的方案用 Pythoncryptography库在本地生成一张回溯时间构造的已过期自签名证书。from datetime import datetime, timedelta from cryptography import x509 from cryptography.x509.oid import NameOID from cryptography.hazmat.primitives import hashes, serialization from cryptography.hazmat.primitives.asymmetric import rsa def create_expired_certificate( common_name: str, expired_days_ago: int 1 ) - tuple[bytes, bytes]: 为混沌测试创建一张已过期的 TLS 证书。 返回 (certificate_pem, private_key_pem) # 生成私钥 private_key rsa.generate_private_key( public_exponent65537, key_size2048 ) # 证书有效期从 365 天前到 expired_days_ago 天前 not_valid_before datetime.utcnow() - timedelta(days365) not_valid_after datetime.utcnow() - timedelta(daysexpired_days_ago) subject issuer x509.Name([ x509.NameAttribute(NameOID.COMMON_NAME, common_name) ]) cert x509.CertificateBuilder().subject_name( subject ).issuer_name( issuer ).public_key( private_key.public_key() ).serial_number( x509.random_serial_number() ).not_valid_before( not_valid_before ).not_valid_after( not_valid_after ).sign(private_key, hashes.SHA256()) # 序列化为 PEM cert_pem cert.public_bytes(serialization.Encoding.PEM) key_pem private_key.private_bytes( encodingserialization.Encoding.PEM, formatserialization.PrivateFormat.PKCS8, encryption_algorithmserialization.NoEncryption() ) return cert_pem, key_pem代码要点时间窗口设计not_valid_before设为 365 天前证书合法签发not_valid_after设为expired_days_ago天前默认 1 天前过期。这样一个看起来内容完全正常的证书恰好处于过期状态可以精准复现生产环境最常见的证书过期事故而不需要真的等待一张证书到期。自签名即可满足测试需求混沌测试关心的是TLS 握手因证书过期失败这一行为服务端或客户端通常只需验证过期状态因此 issuersubject 的自签名证书足够无需内网 CA。返回格式为 PEM 字节对调用方可将cert_pem写入服务器证书路径、key_pem写入私钥路径然后重启目标服务触发握手失败或直接喂给测试中的 TLS 客户端校验逻辑。应用场景把它与 experiment-design.md 中的实验模板结合——例如验证证书过期时告警是否在阈值时间内触发、证书轮换脚本是否自动修复、客户端是否给出可读的错误信息而非无限重试。八、基础设施故障注入速查表infrastructure-chaos.md末尾提供了跨章节的速查表这里原样继承并补充适用场景方便实验设计时快速选型故障类型工具命令/方法注入面推荐使用场景网络延迟toxiproxyadd_latency(proxy, ms)/ CLItoxic add ... -t latency应用↔依赖之间验证超时、重试、熔断丢包toxiproxy / pumbaloss --percent 20代理层 / 容器网络栈验证 TCP 重传与降级逻辑AZ 故障AWS API (boto3)simulate_az_failure(az, asg)/drain_az_from_load_balancer(...)云资源验证多 AZ 冗余与 ASG 自愈CPU 压力stress-ng--cpu N --cpu-load 80主机验证资源配额与弹性伸缩内存耗尽stress-ng--vm 1 --vm-bytes XM主机验证 OOM 行为与内存监控容器击杀pumbakill --signal SIGKILL容器验证容器自愈与编排恢复DNS 故障/etc/hosts / dnsmasq将域名指向 127.0.0.1主机 DNS验证域名解析降级与缓存策略证书过期Python cryptography生成回溯时间的过期证书TLS 层验证证书轮换与过期告警该表与 chaos-tools.md 末尾的工具-场景-集成方式速查表Chaos Monkey→AWS ASG、Gremlin→API/Web UI、Litmus→Kubectl/Helm、Chaos Mesh→CRDs、Toxiproxy→Docker/API、Pumba→Docker CLI形成两张互补的选型视图前者回答注入什么故障后者回答用什么平台工具。九、把故障注入放进安全边界完整实验的执行纪律基础设施混沌的价值不在于把系统弄坏而在于在受控范围内验证系统对故障的可预期反应。因此本文所有工具都应服务于一个由 experiment-design.md 定义、并被仓库 SKILL.md 安全清单强化的执行框架稳态优先Steady state first注入前先确认基线指标错误率 0.1%、P99 延迟 500ms 等达标否则实验结论无效。最小 blast radius优先选择代理层注入toxiproxy 只影响单条链路、单实例/单 AZ、PODS_AFFECTED_PERC式百分比控制在生产环境突破 10% 流量必须同时具备 feature flag 与自动回滚这是 experiment-design.md 中BlastRadiusConfig.validate()硬编码的校验规则。自动化回滚 ≤ 30 秒每个注入手段都要有等价的反操作——toxiproxy 的toxic remove、pumba 的--duration自动恢复、/etc/hosts的sed -i清理、ASG 的进程恢复——并在实验开始前演练一遍回滚路径。单变量原则一次只注入一种故障如只加延迟不改带宽直到系统行为被充分理解。闭环Close the loop每次实验都必须产出书面学习总结与至少一项跟踪改进项可参照 game-days.md 的 Post-Game Report 模板What Went Well / What Didnt / Action Items组织复盘。十、延伸阅读chaos-engineer 技能总览核心工作流、安全清单、Litmus pod-delete 完整实验示例、toxiproxy CLI 示例与 Chaos Monkey 配置。混沌实验设计假设模板、blast radius 分级与自动回滚触发器。混沌工具与自动化Chaos Monkey、Gremlin API 客户端、GitHub Actions / Jenkins 集成。Kubernetes 混沌Litmus、Chaos Mesh、节点 drain 与 HPA 弹性测试。Game Day 规划与执行演练模板、观察记录与复盘报告。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考