📚 课程目录第4章环境搭建与实验设计

4. 环境搭建与实验设计：测试环境准备与故障注入实验设计原则

环境搭建这事儿，说简单也简单，说复杂能让你折腾一整天。我刚开始做故障注入测试时，总觉得随便拉几台机器就能开干。结果呢？实验数据根本没法看——基线都不稳，你注入的故障到底是真有效还是环境抖动，根本分不清。

所以这一章，咱们把环境搭建和实验设计的原则掰开揉碎了讲。说白了，就是让你少走弯路。

先回答一个最实际的问题：我该用哪种环境？

三种环境各有各的脾气，我列个表给你看：

环境类型	隔离性	故障注入精度	成本	典型场景
虚拟机	高（Hypervisor 隔离）	中（受宿主机影响）	中	OS 级故障、网络故障、磁盘故障
容器	低（共享内核）	高（轻量、快速）	低	应用级故障、微服务链路、资源限制
物理机	最高	最高	高	硬件故障、驱动层、固件层、性能基准

我个人习惯是：能用容器先用容器。为什么？因为快。你想想看，故障注入测试往往需要反复调整参数，容器秒级启停，虚拟机至少得等几十秒，物理机就更别提了。

但注意，容器有个坑——它共享宿主机内核。如果你要测试内核崩溃、硬件中断这类故障，容器根本模拟不出来。这时候就得用虚拟机或者物理机。

我的经验： 做微服务链路故障注入，用容器就够了。做操作系统级别的故障，用虚拟机。做硬件可靠性验证，别省那点钱，上物理机。

环境搭好了，接下来就是怎么设计实验。我见过太多人上来就乱注入，结果数据一团糟。

记住三个核心原则：

举个例子。我曾经帮一个团队做数据库故障注入，他们直接在线上环境搞了个磁盘 IO 延迟注入。结果呢？数据库主从同步延迟飙到 30 秒，差点引发雪崩。这就是没做好安全隔离。

警告： 故障注入测试必须在隔离环境中进行。绝对不要在未做风险评估的情况下对生产环境做故障注入。

这是整个实验设计的核心。说白了，就是你要知道「正常」是什么样，才能判断「故障」造成了什么影响。

基线就是系统在无故障状态下的表现。我建议你至少采集以下指标：

采集时间至少持续 24 小时，覆盖业务高峰期和低峰期。别只跑 10 分钟就完事——那叫快照，不叫基线。

  关键点： 基线不是一条线，而是一个区间。比如 CPU 使用率在 30%-50% 之间波动，这就是正常范围。注入故障后，如果 CPU 飙到 90% 以上，那才是异常。

一次只改变一个变量。这是实验设计的基本功。

比如你要测试网络延迟对系统的影响：

每次只改延迟这一个参数，其他条件保持不变。这样你才能确定：响应时间变慢，确实是因为网络延迟，而不是因为 CPU 被其他进程抢占了。

我曾经犯过一个错误：同时注入了 CPU 压力和网络延迟，结果系统挂了，我根本分不清是哪个故障导致的。后来花了整整两天才排查出来。

避坑指南： 每次实验前，先恢复环境到基线状态。我习惯用快照或者容器镜像来保证环境一致性。

实验流程标准化，能省掉你 80% 的排查时间。我一般按这个步骤来：

数据记录一定要自动化。手动记录？不存在的。我见过有人用 Excel 手动记，结果漏了关键时间点，整个实验白做。

下面这张图展示了整个实验设计的核心流程：

最后，给你一份我常用的环境搭建检查清单。每次做实验前，对着过一遍：