@umacloud/knowledge 1.0.1

package/operations/chaos-engineering.md

@@ -0,0 +1,659 @@
+---
+id: chaos-engineering
+title: chaos-engineering
+domain: operations
+category: chaos-engineering.md
+difficulty: intermediate
+tags: [chaos, engineering, operations, 分钟, 实施流程, 实验信息, 实验概况, 核心原则]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 开发：Excellent（11964948@qq.com）
+# 功能：混沌工程实践指南
+# 作用：通过主动注入故障验证系统韧性,提前发现和修复潜在问题
+# 创建时间：2026-03-20
+# 最后修改：2026-03-20
+
+## 目标
+建立混沌工程实践体系,通过受控的故障注入实验,验证系统在生产环境真实负载下的韧性,提前发现和修复潜在问题,提升服务可靠性。
+
+## 适用范围
+- 生产环境关键服务（在充分测试后）
+- 预生产环境（Staging/Pre-prod）
+- 性能测试环境
+- 不适用于：无备份的生产数据库、不可恢复的关键系统
+
+## 核心原则
+
+### 1. 建立稳态假设（Steady State Hypothesis）
+**定义**：系统正常运行的可测量状态
+
+**示例**：
+```yaml
+# 订单服务稳态假设
+steady_state_hypothesis:
+  title: "订单服务正常处理请求"
+  probes:
+    - name: "可用性 >= 99.9%"
+      type: prometheus
+      query: "slo:availability:ratio:5m{service='order-service'} >= 0.999"
+
+    - name: "P95 延迟 < 200ms"
+      type: prometheus
+      query: "slo:latency:p95{service='order-service'} < 0.2"
+
+    - name: "错误率 < 0.1%"
+      type: prometheus
+      query: "slo:error_rate:ratio:5m{service='order-service'} < 0.001"
+
+    - name: "健康检查通过"
+      type: http
+      url: "https://order-service.example.com/health"
+      expected_status: 200
+```
+
+### 2. 模拟真实世界故障（Real-world Events）
+**故障类型**：
+- 基础设施故障：服务器宕机、网络分区、磁盘故障
+- 资源耗尽：CPU 飙升、内存泄漏、磁盘满、连接池耗尽
+- 依赖故障：数据库宕机、缓存失效、第三方 API 超时
+- 网络故障：延迟、丢包、DNS 故障、SSL 证书过期
+- 应用故障：进程崩溃、异常抛出、配置错误
+
+### 3. 在生产环境运行（Run in Production）
+**原因**：
+- 测试环境无法完全模拟生产流量和依赖
+- 生产环境的故障最真实
+- 提前暴露问题,避免真实故障时措手不及
+
+**前置条件**：
+- 完善的监控和告警
+- 快速回滚机制
+- 团队 On-call 能力
+- 充分的测试环境验证
+
+### 4. 自动化持续运行（Automate and Run Continuously）
+**策略**：
+- Game Day：定期（每月/每季度）组织的混沌演练日
+- 自动化实验：CI/CD 流水线中集成混沌测试
+- 渐进式扩大范围：从单个服务 -> 集群 -> 跨区域
+
+### 5. 最小化爆炸半径（Minimize Blast Radius）
+**控制措施**：
+- 分阶段实验：先测试环境,再生产环境
+- 流量隔离：仅对部分用户/流量注入故障
+- 紧急停止：实验失控时立即中止
+- 回滚机制：快速恢复到正常状态
+
+## 实施流程
+
+### 阶段 1：准备（Preparation）
+
+#### 1.1 评估系统成熟度
+**检查清单**：
+- [ ] 服务监控覆盖 >= 90%（日志/指标/追踪）
+- [ ] 核心服务 SLO 定义完整
+- [ ] 自动化部署和回滚流程
+- [ ] 团队 On-call 机制和 Runbook
+- [ ] 灾难恢复（DR）演练过
+
+**成熟度评估**：
+| 维度 | L1（初始） | L2（基础） | L3（成熟） | L4（卓越） |
+|------|-----------|-----------|-----------|-----------|
+| 监控 | 基础指标 | 完整监控 | SLO + 告警 | AIOps |
+| 部署 | 手动 | 自动化部署 | 蓝绿/金丝雀 | 渐进式交付 |
+| 恢复 | 手动恢复 | 自动化恢复 | 自愈系统 | 主动预防 |
+| 混沌 | 无 | 测试环境 | 生产环境 | 自动化混沌 |
+
+**准入标准**：成熟度 >= L2 才能在生产环境运行混沌实验
+
+#### 1.2 选择实验目标
+**优先级评估**：
+- 关键服务（P0）：订单、支付、认证
+- 高频故障服务：过去 3 个月故障次数最多
+- 新上线服务：验证架构韧性
+- 大规模变更前：验证变更影响
+
+**服务依赖图分析**：
+```
+用户 -> CDN -> 负载均衡 -> 订单服务 -> 数据库
+                           -> 库存服务 -> 缓存
+                           -> 支付服务 -> 支付网关
+```
+
+**目标选择示例**：
+```yaml
+# 优先级排序
+targets:
+  - service: "order-service"
+    priority: "P0"
+    reason: "核心业务服务,直接影响营收"
+
+  - service: "payment-service"
+    priority: "P0"
+    reason: "支付关键路径,故障影响订单完成"
+
+  - service: "inventory-service"
+    priority: "P1"
+    reason: "库存服务故障导致超卖风险"
+```
+
+### 阶段 2：设计实验（Experiment Design）
+
+#### 2.1 定义实验假设
+**模板**：
+```
+当 <注入故障> 时,
+如果 <系统行为> 正常,
+则 <业务影响> 在可接受范围内
+```
+
+**示例**：
+```
+当 订单服务的一个 Pod 宕机时,
+如果 自动扩缩容和负载均衡正常,
+则 用户请求成功率保持在 99.9% 以上,P95 延迟不超过 250ms
+```
+
+#### 2.2 选择故障注入类型
+**Chaos Mesh 故障类型**：
+```yaml
+# Pod 故障
+apiVersion: chaos-mesh.org/v1alpha1
+kind: PodChaos
+metadata:
+  name: pod-failure
+  namespace: chaos-testing
+spec:
+  action: pod-failure
+  mode: one
+  selector:
+    namespaces:
+      - production
+    labelSelectors:
+      app: order-service
+  duration: "5m"
+
+# 网络延迟
+apiVersion: chaos-mesh.org/v1alpha1
+kind: NetworkChaos
+metadata:
+  name: network-delay
+  namespace: chaos-testing
+spec:
+  action: delay
+  mode: all
+  selector:
+    namespaces:
+      - production
+    labelSelectors:
+      app: order-service
+  delay:
+    latency: "100ms"
+    correlation: "50"
+    jitter: "10ms"
+  duration: "10m"
+
+# CPU 压力
+apiVersion: chaos-mesh.org/v1alpha1
+kind: StressChaos
+metadata:
+  name: cpu-stress
+  namespace: chaos-testing
+spec:
+  mode: one
+  selector:
+    namespaces:
+      - production
+    labelSelectors:
+      app: order-service
+  stressors:
+    cpu:
+      workers: 2
+      load: 80
+  duration: "5m"
+
+# DNS 故障
+apiVersion: chaos-mesh.org/v1alpha1
+kind: DNSChaos
+metadata:
+  name: dns-failure
+  namespace: chaos-testing
+spec:
+  action: error
+  mode: all
+  selector:
+    namespaces:
+      - production
+    labelSelectors:
+      app: order-service
+  patterns:
+    - "mysql-*"
+    - "redis-*"
+  duration: "3m"
+```
+
+**Litmus Chaos 故障类型**：
+```yaml
+# 节点故障
+apiVersion: litmuschaos.io/v1alpha1
+kind: ChaosEngine
+metadata:
+  name: node-chaos
+  namespace: chaos-testing
+spec:
+  appinfo:
+    appns: production
+    applabel: "app=order-service"
+  chaosServiceAccount: litmus-admin
+  experiments:
+    - name: node-cpu-hog
+      spec:
+        components:
+          env:
+            - name: CPU_CORES
+              value: "2"
+            - name: TOTAL_CHAOS_DURATION
+              value: "60"
+
+# Pod 删除
+    - name: pod-delete
+      spec:
+        components:
+          env:
+            - name: FORCE
+              value: "false"
+            - name: CHAOS_INTERVAL
+              value: "10"
+            - name: TOTAL_CHAOS_DURATION
+              value: "60"
+```
+
+#### 2.3 定义停止条件
+**自动停止条件**：
+```yaml
+stop_conditions:
+  - name: "可用性降至 99% 以下"
+    type: prometheus
+    query: "slo:availability:ratio:5m{service='order-service'} < 0.99"
+    action: "abort"
+
+  - name: "P95 延迟超过 500ms"
+    type: prometheus
+    query: "slo:latency:p95{service='order-service'} > 0.5"
+    action: "abort"
+
+  - name: "错误率超过 1%"
+    type: prometheus
+    query: "slo:error_rate:ratio:5m{service='order-service'} > 0.01"
+    action: "abort"
+
+  - name: "人工终止"
+    type: manual
+    action: "abort"
+```
+
+**手动停止流程**：
+1. 监控团队观察 SLO Dashboard
+2. 发现指标超过阈值 -> 立即通知实验负责人
+3. 负责人执行 `kubectl delete -f experiment.yaml` 停止实验
+4. 如果系统未自动恢复 -> 执行回滚流程
+
+### 阶段 3：执行实验（Execution）
+
+#### 3.1 环境准备
+**检查清单**：
+- [ ] 实验方案已评审（技术负责人 + SRE）
+- [ ] 监控和告警已验证
+- [ ] 回滚流程已测试
+- [ ] 团队已通知（On-call + 相关团队）
+- [ ] 用户通知（如影响较大）
+- [ ] 选择低峰时段（如凌晨 2-5 点）
+
+#### 3.2 基线测量
+**执行步骤**：
+1. 记录实验前 30 分钟的指标基线
+2. 确认系统处于稳态（SLO 达成）
+3. 保存基线数据用于对比
+
+**基线报告模板**：
+```markdown
+# 混沌实验基线报告
+
+## 实验信息
+- 实验名称：订单服务单 Pod 宕机测试
+- 时间：2026-03-20 02:00 - 02:30
+- 负责人：张三
+
+## 基线指标（实验前 30 分钟）
+- 可用性：99.95%
+- P95 延迟：150ms
+- P99 延迟：280ms
+- 错误率：0.05%
+- QPS：1,200
+
+## 系统状态
+- Pod 数量：3
+- CPU 使用率：45%
+- 内存使用率：60%
+- 数据库连接数：80/100
+```
+
+#### 3.3 注入故障
+**执行流程**：
+```bash
+# 1. 应用故障配置
+kubectl apply -f pod-failure.yaml
+
+# 2. 观察系统响应
+watch -n 5 'kubectl get pods -l app=order-service'
+
+# 3. 监控指标
+# 打开 Grafana SLO Dashboard: https://grafana.example.com/d/slo-dashboard
+
+# 4. 持续观察 5-10 分钟
+# 记录关键事件和指标变化
+
+# 5. 停止实验
+kubectl delete -f pod-failure.yaml
+
+# 6. 观察恢复过程
+# 等待 5-10 分钟,确认系统恢复到基线
+```
+
+#### 3.4 实时监控
+**监控维度**：
+- SLO 指标：可用性、延迟、错误率
+- 资源指标：CPU、内存、网络、磁盘
+- 业务指标：订单量、转化率、营收
+- 依赖服务：数据库、缓存、第三方 API
+
+**告警配置**：
+```yaml
+# 实验专用告警（更严格的阈值）
+groups:
+  - name: chaos-experiment-alerts
+    rules:
+      - alert: ChaosExperimentSLOBreach
+        expr: slo:availability:ratio:5m{service="order-service"} < 0.99
+        for: 1m
+        labels:
+          severity: critical
+          experiment: "pod-failure"
+        annotations:
+          summary: "混沌实验导致 SLO 违反"
+          description: "立即停止实验并检查系统"
+```
+
+### 阶段 4：分析与改进（Analysis & Improvement）
+
+#### 4.1 数据收集
+**收集内容**：
+- 实验期间所有指标数据
+- 日志（应用/系统/中间件）
+- 追踪数据（分布式追踪）
+- 事件时间线（故障注入/恢复时间点）
+- 团队观察记录
+
+#### 4.2 结果分析
+**分析维度**：
+1. **稳态验证**：
+   - 实验期间稳态假设是否成立？
+   - SLO 是否违反？违反多久？
+   - 系统是否自动恢复？
+
+2. **性能影响**：
+   - 延迟增加多少？
+   - 吞吐量下降多少？
+   - 用户影响范围多大？
+
+3. **恢复时间**：
+   - MTTR（Mean Time To Recovery）多长？
+   - 自动恢复还是人工干预？
+   - 恢复过程中有无次生故障？
+
+4. **发现的问题**：
+   - 未预期的系统行为？
+   - 监控盲区？
+   - Runbook 缺失或不准确？
+
+**实验报告模板**：
+```markdown
+# 混沌实验报告
+
+## 实验概况
+- 实验名称：订单服务单 Pod 宕机测试
+- 执行时间：2026-03-20 02:00 - 02:15
+- 执行人：张三
+- 环境：生产环境
+
+## 实验设计
+- 故障类型：Pod 删除
+- 注入对象：order-service-7d9f8c6b5-x9k2m
+- 持续时间：10 分钟
+- 稳态假设：可用性 >= 99.9%, P95 延迟 < 200ms
+
+## 实验结果
+### 稳态验证
+- [x] 可用性保持 >= 99.9%（实际：99.92%）
+- [x] P95 延迟 < 200ms（实际：180ms）
+- [x] 错误率 < 0.1%（实际：0.08%）
+
+### 性能影响
+- 延迟增加：+30ms（150ms -> 180ms）
+- 吞吐量下降：5%（1,200 QPS -> 1,140 QPS）
+- 用户影响：无用户投诉
+
+### 恢复时间
+- Pod 重启时间：45 秒
+- 服务恢复时间：60 秒
+- 恢复方式：Kubernetes 自动重启
+- 次生故障：无
+
+## 发现的问题
+### 严重问题
+1. 数据库连接池未及时释放，导致新 Pod 启动时连接池耗尽
+   - 影响：新 Pod 启动延迟 15 秒
+   - 修复：配置连接池超时自动释放
+
+### 一般问题
+1. 监控面板缺少 Pod 重启事件标注
+   - 影响：难以快速定位故障原因
+   - 修复：添加 Kubernetes 事件监控
+
+## 改进措施
+| 优先级 | 措施 | 负责人 | 截止日期 |
+|--------|------|--------|----------|
+| P0 | 数据库连接池配置优化 | 李四 | 2026-03-25 |
+| P1 | 监控面板添加事件标注 | 王五 | 2026-03-27 |
+| P2 | Runbook 更新 | 张三 | 2026-03-30 |
+
+## 结论
+实验成功，系统具备单 Pod 故障自愈能力。但发现数据库连接池配置问题，需要优化。
+建议：下次实验增加双 Pod 同时宕机场景，验证极端情况下的系统韧性。
+```
+
+#### 4.3 改进实施
+**改进优先级**：
+- P0（紧急）：影响 SLO 的问题，立即修复
+- P1（高）：影响系统韧性的问题，1 周内修复
+- P2（中）：监控/文档缺失，2 周内完善
+- P3（低）：优化建议，纳入后续迭代
+
+**验证改进**：
+- 改进后重新运行相同实验
+- 对比改进前后的指标
+- 确认问题已解决
+
+## 实验场景库
+
+### 场景 1：单服务 Pod 宕机
+**目标**：验证自动扩缩容和负载均衡
+**故障**：删除 1 个 Pod
+**预期**：流量自动切换到其他 Pod, SLO 保持
+**难度**：初级
+
+### 场景 2：数据库连接池耗尽
+**目标**：验证数据库连接池管理和超时机制
+**故障**：模拟大量慢查询,耗尽连接池
+**预期**：应用自动降级或熔断,核心功能可用
+**难度**：中级
+
+### 场景 3：缓存服务宕机
+**目标**：验证缓存降级策略
+**故障**：Redis 宕机
+**预期**：应用回源到数据库,性能下降但可用
+**难度**：中级
+
+### 场景 4：网络分区
+**目标**：验证跨可用区高可用
+**故障**：模拟单个可用区网络分区
+**预期**：流量自动切换到其他可用区
+**难度**：高级
+
+### 场景 5：第三方 API 超时
+**目标**：验证熔断器和降级策略
+**故障**：支付网关 API 超时
+**预期**：启用备用支付方式或降级提示
+**难度**：中级
+
+### 场景 6：CPU 飙升
+**目标**：验证资源隔离和自动扩容
+**故障**：注入 CPU 压力
+**预期**：HPA 自动扩容,服务保持响应
+**难度**：初级
+
+### 场景 7：磁盘满
+**目标**：验证磁盘监控和清理机制
+**故障**：快速填充磁盘空间
+**预期**：告警触发,自动清理或扩容
+**难度**：中级
+
+### 场景 8：DNS 故障
+**目标**：验证服务发现和兜底机制
+**故障**：DNS 解析失败
+**预期**：使用 DNS 缓存或硬编码兜底地址
+**难度**：高级
+
+## 工具选型
+
+### Chaos Mesh（Kubernetes 原生）
+**优势**：
+- 支持丰富的故障类型（Pod/网络/IO/压力/DNS）
+- 声明式配置（YAML）
+- 可视化 Dashboard
+- 集成 CI/CD
+
+**适用场景**：Kubernetes 环境
+
+**安装**：
+```bash
+# Helm 安装
+helm repo add chaos-mesh https://charts.chaos-mesh.org
+helm install chaos-mesh chaos-mesh/chaos-mesh --namespace=chaos-testing
+```
+
+### Litmus Chaos（云原生）
+**优势**：
+- 大量预定义实验（100+）
+- ChaosHub 实验市场
+- 支持非 Kubernetes 环境
+- 强大的分析能力
+
+**适用场景**：混合环境、企业级
+
+**安装**：
+```bash
+kubectl apply -f https://litmuschaos.github.io/litmus/2.13.0/litmus-2.13.0.yaml
+```
+
+### Gremlin（商业）
+**优势**：
+- SaaS 平台,无需维护
+- 丰富的故障类型
+- 详细的分析报告
+- 企业级支持
+
+**适用场景**：企业级、快速落地
+
+### Chaos Blade（阿里开源）
+**优势**：
+- 轻量级、易上手
+- 支持多语言（Java/Go/C++）
+- 丰富的故障场景
+
+**适用场景**：应用层故障注入
+
+## 安全与合规
+
+### 安全检查清单
+- [ ] 实验范围限制（namespace/label 选择器）
+- [ ] 权限控制（RBAC）
+- [ ] 实验审批流程
+- [ ] 紧急停止机制
+- [ ] 数据脱敏（避免泄露敏感信息）
+
+### 合规要求
+- 数据保护法规（GDPR/CCPA）：确保实验不泄露用户数据
+- 金融监管（如适用）：需提前报备
+- 审计日志：记录所有实验操作
+
+## 常见失败模式
+
+### 1. 准备不足
+- **未验证监控**：实验期间发现监控盲区,无法判断系统状态
+- **缺少回滚计划**：系统无法恢复,导致真实故障
+- **未通知团队**：On-call 人员误以为是真实故障,启动事故响应
+
+### 2. 爆炸半径失控
+- **误删生产数据库**：标签选择器配置错误,影响数据库
+- **影响范围过大**：同时注入多个故障,导致级联失败
+- **流量超标**：注入故障影响过多用户
+
+### 3. 实验设计不当
+- **假设不明确**：无法判断实验是否成功
+- **停止条件缺失**：故障持续过久,造成不必要影响
+- **未考虑依赖**：只测试了服务本身,忽略依赖服务
+
+### 4. 组织问题
+- **缺少持续实践**：一次性实验后不再进行,能力退化
+- **未改进问题**：发现的问题未修复,下次实验仍然失败
+- **缺少文档**：实验知识未沉淀,人员流失后无法复现
+
+## 验收标准
+
+### 功能验收
+- [ ] 混沌工程平台部署完成（Chaos Mesh/Litmus）
+- [ ] 至少 3 个核心服务完成混沌实验
+- [ ] 实验场景库建立（>= 10 个场景）
+- [ ] 实验报告模板和流程文档化
+
+### 质量验收
+- [ ] 实验成功率 >= 80%（系统符合稳态假设）
+- [ ] 发现问题修复率 >= 90%
+- [ ] 无生产事故由混沌实验导致
+- [ ] MTTR 改善 >= 20%（对比实验前）
+
+### 运营验收
+- [ ] 每月 Game Day 机制建立
+- [ ] 团队培训覆盖率 100%
+- [ ] CI/CD 集成混沌测试
+- [ ] 实验报告归档率 100%
+
+## 参考资源
+
+### 经典著作
+- Chaos Engineering（O'Reilly）
+- Building Secure and Reliable Systems（Google）
+- Site Reliability Engineering（Google）
+
+### 开源工具
+- Chaos Mesh：https://chaos-mesh.org/
+- Litmus Chaos：https://litmuschaos.io/
+- Chaos Blade：https://github.com/chaosblade-io/chaosblade
+- Gremlin：https://www.gremlin.com/
+
+### 最佳实践
+- Principles of Chaos Engineering：https://principlesofchaos.org/
+- Chaos Engineering at Netflix：https://netflixtechblog.com/tagged/chaos-engineering
+- Amazon GameDay：https://aws.amazon.com/blogs/awscn/the-aws-game-day/

