微服务混沌工程场景执行清单（K8s环境适配）

本清单聚焦微服务高频故障场景，按“网络/服务/中间件/资源/第三方依赖”分类，每个场景包含“目标→前置条件→执行步骤→回滚方案→验证指标”，确保落地可操作，默认使用开源工具（Chaos Mesh/Blade），适配K8s容器化环境。

一、通用前置条件（所有场景必满足）

1. 环境准备：在类生产环境（预发环境，K8s集群、中间件配置与生产一致）执行；若生产测试，需选择业务低峰期（如凌晨2-4点）。
2. 可观测性就绪：Prometheus+Grafana（监控指标）、SkyWalking（调用链）、ELK（日志）已部署，且能实时查看目标服务指标（如下单成功率、Pod状态）。
3. 业务确认：核心业务（如下单、支付）当前无异常，且已告知相关团队（开发/运维）测试计划，避免误判故障。
4. 工具就绪：Chaos Mesh（已部署至K8s集群，命名空间chaos-testing）或Chaos Blade（已安装至目标节点）。

二、分场景执行清单

场景1：服务间网络延迟（高频场景）

目标

验证“订单服务调用库存服务时，网络延迟500ms”下，订单服务是否能正常降级（如超时重试），核心下单业务不受影响。

前置条件

1. 目标服务：订单服务（order-service，3个Pod）、库存服务（inventory-service，2个Pod）；
2. 业务低峰期：当前下单QPS＜50（正常峰值1000）；
3. 已配置订单服务超时重试（如Feign重试次数=2，超时时间=1s）。

执行步骤

1. 检查环境：

   # 确认订单/库存服务Pod正常运行
   kubectl get pods -n prod | grep -E "order-service|inventory-service"
   # 确认Chaos Mesh正常
   kubectl get pods -n chaos-testing | grep chaos-controller-manager
   

2. 注入网络延迟（用Chaos Mesh，仅对1个库存Pod注入延迟）：
   创建network-delay.yaml配置文件：

   apiVersion: chaos-mesh.org/v1alpha1
   kind: NetworkChaos
   metadata:
     name: inventory-delay
     namespace: chaos-testing
   spec:
     action: delay  # 故障类型：延迟
     mode: one  # 仅影响1个Pod
     selector:
       namespaces:
         - prod  # 目标服务所在命名空间
       labelSelectors:
         app: inventory-service  # 库存服务标签
     delay:
       latency: "500ms"  # 延迟时间
     duration: "10m"  # 故障持续10分钟
     direction: to  # 仅影响“订单服务→库存服务”的请求
     target:
       selector:
         namespaces:
           - prod
         labelSelectors:
           app: order-service
   

   执行注入：

   kubectl apply -f network-delay.yaml
   

3. 实时监控：
   • Grafana查看：订单服务→库存服务调用延迟（是否达500ms）、下单成功率、订单P95延迟；
   • SkyWalking查看：调用链中“order→inventory”的耗时是否正常重试。

回滚方案

若下单成功率＜99.9%或P95延迟＞1s，立即停止故障：

kubectl delete -f network-delay.yaml

验证指标

指标类型	预期结果	实际结果
业务指标	下单成功率≥99.9%，用户端错误率≤0.1%
技术指标	订单服务→库存服务重试率≤10%，P95延迟≤1s
基础设施指标	库存服务Pod无重启，K8s节点网络正常

场景2：服务Pod宕机（核心场景）

目标

验证“库存服务1个Pod宕机”后，K8s是否能自动重启Pod，且订单服务调用库存服务的成功率无明显下降。

前置条件

1. 目标服务：库存服务（inventory-service，3个Pod，K8s Deployment配置replicas=3）；
2. K8s自愈开启：Deployment已配置restartPolicy=Always，且无状态服务支持自动扩缩容。

执行步骤

1. 检查初始状态：

   # 记录当前库存服务Pod列表（标记要删除的Pod名）
   kubectl get pods -n prod -l app=inventory-service -o wide
   # 示例输出：inventory-service-7f98d7c6b4-2xqzk（待删除）、-5t7k8、-8m2p3
   

2. 手动删除Pod（模拟宕机）：

   kubectl delete pod inventory-service-7f98d7c6b4-2xqzk -n prod
   

3. 实时监控：
   • 1分钟内查看Pod是否重启：kubectl get pods -n prod -l app=inventory-service；
   • Grafana查看：库存服务可用Pod数（是否从3→2→3）、订单服务调用库存服务成功率。

回滚方案

若Pod重启失败（＞5分钟未恢复），手动触发Deployment重启：

kubectl rollout restart deployment inventory-service -n prod

验证指标

