你了解自己系统中某个特定服务使用的产能是多少，对于可扩展性来说，至关重要。知道这一点，就可以计算距离扩展，你还有多少时间和发展空间。它是规划余量和基础设施项目、拆分数据库/应用以及制定预算的基础。而确保你计算准确的方法是对所有发布的版本都进行性能测试，这样可以保证你没有引人意想不到的负载增加。一个组织在一次发布中达到了所允许的最大负载增量是很常见的。当你在产能规划方面变得日益成熟时，你就会把新功能带来的负载看作一种成本，要把它计入成本收益分析。此外，为了确保预计的断点和性能下降曲线仍旧与以前识别的一样，压力测试也是必需的。有可能常规的使用负载没有变化，但新的代码路径或逻辑改变却会造成整体负载能力的下降。例如，如果一个数据结果的查询增加了90毫秒，那么在用户请求的整体响应时间中，它可能不会引起注意，但如果这个服务是和其他服务同步绑定在一起的，如负载构建服务，那么成百上千个90毫秒的延迟累加起来，就会降低该服务的最大产能。
当我们讨论变更管理时，我们不只讨论了适用于创业公司的轻量级变更识别流程，还讨论了积极管理生产环境中的变更的公司可以采用的完整变更管理流程。我们把变更管理定义为由下列组件构成，即变更建议、变更批准、变更日程安排、变更实施和记录、变更验证以及变更审查。性能测试和压力测试强化了变更管理流程，它们提供了实践性的实现，并且非常重要的是，验证了变更。如果你没有证明一个变更会真的按照你预想的那样影响系统，例如修复了一个bug或者提供了一个新功能，那么你一定不想实施这个变更。作为性能测试和压力测试的一部分，我们可以在一个可控的环境中验证预计的变更结果。这个额外的步骤，可以确保变更在生产环境中实施后，它能够在各种负载下，像它在测试时表现的那样运行。
在把性能测试和压力测试关联到可扩展性时，我们应该考虑的最重要的因素是风险管理。要确保你的系统能够扩展，风险管理是最重要的流程之一。在风险管理之前要进行风险分析，即尝试计算各种行动或组件中的风险大小。性能测试和压力测试是两种能够大大降低某次服务变更带来的风险的方法。例如，如果我们使用的是故障模式和后果分析法，识别出某个功能的故障模式是会增加查询时间，而建议的补救措施是在真实的负载条件下测试这个功能，就像性能测试一样，以确定该功能的真正反应。还可以像压力测试那样，用极限负载来进行测试，以观察该功能在超常规条件下的反应。这两种测试都能提供更多关于该功能的真实性能都是强有力的工具。的信息，从而降低了风险。对于降低或管理每次发布的风险或系统整体的风险来说，这两种测试有着内在的联系。
不过，正如我们在讨论网站建设压力测试时所警告的，制造测试负载并不容易，如从余量、变更控制和风险管理这三个方面，我们可以发现系统的可扩展性与采用性能和压力流程。如果做得不好，会生成错误的数据。但这并不意味着就不值得去理解、实施以及(最终)掌握这些测试。
本文地址：//www.qlpinke.com//article/3860.html
