1. 课程导论：混沌工程与基线核验的概念、自助服务门户的价值、驱动开发（TDD/BDD）在混沌工程中的应用
1.1 混沌工程的核心定义与目标
混沌工程是一门在分布式系统上进行实验的学科，旨在通过主动注入故障来建立对系统抵御生产环境中动荡条件能力的信心。其核心目标并非“制造混乱”，而是通过受控实验提前发现系统性弱点，从而提升系统的韧性与可观测性。
关键原则：混沌工程不是随机的破坏行为，而是遵循“假设→控制变量→注入故障→测量→改进”的科学实验循环。
| 维度 | 传统压力测试 | 混沌工程实验 |
|---|---|---|
| 目标 | 验证容量极限 | 验证系统行为与韧性假设 |
| 故障注入 | 预定义、批量式 | 持续、渐进、随机性 |
| 观测指标 | 吞吐量、响应时间 | 稳态偏差、错误预算消耗 |
| 自动化程度 | 通常手动或半自动 | 高度自动化、集成CI/CD |
1.2 基线核验：混沌实验的“度量衡”
基线核验是指在执行混沌实验之前，先定义并验证系统的正常稳态指标（如P99延迟、错误率、CPU饱和度）。只有明确了“正常”的边界，才能准确判断故障注入后系统是否发生了不可接受的退化。
- 定义基线：从生产或预发环境的监控数据中提取关键性能指标（KPI）。
- 核验动作：在实验前、实验中、实验后持续采集指标，并与基线进行比对。
- 通过标准：若实验期间指标波动未超出基线阈值（如延迟上升不超过20%），则判定系统通过核验。
实践建议：基线核验应作为混沌实验的“准入条件”与“退出条件”。基线未达标时，禁止执行故障注入；实验后基线恢复，方可结束实验。
1.3 自助服务门户的价值
在传统混沌工程实践中，实验配置、基线管理、报告查看高度依赖运维或SRE团队，导致实验周期长、协作成本高。自助服务门户将混沌工程能力产品化，使开发、测试、运维人员能够通过统一的Web界面自主完成实验。
- 降低门槛：无需掌握底层故障注入工具（如ChaosBlade、Litmus）的复杂命令行参数。
- 标准化流程：内置基线核验模板、实验审批流、自动回滚策略，确保实验安全可控。
- 可视化反馈：实时展示实验状态、指标曲线、核验结果，加速问题定位。
| 角色 | 自助门户带来的收益 |
|---|---|
| 开发工程师 | 在发布前自助执行“冒烟级”混沌实验，验证代码韧性 |
| 测试工程师 | 将混沌实验纳入测试用例库，实现回归验证 |
| SRE/运维 | 从重复的配置工作中解放，专注于实验策略与平台建设 |
| 技术管理者 | 通过门户仪表盘查看团队混沌实验覆盖率与系统韧性趋势 |
1.4 驱动开发（TDD/BDD）在混沌工程中的应用
将测试驱动开发（TDD）和行为驱动开发（BDD）的理念引入混沌工程，意味着在编写故障注入脚本之前，先定义期望的系统行为与核验断言。
- TDD 模式：先编写基线核验断言（如“当CPU负载达到90%时，P99延迟应小于500ms”），再编写故障注入逻辑，最后重构实验脚本。
- BDD 模式：使用自然语言描述实验场景（Given…When…Then），例如：Given 订单服务正常运行，When 注入数据库连接超时，Then 订单创建接口应返回降级响应且错误率不超过1%。
常见误区：不要将TDD/BDD简单理解为“先写测试再写代码”。在混沌工程中，核心是先定义可量化的韧性契约，再通过实验验证契约是否被满足。
1.5 课程核心架构总览
本课程将围绕“自助服务门户 + 基线核验 + 驱动开发”三位一体的实践体系展开。后续章节将逐步实现从门户设计、基线管理、故障注入引擎集成到TDD/BDD实验编排的完整闭环。
- 第2-5章：自助门户UI/UX设计与前端开发（Vue3 + TypeScript）。
- 第6-10章：基线核验后端服务开发（FastAPI + Prometheus + 自定义核验引擎）。
- 第11-15章：混沌实验驱动开发框架（基于BDD的Gherkin语法 + ChaosBlade适配器）。
- 第16-20章：CI/CD集成与自动化实验流水线。
- 第21-25章：生产级安全策略与多租户隔离。
- 第26-30章：综合实战：构建一个完整的微服务混沌实验基线核验平台。
前置知识：建议读者具备基础的Python、JavaScript、Docker及Linux命令行操作能力。无需预先掌握混沌工程或TDD/BDD经验，课程将从零开始构建。