定義原型之外所需的基礎架構

從生成的系統開始

考慮一個虛構的原型平台。它建立網頁容器、代管 PostgreSQL 資料庫和公開網址。流程使用範例紀錄時能正常執行。這是有用的成果：在投入更多資金實作之前，人們就能評估功能。

現在，公司希望儲存機密合約，並使用自己的員工身分提供者。系統要求已經改變。容器部署成功，不能證明授權、核准的資料處理、可復原性或服務責任歸屬已到位。

不同開發平台提供不同能力。檢查實際服務與設定。不要假設每種原型工具都有相同限制，也不要認為熟悉的雲端品牌就符合公司政策。

提出七個正式環境問題

答案可以利用現有企業服務，不必為每個應用程式建立新的身分系統或監控平台。連接核准能力，並記錄剩餘缺口。

AWS Well-Architected 同時考慮維運、資安、可靠性、效能、成本和永續性。這提醒我們，能正常執行的部署，只是架構評估的一部分。閱讀框架。

定義環境之間的邊界

辨識開發、測試和正式環境資源。定義哪些身分可以跨越邊界。沒有核准的處理流程時，不要為了方便，就將正式環境紀錄複製到預覽環境。

同時檢查對外連線與傳入存取。非公開資料庫仍可能透過應用程式，將資料送到公開記錄服務。程式設計代理程式的模型呼叫，則是另一條必須獨立評估的資料流。

記錄雲端帳戶、DNS、數位憑證、加密金鑰和帳務關係分別由誰掌管。專案若依賴即將離職員工的私人帳戶，即使原始碼可取得，責任歸屬仍有問題。

測試責任分工

代管資料庫提供者可能維運底層服務，而組織控制使用者、資料存取、資料結構描述變更和保留設定。確切分工取決於服務與契約，應明確詢問。

為合約應用程式執行虛構還原演練。測量實際復原時間，並找出可能的資料損失，再與業務要求比較。「已啟用備份」的勾選框，無法提供相同證據。

也要測試離職停權。從身分來源移除虛構員工，驗證存取權是否如預期改變。設計時納入有效工作階段、管理員角色和自動化身分。

將基礎架構連結到交付系統

基礎架構定義、環境設定、管線和應用程式碼，需要協調變更。代理程式應依真實目標環境規劃，否則可能生成與網路、身分或責任要求衝突的部署。

這正是平台工程與軟體工廠交會的地方。平台提供受支援能力與邊界；交付系統必須使用它們、產出證據，並保留清楚的維運交接。繼續閱讀平台工程。