在找到描述稳定状态的业务指标并建立稳定状态的假设后，继而采用注入多样的现实世界事件的方式验证微服务稳定性，但在什么样的环境中进行验证呢？因为稳定性的验证需要注入事件来观察对系统有什么样的影响，这种验证方式和做科学实验一样。问题变为在什么样的环境中进行实验呢？
我们测试提倡尽早的发现问题，越早发现越好，最好在需求阶段或方案阶段的静态测试发现，其次是在单元测试、集成测试、系统测试，最后是在生产环境中发现不了问题。测试的一个经典信条是寻找软件的缺陷要离生产环境越远越好。在越接近生产环境中调试，涉及的服务和系统越多越复杂，越难找到问题的原因。但是在混沌工程领域，整个策略却要反过来，离生产环境越近的地方实验越好，这是为什么呢？因为在混沌工程的实验时，我们所感兴趣的是整个系统作为一个整体的行为。整个系统包括代码，状态，输入以及第三方系统导致的难以遇见的系统行为。此外我们要在生产环境中建立系统的信心。
有状态服务
在微服务架构中，我们提单的状态通常指有状态服务，如数据库服务。仅仅用数据库保存测试设置开关这样的系统和用数据库保存已生产数据的系统在行为上是不同的。其他一些有状态服务包括缓存服务、对象存储服务以及可持久化的消息服务。配置数据是另外一种影响系统行为的状态。无论使用静态配置文件夹还是动态配置服务如etcd，这些配置信息本身也是一种状态。
即使在无状态的服务中，状态仍然在内存中以数据结构的形式存在于请求之间。
在云服务中，一个人自动弹缩组中心虚拟机或者容器个数也是一种状态，这种状态随时间和外部需求或集群变化而不断变化。
生产环境中的输入
用户永远不会如你预期的那样与生产系统交互，这个问题在设计系统的UI时尤为重要。
试想一下，系统提供一个可以从用户接收不同类型请求的服务。你可以为用户输入设计一个数据模型组合，但因为用户永远不会如你所预期般地行动。
真正对系统建立信心的唯一方法是在生产环境中真实的输入数据进行验证并实验。
第三方系统(外部有效性)
我们虽然可以预见所有在控制范围内下系统的状态，但总是会依赖于外部系统，这些外部系统的行为不可能全部知道。
如果你的微服务运行在AWS这样的云服务中，那么所依赖的大量的又不完全了解的外部服务的存在必然有故障存在的风险。即使是全部运行在自己的数据中心上，你也会发现在生产环境中微服务还是会依赖其他的外部服务，例如dns和ntp等。
第三方系统在自己的生产环境中的行为总是和它与其他环境集成的大环境中的行为有所不同。这也强调了在生产环境中进行实验的必要性，生产环境是微服务和第三方系统进行真实交互的唯一场所。
生产环境变更
微服务版本在不断变更，微服务所运行的云服务以及k8s平台版本变更，都需要升级。生产环境中的这些变更，很明显在测试环境中想要模拟这些行为非常困难。
参考资料：侯杰翻译的《混沌工程》之在生产环境中实验
