題目與範圍
為擁有許多服務、團隊和部署環境的組織設計內部開發者平台。平台要降低常見交付任務的成本，同時避免變成工單隊列，也不能強迫所有團隊使用單一架構。
把開發者當作擁有不同工作負載的客戶。Backstage 描述了追蹤服務、函式庫和領域等實體的軟體目錄；DORA 建議把交付表現與開發者體驗訊號結合，而不是用一個生產力數字判斷成效。
面試官考察什麼
面試官考察平台產品思維、使用者分層、工作流優先級、變更管理、治理和指標設計。好的回答會把平台能力連接到開發者任務和可測結果，同時為合理例外保留出口。
作答前需要確認的問題
- 第一批使用者是誰：新團隊、值班工程師、服務負責人還是安全審核者？
- 哪個重複任務成本最高：初始化、部署、尋找負責人、可觀測性還是合規證據？
- 需要支援多少語言、執行環境、雲和成熟度？
- 哪些約束強制執行，哪些允許退出？
- 目標是更快交付、更安全變更、更快入職還是降低認知負擔？
30 秒回答框架
「我會從反覆建立服務、又難以找到負責人和安全部署預設值的團隊開始。MVP 包括明確負責人的目錄、自助服務範本、一條安全部署黃金路徑和可搜尋運行手冊。團隊可以說明理由後退出。我會邀請三個代表性團隊試點，衡量首次生產變更時間、失敗部署復原、入職時間、自助完成率和開發者滿意度，再根據證據擴大範圍。」
分步深入
第一步：按開發者任務分層
分別訪談服務負責人、新人、值班工程師和平台運維。痛點不同：發現依賴、建立儲存庫、安全發布或證明控制措施。使用真實工作流和支援工單，不只收集功能請求。
第二步：繪製黃金路徑
選擇一個高頻且有風險的旅程，定義輸入、預設值、審批和輸出。黃金路徑應是最容易的安全路線，不是隱藏的強制要求。說明團隊可以在哪裡自訂或退出。
第三步：建構最小可用目錄
先提供負責人、生命週期、關鍵依賴、部署與運行手冊連結及新鮮度。Backstage 目錄使用實體和元資料；要求負責人和來源檔案，避免目錄變成無人維護的通訊錄。
第四步：增加自助動作
為下一個瓶頸提供範本：建立服務、接入標準 CI、申請環境或啟用可觀測性。每個動作說明前置條件、預計耗時、結果和自動化失敗後的復原路徑。
第五步：把治理做成護欄
自動化安全和可靠性預設值，同時把政策與實作分開。平台可以用可解釋原因阻止高風險部署並提供例外流程，不應靜默改寫團隊程式碼或隱藏負責人。
第六步：規劃採用與遷移
招募設計夥伴，端到端遷移一個真實服務，發布範例並提供答疑。記錄遷移成本並保留舊路徑文件。透過降低摩擦獲得的採用，比沒有支援的強制要求更持久。
第七步：定義平台可靠性
平台也要有 SLO：目錄新鮮度、範本成功率、部署工作流可用性和事故響應。內部平台故障會成為生產依賴，因此要提供狀態、回滾和支援負責人。
第八步：衡量結果和護欄
使用部署頻率、失敗部署復原時間等交付指標，再加建立服務、首次部署、自助完成和支援工單等任務指標。加入開發者調查，並關注變更失敗、平台事故和團隊間不均衡影響。
權衡與邊界
權衡一：標準化還是自主性
統一預設值能降低認知負擔，自主性保留團隊適配。優先標準化介面和安全控制，讓實作選擇藏在介面後面。
權衡二：自建還是整合
只自建真正差異化的工作流或政策。目錄、CI、密鑰和可觀測系統若滿足契約就優先整合；每個整合都會成為平台可靠性邊界的一部分。
權衡三：更多功能還是更高完成率
二十個半成品外掛會比少量可靠動作更增加摩擦。優先端到端任務完成，而非功能數量。
失敗演練與演進計畫
演練一：範本執行到一半失敗
告訴使用者已建立什麼、如何安全重試以及誰負責清理。盡量讓動作冪等，並在不需要管理員權限的情況下提供日誌。
演練二：團隊繞過黃金路徑
先訪談再貼「不合規」標籤。路徑可能缺少真實用例、預設值差或遷移成本隱藏。改善旅程並記錄合理退出。
演練三：平台故障阻斷發布
測試降級操作、狀態溝通和手動備選。平台應降低運維風險，不應成為不透明的單點故障。
常見錯誤與追問
錯誤一：把入口網站當首頁
只有連結不會減少工作。先識別任務，再提供自助結果。
錯誤二：衡量程式碼行或點擊數
那是活動量，不是產品結果。把交付資料與任務完成和開發者體驗訊號結合。
錯誤三：強制單一技術棧
平台契約可以支援多種執行環境。說明哪些約束出於安全，哪些只是偏好。
錯誤四：忽視元資料負責人
過時目錄會傷害事故響應。要求負責人、版本控制元資料、新鮮度檢查和升級路徑。
錯誤五：先遷移全部團隊
先與設計夥伴驗證一個可量化旅程。證據不足就大規模遷移會製造阻力並掩蓋可用性問題。
錯誤六：忘記平台本身是生產軟體
為平台設定 SLO、事故負責人、發布控制和回滾路徑。