1. 课程导论：可靠性评审与混沌工程的关系、基线核验的重要性、数据传输优化的必要性
1.1 可靠性评审与混沌工程：从被动防御到主动验证
在传统软件工程中，可靠性评审通常依赖架构评审、代码审查、故障模式与影响分析（FMEA）等静态手段。这些方法虽然能发现设计缺陷，但无法验证系统在真实分布式环境下的容错边界。混沌工程（Chaos Engineering）的引入，将可靠性验证从“假设性评审”推进到“实验性验证”阶段。
两者的核心关系可归纳为下表：
| 维度 | 可靠性评审（传统） | 混沌工程（动态） |
|---|---|---|
| 验证方式 | 静态文档审查、专家经验判断 | 线上/预发环境注入故障，观察系统行为 |
| 覆盖范围 | 已知风险清单、架构设计假设 | 未知边界、级联故障、非线性行为 |
| 输出结果 | 评审报告、整改建议 | 稳态偏差、爆炸半径、恢复时长 |
| 迭代周期 | 版本发布前一次性评审 | 持续实验、持续改进 |
| 协同关系 | 提供混沌实验的假设来源 | 反向验证评审结论的有效性 |
关键认知：可靠性评审定义“系统应该怎样”，混沌工程验证“系统实际怎样”。两者形成闭环——评审输出实验假设，实验反馈修正评审盲区。
下图展示了可靠性评审与混沌工程在系统生命周期中的协同流程：
1.2 基线核验：混沌实验的“度量基准”
基线核验（Baseline Verification）是混沌工程实验的前提条件。没有经过核验的基线，实验产生的偏差数据无法被正确解读。基线核验的核心任务包括：
- 稳态指标定义：确定系统在正常负载下的关键性能指标（KPI），如 P99 延迟、吞吐量、错误率、CPU 利用率。
- 数据采集校准：验证监控系统、日志采集、链路追踪的数据准确性，确保实验观测数据可信。
- 环境一致性检查：确认实验环境与基线环境在配置、流量、依赖服务版本上保持一致。
- 噪声排除：识别并剔除由非实验因素（如定时任务、自动扩缩容）引起的指标波动。
实践建议：基线核验应至少持续运行 24 小时，覆盖业务高低峰周期，并记录指标的均值、标准差和百分位分布。建议将基线数据存入时序数据库，作为后续所有混沌实验的“零时刻”参考。
基线核验的典型工作流如下：
1.3 数据传输优化：混沌实验的“效率瓶颈”
在混沌工程实验中，数据传输效率直接影响实验的时效性和准确性。典型问题包括：
- 实验指令下发延迟：故障注入指令从控制面传输到目标节点时，若网络拥塞或序列化效率低，会导致实验开始时间漂移，破坏基线对比的精确性。
- 观测数据回传积压：实验期间产生的指标、日志、链路数据量激增，若传输通道带宽不足或压缩策略不当，会造成数据丢失或延迟，影响偏差分析的实时性。
- 控制面与数据面耦合：部分混沌平台将实验编排与数据传输共用同一通道，导致实验控制指令与观测数据互相争抢带宽。
常见陷阱：许多团队在首次实施混沌工程时，只关注故障注入本身，忽略了数据传输路径的容量规划。结果实验执行后，观测数据延迟到达，导致基线核验窗口错位，最终得出错误的可靠性结论。
数据传输优化的核心策略包括：
| 优化方向 | 具体措施 | 预期收益 |
|---|---|---|
| 协议优化 | 使用 gRPC 双向流替代 HTTP 轮询；采用 Protobuf 序列化 | 减少传输延迟 40%~60% |
| 数据压缩 | 对观测数据启用 Snappy/Zstd 压缩；按时间窗口批量发送 | 降低带宽占用 50%~70% |
| 通道分离 | 控制指令走独立长连接；观测数据走异步消息队列 | 消除指令与数据的带宽争抢 |
| 本地缓存 | 实验节点本地缓存观测数据，网络恢复后批量回传 | 防止数据丢失，保障基线完整性 |