部署後，持續為服務負責

定義使用者依賴的服務

部署讓軟體可以使用。維運則在使用者、相依服務、流量和要求改變時，讓它持續有用。程式碼生成工具無法移除這項持續工作。

對虛構客戶資料匯出而言，使用者需要的不只是能連線的頁面。他們需要在可接受時間內，以必要格式取得有權存取的紀錄。服務也必須防止存取其他組織資料。

發布前指定負責人。如果非工作時間應變屬於服務承諾，就記錄由誰處理。供應商可以執行部分工作，但組織仍需要清楚的決策與溝通途徑。

選擇能支持行動的訊號

服務水準指標（SLI）衡量服務行為的特定屬性。服務水準目標（SLO）則為該指標設定明確期間內的目標。依使用者需求與維運能力選擇目標。

Google 的 SRE 指引說明這個方法，以及如何用錯誤預算支援可靠性決策。不要未確認意義，就照搬其他服務的目標。SLO 指引、錯誤預算政策範例。

為匯出定義哪些符合條件的請求算成功。區分預期拒絕與系統故障。記錄排除項目，避免只是隱藏困難請求，就讓指標看似改善。

不要為了增加可見性，就將完整匯出資料寫入記錄檔。只蒐集診斷問題所需的最少資訊，並保護存取權。

準備事件應變

決定誰協調、誰調查、誰溝通。小團隊可以由同一人兼任，但責任必須清楚。保留觀察與操作紀錄。

Google 的事件應變指引強調，技術緩解之外，還需要協調與溝通。技術上正確的修正，仍可能讓使用者毫不知情，或讓多位應變人員做出互相衝突的變更。事件應變。

代理程式可以在核准資料邊界內彙整記錄檔或比較假設，但不應因事件緊急，就取得不受限的正式環境權限。例外存取應使用明確的升級處理途徑。

演練復原，並提供維護資源

使用具代表性的虛構資料測試復原程序。指出程式碼回復無法撤銷的事項，包括已刪除紀錄或已送出訊息。記錄恢復服務所需時間與資訊。

分配持續工作：相依項目更新、存取權審查、適用時的數位憑證續期、容量調整和文件修正。沒有維護資源的服務，在上線預算結束後，仍會持續累積義務。

事件後，選擇能處理已觀察原因的改善，並連結到實作和驗證。這讓生命週期形成閉環：維運證據改變團隊下一步定義與建置的內容。