Platform Engineering 內部開發者平台（IDP）採購完整指南：Backstage / Cortex / Port / 自架 4 條路徑 — 中小工程團隊 6 個決策、5 條合約紅線、3 個報價區間
我們在最近幾個月做客戶系統諮詢時，發現一個很一致的訊號——當公司工程團隊從 5 個人長到 12 個人之後，老闆會收到同樣一個版本的抱怨：「現在新人 onboarding 要兩週、release 要排隊一週、誰負責哪條服務沒人說得清楚」。這就是平台工程（Platform Engineering）需求出現的時刻，也是 Backstage / Cortex / Port 這幾個 IDP（Internal Developer Platform）平台這兩年在中型工程組織爆紅的原因。
Gartner 2026 報告把 IDP 列為「2027 前 75% 中型工程組織會採購的基礎設施」。但在台灣中小企業現場，老闆面對的問題不是「要不要」，而是「要不要現在動手、要 SaaS 還是自架、要採購誰、要開多少預算」。本文用「業主視角 + 採購紅線 + 報價區間」三個切面回答這四個問題，給 30-150 人公司、有 5-30 人工程團隊的決策者一個可以照著走的決策框架。
為什麼工程團隊長到一定規模就會需要 IDP
先講結論：5 人以下工程團隊不需要 IDP，10 人以上開始痛、20 人以上不裝就會塌方。痛點不是工具不夠用，是「組織知識」沒地方放——新人要問同事才知道 staging 怎麼開、誰是哪條服務的 owner、release pipeline 是誰寫的、Incident playbook 在哪。這些都是隱性知識，沒有 IDP 就靠 Slack 群組和個人記憶撐著，撐到下一個資深工程師離職就垮。
我們公司目前 20+ 個 AI 流程在工作中，自家的「Skill Library 技能庫」就是一個小型 IDP 雛形——所有 agent 的 prompt、tool 定義、執行記錄都集中在一個 catalog，新人不用問就能查。中小企業如果還沒到要自建 IDP 的規模，至少要先把「服務 catalog」這個最小可行版本架起來。
5 個 IDP 需求訊號（出現任 3 個就該開始評估）
- 新人 onboarding 平均要超過 10 天才能第一次 deploy 成功
- 「誰是這條服務的 owner」這個問題每週都會在 Slack 出現至少 2 次
- release pipeline 維護的工程師離職 / 請長假，組裡沒人接得了
- incident 發生時找不到 runbook 或 oncall rotation 表
- 工程師花在「找上次怎麼做」的時間佔每週 ≥ 5 小時
Backstage / Cortex / Port / 自架 四條 IDP 路徑全景對比
IDP 平台選型，本質上是「擁有度」和「TCO」的權衡。Backstage 是 Spotify 開源的 IDP framework，自架免授權費但工程成本高；Cortex 和 Port 是 SaaS，月費高但開箱即用；自架（用 Notion + n8n + 自己寫 portal）成本最低但客製化天花板也最低。下表是 4 條路徑的 6 維度對比。
維度 | Backstage 自架 | Cortex SaaS | Port SaaS | 自架 Notion + n8n |
|---|---|---|---|---|
授權成本 | 免費（開源 Apache 2.0） | $8-15/工程師/月 | $10-18/工程師/月 | Notion $10/人/月 |
上線時間 | 8-16 週 | 2-4 週 | 1-3 週 | 1-2 週 |
客製化天花板 | 極高（React + TS 隨改） | 中（YAML scorecard） | 中高（Blueprint DSL） | 低（受 Notion 限制） |
維運成本 | 2-3 個工程師長期維護 | 低（廠商運維） | 低（廠商運維） | 低（無基礎設施） |
3 年 TCO（20 人團隊） | NT$ 280-450 萬 | NT$ 100-180 萬 | NT$ 120-220 萬 | NT$ 30-60 萬 |
我們的判斷是：30 人以下工程團隊建議走「自架 Notion + n8n」最小可行版本；30-100 人團隊上 Cortex / Port SaaS；100 人以上才值得自架 Backstage（且通常是因為要塞獨家 plugin）。
中小企業老闆採購 IDP 的 6 個決策框架
採購 IDP 不是工程主管自己拍板就能定的事，老闆要從預算、人力、合約三個層面參與。下面 6 個決策每一個都會在合約簽訂前出現。
決策 1：先求服務 catalog，還是先求 scorecard 治理
Cortex 強在 scorecard（用 YAML 把「成熟服務的標準」寫死，自動掃描違規），Port 強在 catalog 視覺化、Backstage 兩者都中等。先求 catalog 適合「我們現在連有哪些服務都不確定」的團隊；先求 scorecard 適合「服務多但治理鬆」的團隊。
決策 2：要不要綁 CI/CD pipeline
Port 的 self-service action 可以直接觸發 GitHub Actions / GitLab CI 跑 release，工程師不用切到別處點。但這也代表 IDP 一掛 release 就停。中小企業老闆要問廠商：「你的可用性 SLA 是多少？掛了之後 release 怎麼辦？」答不出來就不要簽。
決策 3：authentication / SSO 是否包含在標準方案
Cortex 和 Port 的 SSO 通常要升級到企業方案（多 50-80% 月費），Backstage 自架要自己接 OIDC。SSO 不要事後加，加在合約裡，否則一年後續約被宰。
決策 4：scorecard 違規該不該擋 merge
業界一派主張「IDP 應該只是 dashboard，不應該擋人 commit」；另一派主張「不擋就沒用」。我們的觀點是：前 6 個月只看不擋，6 個月後針對「P0 服務」開始擋 merge——讓組織先有感再有牆。
決策 5：要不要把 AI agent / MCP 接進 IDP
2026 年 IDP 大廠（Cortex、Port）都已支援把 IDP 變成 MCP server，讓 Claude / Cursor 直接讀 service catalog 自己 deploy。這是值得加價的功能——前提是工程團隊已經在用 AI coding。
決策 6：合約退場條款 + 資料返還
IDP 裡塞的是 6-18 個月的組織知識（service catalog、ownership、scorecard 歷史）。合約必須寫死「終止合作後 14 天內提供完整 JSON / CSV export，原始碼歸客戶 OR 廠商提供 docker image 自己跑」，兩條至少要有一條。
3 個報價區間：NT$ 30 萬 / 100-200 萬 / 280-450 萬
區間 | 適合規模 | 代表方案 | 3 年 TCO | 上線時間 |
|---|---|---|---|---|
輕量自架 | 10-30 人工程團隊 | Notion + n8n + 自寫 portal | NT$ 30-60 萬 | 1-2 週 |
SaaS 入門 | 30-80 人工程團隊 | Cortex Standard / Port Pro | NT$ 100-180 萬 | 2-4 週 |
SaaS 進階 | 80-150 人工程團隊 | Cortex Enterprise / Port Scale | NT$ 180-280 萬 | 4-8 週 |
Backstage 自架 | 100+ 人工程團隊 | Backstage + 客製 plugin | NT$ 280-450 萬 | 8-16 週 |
ℹ️我們做過這件事
目前內部就有 20+ 個 AI 流程在工作中，每個 agent / Skill / tool 的定義集中放在自家的 Skill Library catalog——這是我們自己驗證過的「最小可行 IDP」雛形：服務元資料 + ownership + 執行歷史三件事先做到，後面 scorecard 和 self-service action 才有意義。
在我們 30+ 個企業客製化系統的諮詢經驗中，平台工程是工程團隊從 10 人成長到 30 人這個區間最容易踩雷的環節。如果你正在評估 IDP 採購、不確定要 SaaS 還是自架，可以從 AI 系統開發（/services/ai-system） 或 客製化系統開發（/services/customize-web） 開始聊起。
5 條 IDP 採購合約紅線（簽前必看）
這 5 條是我們審過幾份 IDP SaaS 合約後整理出來的踩雷點，每一條都來自實際出問題的客戶經驗。
- 資料返還格式必須寫死：終止後 14 天內提供 JSON / CSV / Postgres dump 三選一，不接受「協助匯出」這種開放性字眼
- 服務 catalog 的 ownership 紀錄必須包含修改歷史（audit log），不只是當前狀態
- scorecard rule 是否歸客戶所有：如果用客戶寫的 YAML scorecard，客戶終止後 rule 應該能帶走
- SLA 必須區分「IDP 本身可用性」和「self-service action 觸發 CI 的成功率」，後者通常 SLA 較弱
- SSO / SCIM / audit log 三件套必須在簽約時就含在方案內，不接受「之後加價升級」
ℹ️我們怎麼看：IDP 的下一個 3 年
我們的判斷是：3 年後 IDP 會從「工程治理工具」變成「組織知識 AI 接口」——每個 agent 都會把 IDP 當成「公司服務地圖」來查。Backstage 已經在路上，2026 Q2 開始有官方 MCP plugin；Cortex / Port 也跟進。
給中小企業老闆的判斷工具是：問廠商一句「你的 IDP 有沒有開 MCP 或 API，讓 Claude / Cursor agent 直接讀 service catalog 自己處理 incident？」答得出來的就值得繼續談，答不出來的等 6 個月再回來看。
下載：IDP 採購評估 checklist 與合約紅線範本
如果你正在做 IDP 採購評估，可以先讀過 中小企業 AI / 軟體採購供應商盡職調查 SOP（/blog/smb-ai-software-vendor-due-diligence-sop-12-checks-5-red-flags-4-exit-clauses） 把 12 項盡職調查跑一遍，再讀 客製化系統 SOW + 規格書 + 合約完整指南（/blog/custom-software-sow-spec-contract-guide-5-spec-redlines-4-acceptance-milestones-3-penalty-templates） 把合約紅線對齊。
不該採購 IDP 的 3 種情況
這節是平衡視角：為了避免讀者誤以為「IDP 就是萬靈丹」，列出 3 個明確不該採購的情況。
- 工程團隊 < 8 人：服務 catalog 用 Notion / Confluence 一頁就能寫完，買 IDP 是把月費浪費在「員工數 < 8 人版本」上
- release cadence < 每月 1 次：IDP 的 self-service action 是給「每天 release 多次」團隊用的，如果你 release 很慢，IDP 反而會變成另一個沒人維護的儀表板
- 團隊沒有 platform engineer 角色預算：Cortex / Port 不是「裝了就會自己長 catalog」，需要 0.5-1 個工程師持續做 catalog 維護，沒這個預算先別簽
QIDP 跟 DevOps 工具有什麼差別？
DevOps 工具（GitHub Actions、ArgoCD、Datadog）解決「如何 deploy / monitor」；IDP 解決「組織中有哪些服務、誰負責、達不達標」。前者管 pipeline，後者管 catalog。中型工程組織兩者都要，但採購順序是先 DevOps 工具、後 IDP。
QBackstage 真的免費嗎？
Backstage 本體開源免費，但落地需要 2-3 個工程師花 2-4 個月做 plugin 客製、SSO 接入、catalog 初始化。算進工程師時薪後 3 年 TCO 通常落在 NT$ 280-450 萬，比 Cortex / Port 還貴——但客製化天花板極高。
QCortex 跟 Port 哪個適合台灣中小企業？
Cortex 在 scorecard 治理上更成熟，Port 在 self-service action 更強。30-50 人工程團隊先看 catalog 視覺化（Port 較好），50-100 人團隊要做 maturity 治理（Cortex 較好）。預算差距不大，可以同時 trial 兩週後決定。
Qself-service action 真的能取代工程師做 release 嗎？
可以但有條件：service catalog 必須完整、scorecard 要過、action 要有 audit log。落地節奏建議：前 3 個月只開「重啟 service」「rollback」這兩個 low-risk action，3-6 個月加「create new repo from template」、6-12 個月才開「production deploy」。
QMCP / AI agent 接入 IDP 該怎麼開始？
Cortex 2026 Q1 推出 MCP server beta，Port 在 6 月跟進。建議先從「讀 catalog」這條最安全的 action 開始，讓 Claude / Cursor 能查 service ownership；6 個月後再開「觸發 PR 模板生成」這條寫入動作。incident response 這條最後接，因為錯了會撞到 production。
Q中型工程組織導入 IDP 失敗的最常見原因？
我們觀察到 3 個失敗 pattern：1) 老闆沒給 platform engineer 角色預算，工程師兼差做 catalog 維護半年後 catalog 完全過時；2) scorecard 設太嚴，工程師不爽 + 開始繞過去；3) 沒有 ownership 紀錄機制，「誰負責」這欄全是空的或全寫主管的名字。三條都要在合約簽訂前就規劃清楚。
AUTHOR
自由揚John
留言(0)
尚無留言，成為第一個留言的人吧！