性能测试测试环境与生产环境_不在生产中测试？在生产中进行测试！-白红宇

性能测试测试环境与生产环境_不在生产中测试？在生产中进行测试！

阅读量：2526 次

发布时间：2019-05-11

本文共 6226 字，大约阅读时间需要 20 分钟。

性能测试测试环境与生产环境

如果您上一次更新IT安全标准是在5年前或更早，那么它们很可能与当今的（SRE）实践的现状不符。一个特别棘手的话题是生产中的测试，以及因此使用生产数据进行的测试，因为DevOps和SRE混淆了什么是生产和什么不是生产之间的界限。什么是测试，什么不是。

为了消除一些困惑，我们将深入研究以下问题：

为什么我们将开发/测试与生产系统分开？

根据生产系统的高标准，我们应该管理什么？

为什么在生产系统上进行测试如此危险？

为什么要在生产中进行测试？

生产数据呢？

如何使生产中的测试风险降低？

我应该指出，这是一个观点。它基于多年的DevOps集体经验和测试经验，但是不应作为IBM的正式声明来阅读。

为什么我们将开发/测试与生产系统分开？

至少从合规性和风险管理的角度来看，区别对待开发，测试和生产系统是一种标准做法，主要是因为它们具有不同的安全性，数据和隐私控制。让我们退后一步，考虑一下对这些部署环境的不同态度的历史原因。

此外，生产系统很特殊，因为它们可以访问生产数据。生产数据必须是可靠的真理来源，因此我们必须保护它免受损坏。生产数据还可能包含我们只能与授权用户共享的信息，例如机密或个人数据，因此我们必须确保其受到生产级身份验证和授权的保护。最后，我们可能需要维护对生产数据访问（创建，读取，更新和删除）的审核跟踪，而对于开发/测试系统则不需要。

^{出于充分的原因，对生产系统进行了更严格的控制和监视。}

我们还需要对生产系统的当前状态具有出色的可视性并对其进行控制。我们会仔细监控它们，以便我们能够快速发现问题，并在出现问题时了解这些系统的当前配置，从而可以更轻松地快速恢复。大多数人都不太在乎开发人员是否更改其个人笔记本电脑上的配置设置，但是我们将生产系统锁定为已知的配置，并具有安全的更改控制。无论我们是通过变更控制数据库还是通过基础架构代码来锁定配置，目标都是相同的：可见性和控制性。

最后，请记住我们对开发/测试和生产系统的管理方式不同，因为存在专门针对生产系统的合规性规则和规定。在我们的开发/测试环境中，没有什么比消除不必要的负担更快地杀死速度了！

根据生产系统的高标准，我们应该管理什么？

当我们开始考虑在生产中进行测试时，我们很快意识到我们是从一个假设开始的：应该容易确定什么是生产环境，什么不是生产环境。但是，就像大多数假设一样，我们错了。开发人员和测试人员希望快速行动；如有疑问，我们倾向于将系统分类为开发/测试而不是生产，因此我们不必处理生产系统管理开销。但是，我们如何知道何时需要实施生产控制？并非全部都是黑白的，但有一些注意事项。

一些更明确的例子：我们可以同意专门为测试而设计的开发人员笔记本电脑和环境（例如，集成测试，系统测试，性能测试）不是生产系统。此外，人们普遍认为，直接或在幕后使用真实数据为真实客户服务的系统是生产系统。还有一些我们仅在内部使用的系统，这些系统对于公司的运营至关重要，因此也被视为生产系统。

^{现代软件开发和交付实践可能会模糊开发，测试和生产系统之间的界线。}

但是，“生产”和“非生产”之间的界线通常取决于您的独特情况和对这些术语的使用：

分期

预生产

直播前

预习

例如，您的暂存环境可能是您仅针对其运行测试的环境，在这种情况下，它更像是一个测试系统。另一方面，您的登台环境可能是业务合作伙伴在发布新API之前用来测试它们的环境。在这种情况下，出于大多数目的和目的，应该像生产系统一样管理它，因为您希望它可以模拟那些API的真实用户体验。对于这种类型的服务器，也许您可以忍受更多的停机时间，但是您应该使用生产质量的身份验证和授权。您应该对服务器配置进行控制，并且应该像生产系统一样监视服务器。

内容管理系统的预览环境是听起来像一种类型但实际上是另一种类型的系统的另一个示例。预览内容尚未发布。也许它也是时间敏感的，例如一个未发布产品的网站。公告发布后，有人将发布新产品的网页供全世界查看；但是在发布之前，它们是高度机密的。因此，预览环境必须比生产环境具有更多的身份验证和授权控制。除非当前用户有权查看预览页面，否则不得渲染预览页面。

我们也应该将它们像生产系统一样对待：

蓝色/绿色部署。为什么？没有流量的备份环境随时可能成为生产环境。

高可用性配置中的备份服务器。为什么？备份服务器可以随时开始提供生产流量。

金丝雀部署。为什么？这些服务仅占生产流量的一小部分。

分阶段推出。为什么？用于生产流量的所有版本的硬件和软件都在“生产中”。

