在我见过的大多数公司中，生产/准备二分法都以 Facebook 的实时信息流作为示例，表达如下：
- prod（显然）会及时了解新发布的帖子、消息等
- 暂存环境是具有自己的数据库的生产快照，不会使用新的生产数据进行更新
- 当用户（在生产环境中）创建新帖子时，该帖子会出现在生产环境中，但不会出现在任何预先存在的暂存环境中
有了这样的设置，当一个新功能需要在投入生产之前进行“实时”测试时，唯一的方法就是基于生产数据库的快照创建一个暂存环境，然后在其上测试新功能。
当测试的功能严重依赖不断涌入的新数据的复杂组合并与之交互时，这种情况就会非常不利。例如，这些功能可以是改变新帖子在其他用户的推送中显示的方式，或者根据用户刚刚点赞的帖子推荐内容。或者它也可能依赖于流入的外部数据，例如天气或来自外部新闻机构的文章等。或者它可能是机器学习算法，可以预测用户下一步会做什么，并实时对任何传入的数据做出反应。
在明显的初步测试阶段之后，我们需要评估新功能在实际生产环境中新数据流入时的实际表现，而不是基于一些静态模拟用例的理论。
在我看来，上述要求最好通过“实时暂存”环境来处理，该环境是 prod 的精确副本，并且会像 prod 一样继续使用新数据进行更新。与 prod 的唯一区别在于需要测试的新代码。在这个暂存环境中，QA 测试人员将能够在新数据到达时测试这个新系统的工作方式。
然而，我必须说，到目前为止，我工作过的公司都没有这种能力，在所有这些公司中，“暂存”意味着产品的冻结快照，而处理上述“依赖实时数据”功能的唯一方法是诉诸费力的手动测试，涉及奇怪的模拟数据提取（创建具有虚假用户的虚假帖子，或模拟外部传入数据，这既低效又不可靠）。
在内部讨论时，答案通常是“我们没有时间”或“我看不出这有什么用，只需手动添加一些数据就可以了”。所以我的问题是：
- 您现在/过去的公司是否有这样的“实时登台”环境？
- 实现这种环境本身是否存在困难？
- 这种能力在“成熟”公司（Facebook、Google、Twitter……）中是否很常见？
- 您对那些致力于发展这种能力的公司有什么建议？
- 最后但同样重要的一点是，业界是否有一个通用术语来表示这种能力？