GitHub 故障拖慢微軟 AI 編碼優勢

我拆 GitHub 故障與 Azure 轉移卡住微軟 AI 編碼優勢的原因，最後給你一份可直接套用的穩定性 playbook。

我盯微軟這條 AI coding 線很久了，老實說，越看越不對勁。零件明明都在：GitHub、Copilot、Azure、OpenAI 的資源、開發者心智。照理說，這應該是一路往前衝的局。但實際上不是。服務一直抖，使用者一直卡，團隊一邊說 AI 能力很強，一邊又把產品丟進一個看起來快撐不住的基礎設施裡。最尷尬的是，微軟明明握著開發者平台的門票，卻眼睜睜看著 Cursor 和 Claude Code 把場子搶走。

我最有感的是那種「明明有優勢，卻越用越像在補洞」的感覺。很多團隊都會把 distribution 當成免死金牌，覺得只要平台夠大，使用者就會忍。問題是，開發者不是來參拜的。你一旦開始擋人工作，他們就會默默開新分頁、換工具、在 Slack 裡抱怨，最後把原本的默認選項踢掉。這種事我看太多次了，真的不是靠幾張 roadmap slide 就能壓住。

觸發我把這件事拆開來看的，是 CNBC 這篇 文章，作者是 Jordan Novet。它把 GitHub 的故障、Azure 遷移壓力、管理層變動，跟 AI coding 市場的快速變化串在一起。這篇沒給觀看數或 bookmark 數，我就不亂掰。它真正有價值的地方，是把「技術問題」講成了「信任怎麼掉光」的故事。

GitHub 不是輸在 AI 不夠強，是輸在穩定性太難看

“We have not met our own availability standards,” Vlad Fedorov, GitHub’s technology chief, wrote in a March blog post.

翻譯一下就是：我們連自己訂的可用性標準都沒守住。這句話很直白，也很傷。因為對開發者平台來說，availability 不是營運指標而已，它就是產品本體。你把工作流卡住，後面再疊多少 AI 功能，都只是把裝飾貼在壞掉的廚房上。

CNBC 提到，GitHub 自三月以來有超過十幾起超過一小時的事故。這不是單次失誤，是使用者會感受到的模式。開發者很現實，真的很現實。他們不會因為你有宏大願景就原諒你把 clone、push、review、merge 搞到幾個小時不能用。HashiCorp 的 Mitchell Hashimoto 在文中提到，他們被卡到「for hours per day」，這種話一出來，信任基本就開始漏氣了。

我以前待過一個團隊，內部平台也是這樣：每次 demo 都很漂亮，一到尖峰就開始抖。結果大家嘴上說接受，手上卻偷偷繞路。這就是 GitHub 現在的處境。AI coding 是放大器沒錯，但它放大的不只效率，也會放大底層的痛。底層撐不住，AI 只會讓人更快看見你撐不住。

實操寫法很簡單：如果你在做 developer platform，不要把可用性藏在「平台健康」這種模糊字眼裡。把它當成一個獨立產品線來管，設自己的 owner、自己的 release gate、自己的 downtime budget。內部要看數字，不能只看感覺。你守不住，就不要說自己有平台策略，頂多叫願望。

• 把 availability 拆到 workflow 層級，不要只看服務總體。
• 針對 clone、push、review、merge 設 error budget。
• 事故回顧要進產品規劃，不要只留給 ops 收尾。

Azure 遷移不是背景板，它就是卡住容量的那根手

CNBC 的重點之一，是 GitHub 長期遷移到 Microsoft Azure 的過程拖得很久，結果限制了可用算力。這種企業內文看起來很官腔，實際上意思很簡單：遷移債會很快變成產品債。你以為你在搬家，實際上你在一邊搬、一邊接客、一邊修漏水。

文中還提到，Vlad Fedorov 在三月說，GitHub 有 12.5% 的流量走 Iowa 的 Azure region，目標是到七月把 50% 流量放到 Azure。這代表什麼？代表根本還沒完成遷移，只是在半路上硬撐。半路上最麻煩，因為 queue 會開始怪，capacity 會開始歪，大家就會一直為例外開綠燈。

我看過太多公司把「上雲」講得像一個乾淨俐落的動作。實際上不是。它通常是老系統、法務限制、供應商條件、季度目標一起攪成一鍋。問題是 AI coding 的需求不會等你遷移完。使用量一上來，平台要嘛有 headroom，要嘛沒有。沒有就會有 throttling、有延遲、有事故，然後使用者完全不在乎你的架構圖畫得多漂亮。

實操上，如果你一邊遷移、一邊推 AI heavy product，就不要假裝遷移不影響體驗。你要先做 peak load model，而且不是只看平均流量，是看高峰、故障恢復、區域切換、AI agent 爆量這些情境。然後明確講清楚：系統撐不住時，哪些功能先停、哪些先降級、哪些延後。

