antony@notes:~/kubernetes$ cat "Introduction-to-Backstage-Developer-Portals-Made-Easy-LFS142.md"

Introduction to Backstage: Developer Portals Made Easy (LFS142)

2025-09-01· kubernetes

Introduction to Backstage (LFS142)

1. 認識 Developer Portals

1.1. 開發者自主權：一把雙面刃

雲原生組織不僅受益於其服務的擴展性與彈性，也得益於敏捷的團隊動態。由於服務是獨立部署的，團隊可以全權負責他們所開發的軟體元件。這是一大優勢，因為十多年來的研究已指出，能夠選擇工具並享受其工作環境的開發者，通常表現更佳。然而，開發者自主權可能導致組織碎片化，從而造成重複性工作、孤兒專案與資訊不透明等問題。

開發者自主權之所以至關重要，有兩個原因：更快的交付速度和人才留存。正如 Google 的 DORA DevOps 報告所強調：「沒有人比第一線的實踐者更清楚他們需要什麼才能有效工作。」這份業界報告觀察到，被賦予選擇自由及執行決策能力的團隊，其產出高於其他團隊。

此外，Microsoft 的開發者生產力 SPACE 框架指出，除了為任務選擇合適的工具，軟體所有權還包含心理層面的因素。當開發者能掌控自己的工作時，他們會感到被賦予權力。團隊也需要對其服務的品質、成本和其他面向負責，並會努力進行優化。

然而，自主不代表無政府狀態。組織必須提供一個有用的基準，讓開發者能在此之上建構解決方案。在限制與自由之間找到平衡點需要下功夫。透過結合政策、自助式基礎設施，以及能引導工程師走向最佳路徑的管線 (pipelines)，可以打造出保障自主權的更佳開發體驗 (Development Experience)。

但即使有良好的實踐方法，碎片化在雲原生組織中仍是一個常見問題。組織規模越大，其需要管理的複雜性就越高。隨著每個團隊交付自己的服務——而這些服務往往相互關聯且依賴第三方雲端服務——要得知有哪些服務可用以及如何使用它們，會變得很困難。

碎片化對一般貢獻者、新進人員和領導者都構成了挑戰。一般貢獻者在各自的孤島中工作，必須盲目地四處摸索才能存取組織資源。新進人員被拋入一個充滿不確定性且資訊不透明的環境，使得他們的到職流程 (onboarding) 更加困難與漫長。領導者則無法掌握其團隊正在開發的軟體，也無從得知它是否符合成熟度和安全標準。

1.2. 可發現性 (Discoverability)：唯有自動化才有效

「可發現性」取決於您能多快找到關於服務、函式庫、工具、團隊或儲存庫 (repository) 的資訊。在現今環境下，數十甚至數百個開發團隊為多個程式碼庫 (codebase) 貢獻、使用數十種開發工具並每日交付服務，因此一開始幾乎不可能知道要尋找什麼。由於雲原生團隊需處理不同的技術堆疊 (stack) 和情境，他們必須設計出一種溝通方式，讓他人了解他們的工作內容與方法，並藉此向其他團隊學習。通常，這意味著由某人手動將各種資源彙整在一份文件中。問題不在於撰寫文件，而在於如何保持其內容更新，並讓每個人都知道它的存在。

根據我在大型組織進行開發體驗 (DevExp) 研究的經驗，我發現人們會採用幾種策略來探索其內部生態系。出乎意料的是，最有效的方法似乎是「口耳相傳」：你在一個 Slack 頻道提問，他們會指引你到另一個頻道，在那裡你又會被轉介給幾個可能幫得上忙的人。接著你得想辦法和他們談談——如果他們的團隊在另一個大洲，那就祝你好運了。

但為什麼這種臨時性的策略最有效？儘管這個過程可能耗時數天或數週，但考量到其他現有文件的局限性，開發者往往視其為唯一的選擇。另一個選項是去尋找某人去年在 Atlassian、Google Docs 或 Notion 上寫的文件。但不僅跨平台搜尋不易，裡面的手繪架構圖、API 參考資料和其他資訊，在被找到時很可能也早已過時。

