8月17日晚上（北京时间21点多），GitHub宕了7小时47分钟。知乎Issues打不开，PR提不了，Actions全线卡死，Copilot罢工，连企业SSO都进不去。官方复盘给出的根因有点出乎意料：不是代码变更，不是配置失误，是容量——流量创下新峰值时，美国中西部数据中心的一个关键组件没有跟着扩容，压力扩散，认证服务连锁崩掉。知乎
对关注混沌工程的人来说，这次事故最扎心的地方在于：我们平时练得最多的那些招式——杀Pod、断网络、打满CPU——恰好防不住这类事故。组件级故障注入假设的是"某个部件坏了，系统能不能扛住"；而这次GitHub的故障是"需求超过了供给，而且没人提前知道"。这是两类完全不同的实验对象。
先把事故本身捋清楚，因为现在社区里流传的版本和官方结论有出入。
官方口径（CTO Vlad Fedorov 8月20日发布的复盘）：故障从8月17日13:28 UTC开始，21:15 UTC全部恢复，持续7小时47分。知乎网页与API流量错误率约20%，仓库归档和源码下载错误率约50%——注意这是请求级错误率，不是"两成用户掉线"。知乎恢复期间还出了个二次事故：认证令牌重试和Copilot客户端的重试循环反向放大流量，GitHub不得不部分禁用重试才把Copilot救回来。官方明确说，这起事故和8月6日的Actions故障"都不是代码或配置变更导致的，本质都是容量失败"。知乎
社区里流传更广的是一版更具体的技术推演：Central US的Istio sidecar pod并发连接打满，但HPA只盯着宿主服务的CPU和内存，没把sidecar的容量纳入扩容判断，于是"宿主正常、伸缩系统认为不用扩"，瓶颈却在sidecar上；压力传导到4个HAProxy节点，流限制耗尽，认证路径退化。知乎还有数据说Copilot的Token Service从正常的7000-9000 RPS被重试风暴打到7-10万RPS，一个VS Code客户端的重试bug让恢复多花了3个小时。知乎这版推演讲得头头是道，但要说明：截至目前官方并没有公布出问题组件的具体名称，这些细节属于社区复盘，可信但不宜当成官方结论。知乎
顺带一提，这已经是8月内第二起重大事故，7月8日还有一次7小时4分的中断。背景是AI编码带来的流量暴涨——4月以来月提交量从14亿涨到29亿，翻了一倍多。知乎
现在说重点：如果要做混沌演练，这类事故对应哪些实验？
第一个缺口是"负载和故障没有一起注入"。绝大多数团队的混沌实验是在低峰期、甚至空闲环境里跑的——系统本身没什么流量，这时候杀Pod、断依赖，验证的是"坏了能不能自愈"，根本触发不了容量型失败。GitHub这次的触发条件是"流量峰值×关键组件容量上限"，两个变量缺一不可。对应的做法是组合实验：先用压测工具把流量拉到接近容量水位，再注入组件故障或扩容阻断，观察系统是平滑降级还是雪崩。演练环境先圈定爆炸半径，生产上从影子流量或小比例流量开始。
第二个缺口是"自动扩缩容策略本身没被验证过"。社区推演里最经典的一幕就是：瓶颈在sidecar，扩容决策却只看宿主服务的指标。这种"监控指标覆盖不到真实瓶颈"的问题，几乎每个用HPA的团队都可能存在。演练方式很简单也很反直觉：故意只压不被监控的那个维度（连接数、线程池、文件句柄、sidecar并发），验证扩容链路能不能感知到、多久能扩出来、扩容期间的请求怎么处理。
第三个缺口是"重试和客户端不在演练边界内"。这次GitHub恢复被拖慢，主要不是服务端的问题，而是客户端的重试风暴——一个IDE插件的重试bug乘以百万用户，就是把刚缓过来的服务再次打垮的洪水。混沌工程原则里讲"最小化爆炸半径"，但重试风暴的特点恰恰是爆炸半径在系统边界之外。知乎可以做的实验：对某个依赖注入大面积失败（比如让认证服务批量返回401或超时），观察上游调用方的重试行为是否收敛，重试预算、熔断、指数退避这些配置在真实失败面前是否生效。如果你的系统有客户端（App、SDK、IDE插件），这一项尤其值得做。
第四个缺口是"认证这种隐性单点没被单独练过"。这次故障从容量问题扩散成全局认证危机——认证链路是所有服务的必经之路，它一抖，整条交付链（拉代码、评审、构建、部署）同时失败。对应的演练：对token服务、SSO、网关这类共享依赖做降级注入，验证各服务是跟着一起死，还是能降级、能缓存、能排队。
第五个是预案层面的：故障恢复期间的意外流量。社区复盘提到恢复过程中codeload端点还遭遇了爬虫攻击。知乎系统最脆弱的就是恢复期，预案里除了"怎么修"，最好把"怎么挡住额外负载"也写进去。
说完演练，补充两个这个圈子里最近的动态，都跟"把演练做起来"有关。
一个是AI Agent正在把混沌演练的成本打下来。阿里ChaosBlade生态推出了智能代理层BladeAI，用自然语言描述故障场景（比如"给某命名空间的某服务注入CPU压力80%，持续5分钟"），Agent自动完成定位、安全校验、注入、效果验证、恢复的全链路——以前一次人工演练要查文档、拼命令、盯监控，20-30分钟起步，现在压到可以日常跑。知乎千问云也在8月初发了多Agent协作的韧性验证平台，专攻专有云IaaS场景的节点掉电、磁盘故障这类。知乎方向是一致的：混沌工程落地难，难在每次演练的认知成本，而不是注入技术本身。当演练成本低到像跑单元测试，“年度任务"才有可能变成"日常习惯”。
另一个是工具本身也要被当成变更来管理。CNCF旗下的LitmusChaos上半年发了六个版本，几乎每月一版，其中一次还把安全补丁（gRPC的CVE修复）和新功能（Prometheus指标）打在了同一个版本里。知乎这对使用者意味着：每次升级都要重新验证一遍配置。有团队就指出，混沌实验往往接在CI/CD里自动跑，如果实验环境和生产环境跑的工具版本不一致，实验结果就失去可比性。所以如果你的团队在用这类工具，把工具升级纳入变更管理、做好版本一致性校验，本身就该是稳定性工作的一部分。
最后给几个值得持续关注的信号：GitHub官方立了三个检验点——2026年底前把生产流量全部迁出自有数据中心、读容量做到随读者数量线性扩展、服务间统一施加重试上限和重试预算。知乎下次流量峰值来时能不能扛住，就看这些兑现得怎么样。而对依赖GitHub的团队，比争论"要不要跑路"更实际的是三件事：仓库镜像、CI可迁移性、紧急发布流程。
你们团队做过上面哪种演练？或者你的系统里，哪个环节最像这次GitHub的那块"没被监控的sidecar"？评论区聊聊。