• 把 peak traffic 跟 average traffic 分開測。
• 把 migration risk register 綁到 customer-facing incidents。
• 平台已經發熱時，不要硬上新的 AI feature。

分發優勢不等於習慣優勢，這兩個差很多

微軟原本最大的牌，就是 GitHub 本來就站在開發者工作流裡。按理說，Copilot 應該很自然地變成預設選項。但 defaults 只有在持續好用時才黏得住。CNBC 引用的資料說，GitHub 現在的開發者數量是 2018 年被微軟收購時的六倍，還是 devops 市場的大站；可同時，Cursor 和 Anthropic 的 Claude Code 已經把動能拉過去了。

白話一點就是：分發很大，不代表偏好很穩。你可以到處都是，但只要體驗比別人慢、吵、卡，使用者還是會走。CNBC 也提到，根據 Ramp 的資料，Cursor 大約在一年前就已經在市占上超過 GitHub Copilot。這訊號夠直接了吧，不是被挑戰，是被超車。

我覺得很多平台公司都會犯一個老毛病：以為既有用戶會因為已經在流程裡，就願意吞下更多摩擦。短期也許會，長期不會。只要有一個競品把 loop 做得更短、回饋更快、少一堆廢話，原本的「夠用」就會顯得很偷懶。AI coding 特別殘酷，因為使用者幾個 keystroke 就在評分，根本沒有長 sales cycle 幫你拖時間。

實操寫法：如果你手上有 default 優勢，請你先假裝自己是 challenger。不要拿老客戶安慰自己，要拿最兇的對手當標準。看使用者是不是在同一個任務中途切工具，看你的產品是不是只是備胎，不是第一選擇。

• 追蹤使用者是否會中途切到別的工具。
• 看你的產品是 first tab 還是 fallback tab。
• 新功能如果只是多按鈕，別自欺欺人說有提升。

領導層在換人，使用者只會把它解讀成失控

文章裡提到 Thomas Dohmke 在八月卸任 GitHub CEO，Julia Liuson 在四月退休，還有幾位 GitHub VP 轉去微軟其他部門。這種組織變動平常看起來像 HR 資訊，但在產品出問題時，它會變成放大器。因為使用者不會把故障解讀成單純技術事件，他們會直接把它讀成：這家公司是不是在漂移？

也就是說，當產品本來就不穩，組織又看起來在洗牌，外界不會想「喔，應該很快就修好」。他們會想「這團隊是不是沒人真正接手」。你可以撐過一次大事故，但很難撐過一連串看起來彼此相連的「我們正在處理」更新。

我以前也在那種公司待過，工程其實有能力修，問題是 ownership 一直換，最後 postmortem 變成政治文件。那種感覺很糟，因為使用者感受到的不是 bug，而是沒人負責。你一旦讓人覺得「每次出事都沒人能把整條線扛到底」，信任就回不來了。

CNBC 也引用了 Flask 作者 Armin Ronacher 的說法，意思大概就是：大家已經受夠不穩定、產品亂改、Copilot 噪音、領導不清楚，以及那種平台不再主要為原本社群服務的感覺。這種抱怨不是隨口罵，是使用者心裡已經準備離場時才會講的話。

實操上，如果你的產品正在出問題，組織又在變動，你就要過度溝通 ownership。不要讓人猜。誰負責 reliability、誰負責 incident、誰負責 migration、誰負責對外溝通，全部寫清楚。使用者看不出誰在開車，就會直接假設沒人在開。

• 可靠性只給一個 owner，不要委員會式分散責任。
• 事故時間線跟復原步驟，用白話公開。
• 高層異動不要變成產品責任模糊。

AI coding 市場跑得太快，Copilot 已經不像 pace setter

CNBC 引用 OpenAI 的說法，4 月時 Codex 的 active users 有 400 萬，比不到兩週前的 300 萬又往上跳。文中也提到 Anthropic 的 Claude Code 和 Cursor 的動能。反過來看，微軟在一月說 GitHub Copilot 有 470 萬付費訂閱者，比前一年成長 75%。數字都漂亮，但漂亮不等於領先。

翻譯一下就是：市場現在不再只看你是不是先發。Copilot 早在 2021 年就出來了，先發當然有價值，但現在門檻更高。開發者要的是：回饋快、流程順、真的幫得上忙，而且每次用都不會讓人翻白眼。如果你的產品只剩「大家都知道它」，競品卻一直在推新東西，久了你就會像舊標準，不像新標準。

我一直覺得平台公司最容易掉進一個坑：發明了類別，就開始守類別，守到最後把原本的速度守沒了。AI coding 不是博物館，沒人在乎誰先進場，大家在乎的是現在誰比較省時間。能不能少一個步驟、少一次等待、少一次出錯，這才是決勝點。

實操寫法：不要只看 signup 或 paid subs。你要看的是，這個 AI 工具有沒有真的變成 coding session 的預設。看 retention by task，不要只看 account。使用者訂了，但真正幹活時還是去開別的工具，那你的 lead 多半只是表面數字。

