Linux 服务运维故障演练

一、混沌工程核心原理与实验设计方法

混沌工程四大原则（Principles of Chaos）：

1. 从稳态开始：在正常业务流量下进行实验
2. 提出假设：明确“系统在 X 故障下仍能保持 SLA”
3. 注入真实故障：模拟生产可能发生的故障
4. 持续验证与改进：分析结果，修复问题，形成闭环

实验设计框架（Blast Radius 控制）：

• 范围：从单 Pod → 单节点 → 可用区 → 全集群
• 强度：从小流量灰度 → 全流量
• 回滚：必须具备快速终止实验的能力
• 监控：全链路可观测性（Prometheus + Loki + Tempo）

常见实验类型：

• 资源类：CPU/Memory 压力、磁盘满
• 网络类：延迟、丢包、分区
• 应用类：Pod Kill、容器重启、配置错误
• 基础设施类：节点宕机、DNS 故障

二、Chaos Mesh 部署与实战（Kubernetes 原生推荐）

Chaos Mesh 是 CNCF 孵化项目，基于 Kubernetes CRD 实现，功能强大且易用。

1. 安装 Chaos Mesh

helm repo add chaos-mesh https://charts.chaos-mesh.org
helm install chaos-mesh chaos-mesh/chaos-mesh --namespace chaos-testing --create-namespace

2. 核心实验类型示例

Pod Kill 实验（测试服务自愈）：

apiVersion:chaos-mesh.org/v1alpha1
kind:PodChaos
metadata:
name:nginx-pod-kill
namespace:prod
spec:
action:pod-kill
mode:one
selector:
labelSelectors:
app:nginx
scheduler:
cron:"@every 10m"# 定时实验
duration:"30s"

网络延迟实验：

apiVersion:chaos-mesh.org/v1alpha1
kind:NetworkChaos
metadata:
name:network-delay
spec:
action:delay
mode:all
selector:
namespaces:
-prod
labelSelectors:
app:backend
delay:
latency:"100ms"
jitter:"10ms"
correlation:"50"
duration:"5m"

CPU 压力实验：

apiVersion:chaos-mesh.org/v1alpha1
kind:StressChaos
metadata:
name:cpu-stress
spec:
mode:one
selector:
labelSelectors:
app:api-service
stressors:
cpu:
workers:2
load:80
duration:"2m"

3. Dashboard 可视化 Chaos Mesh 提供 Web Dashboard，支持实验编排、实时监控和历史记录。

三、Litmus Chaos 实战（多云与混合架构友好）

Litmus 同样基于 CRD，实验类型丰富，适合混合环境。

1. 安装

kubectl apply -f https://litmuschaos.github.io/litmus/2.14.0/litmus-2.14.0.yaml

2. 典型实验

• Kubernetes Pod Delete
• Node Drain
• Disk Fill
• JVM Chaos（Java 应用特定）

与 Systemd 混合使用：

• 对裸机 Systemd 服务使用 Litmus 的 Linux 实验（CPU Hog、Memory Hog、Network Corruption）
• 通过 Chaos Operator 统一管理

四、生产级混沌演练流程与风险控制

1. 完整演练流程：

1. 准备阶段：定义实验范围、SLO 指标、回滚计划、通知相关方
2. 审批阶段：低峰期 + 变更管理委员会审批
3. 执行阶段：小范围灰度 → 监控观察 → 逐步扩大
4. 分析阶段：回顾故障定位时间、恢复时间、弱点修复
5. 文档化：更新 Runbook 和架构图

2. 安全控制措施：

• Blast Radius：使用 Namespace 隔离 + NodeSelector
• 暂停机制：Chaos Mesh 支持 Pause/Resume
• 监控联动：Prometheus Alert + OnCall 通知
• 回滚：预先准备扩容、流量切换脚本

3. 与可观测性集成（第十三篇回顾）：

• 实验期间重点关注 Trace 错误率、Latency P99、错误日志突增
• 使用 Grafana + Loki 实时仪表盘

五、常见混沌实验场景与优化案例

案例1：Pod Kill 后服务不可用 现象：部分实例 Down 导致 502 错误。 优化：增加 replicas + PodDisruptionBudget + Readiness Probe

案例2：网络分区后数据不一致 实验：Cilium NetworkChaos 隔离数据库副本。 优化：引入 Raft 共识或最终一致性设计

案例3：节点宕机后调度慢 优化：Cluster Autoscaler 调优 + Pod Priority + Topology Spread Constraints

案例4：Systemd 服务在裸机上的混沌测试 使用 stress-ng + systemd 单元 Kill 测试：

stress-ng --cpu 4 --timeout 60s
systemctl kill -s SIGKILL nginx.service

案例5：全链路压测 + 混沌结合 使用 Locust / k6 产生流量 + Chaos Mesh 注入故障，验证极限场景。

六、生产环境混沌工程最佳实践

1. 分阶段引入：

• Stage 1：测试/预发环境
• Stage 2：生产低峰灰度
• Stage 3：常态化生产演练

2. 自动化演练：

• GitHub Actions / GitLab CI + Chaos Mesh CRD
• 每周固定时间窗口执行

3. 文化建设：

• Chaos Day / Game Day
• 将演练结果纳入架构评审

4. 工具链集成：

• Chaos Mesh + ArgoCD + Prometheus + PagerDuty
• Litmus + Crossplane（第十七篇）

5. 风险与合规：

• 客户数据敏感环境需额外审批
• 记录所有实验日志用于审计