在关于昨日 GitHub 中断的文章中，有一个细节我没有提及：在饱和的 Istio 侧车上服务的自动扩展策略。最初，这是由一个 Istio 侧车 Pod 达到其并发限制并由于一个观察主机服务而不是侧车限制的错误配置策略未能正确自动扩展所导致的。我怀疑本博客的读者对自动扩展的概念及其工作原理是熟悉的，但如果您不熟悉，这里有一个简要总结。服务所需的计算和内存资源量取决于对该服务的负载。这里相关的负载源是针对该服务的外部请求，也称为流量。流量量随时间变化。例如，对于像 GitHub 这样的公司，我猜测在工作时间内的流量比晚上和周末的流量要多。鉴于负载动态变化，且服务所需的计算和内存资源是负载的函数，因此有两种一般策略。一种策略是为峰值负载预配服务。另一种策略是根据当前负载动态调整分配给服务的资源；这称为自动扩展。如果您希望您的服务使用自动扩展，您需要定义一个自动扩展策略。特别是，您需要选择哪些指标作为负载的代表，然后您需要指定如何根据该指标的变化添加或删除资源。CPU 利用率是常用的自动扩展指标。但请注意，即使 CPU 利用率较低，服务也可能会饱和。例如，想象一个场景，您使用每请求一个线程的线程池，而下游请求的延迟增加，线程池中的所有线程最终都被阻塞。在这里，服务处于饱和状态，您将受益于启动新的 Pod，但 CPU 实际上是低的，因为线程被阻塞在等待 I/O（这在 2021 年发生在 Slack 上）。现在，您可以向自动扩展策略中添加额外的规则以处理这种情况（这就是 Slack 所做的，他们根据线程数量迅速扩展）。或者，如果您的服务不是 CPU 绑定的，可以根据传入请求量而不是 CPU 进行扩展。根据 GitHub 的相关写作，受影响服务的自动扩展策略似乎使用了仅考虑服务本身负载的负载指标，而没有考虑 Istio 侧车的负载。一般来说，每个服务在负载下的行为不同，这意味着每个自动扩展策略实际上都是定制的。这意味着拥有服务的团队不仅对业务逻辑负责，还对具有自定义参数的操作控制系统负责，而这些参数只能通过负载测试来检查。（您对所有服务进行负载测试吗？）服务拥有者几乎肯定不是自动扩展专家。因此，我并不感到惊讶，错误配置的自动扩展策略在这里是一个因素。不过，虽然我认为值得讨论这个策略特定缺陷，因为让人们意识到自动扩展的风险是有益的，但我也认为很容易就将注意力集中在这一点上，而忽略了此事件中的其他相关因素。这就是 David Woods 所称的组件替代谬误——改善可靠性的方法是将精力集中在识别和修复有缺陷的组件上。虽然，是的，您应该识别和修复事件中发现的缺陷，但您也应该认识到：您的系统在此刻依然充满潜在的组件缺陷，尽管存在所有这些缺陷，但您的系统并非一直在失败。这意味着组件缺陷不足以使您的系统崩溃，否则您的系统现在就会宕机。不要只关注单个组件：将交互视为首要任务。在 GitHub 的中断中，我们看到讨论了诸如：流量模式变化（包括爬虫）、自动扩展策略、Istio 侧车饱和、重试逻辑、HAProxy 节点饱和和身份验证流量之间的交互。还有大量的细节我们并不知道，因为这是一个迅速发布的公共写作，而好的内容只在内部写作中能找到。我在这篇文章中推测了服务拥有者与自动扩展策略之间的关系，但我想知道这里的历史更多信息（例如，这项政策是在使用 Istio 侧车之前制定的的吗？）。我也想了解更多有关问题流量的信息。（它们是什么类型的请求？是突然增加还是逐步上升？我们知道流量增加的原因吗？）。您无法从公共事件写作中获得这类问题的答案，但在您自己组织的内部写作中可以获得。提问的责任在于您自己。