• 比較 active usage 跟 paid adoption，不要只看一邊。
• 追蹤 AI 建議被直接接受的比例。
• 看新功能到底有沒有被用，還是只是發新聞稿時很好看。

多雲不是戰功，是止血

文章還提到，GitHub 現在除了自家機房，也依賴 Amazon、Google、Microsoft、Oracle 這些雲端資源。Fedorov 說，他們已經開始走向 multi-cloud，並且在把較小的自建 data center 逐步移出。這段話如果翻成人話，就是：原本想要的集中式架構，現在不夠用了，只能用更麻煩的方式換穩定。

也就是說，多雲很多時候不是策略炫技，而是被逼出來的生存手段。它貴、它亂、它很難維運，但如果不這樣做，代價是更頻繁的故障。所謂「架構比較優雅」在這裡通常只是比較好聽的失敗方式。

我一直覺得團隊講 multi-cloud 時太浪漫了。實務上，它常常是因為某個 cloud 太熱、某個 region 太擠、某個 dependency 變成單點，最後只好到處留後路。GitHub 現在看起來就是這種狀態：不是因為喜歡複雜，而是因為不這樣會更痛。

實操上，多雲只該放在真的能降低風險的地方，不要為了看起來很成熟就把工作負載撒滿天。優先放在 auth、storage、code review、deployment 這種出事會直接傷到使用者的路徑，然後真的去測 failover，不要只在簡報裡畫箭頭。

如果你是在別人的平台上做產品，這件事也順便提醒你：出口不能死。真正跑得快的團隊，不是架構圖畫得最漂亮的那個，而是有 fallback、而且敢用 fallback 的那個。

可抄的模板

# Reliability-first AI coding playbook

## 我們到底在優化什麼
- 開發者信任，先於功能數量
- 可用性，先於 AI 新鮮感
- 容量，先於上線速度
- 清楚 ownership，先於組織改組

## 1) 把產品定義成 workflow，不是功能
產品不是「Copilot」或「agentic coding」，產品是：
- 開 repo
- 編輯 code
- 產生建議
- 審查建議
- 合併變更
- 出事時復原

每一步都要定：
- owner
- SLO
- 主要 failure mode
- escalation path

## 2) 設硬性的 reliability budget
每週追這些：
- uptime
- p95 latency
- failed pushes
- failed merges
- 超過 1 小時的 incident 數
- mean time to recover

規則：
- core workflow 事故超標時，不准上新 AI feature
- rollback 沒測過，不准 launch
- migration 沒穩定 30 天，不准算完成

## 3) 容量規劃要看 AI load，不是舊流量
模型要至少包含：
- 正常使用
- 平日高峰
- 事故恢復流量
- AI agent burst
- 區域 failover

每個情境都要回答：
- 先壞的是什麼？
- 哪些會優雅降級？
- 哪些要 throttle？
- 哪些要暫停？

## 4) 讓 migration 透明
做一個 migration dashboard，至少包含：
- 目前流量切分
- 還沒搬完的 legacy dependency
- 被卡住的項目
- 容量風險
- 對客戶的影響

如果 migration 正在拖累產品可靠性，就直接講。

## 5) 把競品當成產品規格
每季比較一次最強競品，問：
- 哪個任務它更快？
- 哪個步驟它更不煩？
- 哪種失敗它更能接受？
- 使用者會主動提到什麼？

然後挑前三個 gap 直接補。

## 6) 寫 ownership memo
格式固定成這樣：
- Incident owner:
- Infrastructure owner:
- Product owner:
- Migration owner:
- Support owner:
- Escalation channel:
- Customer communication lead:

## 7) 上新前檢查
每次 ship 新 AI coding feature 前，先確認：
- load test 過了
- rollback 測過了
- support docs 更新了
- incident playbook 更新了
- human review path 確認了
- capacity headroom 夠了
- 對客戶的溝通稿先寫好了

## 8) 客戶 fallback
如果主平台 degraded：
- 清楚顯示 status
- 盡量提供 read-only
- 自動保留工作內容
- 提供 export 路徑
- 把 recovery steps 寫成一頁

## 9) 每週營運 review
每週回答：
- 這週壞了什麼？
- 使用者受到了什麼影響？
- 我們對容量學到了什麼？
- 因為可靠性，我們延後了什麼？
- 競品這週又補了什麼？

## 10) 決策規則
如果一個 feature 讓 AI 更炫，但也讓 outage 風險上升，先不要 ship，直到可靠性補齊。

這段我會直接丟給團隊，不用客氣。它不帥，但它逼你把真正重要的事情講清楚。AI coding 產品如果正在掉信任，補法不是再多喊幾次 AI，而是把 headroom、ownership、workflow 定義先拉正。

原始報導來自 CNBC 的 這篇文章。我這篇是基於它的報導內容、文中引用的公開來源，加上我自己對平台可靠性怎麼把優勢磨掉的整理；模板則是我重新整理後可直接拿去用的版本。