此外，假設你為你的服務 API 及相關函式庫寫了一份終極指南，並承諾定期維護。但你要如何告訴一位你根本不認識的同事，你可能已經建立好一個他正好能用的測試框架 (test harness)？你辦不到，因為你不知道他們需要，而他們此刻也正在從零開始打造自己的。除非有一個統一且可靠的方式來探索組織內的可用資源，否則「可發現性」很難實現。

大規模、統一且可靠的資訊，唯有透過自動化才可能實現。不少公司已為不同需求建立了資訊聚合器，這卻導致人們需要同時使用多個聚合器來搜尋資訊。對於那些投資發展內部開源 (Inner Source) 文化的組織而言，提供自動化的「可發現性」已成為改善協作的一大關鍵推手。

1.3. 什麼是開發者入口網站 (Developer Portal)？

開發者入口網站 (Developer Portal) 是開發者需要了解並貢獻於其內部生態系時的首選平台。Developer Portal 的存在是為了在「開發者自主權 (Developer Autonomy)」與「可發現性 (Discoverability)」之間取得平衡：它允許團隊獨立工作、選擇偏好的工具並進行每日部署，同時也將其工作成果展示出來，讓所有人都能探索並受益於他們的微服務、API、函式庫、網站、管線 (pipeline) 和演算法。Developer Portal 有三大主要目的：

協助開發者探索其內部生態系。
透過自助式服務賦予工程師能力。
為領導者和團隊提供關於技術健康度與成熟度的洞見。

Developer Portal 中的「可發現性」是自動化的，並集中呈現在一個軟體目錄 (software catalog) 中。Developer Portal 可透過多種方式收集組織內服務與其他軟體元件的資訊。它會聚合每個元件的相關資訊，包括負責團隊、文件、可用性、部署情況、Snyk 問題、PagerDuty 事件，以及任何其他可能對團隊有用的資訊。

確實，Developer Portal 一個廣受歡迎的功能，就是能夠追蹤服務之間的「所有權」與「相互依賴性」。每個軟體元件都有所屬的負責團隊或個人貢獻者。此外，軟體目錄會將元件之間的依賴關係圖形化。

此外，Developer Portal 還能為您的系統建立模型，將所有軟體元件依據有意義的分類法 (taxonomy) 進行整理。如此一來，開發者便能透過功能類別來探索生態系，更輕易地找到有用資訊。

另一方面，Developer Portal 不一定是唯讀的。DevOps 團隊可以提供樣板 (template)，讓開發者在 Portal 中一鍵完成新服務的基礎設施配置 (provision)，而無須再開立工單 (ticket) 請求支援。這樣做有雙重好處：開發者因近乎即時的可用性而更具生產力；DevOps 團隊則能在不強迫的情況下，引導開發者走上「黃金路徑」(golden path)。

最後，由於 Developer Portal 聚合了來自不同來源、關於組織大部分技術資產的資訊，因此有大量機會從中萃取洞見。技術洞見對領導層有益，因為他們可以全面審視技術成熟度與遷移計畫，並找出需要額外支援之處。團隊和開發者同樣能從這些洞見與透明度中受益，因為他們可以依據標準進行優化，並為自身的進步感到自豪。

1.4. 開發者入口網站 (Developer Portal) 與開發平台 (Development Platform) 有何關聯？

根據雲原生生態系中最全面的調查《DORA’s State of DevOps 2024》，約有 89% 的組織正在使用開發平台 (Development Platform)。但什麼是「平台 (Platform)」？

CNCF 平台工作小組 (CNCF Platforms Working Group) 將「平台」定義為：

一系列能力、文件和工具的集合，用以支援產品和服務交付過程中的開發、部署、營運和／或管理。一個平台可能包含 Web 入口網站、API、CLI、協定定義、文件、標準和／或黃金路徑樣板 (golden path templates)。若建置得當，平台能讓組織更快、更可靠地交付其應用程式和服務。

