Docker容器故障演练核心是模拟高频真实故障并验证恢复机制有效性，重点在于可控、可观测、可回退；应聚焦容器级异常、网络级干扰、依赖级故障三类场景，使用标准工具安全注入故障，严格验证业务级恢复效果，并做好记录闭环。
做 Docker 容器故障演练，核心不是“制造崩溃”，而是模拟真实生产中高频、可复现、有代表性的故障场景，并验证你的恢复机制是否有效。重点在于可控、可观测、可回退。
明确演练目标与范围
先想清楚这次练什么：是测单容器自愈？网络中断影响？还是整个服务链路的容错能力？避免“随便 kill 一下”——那样只练了手速，没练出系统韧性。
建议从三类典型故障切入：
- 容器级异常：进程崩溃、OOM 被杀、健康检查连续失败
- 网络级干扰：容器间通信断开、DNS 解析失败、出口访问超时
- 依赖级故障：数据库连接拒绝、Redis 不可用、下游 HTTP 服务返回 503
用标准工具安全注入故障
别直接 kill -9 或删容器——这跳过了 Docker 的生命周期管理，无法验证 restart 策略或编排平台行为。推荐方式：
- 触发应用主动退出：在容器内执行 exit 1（如 docker exec -it app sh -c 'exit 1'），观察是否按 --restart=on-failure 规则重启
- 模拟健康检查失败：临时修改 HEALTHCHECK CMD，让它返回 false；或停掉内部服务（如 systemctl stop nginx）
-
限流/断网测试：用
nicolaka/netshoot进入容器后执行 tc netem delay 2000ms 或 iptables -A OUTPUT -d 8.8.8.8 -j DROP -
资源耗尽模拟：运行
docker run --memory=100m --cpus=0.1 alpine sh -c 'dd if=/dev/zero of=/tmp/big bs=1M count=200'触发 OOM Killer
验证恢复动作是否生效
故障注入后，不能只看容器“起来了”，要确认业务真正恢复：
- 查状态：
docker ps看 STATUS 是否变回 Up，docker inspect app | grep Health看健康状态是否转为 healthy - 验连通：
curl -I http://localhost:8080/health或从另一容器 ping/app curl 目标服务 - 看日志：
docker logs --since 1m app检查重启后是否有初始化成功日志、是否重连了 DB/Redis - 盯指标：如果有 Prometheus，观察 container_restarts_total、container_status、http_request_duration_seconds 是否回归基线
记录与闭环
每次演练后，记下三件事：
- 故障如何触发、多久被发现（告警延迟？）、多久恢复（MTTR）
- 哪些配置起了作用（比如 restart: unless-stopped 生效了，但 healthcheck timeout 太短导致误判）
- 暴露的盲点（例如日志没打到 stdout，导致 docker logs 看不到关键错误）
把问题写进 checklist，下次演练前先加固。不复杂但容易忽略。
