生产环境测试：金丝雀、暗发布、影子流量与生产流量回放

① 流量失真：压测流量 ≠ 真实用户行为（缓存命中率、并发模式、尾延迟都不同）
② 数据失真：造的数据 ≠ 生产数据分布（长尾、脏数据、真实 Schema）
③ 规模失真：测试环境永远比生产小，配置/拓扑不同

结论：某些问题（配置错误、规模相关缺陷、真实依赖故障）只在生产暴露
——但不是「都到生产测」，而是「把不可替代的生产验证最小化、安全化」。

金丝雀放量阶梯：
  1% 流量 → 5% → 25% → 50% → 100%
每个阶梯停留一段时间（如 10-30 分钟），观察指标无恶化再继续

放量维度：
  按用户百分比 / 按区域 / 按客户端版本 / 按内部员工（内测金丝雀）

金丝雀观察指标（分级）：
  - 黄金指标：错误率、延迟 P99、成功率（必看）
  - 业务指标：转化率、订单量、接口调用量（不可回退的防呆）
  - 系统指标：CPU/内存/GC（资源异常）
  - 依赖指标：下游调用错误率（连锁反应）

判定规则：
  任一黄金指标超过基线阈值 → 立即停止放量 + 自动回滚

# 伪代码：金丝雀自动判定
def canary_decision(canary, baseline, config):
    error_rate = canary.error_rate / max(baseline.error_rate, 1e-6)
    latency_ratio = canary.p99 / baseline.p99
    if error_rate > config.max_error_ratio or \
       latency_ratio > config.max_latency_ratio:
        return "rollback"          # 自动回滚
    if config.budget_ok(canary.traffic_pct):
        return "promote_next"      # 按阶梯继续放量
    return "observe"

暗发布的验证价值：
  - 部署本身正确（能起、能连依赖）
  - 新路径在真实流量下不炸（先小比例内部流量探路）
  - 依赖兼容性（新代码与旧数据/Schema 兼容）

开关粒度：
  全量开关 / 按用户 / 按请求属性 / 按概率

开关本身要测：
  - 开关切换即时生效（无需重启）
  - 开关回切安全（能切回旧逻辑，新旧状态兼容）
  - 开关的组合矩阵：新/旧 × 新/旧依赖的交叉
  - 开关的最终清理：稳定后移除代码与开关（防技术债）

影子链路：
  生产请求 → 主路径（旧版）→ 返回用户
         └→ 影子副本 → 新版本 → 结果对比（离线/异步）
对比维度：
  - 返回一致性：新旧版本响应是否一致（正常路径）
  - 错误一致性：新版本错误率是否过高
  - 副作用差异：写入行为/时序是否异常

影子流量的风险与对策：
  - 影子流量放大负载 → 影子系统独立资源池，限流隔离
  - 影子写入污染 → 影子系统指向影子存储/打标记
  - 影子慢拖累主路径 → 影子请求非阻塞、设超时、异步比对

适用场景：
  - 重构/迁移（DB 迁移、缓存策略变更）的逐请求验证
  - 新版本上线前行为等价性验证
  - 读多写少的系统尤其适合（成本可控）

录制：网关/中间件层录制请求（脱敏后）→ 存储成回放集
回放：按原始时序/并发重放到目标系统 → 断言行为

回放价值：
  - 真实负载：用线上流量压新版本（最真实的压测）
  - 行为等价：新旧版本对相同请求的响应比对
  - 回归发现：线上特有的边界/脏数据被回放覆盖

回放注意事项：
  - 时序还原：保留请求间隔与并发度（否则不成负载）
  - 脱敏：录制的请求体要脱敏（PII/密钥），或加密存储
  - 响应动态：依赖当前时间的响应，回放时要归一化
  - 幂等校验：回放的重放可能导致副作用，需隔离环境/幂等
  - 覆盖度：录制集要覆盖关键路径与高峰时段

# 伪代码：回放比对
def replay_compare(replay_set, old_version, new_version):
    for req in replay_set:                 # 按原时序
        old_resp = old_version.handle(req)
        new_resp = new_version.handle(req)
        # 归一化后比对（忽略时间戳/随机值等字段）
        assert normalized(old_resp) == normalized(new_resp), \
            f"请求 {req.id} 新旧响应不一致: {old_resp} vs {new_resp}"

生产混沌的规范：
  - 爆破半径：只影响可控范围（如 1 个实例，而非整个集群）
  - 时限：实验有明确起止，超时自动恢复
  - 观测：实验期间全量观测（黄金指标 + 告警）
  - 审批：高影响实验需演练/审批
  - 回滚：任何实验一键终止并恢复

与测试环境的区别：
  测试环境混沌验证「机制有没有」，
  生产混沌验证「真实依赖下机制是否真的能扛」。

生产混沌最小集：
  - 单实例故障（kill 一个 pod）→ 流量漂移正常
  - 依赖超时（下游注入延迟）→ 熔断/降级生效
  - 配置中心抖动 → 配置加载有兜底

观测闭环：
  ① 指标：黄金指标 + 业务指标 + 系统指标（带基线）
  ② 告警：异常即告警，且告警能自动触发回滚
  ③ 日志/追踪：实验流量打标记（canary/shadow），可回溯
  ④ 慢速观察：渐进放量时留足观察窗口

回滚设计：
  - 代码回滚：版本回退（秒级）
  - 流量回滚：放量回切（把流量切回旧版）
  - 配置回滚：特性开关关闭（即时）
  - 数据回滚：写操作要有补偿/可恢复

回滚测试本身：
  演练「发布 → 发现异常 → 回滚」的完整链路，
  保证回滚真的能用（回滚按钮坏了比不发布更危险）。