GitHub可用性改造背后的故障隔离真相
本文指出，系统出现性能问题或故障后，团队常倾向于拆微服务、上 Kubernetes、增加机器，但这些手段不会自动带来高可用。GitHub 2026 年可用性改造的真正主线不是增加服务数量，而是持续移除共享故障点，把故障限制在更小范围。微服务数量不等于故障隔离，真正隔离包含代码边界、资源边界和故障边界。GitHub 通过迁出认证权限、让仓库与 Pull Request 使用独立基础设施、降低单机房依赖，逐步建立隔离。文章提出可靠性改造五原则：识别核心用户路径、优先隔离资源、主动丢弃负载、逐步放量快速回退、高可用不等于所有功能正常。中小团队可先画依赖关系、识别共享资源、建立软隔离，再拆分高风险域。真正架构升级是控制故障传播，拆服务前应问：模块失控后，能否只让自己失败？