我一直在考虑这个问题。这个想法是PROD出了问题。捕获的数据导致Web应用程序的行为与其他环境不同。因此，其他环境中的数据也与prod不同步（如预期的那样）。但是，出现了一个错误，由于某些原因它只发生在PROD中，可能是因为数据存在差异。
我想知道解决这些问题的好方法是什么？肯定会有更多测试。但除此之外？可以在dev中创建新数据，但重点是某些数据点或某些操作组合会导致数据点出错。也许当使用其他数据源到达“实际”数据点时，这与“预期”数据点不同。道歉这不是一个很好的描述，并试图成为一般生产错误的一个例子和定义。
我知道这不是一个非常精确的问题。希望有参考文献可以提出好的建议。
答案 0 :(得分：4)
这是一个非常有趣的问题。我之前使用的一种方法是刻意进行生产中的最终测试（TIP）。
在你用多针尖针勾住我的肖像之前，在我谈论持续部署时，请听我一会儿： - ）
我们的想法是将新版本部署到生产环境中，然后使用自定义路由来引导新旧生产版本之间的流量。原则上这很简单：首先将旧构建路由到当前客户，然后将新构建路由到工程团队。您的客户看不到任何变化。但是你的团队可以开始测试你的新版本，包括灾难恢复和压力测试等杂乱的东西。您希望能够发现您在问题中谈到的错误类型。
如果出现问题，那么您只需回滚新版本即可。如果您的测试没有发现任何问题，那么您将推出5％的客户群。然后是10％和20％等等。
虽然原则上很简单，但从一开始就需要制定一些问题。第一个是数据和数据模式，它们需要在新旧构建中正确运行。只要您的Web应用程序使用的服务设计为在部署新构建后至少处理一次回滚，并且您的新构建同时理解旧数据和新数据，那么您应该没问题。
第二个问题是API /接口更改。您不需要编辑或删除方法或参数，而是需要创建一个新的API /接口，该接口主要重定向到旧的API /接口，但新的/更改的代码除外。
其他问题包括构建之间的配置和设置的不兼容更改。这些问题并不是致命的，但您需要事先进行一些规划和测试。最重要的是，您可以安全地在生产中对代码进行最终测试，而不会影响您的客户。
有关生产测试的一些链接：