BridgeCraft logobridgecraft
週報顧問服務作品集關於聯絡登入
聯絡

bridgecraft

從資料視覺化到 AI Agent,一直在找下一個 meta

文章主題指南週報顧問服務Labs作品集系統架構關於聯絡RSS

© 2026 BridgeCraft — Waiting7777. All rights reserved.

← 所有文章
GitHub appears to be struggling with measly three nines availability

GitHub appears to be struggling with measly three nines availability

2026年3月24日 · Waiting7777 · 3 分鐘閱讀

AI
📂 AI 系列

GitHub 這幾個月的 uptime 真的慘不忍睹,三個九都撐不住,讓我開始認真思考依賴單一平台的風險。

宕機的真實成本

前端開發者每天要跟 GitHub 互動幾十次 — push code、拉 PR、看 issue、下載 npm packages。當 GitHub 掛掉的時候,影響層面遠比想像中大:

CI/CD 全停。GitHub Actions 一掛,整個 deployment pipeline 就卡住了。我們專案的 staging 更新被延了四個小時,結果 PM 還在問為什麼功能沒上線。

npm registry 連帶受影響。雖然 npmjs.com 是獨立服務,但很多 private packages 跟 GitHub Packages 綁定。npm install 失敗的時候,整個開發環境都建不起來。

協作徹底中斷。Pull Request review、issue tracking、project board — 這些都是現代開發流程的核心。GitHub 一掛,team sync 就變成在 Slack 裡面貼 code snippet,效率直接腰斬。

為什麼會這樣?

GitHub 的基礎建設老實說已經撐不住現在的規模了。每天幾千萬的 Git 操作、Actions minutes、Package downloads — 這個量體要做到 99.99% 的 uptime 真的很難。

更麻煩的是,GitHub 不只是 Git hosting,它已經變成整個開發生態系的中樞。OAuth provider、CI/CD、Package registry、Project management — 把這麼多 critical path 綁在一起,任何一個環節出問題都會連鎖反應。

我覺得 Microsoft 當初收購的時候可能低估了維運的複雜度。Azure 的那套基礎建設要完全適應 GitHub 的使用模式,顯然還在磨合期。

備用方案策略

Git 分散式架構要用好用滿。我現在會把重要的 repo 同步 push 到 GitLab 或 Bitbucket,至少 code 不會消失。雖然多一個步驟,但 peace of mind 值得。

CI/CD 不要 all-in GitHub Actions。我們開始把部分 workflow 移到 GitLab CI 和 Vercel,分散風險。GitHub Actions 的 YAML 語法轉移到其他平台其實沒那麼痛苦。

重要 dependencies 本地化。對於 critical 的 npm packages,我會定期備份到 company registry 或至少 cache 起來。npm ci --offline 救過我好幾次。

Documentation 和 Project tracking 多備份。README、API docs、project roadmap 這些東西不能只放 GitHub。我們開始用 Notion 做主要的 knowledge base,GitHub repo 只放 technical specs。

產業層面的問題

這件事反映出整個 tech industry 對單一平台的過度依賴。GitHub 已經變成 too big to fail 的存在,但 uptime 卻沒有跟上這個責任。

銀行業有 99.99% 的 SLA 要求,為什麼支撐全球軟體開發的平台可以連 99.9% 都達不到?這個標準設定本身就有問題。

我猜接下來會看到更多 enterprise 客戶開始評估 self-hosted 的 GitLab 或 Bitbucket Server。雖然 maintenance overhead 比較高,但至少 uptime 掌握在自己手裡。

對個人開發者來說,這是個 wake-up call。不要把所有雞蛋放在同一個籃子裡,即使那個籃子是 Microsoft 的。

實際行動

我已經開始調整工作流程:每個重要 project 至少要有兩個 remote,CI/CD 要有 fallback option,critical dependencies 要有離線 cache。

雖然多了一些 setup 時間,但總比在 demo day 前夕因為 GitHub 掛掉而手忙腳亂來得好。

GitHub 要嘛提升 infrastructure,要嘛調整大家的期待。現在這種狀況對誰都不好。

<h2>延伸閱讀</h2> <ul> <li><a href="/blog/frances-aircraft-carrier-located-in-real-time-by-le-monde-through-fitness-app">法國航母因為 strava 被追蹤</a></li> <li><a href="/blog/building-nextjs-for-an-agentic-future">Building Next.js for an agentic future</a></li> </ul>

每週一篇 — 技術趨勢背後的商業邏輯

分享:

Waiting7777

WoW Arena 冠軍轉前端,用電競 meta 思維拆解技術趨勢。

關於作者

相關文章

他幫忙訓練開源 AI,然後跑去做 AI 管控 — Connor Leahy 到底看到了什麼AI創辦人故事+3

他幫忙訓練開源 AI,然後跑去做 AI 管控 — Connor Leahy 到底看到了什麼

從 Leahy 的個人轉變切入 — 一個幫助訓練開源大模型的人,為什麼最後跑去做 AI 管控?他看到了什麼讓他轉向?

2026年9月12日 · HW SHU · 7 分鐘閱讀

繼續閱讀 →
GPT-6 Astra 怎麼運作的?Looped Transformer 和隱藏推理鏈拆解GPTAI+2

GPT-6 Astra 怎麼運作的?Looped Transformer 和隱藏推理鏈拆解

用「為什麼 OpenAI 要做 looped transformer」切入 — 不只解釋技術,而是這個設計選擇背後的工程取捨和成本考量。

2026年9月11日 · Waiting7777 · 8 分鐘閱讀

繼續閱讀 →
ChatGPT Work 幫 Stampli 省了 68% 工時 — 這個數字真的可信嗎?GPTAI+3

ChatGPT Work 幫 Stampli 省了 68% 工時 — 這個數字真的可信嗎?

用 Stampli 這個案例分析「AI 到底幫企業省了什麼成本」,並拆解 68% 這個數字背後的商業邏輯,以及 OpenAI 為什麼要積極收集這類 case study。

2026年9月8日 · Waiting7777 · 7 分鐘閱讀

繼續閱讀 →

這篇文章對你有幫助嗎?

每週一篇 — 技術趨勢背後的商業邏輯

AI 產業在變什麼、工程師該注意什麼——拆清楚寄到你的信箱。