A / B测试服务器。为什么？即使以“测试”为名，它们也为生产流量服务。

将规则和试探法应用于系统和环境时，保持一致很重要。您不应将过渡环境视为生产系统的一天，而将其视为测试系统的第二天。那是灾难的秘诀。确保每个人都了解哪些系统是生产系统，哪些不是，然后记录您团队的决策和任何例外情况。

努力了解哪些系统是生产系统，哪些不是生产系统，并对它们进行适当的处理，将确保您在不损害开发和测试速度的情况下保护生产系统。

为什么在生产系统上进行测试如此危险？

当人们说“不要在生产中进行测试”时，是因为他们想避免几种可能的（不良）结果：

数据损坏或无效

受保护的数据泄漏

错误的收入确认（取消的订单等）

重载系统

对其他生产系统的意外副作用或影响

高错误率会触发警报并呼叫呼叫人员

偏斜的分析（流量漏斗，A / B测试结果等）

包含脚本和漫游器活动的不正确流量日志

不符合标准

为什么我们应该继续进行生产测试？

是的，在生产中进行测试是有风险的，但是我们仍然应该这样做，在罕见或例外的情况下也不应该这样做。这些生产测试已被DevOps和SRE社区接受为最佳实践：

A / B测试和实验

可用性测试和UX研究

蓝色/绿色部署的最终烟雾测试

功能标记

分阶段推出

金丝雀测试

健康检查和其他生产系统监视，包括脚本化的健康测试

网页的视觉回归测试，以比较暂存版本和生产版本

辅助功能回归测试（在初始测试和部署之后）

扫描网页的链接断开并报告错误的脚本

真实用户监控

混沌工程

故障转移测试

高可用性/灾难恢复计划的其他测试

错误赏金计划

生产测试可帮助我们：

防止不良部署破坏生产系统

客观地确定哪种用户体验更有效

设计更令人愉快的用户/站点交互

逐步推出新功能

快速获得关于我们最新更改成败的反馈

在用户注意到之前发现问题

了解网页性能特征和变更影响

建立更具弹性的系统

提高系统质量

通过在部署时或频繁地运行几种类型的生产测试，我们可以满足各种关键的非功能性需求：

	User experiences	可用性	推出变更	反馈	质量	性能	弹性
A / B测试	✔			✔
可用性/ UX	✔			✔	✔
烟雾测试		✔	✔		✔		✔
功能标记	✔		✔	✔
分阶段推出	✔		✔	✔
金丝雀测试		✔	✔	✔			✔
健康检查	✔	✔			✔
回归测试	✔				✔
链接断开检查器	✔				✔
真实用户监控	✔			✔		✔
混沌工程		✔			✔	✔	✔
故障转移测试		✔			✔		✔
HA / DR测试		✔			✔		✔
错误赏金	✔			✔	✔
渗透测试		✔			✔		✔

^{各种生产测试的目标}

…和一个异常值（因为孩子不是总有问题吗？）：第三方渗透（“ pen”）测试。我们应该在生产系统上这样做吗？一方面，它无疑具有风险；例如，如果笔测试人员发现一个注入漏洞，则最终可能会导致数据库中的数据损坏。另一方面，黑客可能每周都会在面向互联网的系统上运行笔测试套件。因此，无论您是否批准笔测试都在您的许多生产系统上进行。这就是为什么我将其包含在此生产测试列表中的原因。我有两个建议：

确保您的聘用笔测试仪在类似于生产环境而不是玩具下工作。

在您的测试系统上运行最受欢迎的安全测试套件，并在所有其他人对您的生产系统运行相同测试之前修复发现的错误。

^{您的生产系统必须能够抵御黑客攻击，并能优雅地对其进行处理。}

最后，您是否注意到这些生产测试有一些共同点？他们都没有制作生产数据的“测试副本”。它们都直接在实际生产系统和数据上运行。

生产数据呢？

这是一条捷径：开发/测试环境可能不需要特殊的测试数据。他们通常可以使用任何人都可以使用的生产数据，例如实际的网页内容，只要您的测试不会修改该数据即可，从而节省了创建测试数据的时间和费用。上一节中的所有生产测试以及许多Web服务和API都属于此类别。

但是要当心！仅仅因为数据可以从Internet上获得或REST API是免费使用的，并不意味着您可以将其用于开发/测试目的。在获取和使用开放数据之前，请确保您了解并遵守任何适用的许可协议和网站使用协议。

如果可以通过使用生产数据节省时间和金钱，那就太好了，但是某些应用程序和服务需要修改数据存储，因此，您还需要进行测试以修改数据。在不破坏生产系统的情况下，很难在生产中运行这些测试。面对这一现实，当有必要修改数据存储以验证测试方案时，大多数开发团队会选择具有不同的数据源：一个用于开发/测试，一个用于生产。但是，您如何设置足够真实和完整的测试数据来进行良好的测试呢？

如果您的生产数据库足够小，您可以从技术上对其进行复制，然后进行测试，但是将生产数据复制到开发/测试环境中会遇到问题，因为它可以绕过安全性和隐私控制。（，有人吗？）

