SRE 故障预案与演练：从纸上谈兵到肌肉记忆的工程实践

# [服务名] 应急卡片

## 故障特征
- 核心指标：P99 延迟 > 500ms 或 错误率 > 1%
- 典型告警：service_latency_p99_critical / service_error_rate_high

## 快速止血（按优先级）
1. 确认是否正在发布 → 是则立即回滚
2. 检查下游依赖状态 → [依赖面板链接]
3. 切换流量到备用集群 → [切换脚本链接]
4. 通知业务方降级非核心功能 → [降级开关列表]

## 升级条件
- 5 分钟内未止血 → 升级到 SRE Lead
- 影响交易链路 → 立即升级到 P0 事故

## 联系人
- 服务负责人：@xxx
- DBA：@yyy
- 业务方：@zzz

编写 → 评审 → 演练验证 → 修正 → 归档 → 定期复审 → 更新 → 再演练

场景示例：
- 触发条件：周五 17:30，订单服务 P99 延迟从 80ms 飙到 2s
- 影响范围：下单接口超时率 30%，支付回调延迟
- 约束条件：不能全量切流（备用集群容量只够 50%）
- 附加干扰：值班同学正在处理另一个 P2 告警

#!/usr/bin/env python3
"""
红蓝对抗演练记录器
记录蓝队每个操作的时间戳，用于事后分析 MTTR 各阶段耗时
"""
import json
import time
from datetime import datetime
from pathlib import Path

class DrillRecorder:
    def __init__(self, scenario_name: str):
        self.scenario = scenario_name
        self.start_time = time.time()
        self.events = []
        self.phases = {
            "detect": None,    # 故障发现时间
            "acknowledge": None,  # 值班响应时间
            "diagnose": None,  # 定位原因时间
            "mitigate": None,  # 止损执行时间
            "resolve": None,   # 完全恢复时间
        }

    def log(self, phase: str, action: str, operator: str, detail: str = ""):
        """记录一个演练事件"""
        elapsed = round(time.time() - self.start_time, 1)
        event = {
            "timestamp": datetime.now().isoformat(),
            "elapsed_sec": elapsed,
            "phase": phase,
            "action": action,
            "operator": operator,
            "detail": detail,
        }
        self.events.append(event)
        if phase in self.phases and self.phases[phase] is None:
            self.phases[phase] = elapsed
        print(f"[{elapsed:>7.1f}s] [{phase}] {operator}: {action}")
        if detail:
            print(f"         └─ {detail}")

    def summary(self) -> dict:
        """生成演练复盘报告"""
        report = {
            "scenario": self.scenario,
            "total_mttr": round(time.time() - self.start_time, 1),
            "phases": {},
            "events_count": len(self.events),
        }
        prev = 0
        for phase, t in self.phases.items():
            if t is not None:
                report["phases"][f"{phase}_elapsed"] = t
                report["phases"][f"{phase}_delta"] = round(t - prev, 1)
                prev = t
        return report

    def save(self, path: str = None):
        """保存演练记录到文件"""
        if path is None:
            path = f"drill-{self.scenario}-{int(self.start_time)}.json"
        Path(path).write_text(
            json.dumps({"summary": self.summary(), "events": self.events},
                       ensure_ascii=False, indent=2)
        )
        print(f"\n演练记录已保存: {path}")


# 使用示例
if __name__ == "__main__":
    drill = DrillRecorder("订单服务延迟飙升")

    drill.log("detect", "告警触发", "Prometheus", "P99延迟 2.1s 超过阈值 500ms")
    drill.log("acknowledge", "值班响应", "oncall-zhang", "确认告警，开始排查")
    drill.log("diagnose", "定位原因", "oncall-zhang", "Redis 连接池耗尽导致缓存命中率下降")
    drill.log("mitigate", "执行止损", "oncall-zhang", "重启 Redis 从节点，切换读流量")
    drill.log("resolve", "完全恢复", "oncall-zhang", "P99 恢复至 85ms")

    drill.save()

# 网络延迟注入：给订单服务的 Pod 注入 200ms 网络延迟
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: order-service-network-delay
  namespace: chaos-testing
