压力测试：在系统崩溃之前找出它是如何崩溃的

区分成熟团队和乐观团队的问题很简单：你知道你的系统是如何失败的吗？

不是“如果”失败，而是每个系统都会在某种程度的需求下失败。问题是如何。当压力消失时，它是否会优雅地减速并恢复正常？或者它是否会崩溃、损坏数据并需要在半夜进行手动干预？这两种情况之间的区别很少是运气。这是有意或无意测试极限的结果。

压力测试正是这样的：将系统推到超出其应能处理的范围，看看绳子断裂时会发生什么。导致失败听起来违反直觉。事实上，这是工程领域最负责任的实践之一。

什么是压力测试，什么不是

压力测试将系统置于远远超出预期需求的极端条件下，以观察其在极限及超出极限时的行为。目的不是验证它是否可以处理正常负载，而是了解当它无法再处理时会发生什么。

这就是它与负载测试的区别，而负载测试经常与负载测试混淆。负载测试衡量预期和不断增长的需求下的行为：系统可以维持多少用户的质量。压力测试无视预期，故意走向极端，寻找突破点并观察恢复情况。

换句话说：货物响应“它能处理将要发生的事情吗？”。压力的答案是“当你无法承受时会发生什么？”。这两个问题都很重要，但第二个问题是让团队为最糟糕的一天做好准备的问题。

从未承受过压力的系统会出现未映射的故障，等待最糟糕的时刻出现。最糟糕的时间总是需求最大的时候，也就是系统最重要的时候。

想象一下在截止日期那天有一个公民服务门户网站。实际负载超出了任何合理的估计，因为每个人都把它留到最后一刻。仅针对“预期”负载进行测试的系统不知道它是否会正常降级或完全陷入这种情况。压力系统已经在实验室中看到了这种情况，并且团队已经知道会发生什么以及如何反应。

在受控环境中引发失败就是用廉价的学习来交换昂贵的惊喜。这与消防演习的逻辑相同：你不会等到真正的火灾才知道出口是否有效。

压力测试中最重要的数字不是突破点本身。这是他周围的行为。

首先要注意的是退化是如何发生的。系统是否会逐渐减慢速度、发出信号，或者在没有任何警告的情况下急剧下降？温和的降解是可控的；突然跌倒是危险的，因为没有时间做出反应。

第二个是第一个失败的。在压力下，总是有一个组件先于其他组件让位，即[数据库0、连接池、内存、队列。识别这个最薄弱的环节是测试价值的一半，因为这是值得投资来突破极限的。

第三，也许也是最重要的，是恢复。当压力过去后，系统会自行恢复正常吗？或者它是否处于降级状态，队列堵塞和连接悬空，需要手动重新启动？无法自行恢复的系统会将暂时的峰值变成长期不可用。

有一个概念可以指导所有这一切：优雅降级。一个设计良好的系统，当超出极限时，应该保留本质，牺牲次要，而不是完全崩溃。

例如，这意味着以受控方式拒绝新请求，而不是全部接受并崩溃。这意味着保护核心操作、支付交易、关键记录，而辅助功能不可用。这意味着清晰、快速地返回错误，而不是让用户陷入永恒的加载状态。

压力测试可以揭示您的系统是否有这种行为。但它几乎总是表明它还没有。一旦发现问题，就可以刻意设计速率限制、丢弃队列、故障隔离等保护机制。

第一个错误是在看起来不像生产环境的环境中施加压力。寻找较小测试基础设施的极限并不能说明真实基础设施的极限。环境需要具有代表性，否则数字就是骗人的。

二是停在突破点。很多人都会进行测试，找出系统出问题的地方，记下数字，然后就到此为止。黄金之后：关注复苏。一个早期崩溃但可以自行恢复的系统比一个持续时间较长但需要手动干预才能恢复的系统更健康。

三是将测试视为单一事件。每个架构变化都可以移动断点并改变故障行为。在关键系统中，压力是一种反复出现的做法，而不是一种奠基仪式。

避免思考失败的组织和研究失败的组织之间存在文化差异。第一次活着就希望巅峰永远不会到来。第二个清楚地知道他到来时会发生什么，并且已经决定了如何反应。

压力测试是实现第二种姿势的实践。它并不能防止失败；没有任何测试可以做到这一点。但它将未知的灾难性故障替换为已知的、可预测的和可控的故障。在支持基本服务的系统中，这就是小问题和危机之间的区别。

了解系统如何工作是基础知识。知道它如何破裂以及如何恢复，是充满信心的人与凭信心行事的人的区别。

如果您的组织依赖于经历关键峰值的系统，并且没有人故意导致它们失败，那么在现实为您做到这一点之前，这是一项值得做的练习。我的博客上还有其他与本文相关的关于可靠性、性能和弹性的文章。