我们服务的流量并非完全可预测。为了帮助保持服务略微过度配置，并提前警告因流量增加而导致的任何性能下降，我们维护了一种“连续缓冲负载生成器”。这会在用户流量之上对我们的生产 API 产生持续的负载。如果我们发现服务正在降级，它会自动关闭，理想情况下，我们有一点时间来找出问题并在自然用户流量与导致服务降级的增强流量相匹配之前扩大规模。一旦服务再次稳定，缓冲负载就会重新打开。
虽然我们一直将这种持续的流量生成称为“持续负载测试”，但这似乎是令人困惑的措辞，并且很难区分“实际”负载测试（我将称之为具有定义的开始和结束的实验，加载模式，以及最后的二进制通过/失败结果）。我几乎想将其称为“金丝雀流量”，因为我们会发送额外的流量以在用户遇到问题之前警告我们，但这与业内对金丝雀含义的一般理解不太相符.
这是在负载平衡、自动缩放等之上的附加策略。我们不会尝试在这里替换任何行业标准的流量管理步骤。
我怀疑这是不知道谷歌正确用词的情况，所以：
- 如果这是其他地方使用的模式，它叫什么？
- 或者，如果没有其他人这样做，为什么不呢？我完全愿意相信通过其他类型的测试或监控可以更好地获得这个结果。