如您所見，這個定義為詮釋留下了空間。這是因為不同組織的平台樣貌大相逕庭。平台的設計與建置，必須與組織的目標、基礎設施和團隊相契合。

為了讓定義更清晰，CNCF 平台工作小組提供了一張圖表，說明平台能力的樣貌：

請看圖中的「平台介面 (Platform Interfaces)」部分。這裡列出的功能——文件、透過 Web 入口網站提供的 GUI，以及專案樣板——正好對應到 Developer Portal 的功能。

因此，Developer Portal 是「平台介面 (Platform Interfaces)」的一種。然而，平台也可以有不同類型的介面，例如基於 API 或 CLI 的介面。

1.5. 知識確認

Which of the following are the benefits of Developer Autonomy? Select all answers that apply.
A. Developers feel more motivated when empowered with ownership B. The organization promotes creativity by having several ways to solve a problem C. Developers are more productive when they can choose their tools D. Easier onboarding for new hires
:::spoiler 解答
正確答案：A、C
A. 當被賦予所有權時，開發者會感到更有動力
- ✔️ 正確
  - 原因： 賦予所有權能提升開發者的責任感與工作投入度。當團隊能完全掌控自己的工作成果時，會更有動力去追求卓越的品質與效能。
B. 組織透過擁有多種解決問題的方法來促進創造力
- ❌ 錯誤
  - 原因： 雖然表面上聽起來像是促進創意，但在文章的脈絡中，這種情況更多被描述為一個負面的副作用。自主權導致的「多種解決方案」往往等同於「重複性工作 (redundant work)」和「組織碎片化 (organizational fragmentation)」。
  - 當不同團隊在資訊不互通的情況下各自為政，他們可能會花費大量時間和資源去重複打造功能相似的輪子。從組織整體效率的角度來看，這並非值得鼓勵的「創造力」，而是一種需要透過開發者平台 (Development Platform) 來管理的資源浪費。
C. 當開發者可以選擇自己的工具時，他們會更有生產力
- ✔️ 正確
  - 原因： 開發者使用自己熟悉且偏好的工具時，能大幅減少學習成本與操作摩擦，直接提升開發效率與產出。
D. 新進人員的到職流程更容易
- ❌ 錯誤
  - 原因： 這恰好是自主權的主要缺點。各團隊獨立運作會導致技術與資訊的「碎片化」，使組織環境變得複雜不透明，反而讓新進人員的到職流程 (onboarding) 變得更加困難。
:::
Why do developers often discover resources through a word-of-mouth approach? Select all answers that apply.
A. Developers don’t like reading documentation B. Developers don’t always know the name of what they’re looking for C. Developers want to break silos by talking with more teams D. Developers find it difficult to find reliable documentation
:::spoiler 解答
正確答案：B、D
A. Developers don’t like reading documentation (開發者不喜歡閱讀文件)
- ❌ 錯誤
  - 原因： 問題的核心不在於開發者「不喜歡」閱讀，而在於現存的文件常常是不可靠或過時的。如果有一份集中管理、內容準確的最新文件，開發者通常會很樂意使用它。
B. Developers don’t always know the name of what they’re looking for (開發者不一定知道他們要找的東西叫什麼名字)
- ✔️ 正確
  - 原因： 在複雜的組織中，開發者可能只知道自己要解決的「問題」（例如：我需要一個處理用戶支付的 API），但並不知道解決這個問題的內部服務或工具的「確切名稱」。既然無法用關鍵字搜尋，最直接的方式就是向人描述問題。
C. Developers want to break silos by talking with more teams (開發者想透過與更多團隊交談來打破孤島效應)
- ❌ 錯誤
  - 原因： 這種跨團隊溝通通常是為了解決問題而不得不採取的低效率手段，而非開發者主動想要社交或打破壁壘。文章將這個過程描述為耗時數天甚至數週，是「別無選擇」下的方法，而不是出於主動的社交意願。