指标类型	预期结果	实际结果
业务指标	订单调用库存服务成功率≥99.5%
技术指标	库存服务Pod重启时间≤2分钟，服务不可用窗口≤30秒
基础设施指标	K8s Deployment replicas维持3个，无异常事件

场景3：Redis主从切换（中间件场景）

目标

验证“Redis缓存主从切换（耗时30秒）”时，商品服务是否能通过本地缓存降级，商品详情页加载成功率≥99.5%。

前置条件

1. 中间件：Redis集群（1主2从，部署在middleware命名空间，商品服务用Redis缓存商品详情）；
2. 商品服务：已实现本地缓存（Caffeine，缓存有效期5分钟）。

执行步骤

1. 检查Redis主从状态：

   # 进入Redis主节点Pod
   kubectl exec -it redis-master-0 -n middleware -- redis-cli
   # 查看主从信息（记录主节点IP：如10.244.1.5）
   info replication
   

2. 手动触发主从切换：

   # 在原主节点执行“放弃主身份”
   redis-cli -h 10.244.1.5 slaveof no one
   # 在从节点（如10.244.1.6）执行“成为主节点”
   redis-cli -h 10.244.1.6 slaveof no one
   # 确认切换结果（新主节点为10.244.1.6）
   info replication
   

3. 实时监控：
   • Grafana查看：Redis主从切换耗时、商品服务本地缓存命中率、商品详情页P95加载延迟；
   • ELK查看：商品服务是否有“Redis连接超时”日志，是否触发本地缓存降级。

回滚方案

若商品详情页成功率＜99.5%，手动恢复Redis主从关系（按初始主从配置重新设置）。

验证指标

指标类型	预期结果	实际结果
业务指标	商品详情页加载成功率≥99.5%，错误率≤0.5%
技术指标	商品服务本地缓存命中率≥80%，P95延迟≤300ms
中间件指标	Redis主从切换耗时≤60秒，无数据丢失

场景4：容器CPU高负载（资源场景）

目标

验证“订单服务1个Pod CPU使用率达90%”时，K8s是否能限制CPU资源，且订单服务核心下单逻辑不受影响。

前置条件

1. 目标Pod：订单服务order-service-7f98d7c6b4-2xqzk（K8s配置CPU请求=1核，限制=2核）；
2. 已确认该Pod非核心实例（当前仅处理10%下单流量）。

执行步骤

1. 检查初始CPU使用率：

   kubectl top pod order-service-7f98d7c6b4-2xqzk -n prod
   # 预期初始使用率＜30%
   

2. 注入CPU压力（用Chaos Mesh）：
   创建cpu-stress.yaml：

   apiVersion: chaos-mesh.org/v1alpha1
   kind: StressChaos
   metadata:
     name: order-cpu-stress
     namespace: chaos-testing
   spec:
     action: stress-cpu  # CPU压力
     mode: one
     selector:
       namespaces:
         - prod
       labelSelectors:
         app: order-service
       podNames:
         - order-service-7f98d7c6b4-2xqzk  # 指定目标Pod
     stressors:
       cpu:
         cores: 1.8  # 占用1.8核（达90%限制）
         load: 100   # 满载
     duration: "10m"
   

   执行注入：

   kubectl apply -f cpu-stress.yaml
   

3. 实时监控：
   • Grafana查看：目标Pod CPU使用率（是否达90%）、订单服务整体下单成功率、其他Pod负载是否正常。

回滚方案

若整体下单成功率＜99.8%，立即停止CPU压力：

kubectl delete -f cpu-stress.yaml

验证指标

指标类型	预期结果	实际结果
业务指标	整体下单成功率≥99.8%，无批量错误
技术指标	目标Pod CPU使用率≤90%，其他Pod CPU＜50%
基础设施指标	K8s未触发Pod驱逐（eviction），资源限制生效

三、通用回滚原则

1. 优先止损：任何场景下，若核心业务指标（如下单成功率、支付成功率）低于阈值，立即停止故障注入，不纠结“故障未执行完”；
2. 快速恢复：回滚操作需1分钟内完成（如删除Chaos Mesh配置、重启Pod），避免故障扩散；
3. 事后验证：回滚后需观察5分钟，确认业务指标恢复至正常水平，再结束测试。

四、复盘要点（每个场景执行后必做）

1. 记录异常现象：如“Redis切换时，商品服务本地缓存未生效，导致DB QPS飙升至2000”；
2. 定位根因：如“本地缓存初始化逻辑错误，Redis连接超时后未触发缓存加载”；
3. 输出优化方案：如“修复商品服务本地缓存降级逻辑，添加Redis连接超时监听”；
4. 验证优化效果：下次执行相同场景前，先验证优化方案是否生效。