性能测试测试环境与生产环境
如果您上一次更新IT安全标准是在5年前或更早,那么它们很可能与当今的DevOps和站点可靠性工程 (SRE)实践的现状不符。 一个特别棘手的话题是生产中的测试,以及因此使用生产数据进行的测试,因为DevOps和SRE混淆了什么是生产和什么不是生产之间的界限。 什么是测试,什么不是。
为了消除一些困惑,我们将深入研究以下问题:
- 为什么我们将开发/测试与生产系统分开?
- 根据生产系统的高标准,我们应该管理什么?
- 为什么在生产系统上进行测试如此危险?
- 为什么要在生产中进行测试?
- 生产数据呢?
- 如何使生产中的测试风险降低?
我应该指出,这是一个观点。 它基于多年的DevOps集体经验和测试经验,但是不应作为IBM的正式声明来阅读。
为什么我们将开发/测试与生产系统分开?
至少从合规性和风险管理的角度来看,区别对待开发,测试和生产系统是一种标准做法,主要是因为它们具有不同的安全性,数据和隐私控制。 让我们退后一步,考虑一下对这些部署环境的不同态度的历史原因。
此外,生产系统很特殊,因为它们可以访问生产数据。 生产数据必须是可靠的真理来源,因此我们必须保护它免受损坏。 生产数据还可能包含我们只能与授权用户共享的信息,例如机密或个人数据,因此我们必须确保其受到生产级身份验证和授权的保护。 最后,我们可能需要维护对生产数据访问(创建,读取,更新和删除)的审核跟踪,而对于开发/测试系统则不需要。
我们还需要对生产系统的当前状态具有出色的可视性并对其进行控制。 我们会仔细监控它们,以便我们能够快速发现问题,并在出现问题时了解这些系统的当前配置,从而可以更轻松地快速恢复。 大多数人都不太在乎开发人员是否更改其个人笔记本电脑上的配置设置,但是我们将生产系统锁定为已知的配置,并具有安全的更改控制。 无论我们是通过变更控制数据库还是通过基础架构代码来锁定配置,目标都是相同的:可见性和控制性。
最后,请记住我们对开发/测试和生产系统的管理方式不同,因为存在专门针对生产系统的合规性规则和规定。 在我们的开发/测试环境中,没有什么比消除不必要的负担更快地杀死速度了!
根据生产系统的高标准,我们应该管理什么?
当我们开始考虑在生产中进行测试时,我们很快意识到我们是从一个假设开始的:应该容易确定什么是生产环境,什么不是生产环境。 但是,就像大多数假设一样,我们错了。 开发人员和测试人员希望快速行动; 如有疑问,我们倾向于将系统分类为开发/测试而不是生产,因此我们不必处理生产系统管理开销。 但是,我们如何知道何时需要实施生产控制? 并非全部都是黑白的,但有一些注意事项。
一些更明确的例子:我们可以同意专门为测试而设计的开发人员笔记本电脑和环境(例如,集成测试,系统测试,性能测试)不是生产系统。 此外,人们普遍认为,直接或在幕后使用真实数据为真实客户服务的系统是生产系统。 还有一些我们仅在内部使用的系统,这些系统对于公司的运营至关重要,因此也被视为生产系统。
但是,“生产