微软将优先推进 GitHub 向 Azure 迁移而非功能开发
随着GitHub首席执行官托马斯·多姆克于今年八月离职，以及GitHub被更深度整合进微软组织架构，其独立性已不复存在。
尽管这意味着部分功能开发将被迫推迟，微软仍在全力推进GitHub全部基础设施向Azure的迁移工作。
自2018年收购GitHub后，微软基本保持该开发者平台的独立运营。但近几个月情况发生变化：随着GitHub首席执行官托马斯·多姆克于今年八月离职，以及GitHub被更深度整合进微软组织架构，其独立性已不复存在。据The New Stack获得的GitHub内部文件显示，此次深度整合的下一步举措是将所有基础设施迁移至Azure云平台，即便这意味着新功能开发将被迫延迟。
首席技术官弗拉基米尔·费多罗夫在致员工的信中指出，GitHub位于弗吉尼亚的数据中心容量已趋于饱和。“满足AI和Copilot功能的需求关乎我们的生存，这些功能正在改变人们使用GitHub的方式。”他写道。
该计划要求GitHub在24个月内完全迁出自有数据中心。“这意味着我们只有18个月执行时间(含6个月缓冲期)，”费多罗夫在备忘录中强调。他承认，鉴于此规模的迁移需在新旧基础设施并行运行至少六个月，团队实际必须在未来12个月内完成迁移。
为此，他要求GitHub各团队将迁移至Azure作为压倒一切的优先任务。“我们将要求团队推迟功能开发以专注迁移工作。当前存在一个有限的窗口期可延后功能开发，我们必须最大限度缩短这个窗口期，”费多罗夫写道。
尽管GitHub此前已启动部分服务向Azure的迁移工作，但据我们了解，这些迁移进程时断时续且屡屡受挫。部分项目(如数据驻留计划，内部代号Project Proxima)已完全采用Azure本地云区域，该计划将使GitHub企业用户能够将所有代码存储在欧洲。
“我们必须完成这项工作，”费多罗夫强调，”GitHub能否扩展以满足AI和Copilot的需求关乎生存，而Azure正是我们的前行之路。我们已在Actions、搜索、边缘站点和Proxima等领域逐步增加Azure资源使用量，但现在必须全力推进并完成迁移。”
近期GitHub频发服务中断，部分原因在于其弗吉尼亚州核心数据中心确实面临资源瓶颈和扩展瓶颈，而AI代理正是问题根源之一。但据我们了解，部分GitHub员工对此次迁移表示担忧——因为支撑服务核心的MySQL集群运行于裸机服务器，难以顺利迁移至Azure，可能导致未来故障频发。
GitHub发言人在声明中证实了我们的报道，并表示：”未来24个月内，GitHub将迁移至Azure平台，我们认为这是对社区和团队最有利的决策。当前基础设施已达极限，我们亟需加速扩展以应对开发者活动和AI驱动工作流的爆发式增长。当前我们优先推进这项工作，因为它将为后续发展扫清障碍。对我们而言，可用性是头等大事，此次迁移既能确保GitHub保持开发者依赖的快速可靠平台属性，又能让我们具备无限扩展能力，实现更多功能开发与交付。这关乎GitHub能否以未来所需的速度和规模与社区共同成长。”
对部分开源开发者而言，GitHub与微软及Azure的深度绑定可能引发担忧；但就整体而言，近期频发的服务中断和速率限制才是开发者面临的更严峻问题。微软长期以来是GitHub的优秀管理者，但终究没有优质服务能完全摆脱微软这类巨型企业的内部政治——高管们永远渴望扩大自己的势力范围。
> 他写道，计划是让GitHub在24个月内完全迁出自有数据中心。
我发现将这类时间线(对GitHub规模的组织而言非常合理且符合预期)与《AI 2027》对2027年10月世界面貌的描述进行对比颇有意思。
若所有预测皆可信，未来24个月内：人工智能将攻克癌症；特工5号正利用全球中央存储库的数据策划灭绝人类，并操纵所有企业、政府及军方的内部政治以达成目标(这些均是AI 2027的真实预言)；而GitHub仍在将工作负载迁移至Azure。
或许他们该请4号特工来帮忙。
这种偏差恰恰是AI 2027推测所有重大突破都将发生在领先AI实验室内部的原因(至少是其中之一)。AI 2027设想的该时期人工智能代理，能在远少于24个月内完成迁移——但前提是组织必须彻底变革内部运作模式，确保所有决策都以最大化挖掘人工智能潜能为目标。微软/GitHub恐怕难以如此迅速实现转型。
你当然说得对，他们确实做不到。不过我认为将“这就是为何所有有趣的发展都将发生在AI实验室内部”作为对《AI 2027》论文的评价并不公正——该论文对AI将如何影响军事、政府、医学研究、典型企业政治、软件工程以及AI研究本身，都提出了许多广泛而深刻的论断。
你即将领悟的要点——且愿我能助你明晰：若微软与GitHub都无法如此迅速地实现AI效益，世人凭什么相信其他企业能做到？毕竟，几乎没有任何“非AI企业”正在强行改造组织架构，以比微软更快的速度拥抱AI[1]。
[1] https://www.theverge.com/tech/780946/microsoft-satya-nadella…
《AI 2027》的核心观点在于：只要有一家公司能如此迅速地实现人工智能的效益，就足以改变一切。这既源于强大人工智能加速自身发展的反馈循环，也因我们已目睹OpenAI的客户群体在眨眼间从零扩张至几乎覆盖所有领域。(此处无意介入OpenAI财务可持续性的争议；关键在于我们已知在这种情境下，单一企业快速实现全经济体市场渗透是可能的，因此这未必构成技术普及的重大障碍。)
哪些企业若能独自实现效率飞跃，便能彻底改变行业格局？绝大多数企业都处于价值链中，其实际价值创造还取决于供应商和客户。通常存在多个供应商和客户，有时每方还存在多层级关系…这限制了单个企业提升效率的速度与幅度。
我虽未读过该论文，但它似乎陷入了AI鼓吹者常犯的谬误：那个强大的“如果”。
没错，如果 AI真如神明般强大，那么率先驾驭机器之神的公司必将获益。
但现实并非如此。所谓“人工智能的益处”不过是安慰剂效应、平庸工作的自动化，以及少数有限的杠杆点。
与此同时OpenAI正专注于制作海绵宝宝警匪追逐视频
这不公平。
我还看到一只诡异的戴帽猫闯入民宅，结果被霰弹枪击中胸口。
你觉得这些事能多大程度分散他们对通用能力加速工作的注意力？我认为影响甚微，所以这似乎不是什么有力论据。
若你确信自己正参与通用人工智能竞赛，理应倾尽所有资源全力超越对手
而非把人力和千亿亿次CPU运算周期浪费在米老鼠视频上(字面意思)
哇，那个“2027年实现AI”的说法简直是OpenAI粉丝的狂热幻想。
我实在反感这种论调，因为我那些爱唱衰的朋友简直把它当成圣经。
据我记忆，论文本身只是用他们之前成功率仅50%的预测来支撑声誉。
更不明白的是，这篇论文为何要编造故事式预测，而不是更直截了当些。
我的意思是，在《AI 2027》里，OpenAI的替代者大多没被刻画得很正面。
我敢肯定我们现在处于比夫·坦南的时间线。事情在2012年左右就变得诡异了。
所以这些设定都不算牵强。
区别在于——你应该清楚——股市根本不在乎Azure迁移，它们只关注那些狂妄自大的幻想
[已删除]
为什么要推诿？烟雾弹！
明白了，但他们连Terraform提供程序的维护都放弃了！简直荒谬！他们甚至不愿开放维护权限给社区！几千个仓库怎么可能手动管理？！这提供程序向来糟糕透顶——速度慢、漏洞多，还严重滞后于GitHub新功能，现在彻底完蛋了！他们公开宣称要专注API开发，声称在API修复前会继续维护提供程序。这根本不可接受！
这很合理。现在GitHub的安全性也和Azure一样了：
https://www.wired.com/story/microsoft-entra-id-vulnerability…
从自用自销的角度看这当然合理——云服务商(微软)同时拥有产品(GitHub)，但我始终不解：技术实力雄厚的公司为何认定自己连裸机运维都做不到？
自建服务器从来不是什么高深技术，二十年前这根本是唯一选择。当年每家初创公司都得在储物间里摆满服务器机架。
我始终认为云托管是因无力承担全职运维团队才选择的方案，因此像Netflix这类企业竟宣称缺乏管理服务器的运维能力，着实令人费解。
并非他们不具备能力，而是他们根本不愿拥有这种能力。
我虽未参与过如此规模的迁移，但见过同等规模的基础设施，实在难以想象在12个月内完成有多困难。GitHub的运维/开发团队规模有多大？这个目标在我看来实在不切实际，预计会出现服务中断。
以GitHub的服务记录来看，这次迁移与日常运营之间不应存在可察觉的差异。
我在Adobe基础设施部门任职时，类似迁移耗时约8-9个月(例如扩展至Azure、现代化数据中心改造、迁移至Kubernetes)。
声明中提到要实现“完全迁移”。
我认为实际执行中可能存在长尾效应，导致迁移无法快速完成。
(不过这或许无关紧要…如果他们的核心目标是利用Azure实现扩展，那么只需确保需要扩展的部分到位即可。他们可能还希望展现“吃自家狗粮”的形象，这在不处理所有长尾系统的情况下也能合理实现。)
或许吧。不过我认为GitHub内部项目的DevOps实践和自动化效率远超普通企业。
实际操作中，我预计多数服务器会通过Azure Migrate这类工具实现迁移。我们正用它将约6000台州政府服务器迁移至云端。遇到低成本现代化改造机会时，我们会优先选择——比如迁移到SQL托管实例而非部署在虚拟机中的SQL。
自建物理基础设施难度极高，因此GitHub借助Azure的规模经济效应是明智之举。考虑到公有云最大的弊端在于成本，这对GitHub而言并非问题——他们将与Azure深度整合，以成本价获取基础设施资源。
但愿他们做好了迎接诸多麻烦的准备：随机性停机、工具与基础设施的极度迟缓(我强调是极度迟缓)、GPU资源获取困难，以及至少比其他云服务高出2-3倍的成本。技术支持团队由海外印度员工组成，他们拖延每一次沟通，直到耗尽你的耐心让你放弃。
> 支持团队由海外印度人组成，他们拖延每次互动，磨得你精疲力竭直至放弃
你真以为他们和多数顶尖微软合作伙伴一样，支持都来自印度？
试试直接联系雷德蒙德团队吧。
对此我持中立态度…相较微软收购后的预期，进展已超出想象。最意外的是：既没想到会这么晚才发生，更没想到他们竟做出相对理性的选择——明确优先推进环境迁移，而非同时推进多个“优先级”项目和功能。
这是否意味着GitHub终于要支持IPv6了？
Azure必须先修复其IPv6支持，才能摆脱“基本失效”的状态，否则就只是“为满足合规要求而存在的摆设”。
我基本上不想要任何GitHub新功能，所以这听起来完全是好事。
若能完善Actions功能就太好了。大家如何应用组织/团队级策略(如任务超时设置)来避免耗尽月度配额？上次检查时这功能还没实现 :/
你可以自定义JSON模式，并在创建PR时将其作为验证规则。或者直接用正规编程语言处理YAML检查。
可搭配组织模板仓库使用，让所有成员从该模板启动新项目(模板中已包含检查未来工作流文件的流程)。
若需协助制定全组织代码规范，我的邮箱在个人资料中，随时可提供支持。
最终我采用了模板和配置检查方案，但若能开箱即用强制执行会更理想。这只是我想到的一个例子，当前体验粗糙到需要绕行方案https://github.com/orgs/community/discussions/14834。或许是别处草更绿的错觉加上记忆模糊，我竟开始怀念Jenkins了…
这算好消息吧？毕竟大家抱怨他们功能堆砌太臃肿。如果这能阻止他们把AI编辑器搞得更离谱，转而专注于完善现有编辑器，那真是太好了。
完全同意！我抱怨这个问题很久了：别再强推没人要的AI功能，先提升可靠性吧。
我只希望他们能先收拾GitHub通知功能的烂摊子：https://github.com/orgs/community/discussions/15747
> 他写道：“跟上AI和Copilot的需求对我们至关重要，它们正在改变人们使用GitHub的方式。”
没错，那些无法禁用的“AI”功能迫使我耗费大量时间精力，将所有项目迁出GitHub
考虑到“CTO弗拉基米尔·费多罗夫指出GitHub弗吉尼亚数据中心存在容量限制”，且Azure拥有完善的AI支持基础设施和基础虚拟机配置，此举合乎情理。
但作为经历过数据中心迁移的人，根据他们现有架构的“独特性”程度，我对他们面临的挑战深表同情(估计实际耗时会是预期两倍：P)。
弗拉基米尔·费多罗夫几个月前才从Meta跳槽到GitHub。他懂什么？
至少有人告诉过他“我们弗吉尼亚数据中心的容量受限”。
尽管GitHub此前已启动部分服务迁移至Azure的工作，但据我们了解这些迁移进程屡遭中断甚至失败
且没有理由认为下一批迁移会有所不同。告诉工程师们“祝你好运，接下来18个月你们只能原地踏步”，这种方式既无法激发他们全力以赴，更难留住人才。
我认为迁移暂停更多是微软有意延缓。微软通过向外部销售Azure获利更多，且当大型语言模型和人工智能成为微软核心业务之一时，他们需要更多算力来扩展GPU基础设施。
话虽如此，工作难度确实也是导致早期迁移计划搁浅的因素之一，因此我认为你的观点总体上仍然成立。只是现在阻碍因素将得到解决，工程师们也将持续推进工作，而非让项目停滞不前。
正如俗语所说：“这是终结的开始。”
终结什么的开始？若几年前有人问“GitHub会迁移到Azure吗”，我绝对会下注。
收购后这似乎是必然趋势，未必是坏事。我认为是中性的。
关键在于他们将此置于新功能之上。
不过既然所谓“新功能”主要就是把该死的Copilot助手硬塞给所有人，倒未必是坏事。
再加上测试版的新React差异查看器。旧版似乎只是Rails Turbo框架里的简单Web组件。
我测试过测试版，和多数单页应用一样，它在大数据量(大量文件/行数)下扩展性很差。即使在高端MacBook上也能感受到DOM响应变慢，甚至出现过几次页面空白——这是浏览器过载时的常见问题。所以我又切回了旧版本。
新版在URL片段中也无法始终精确定位到特定行，尤其当差异过大时，这使得链接分享变得棘手。
关键在于他们将此问题置于新功能之上优先处理。
很好！巩固基础设施而非追逐最新潮流本就鲜少被重视。我宁愿选择枯燥但可靠的方案。
有道理，但我觉得他们迁移只是为了讨好微软老板。
有人知道他们现在用什么基础设施吗？AWS？
若认为Copilot编码助手不是他们当前最重要功能，那你可真是傻瓜。它现在表现平平，但必须变得出色。
他们当前的Git仓库服务架构相当复杂——这次迁移导致稳定性或性能下降我一点都不意外。
确实，但或许也能促使他们修复部分问题。
不，我是说其本质如此。这本质上是一系列缓存问题的叠加。
这种趋势始于微软收购，随着Copilot加速发展。据传GitHub管理层只关注Copilot/AI项目，其他功能获得的关注度和资源严重不足。我从现任及离职员工处反复听到这种说法。
不，我认为我们早已越过临界点。转折点或许是微软收购GitHub之时，或是GitHub独立性被彻底剥夺之时。
个人观点：加速走向不可逆转的转折点，是微软决定全力押注人工智能，并将GitHub Copilot视为关键突破口——甚至不惜将Copilot品牌推广至整个公司。
在此之前，平台整体上仍保留着某种程度的自主性，能独立思考开发者体验。但当ChatGPT风靡一时，微软决定全力押注人工智能后，Copilot(以及GitHub)对微软而言变得至关重要，无法再置之不理。
考虑到收购案的惯常走向，这种滑坡或许本就难免。但在我看来，Copilot正是那场将八爪鱼冲向大海的海啸。
这确实让老用户想起Hotmail.com的往事
此后他们终于会为所有人启用Entra的单点登录功能了吗？