D. Developers find it difficult to find reliable documentation (開發者覺得很難找到可靠的文件)
- ✔️ 正確
  - 原因： 這是最主要的原因。文章明確指出，文件通常散落在不同平台（Google Docs, Notion 等），導致搜尋困難；更重要的是，手動維護的文件很容易過時，資訊不可靠。因此，開發者寧願去問「人」，因為人通常能提供比過期文件更即時、更準確的資訊。
:::
How do Developer Portals help reduce software fragmentation?
A. Through a comprehensive software catalog B. By nudging developers to a golden path through self-service options C. By aggregating information from different sources for each component D. By providing insights on maturity and security
:::spoiler 解答
正確答案：B
A. 透過一個全面的軟體目錄 (Through a comprehensive software catalog)
- ❌ 錯誤
  - 原因：軟體目錄主要解決的是「可發現性 (Discoverability)」問題，它讓開發者能「看見」已經存在的碎片化情況。雖然找到並重複使用現有元件能間接減少碎片化，但這是一個被動的功能。它幫助你了解現狀，但沒有主動引導你如何標準化地「建立新東西」。
B. 透過自助式選項，引導開發者走上黃金路徑 (By nudging developers to a golden path through self-service options)
- ✔️ 正確
  - 原因：這是最直接且主動減少碎片化的方法。「黃金路徑 (golden path)」代表了組織推薦的最佳實踐與標準化建置方式。開發者入口網站透過提供「自助式」的樣板（template）或一鍵生成功能，讓「遵循標準」成為最簡單、最快速的選項。這從源頭上確保了新建立的服務或元件都具備一致性，從而有效抑制了碎片化的產生。
C. 透過為每個元件聚合來自不同來源的資訊 (By aggregating information from different sources for each component)
- ❌ 錯誤
  - 原因：這個選項描述的是如何建構軟體目錄 (選項 A)的技術細節。它解釋了入口網站如何收集資訊，但這個「資訊聚合」的動作本身並不能減少碎片化，它只是更完整地呈現了現有的軟體樣貌。
D. 透過提供關於成熟度和安全性的洞見 (By providing insights on maturity and security)
- ❌ 錯誤
  - 原因：這個功能主要是用於「衡量與監控」。它幫助領導者和團隊「發現」因碎片化而導致的問題（例如：安全標準不一、技術債過高）。這是在問題發生後進行觀察與分析，而不是像選項 B 那樣在開發初期就主動預防問題的發生。 :::
What is the relationship between a Developer Portal and a Developer Platform?
A. Developer Portal and Developer Platform are just different names for the same thing B. A Developer Portal can contain a Developer Platform as part of its features C. A Developer Portal can be an interface for a Developer Platform D. There is no relationship between a Developer Portal and a Developer Platform
:::spoiler 解答
正確答案：C
A. 開發者入口網站和開發平台只是同一樣東西的不同名稱
- ❌ 錯誤
  - 原因：這兩個是不同但相關的概念。平台是底層的、更廣泛的「能力集合」（包含工具、API、基礎設施等）；而入口網站是上層的、用來與平台互動的「介面」。
B. 開發者入口網站可以包含一個開發平台作為其功能的一部分
- ❌ 錯誤
  - 原因：這個選項將兩者的關係說反了。開發平台是更大、更基礎的實體。應該是平台「包含」了入口網站作為其介面層，而不是入口網站包含平台。
C. 開發者入口網站可以是開發平台的一個介面
- ✔️ 正確
  - 原因：Portal 可作為 Platform 的使用介面（例如服務目錄、模板、流水線啟動、文件與治理護欄）。
D. 開發者入口網站和開發平台之間沒有關係
- ❌ 錯誤
  - 原因：它們之間有非常緊密的關係。入口網站是現代開發平台策略中，面向開發者的關鍵使用者體驗層，是平台能否成功被採用的重要一環。 :::

Quick Start Istio with ambient mode Backstage Quick Start