spec:
  action: delay           # 故障类型：延迟
  mode: all               # 影响所有匹配的 Pod
  selector:
    namespaces:
      - production
    labelSelectors:
      "app.kubernetes.io/name": "order-service"
  delay:
    latency: "200ms"      # 延迟 200ms
    correlation: "0"      # 延迟不相关性
    jitter: "50ms"        # 抖动 50ms，模拟真实网络
  direction: to           # 出站流量
  target:
    selector:
      namespaces:
        - production
      labelSelectors:
        "app.kubernetes.io/name": "payment-service"
    mode: all
  duration: "5m"          # 持续 5 分钟
  scheduler:
    cron: "@once"

# Pod 故障注入：随机 kill 订单服务的 30% Pod
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: order-service-pod-kill
  namespace: chaos-testing
spec:
  action: pod-kill        # 故障类型：杀 Pod
  mode: fixed-percent     # 按比例
  value: "30"             # 30% 的 Pod
  selector:
    namespaces:
      - production
    labelSelectors:
      "app.kubernetes.io/name": "order-service"
  duration: "0"           # 立即执行
  scheduler:
    cron: "@once"

#!/bin/bash
# 混沌演练一键中止脚本
# 用法：./chaos-abort.sh

set -euo pipefail

NAMESPACE="chaos-testing"
DRY_RUN="${1:-false}"

echo "=== 混沌演练紧急中止 ==="
echo "时间: $(date '+%Y-%m-%d %H:%M:%S')"
echo ""

# 列出所有正在执行的混沌实验
EXPERIMENTS=$(kubectl get networkchaos,podchaos,iochaos,stresschaos \
  -n "$NAMESPACE" \
  -o custom-columns=NAME:.metadata.name,KIND:.kind \
  --no-headers 2>/dev/null || true)

if [ -z "$EXPERIMENTS" ]; then
  echo "当前没有正在执行的混沌实验。"
  exit 0
fi

echo "正在执行的混沌实验："
echo "$EXPERIMENTS"
echo ""

if [ "$DRY_RUN" = "true" ]; then
  echo "[DRY-RUN] 将删除以上所有混沌实验资源。"
  exit 0
fi

# 删除所有混沌实验资源
kubectl delete networkchaos,podchaos,iochaos,stresschaos \
  -n "$NAMESPACE" --all

echo ""
echo "所有混沌实验已清除。等待 30 秒让系统自动恢复..."
sleep 30

echo "=== 系统状态检查 ==="
kubectl get pods -n production --field-selector=status.phase!=Running
echo ""
echo "如果以上有异常 Pod，请手动检查。"

故障发生 ─→ 发现 ─→ 响应 ─→ 定位 ─→ 止损 ─→ 验证 ─→ 恢复
            MTTD    MTTA   MTTD-i   MTTF    MTTR-v
|_______________________ MTTR ___________________________|

演练场景：订单服务延迟飙升
───────────────────────────────────
发现(detect):     12.3s   ✓  告警及时
响应(acknowledge): 38.7s  ⚠  On-Call 响应偏慢（在处理另一个告警）
定位(diagnose):   156.2s  ✗  花了2分钟才确认是Redis问题
止损(mitigate):   203.1s  ⚠  手动切换耗时过长
验证(resolve):     45.0s  ✓  自动化健康检查有效
───────────────────────────────────
总 MTTR: 455.3s (7.6分钟)

# Game Day 复盘模板

## 基本信息
- 日期：2026-07-16
- 场景：订单服务 + 支付服务双故障
- 参与人员：8 人（蓝队 5 人 + 红队 2 人 + 观察员 1 人）
- 总耗时：47 分钟

## MTTR 分解
| 阶段 | 耗时 | 评价 | 备注 |
|------|------|------|------|
| 发现 | 15s | ✓ | 告警及时 |
| 响应 | 52s | ✓ | On-Call 30s 内上线 |
| 定位 | 8min | ⚠ | 同时排查两个服务，缺乏优先级判断 |
| 止损 | 12min | ✗ | 手动切换脚本失败，改用备用方案 |
| 验证 | 3min | ✓ | 自动化探活有效 |
| **总 MTTR** | **24min** | **需改进** | 目标 < 15min |