package/operations/incident-command-system.md

@@ -0,0 +1,38 @@
+---
+id: incident-command-system
+title: incident-command-system
+domain: operations
+category: incident-command-system.md
+difficulty: intermediate
+tags: [command, incident, operations, system]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 开发：Excellent（11964948@qq.com）
+
+## 事故指挥体系（ICS）手册
+
+### 目标
+- 在生产事故中实现统一指挥、快速止损、清晰协同。
+
+### 角色定义
+- 指挥官：统一决策与优先级管理。
+- 技术负责人：定位根因与恢复方案执行。
+- 沟通负责人：对内对外同步状态与影响。
+- 记录员：维护时间线与关键决策记录。
+
+### 响应流程
+- 事故分级：按用户影响与业务损失快速定级。
+- 首轮止损：优先保护关键交易链路与数据一致性。
+- 分工执行：并行推进定位、恢复、沟通。
+- 持续更新：固定时间窗发布状态更新。
+- 关闭与复盘：确认恢复、收敛风险、输出复盘。
+
+### 执行门禁
+- P1及以上事故必须启用指挥角色。
+- 关键决策必须有时间戳与责任人。
+- 事故结束后24小时内提交初版复盘。
+
+### 常见失败模式
+- 没有单一指挥导致多头决策冲突。
+- 恢复后不复盘，问题重复发生。