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