## 发现的问题
1. [P0] 切换脚本 `switch-traffic-v2.sh` 在新环境未验证，缺少依赖
   - Owner：@devops-li / Deadline：2026-07-23
2. [P1] 双故障场景没有明确的优先级判断标准
   - Owner：@sre-lead / Deadline：2026-07-20
3. [P2] 通讯链路过长：值班 → SRE Lead → 业务方 → 管理层，4 级传递耗时 5 分钟
   - Owner：@sre-lead / Deadline：2026-07-30

## 做得好的地方
- On-Call 响应迅速，30 秒内确认告警
- 自动化探活脚本有效，止损后 3 分钟内确认恢复
- 观察员记录详实，复盘有据可查

incident-playbook/
├── README.md
├── L1-cards/                    # 应急卡片
│   ├── order-service.md
│   ├── payment-service.md
│   └── redis-cluster.md
├── L2-dr/                       # 灾备预案
│   ├── multi-region-failover.md
│   └── database-disaster-recovery.md
├── L3-bcp/                      # 业务连续性预案
│   ├── datacenter-loss.md
│   └── ransomware-response.md
├── drill-records/               # 演练记录
│   ├── 2026-07-16-gameday.md
│   └── 2026-07-01-desktop-drill.md
└── scripts/                     # 自动化脚本
    ├── traffic-switch.sh
    ├── chaos-abort.sh
    └── health-check.sh

# GitLab CI 配置示例：每周自动执行一次小范围混沌实验
chaos-drill-weekly:
  stage: test
  image: bitnami/kubectl:latest
  schedule:
    - cron: "0 2 * * 1"      # 每周一凌晨 2 点
  script:
    - # 1. 确认系统健康基线
    - kubectl get pods -n production --field-selector=status.phase!=Running | tee /tmp/unhealthy-pods.txt
    - if [ -s /tmp/unhealthy-pods.txt ]; then echo "系统存在不健康 Pod，取消演练"; exit 1; fi

    - # 2. 注入小范围故障（杀 1 个非核心 Pod）
    - kubectl apply -f chaos-experiments/low-risk/pod-kill-non-critical.yaml

    - # 3. 等待 5 分钟
    - sleep 300

    - # 4. 检查自动恢复
    - kubectl get pods -n production --field-selector=status.phase!=Running | tee /tmp/post-drill.txt
    - if [ -s /tmp/post-drill.txt ]; then echo "演练后存在异常 Pod，需要人工介入"; exit 1; fi

    - # 5. 清理混沌实验
    - kubectl delete -f chaos-experiments/low-risk/pod-kill-non-critical.yaml

    - # 6. 发送演练报告
    - |
      cat << EOF | mail -s "[混沌演练] 周例行报告" sre-team@company.com
      演练时间：$(date)
      演练内容：随机杀 1 个非核心 Pod
      结果：通过（自动恢复正常）
      下一轮计划：周五 Game Day 全场景演练
      EOF      
  only:
    - schedules

## 改进项看板

### 待处理
| ID | 优先级 | 描述 | Owner | Deadline | 状态 |
|----|--------|------|-------|----------|------|
| 001 | P0 | 切换脚本 v2 在新环境未验证 | @devops-li | 07-23 | 进行中 |
| 002 | P1 | 双故障优先级判断标准缺失 | @sre-lead | 07-20 | 待开始 |

### 已完成
| ID | 优先级 | 描述 | Owner | 完成日期 | 验证方式 |
|----|--------|------|-------|----------|---------|
| 000 | P0 | Redis 连接池监控告警缺失 | @sre-wang | 07-10 | 07-15 演练验证 |

P0 故障沟通矩阵：
├── 0-1min: On-Call 确认故障 → 通知 SRE Lead
├── 1-3min: SRE Lead 评估影响 → 通知业务方负责人
├── 3-5min: 业务方评估用户影响 → 决定是否通知管理层
├── 5-15min: 每 5 分钟同步进展 → 发到事故群
└── 恢复后: 24h 内提交事故复盘报告