8月17日，GitHub又宕机了，这次持续7小时47分钟，github.com、登录认证、Actions、API、PR、Issues、Copilot全部受影响。这是8月的第二次重大事故，前一次是8月6日的Actions故障。官方博客给出的解释是“一个关键基础设施组件没能随流量扩容”，听起来像一句反复打磨过的公关句——真正发生的事，写在另一份文件里。
博客里的说法：流量太猛，已经在补
官方博客称，过去几个月月度commit量从14亿涨到29亿，Central US数据中心的一个关键组件没跟上这波增长，认证系统随之崩溃。应对措施列得很实：新增300万+ CPU核心、120PB高速存储，Azure现在扛下GitHub约58%的平台负载和一半的Git操作，5月这个数字还是12%。
这套叙事的逻辑很简单：增长太快，基础设施没跟上，现在砸钱补。这个说法没错，但没说全。
事故报告里的说法：是指标看错了
githubstatus.com上的完整根因分析给出了更具体的链条——真正的触发点不是“容量不够”，是扩容策略盯错了指标。
Istio的sidecar并发数撞到了上限，但负责自动扩容的策略监控的是宿主服务的容量，不是sidecar自己的限制。sidecar一直在报警，扩容系统却没收到该收到的信号。等问题传导到4个HAProxy节点、流量限额被耗尽，认证网关已经先垂下去了。
更麻烦的是Copilot。多数服务恢复得早，但Copilot的Token Service卡了很久——VS Code客户端有个重试bug，一次失败的令牌请求会触发多次额外重试。日常这个服务承载7000到9000次请求每秒，事故期间被推到7万到10万次每秒，相当于流量被自己的客户端放大了十倍。团队得先把这个重试行为压下去，才能安全地把流量放回来。
- 风险.整改清单里写着“审计Istio扩容策略”“统一重试预算”“修复VS Code重试放大”，但这些都是事后补丁，不是提前设计好的护栏。
一个没对齐的数字
官方博客说Azure在5月扛着12%的平台负载，现在到了58%。但翻回GitHub 3月和4月的可用性报告，数字是另一套：3月披露Azure在Central US承担12.5%的流量，5月是40%，6月峰值到过45%。
同样是“5月”，一个说12%，一个说40%，中间差了三倍多。这不一定是有意造假，更可能是统计口径变了——平台负载、Git操作、monolith流量，分母换了，结论就换了。但对外沟通里，这种口径漂移本身就是一种叙事管理：数字看起来在稳步爬升，读者不会去追问分母到底是什么。
半年锯齿，不是一条直线
3月GitHub发生过4次事故，4月是10次，8月两次重大——这是从3月开始就没停过的可用性拉锯战。博客里“我们已经取得进展”这句话，和这条事故频率曲线摆在一起看，更像是必须说的场面话，而不是可验证的事实。
真正值得验证的进展，是9月即将发布的8月完整可用性报告——它会不会承认sidecar配置错误这种具体的工程失误，还是继续用“流量增长”这套万能解释，决定了这份报告有没有参考价值。
说流量太猛容易，说指标看错了才是真话。
GitHub这次至少把技术账本摆在了githubstatus.com上，没有藏起来，这一点该给的信任要给。但对外博客选择只留“增长压力”四个字，把配置错误和客户端bug都留在附录里——只看博客的读者，根本看不出GitHub到底修没修对地方。