GitHub, 自动扩展与组件替代谬误

# GitHub、自动扩展与组件替换谬误 来源：https://surfingcomplexity.blog/2026/08/19/github-autoscaling-and-the-component-substitution-fallacy/ 在昨天关于近期GitHub服务中断（https://www.githubstatus.com/incidents/zkxwbgr0cnmx）的文章（https://surfingcomplexity.blog/2026/08/18/tough-days-at-github-a-continuing-series/）中，报告中有一个细节我未曾提及：受影响服务的自动扩展策略配置存在问题。 > 问题最初源于一个Istio sidecar容器达到并发上限，由于策略配置错误（仅监控宿主服务负载而未监控sidecar的资源限制），导致其无法正确自动扩展。 我推测本博客的读者对自动扩展的概念和工作原理已经很熟悉，但为方便理解，这里做个简要说明。服务所需的计算和内存资源取决于其负载。此处的负载主要指针对服务的外部请求，即所谓的*流量*。流量规模随时间变化——例如对于GitHub这样的公司，我猜测工作时段的流量会高于夜间和周末。 既然负载动态变化，而服务所需资源又是负载的函数，通常有两种应对策略。其一是按峰值负载配置资源，其二是根据当前负载动态调整资源分配，后者即*自动扩展*。 若要使用自动扩展，就需要制定扩展策略：首先选择能代表负载的指标，然后根据该指标的变化来决定资源的增减。 CPU使用率是常用的扩展指标，但需注意即使CPU使用率较低，服务也可能达到饱和。例如采用线程池处理请求时，当下游请求延迟增加导致所有线程阻塞，服务虽已饱和（此时扩展新实例会有所帮助），但CPU使用率实际上很低，因为线程正阻塞在I/O等待中（这正是Slack在2021年遇到的情况：https://surfingcomplexity.blog/2021/02/08/slacks-jan-2021-outage-a-tale-of-saturation/）。对此，可以为自动扩展策略添加额外规则（如Slack当时根据线程数快速扩容），或者若服务非CPU密集型，可以基于请求量而非CPU使用率进行扩展。 根据GitHub的事故报告，受影响服务的自动扩展策略似乎仅考虑了服务本身的负载指标，而忽略了Istio sidecar的负载状况。 通常每个服务在负载下的表现各不相同，这意味着每个自动扩展策略实际上都是定制化的。服务团队不仅需要负责业务逻辑，还需维护一个包含定制参数的运营控制系统，且这类参数通常只能通过压力测试来验证（你是否对所有服务都进行了压力测试？）。服务所有者几乎不可能同时是自动扩展专家，因此配置错误的扩展策略成为诱因之一并不令人意外。 不过，虽然我认为有必要讨论这个具体缺陷（帮助人们认识自动扩展的风险），但也认为不宜过度聚焦于此而忽略其他相关因素。正如David Woods提出的*组件替换谬误*（https://surfingcomplexity.blog/2023/04/15/missing-the-forest-for-the-trees-the-component-substitution-fallacy/）所指出的——改进可靠性的方法不应仅仅聚焦于识别和修复缺陷组件。 诚然，应当识别并修复事故暴露的缺陷，但同时要认识到： - 系统此刻*充斥着潜在的组件缺陷*（https://surfingcomplexity.blog/2025/07/09/component-defects-rca-vs-re/） - 尽管存在这些缺陷，系统并非持续崩溃 这说明*仅靠组件缺陷不足以摧毁系统*（否则系统早已瘫痪）。不能只关注单个组件，必须将组件间的交互视为核心要素。在此次GitHub事故中，我们需要综合分析以下因素的相互作用：流量模式变化（包括爬虫）、自动扩展策略、Istio sidecar饱和、重试逻辑、HAProxy节点饱和以及认证流量。 由于这是快速公开的事故报告，许多细节尚未披露，真正的关键信息往往存在于内部报告中。我在文中推测了服务所有者与自动扩展策略的关系，但很希望了解更多背景（比如该策略是否早于Istio sidecar的采用？）。同时也想了解问题流量的具体情况（请求类型、增长模式、流量激增原因等）。 公开的事故报告无法回答这些问题，但在贵司内部事故报告中却可以找到答案——关键在于主动提出这些质询。