当全球最大的代码托管平台开始频繁宕机，"GitHub Actions又挂了"成了开发者群聊的日常开场白。这份迟到太久的道歉信，读起来像一份危机公关教科书——但问题是，用户还信吗？

事件现场：一张写满"X"的日历

打开网易新闻 查看精彩图片

HashiCorp联合创始人Mitchell Hashimoto的日记本最近成了技术圈的热门谈资。过去一个月，他每天在日历上标记GitHub故障影响工作的日期，结果"几乎每天都有X"。

发文当天，GitHub Actions故障让他整整两小时无法审查代码。这位终端模拟器Ghostty的作者最终宣布：项目将迁出GitHub，"这里不再适合严肃工作"。

Hashimoto不是唯一一个。社交平台上，开发者们的抱怨早已从吐槽变成行动——有人开始自建Git服务器，有人批量迁移到GitLab，更多人则在观望：这份道歉是转折点，还是又一张空头支票？

故障清单：2025年的四次打脸

GitHub CTO Vlad Fedorov的道歉信里，被迫复盘了近期几起典型事故。这些细节拼凑出一个基础设施正在过载的平台画像。

4月23日的合并队列（Merge Queue）故障堪称低级错误：当合并组包含多个拉取请求时，系统会生成错误提交，导致先前已合并的代码被意外回滚。对依赖持续集成的团队来说，这等于在生产线中央埋了颗随机引爆的雷。

四天后，搜索功能集体罢工。GitHub的Elasticsearch集群"过载（可能是僵尸网络攻击所致）"，依赖搜索的界面模块全部哑火。截至道歉信发布，根因分析仍在进行中。

把时间轴拉长，趋势更令人不安。据重建的状态页面统计，GitHub 2025年可用性已跌破90%，4月更是滑向85%以下。要知道，企业级SaaS的行业基准通常是99.9%——GitHub现在的表现，连"三个九"的边都摸不着。

Fedorov在信末写道：「我们听到了你们的痛苦。每一封邮件、每一条社交动态、每一张支持工单，我们都放在心上。」但"听到"和"解决"之间的距离，正是开发者信心的裂缝所在。

根因拆解：AI编程正在压垮旧架构

GitHub把锅扣给了自己也没料到的变量：AI。

道歉信中有个关键判断："软件构建方式正在快速变化。"2025年12月下旬以来，智能体开发工作流（agentic development workflows）急剧加速——简单说，就是AI写代码、AI提PR、AI跑测试的全自动流水线开始普及。

这直接改写了GitHub的负载模型。平台原本规划了10倍容量扩张，2024年10月启动工程；结果到2025年2月发现，实际需要30倍。三个月内需求预测翻三倍，任何基础设施团队都会头皮发麻。

这里有个有趣的细节：GitHub特意澄清，向Azure的迁移"不是罪魁祸首"，反而帮助快速扩容。言下之意，问题出在需求侧爆炸，而非技术债或云架构失误。但开发者是否买账，是另一回事——当服务频繁不可用，解释听起来都像借口。

GitHub现在的优先级排序很务实：可用性第一，容量第二，新功能第三。具体动作包括削减非必要工作、优化缓存、隔离关键服务、消除单点故障、把性能敏感路径迁移到专用系统。全是基础设施基本功，没有花哨的AI功能发布。

这种"返璞归真"本身说明问题：一家靠开发者生态起家的公司，正在被迫重新学习如何做一个可靠的水电煤服务商。

信任重建：道歉之后的关键战役

Hashimoto的迁移决定，对GitHub是个危险信号。

Ghostty不是普通开源项目——它的作者有HashiCorp创始人的光环，有技术社区的广泛影响力。这种"意见领袖"的出走，往往比数据更能动摇平台的心智地位。更麻烦的是，GitHub的护城河从来不是技术（Git协议是开源的），而是网络效应：开发者在这里，因为其他开发者在这里。

一旦迁移潮启动，网络效应会反向加速。GitHub的道歉信里有个未明说的焦虑：它正在从"默认选项"变成"需要被说服的选项"。

Fedorov的"我们放在心上"能否转化为"我们修复了"，将决定这场危机的走向。对25-40岁的技术从业者来说，平台选择越来越务实：不是谁品牌大，而是谁不耽误我干活。GitHub过去十年的"开发者第一"叙事，正在被2025年的可用性数据一点点瓦解。

如果你正在管理技术团队或开源项目，现在或许是时候评估：你的代码托管策略，是否过度依赖单一平台？Hashimoto的日历和GitHub的道歉信，共同指向一个老道理——基础设施的可靠性，从来不是靠公关文案保证的。