让我们举个例子。您已经放置了经过深思熟虑的安全性和隐私控制。您设置了生产系统，以便只有有“需要知道”的人才能访问任何个人数据；您知道数据存储在哪里；您已经建立了一个流程，可以根据需要从系统中删除个人数据；等等。也许您的数据库中有客户地址和电话号码。如果有人将数据库复制到开发/测试系统，而您未在其中实施安全性和隐私控制，那么您的系统就会出现漏洞。如果客户行使其“擦除权”并要求您删除其地址和电话号码，您将如何知道需要更新哪些开发/测试系统才能删除该信息？如果开发人员的便携式计算机或带有个人数据的测试移动设备被盗怎么办？您是否需要报告并缓解安全漏洞？要消除这些漏洞，您需要将个人数据保留在开发/测试系统之外，或者将开发人员/测试系统包括在您的生产数据合规性范围内，以访问个人数据。

^{用链条锁住笔记本电脑和手机不是最佳方案。} ^{假设这些设备最终将被盗，并决定如何对其进行相应的管理。}

显而易见的替代方法是在开发/测试环境中使用模拟数据，但是很难确定何时使用模拟数据进行测试，因为创建和维护模拟数据既耗时又容易出错。如果从生产数据库开始并手动进行清理以掩盖或删除敏感数据，则可能会丢失某些内容。如果使用清理工具走得太远，可能会破坏数据或限制其测试用途。相反，如果您从头开始构建测试数据库，则很难创建一个良好的测试套件需要包括的所有排列和边缘情况。

只有您和您的队友才能为您的独特目的决定哪个方向是正确的方向，但是以下一些考虑因素将有所帮助：

在使用生产数据之前，请先了解它们上有哪些控件，并尊重这些控件。

确保整个团队都同意敏感数据和个人数据的含义。

定义并接受您用于处理敏感和个人数据的协议。

记录并了解系统中的敏感和个人数据。确保您的开发人员和测试人员确切了解他们使用的敏感和个人数据。

如果您决定对生产数据进行清理以删除个人或敏感信息，请确保对数据进行清理的过程本身不是安全/隐私/合规漏洞。考虑使用第三方清理和消毒软件，因为它比自行开发的解决方案更不会引起错误。

如何使生产中的测试风险降低？

格言“请勿在生产中进行测试”是为了保护我们的生产系统。既然我们已经确定可以并且应该每天在生产中进行测试，那么如何确保生产系统的安全？

^{在将新组件投入生产之前，有一个测试计划并完成它。} ^{经过良好测试的代码在生产中失败的可能性较小。}

首先，在投入生产之前，请使用自动化测试对所有系统进行全面测试。我坚信100％的自动化单元测试覆盖率，并且单元测试在它们验证的代码更改相同的更改集中或提取请求中。在投入生产之前，您应该完成多层测试：功能/行为测试，集成测试，部署/配置测试，可访问性测试，安全性测试和高可用性故障转移测试。而且，如果您要逐步推出新功能，请也测试一下推出过程。是的，我也相信手动测试，但绝不能替代自动化测试！

生产中的自由形式测试呢？两个字：小心。例如，“ Bug hunt”日子是一种最佳实践，您可以要求团队中的每个人都花一定的时间来尝试查找软件中的错误。只要设置正确的护栏，这些都是有趣且富有成效的。与您的团队一起审查在生产中进行测试的风险，并教您的Bug猎手不要做什么，例如使用其个人信用卡下订单并立即取消订单。这些测试可能会干扰收入确认和订单统计。

此外，请勿出于测试目的或出于任何其他原因而手动重新配置生产系统。手动更改使您的系统处于未知状态，很难将它们恢复为已知配置。使用基础结构代码（Chef，Helm等）和/或发行管理和编排工具（例如IBM UrbanCode Deploy或）来管理生产系统的配置。

在进行任何混沌工程之前，请确保您已按照的基本原理规划了实验：

计划实验

包含爆炸半径

鳞或壁球

您还可以通过满足以下先决条件来降低混乱工程的风险：可靠的自动化测试覆盖范围，良好的监视和警报，具有快速自动故障转移功能的高可用性设置以及随时待命的团队，随时准备在您的服务中恢复服务-失败的情况下实现级别目标（SLO）。在我的团队中，我们通常在周末在开发人员在场的情况下对每个组件进行首次故障转移测试，并且团队在通过第一组测试后，在正常工作时间内“毕业”以测试其弹性。

^{不要让混乱的工程，可伸缩性或性能测试在您的系统中引起一系列问题。} ^{松散耦合的组件，良好的错误处理以及计划好的故障模式有助于隔离故障。}

在计划可伸缩性和性能测试时，请确保不会影响客户。不要在您的生产系统上抛出大量API请求，并希望获得最好的结果。如果成本效益分析证明是合理的，请使用单独的隔离环境。如果您需要测试生产中的可伸缩性或性能，请在监视系统的同时逐渐增加流量，并在服务中断或故障之前停止。并且不要忘记从生产分析中过滤掉可伸缩性/性能测试流量！

这些降低风险的技术将帮助您保持生产系统的弹性，并减少因生产测试而导致的故障。