為雲端原生環境設計軟體

定義所需行為

雲端原生實務支持在公有、私有或混合環境中，重複執行開發與維運。CNCF 強調系統在變更時仍須可管理、可觀察且具韌性。容器與協調機制能支持這種方式，但本身無法確保所有特性。

從虛構報表服務開始。AI 工具建立端點、工作程序（worker）和容器映像檔。展示時能產生正確 PDF。進入正式環境前，團隊還必須回答另一個問題：平台若在工作進行中替換工作程序，會發生什麼？

這既是基礎架構問題，也是應用程式設計問題。重新啟動可以恢復程序，但可能遺失尚未完成的工作。

將程序與持久狀態分開

原型把排隊工作與完成報表存在容器磁碟。替換容器可能同時移除兩者。增加工作程序，也可能因接收請求的程序不同而產生不同答案。

修訂後的設計使用持久工作儲存區，以及核准的物件儲存服務。請求記錄工作識別碼。工作程序領取工作、產生結果，再記錄結果位置。使用者下載報表時，仍要執行存取檢查。

機密值放在映像檔之外，透過核准的機密值系統提供。記錄哪些設定變更需要新發布版本，或重新啟動程序。

增加工作程序前，先設計重試

假設工作程序儲存 PDF 後，在確認工作完成前停止。佇列再次交付同一工作。第二次嘗試不得再次向客戶收費，也不得送出互相矛盾的完成訊息。

適當時使用等冪操作。重複相同邏輯請求，應保留預期效果。定義穩定的請求識別碼、持久記錄結果，並檢查每個故障點會發生什麼。AWS 在安全重試指引中說明這項技術。

重試也需要限制。設定逾時、重試次數上限，以及避免同時重複請求的延遲。保留失敗工作供檢查，不要無限重試。

讓預期狀態可以接受審查

宣告式設定描述預定部署狀態，控制器則努力維持該狀態。例如，Kubernetes Deployment 管理應用程式副本與受控更新。應用程式仍須正確處理替換。

為基礎架構與應用程式設定保留版本，並透過正常交付流程審查變更。觀察實際工作完成情形、佇列等待時間、失敗和相依服務限制。程序正在執行，仍可能無法產生報表。

選擇團隊能維運的平台

雲端原生不要求每個應用程式都改成微服務。在代管執行環境上的模組化應用程式，也可能滿足要求。更多服務會帶來更多介面、部署決策和維運工作。

提供真實平台契約給開發代理程式：受支援執行環境、身分方法、資料服務、部署規則和必要證據。除了成功請求，也要測試中斷與替換行為。繼續閱讀可用性與故障邊界。