当您无法重现环境时，如何进行测试和优化？

过去，我曾在多种环境中工作过。桌面应用程序，游戏，嵌入式内容，Web服务，命令行作业，网站，数据库报告等。所有这些环境都具有相同的特征：无论它们的复杂性如何，无论它们的大小如何，我都可以始终在我的机器上或开发环境中对应用程序的子集或分片进行测试。

今天我没有。今天，我发现自己处于主要关注可伸缩性的环境中。复制环境的成本过高。截取一部分环境，虽然很合理（某些部分需要模拟，或者不能在单实例模式下使用），但由于破坏了并发性和负载真正的系统遇到。即使是小的“测试”系统也有其缺陷。当您有2个节点和64个节点时，事情的表现会有所不同。

我通常的优化方法（度量，尝试某些操作，验证正确性，度量差异，重复）在这里不起作用，因为我无法有效地对问题的各个部分（并发鲁棒性和性能降低）进行第2步和第3步加载）。这种情况似乎并不独特。在这种环境下执行此类任务的常用方法是什么？

有一些相关的问题：

• 这个问题与硬件（如频谱分析仪）不可用有关，可以（相对）轻松地进行仿真。
• 这个问题是关于追踪仅存在于生产环境中的错误，这很有帮助-但是是另一种活动。

实际上这很困难，但是我可以肯定，在许多类似的情况下，这主要是组织问题。唯一可行的方法可能是综合措施的混合，而不仅仅是“一个银弹”。您可以尝试以下操作：

• 日志记录：正如我在评论中已经提到的那样，过多的时间和资源日志记录（这是一种概要分析）可以帮助您确定生产中的真正瓶颈。这可能不会告诉您替代实现是否会更好，但是它肯定会帮助您避免优化应用程序中完全错误的部分。

• 测试您可以预先测试的内容-进行全面的预先计划。当然，生产中事物的行为会有所不同，但并非所有事物。通常可以事先检查不同实现的正确性-如果实现的伸缩性很好，那就是另一个问题。但是计划可以有很大帮助。认真考虑一下您的测试环境可以为您解决的问题，哪些不是。乍一看，您总会相信有些事情“无法事先进行测试”，但是如果三思而后行，通常还有更多可能。

• 团队合作。当尝试一种新方法或想法时，请与您团队中的至少另一个人进行讨论。当您实施其他算法时，请坚持进行代码检查和质量检查。您可以事先避免的错误和问题越多，在生产中必须解决的问题就越少。

• 由于您无法事先测试所有内容，因此请预见生产中会出现问题。因此，在将新代码投入生产时，尝试准备一个非常好的后备策略。当您的新代码有比旧解决方案慢的风险或崩溃的风险时，请确保可以尽快更改为先前版本。如果存在破坏生产数据的风险，请确保已进行了良好的备份/恢复。并通过在系统中添加一些验证机制来确保检测到此类故障。

• 认真保存项目日记或解决方案日志。每天您都会发现有关环境的新知识，并写下来-成功案例和失败案例。不要两次犯同样的错误。

因此，要点是-当您无法尝试时，最好的选择是保守的，经典的前期计划和质量检查技术。

如果您无法重现现场环境，那么令人不舒服的现实是，无论您做什么，都不会经过充分的测试。

所以，你可以做什么？

好吧，无论需要扩展什么，无论是进程，服务器群集还是数据库卷，都应该在零，一，无穷大规则的基础上进行测试，以弄清楚潜在的瓶颈/局限性是IO，CPU，CPU负载，内部-过程通讯等

一旦有了这些，您就应该对受影响的测试类型有所了解。如果是单元测试，则通常由开发人员负责，如果是集成/系统测试，则可能与其他团队有接触点，他们可能会协助提供更多的专业知识或更好的工具。

说到工具，开发人员没有能力在其开发环境中进行超出系统负载的测试。这应该推送到测试部门或其他第三方。

当然，房间里的大象是系统并不总是以可预测的方式扩展！

在过去，我曾是拥有数十亿行的银行数据库的DBA，并且拥有执行计划，我们通常可以预测在给定输入量的情况下，对空闲数据库进行的查询将花费多长时间。但是，一旦这些卷达到一定​​大小，除非调整查询/数据库，否则执行计划将改变并且性能将迅速下降。

我建议实验。

日志记录将发现瓶颈。然后，您可以在某些计算机上甚至在所有计算机上以一定概率或在有限的时间段内尝试另一种实现。然后再次比较日志以检查是否有改进。

这与您习惯的理论-实验-测量周期相同，但设置成本较高-因为必须在生产中运行假设-并且根据您的数量，从生产中接收大量数据的过程也可能很慢。