DevOps 工程師的螢幕錄影指南：事件應變、CI/CD 流程與 Runbook

DevOps 工作步調快速、團隊分散，還經常被告警呼叫打斷。凌晨三點診斷故障的人與隔天早上檢討問題的團隊之間，往往會出現情境斷層。螢幕錄影正好能填補這個落差，將轉瞬即逝的終端機操作、儀表板調查與流程（pipeline）除錯，轉化成全團隊都能學習的紀錄——不需要任何人事後憑記憶重建當時發生的一切。

為什麼 DevOps 團隊需要影片，而不只是日誌

日誌與指標只能告訴你發生了什麼，卻很少能呈現工程師如何進行調查——他們最先查看哪個儀表板、哪個指令揭露了關鍵線索，或是為什麼排除了某個誤導性的方向。而這正是下一位值班工程師最需要的推理過程。

常見的 DevOps 應用情境：

• 事件調查：即時捕捉正在進行的除錯過程，而不是事後才重建
• CI/CD 流程演練：說明建置失敗的原因，以及修復方式為何有效
• 基礎設施即程式碼（IaC）審查：在合併前逐步說明 Terraform 或 Pulumi 的變更計畫
• 待命交接：在幾分鐘內向下一位工程師簡報未解決的問題，取代冗長的書面交接文件
• 部署示範：在將新的上線流程交接給其他團隊前先錄影記錄
• 事後檢討證據：保留事件發生當下的儀表板確切狀態，供檢討會議使用

錄製事件調查過程

錄影的最佳時機不是問題解決之後，而是仍在診斷問題的當下。即時的調查錄影會捕捉你真實的思考過程，包括走過的死路，這往往比一份精修過的摘要更具教學價值。

如何錄製事件調查：

1. 一開始調查就立即錄影，即使還不知道根本原因也一樣
2. 把你的假設大聲說出來：「延遲在 14:02 出現飆升，正在確認是否與 14:00 的部署有關」
3. 記錄你查看的每個儀表板、執行的每個日誌查詢與指令
4. 找到根本原因時，在鏡頭前清楚說明，方便日後透過時間戳記快速查找
5. 持續錄影直到完成修復與驗證

事後可以將錄影剪輯成關鍵片段用於事後檢討，但務必保留完整未剪輯的版本並歸檔——當類似事件再次發生時，這份完整紀錄往往比精華片段更有價值。

CI/CD 流程演練

故障的流程（pipeline）是 DevOps 工程師最常見的中斷來源之一，同時也是解決後最容易記錄下來的類型。

錄製流程除錯過程：

• 完整擷取失敗建置的日誌——不要裁掉看似雜訊的部分，線索往往就藏在裡面
• 顯示上一次成功建置與這次失敗建置之間的差異（diff）
• 說明是哪個階段失敗以及原因（相依套件解析、測試不穩定、逾時、權限問題）
• 示範修復方式，並在鏡頭前重新執行流程以確認結果為綠燈

將這些錄影與流程設定檔一起保存，讓下一位遇到類似問題的工程師能在幾秒內找到解決方法，而不必從頭重新除錯。

審查基礎設施即程式碼（IaC）變更

在 pull request 留言中審查 Terraform plan、Kubernetes manifest 或 CloudFormation 範本相當困難——審查者必須在腦中記住整個資源關係圖。一段簡短的影片演練能讓變更的影響範圍一目了然。

有效的 IaC 審查錄影：

1. 在開始說明前，先完整呈現 plan 或 diff 的輸出結果
2. 逐一說明每個將被建立、修改或刪除的資源
3. 指出任何會觸發資源替換（replacement）的項目（這通常是風險最高的變更類型）
4. 說明不易理解的決策背後的原因，例如為什麼某個模組版本被鎖定
5. 指出套用（apply）後需要的任何手動步驟（金鑰輪替、DNS 傳播、快取預熱）

對於涉及正式環境網路或 IAM 政策的變更而言，這種做法特別有價值，因為誤讀 diff 可能帶來超乎預期的後果。

免開會的待命交接

書面待命交接文件很快就會過時，而即時交接通話又難以因應跨時區的情況。一段 5 分鐘的錄影往往是最理想的折衷方案。

交接錄影應包含的內容：

• 尚未解決的事件及其目前狀態
• 曾經觸發但屬於誤報的告警，避免下一位工程師重複調查
• 值得持續關注的儀表板，以及「正常」狀態的樣子
• 下一班次期間已排定的部署或變更
• 已知不穩定的檢查項目或可安全忽略的雜訊告警

在班次結束時錄製這段影片，並將連結貼到團隊的交接頻道。下一位工程師只需要泡杯咖啡的時間就能看完。

清楚擷取儀表板與終端機輸出

可觀測性（observability）工具與終端機輸出在錄影中都有各自的可讀性挑戰。

• 儀表板：使用縮放效果凸顯你正在說明的特定圖表或面板，而不是讓觀眾自己在擁擠的版面中尋找
• 終端機：將字體大小提高到至少 16pt，並使用高對比主題，讓指令輸出在正常播放速度下仍清晰可讀
• 多螢幕：如果調查過程橫跨一台螢幕上的指標儀表板與另一台螢幕上的終端機，請使用視窗擷取並俐落地切換畫面，而不是擷取整個桌面
• 長時間執行的指令：在剪輯時加速或刪除等待時間（例如等待 kubectl rollout status 或漫長的 terraform apply），讓錄影內容保持聚焦

分享前遮蔽敏感資料

基礎設施相關的錄影經常包含敏感資訊。在分享給直屬團隊以外的對象前，請注意：

• 若錄影將對外分享，請模糊化或裁切內部主機名稱、IP 範圍與帳號 ID
• 絕對不要讓憑證、token 或連線字串外露——輸入機密資訊前請先暫停錄影
• 檢查儀表板錄影中是否有可能出現在日誌或追蹤（trace）中的客戶資料
• 對錄影套用組織的資料分類政策，比照書面事件報告的處理標準

建立事後檢討與 Runbook 資料庫

單一一支事件錄影只能用一次，但一個可搜尋的錄影資料庫，卻能大幅放大整個 SRE 或平台團隊的戰力。

依以下方式組織錄影：

• 服務或系統（例如 payments-api、主要資料庫、ingress controller）
• 事件嚴重程度，讓高嚴重度的調查更容易被找到
• 根本原因類別（部署相關、容量問題、相依項目故障、設定漂移）

在事後檢討文件與 runbook 索引中都附上對應錄影連結，讓調查新事件的工程師能快速確認過去是否發生過類似狀況。

結語

DevOps 知識很容易流失，重建起來卻代價高昂。螢幕錄影能在事件發生的當下，捕捉事件應變、流程修復或基礎設施變更背後的推理過程——這正是取得成本最低、對下一位需要它的人價值最高的時刻。就從下一次事件開始：在知道答案之前就按下錄影，而不是事後才錄。

祝錄影愉快！