變更審核時我們審什麼
變更是運維工程師最經常參與的一項活動，在重要變更進行之前，我們往往需要在組織內部進行變更評審，那變更評審的作用是什麼，我們應當進行變更評審，本文與大家一起探討。
當運維的組織超過一定規模後，一定要通過變更流程來進行管理，從而實現風險的有效控制，避免出現刪庫跑路的情況。變更管理的目標是提高變更實施的計劃性，規範生產變更實施的活動，這塊如果要詳細闡述內容非常多，大家可以參考 ITIL 相關流程設計。
不管採用什麼樣的變更管理流程，變更分析評審是變更順利實施的重要保障，本文從以下幾個方面來做變更評審。
- 變更影響評估是否清晰
- 變更窗口是否合適
- 變更時長控制是否合適
- 變更操作步驟是否清晰、簡便
- 變更驗證是否完備
- 變更回退方案是否完善
變更影響
在執行一個變更之前，我們首先要非常確切的知道變更的影響，例如是否會引起聯機業務中斷，會影響哪些用戶，和批量業務的時間是否衝突，是否會影響上下游的系統。
這就要求我們運維一個系統時，不管要知道自己運維的技術組件，還要深刻理解系統之上運行的各項業務。
變更影響的分析結果，會直接影響我們的「變更窗口」和「變更時長」的選擇。如果是對一個集群模組進行維護，例如 Apache 組件，因為支援優雅重啟，我們甚至可以選擇在業務高峰時段進行變更。如果是一個需要停機的版本變更，我們則只能選擇沒有業務或者業務低峰的時候執行。
操作步驟
變更方案是指導我們具體實施變更的最後一份材料，我所在的單位會將變更方案體現為變更控制表，變更控制表的基本格式包括以下要素。
| 階段 | 操作內容/目的 | 目標主機/目標網址 | 用戶名 | 詳細操作步驟 | 開始時間 | 完成時間 | 操作人 | 驗證方法 | 複核人 |
|---|---|---|---|---|---|---|---|---|---|
| 準備階段 | 備份應用 | hostname_ap1001 | root | cp x x.bak | xx | xx | A | diff xx | B |
| 實施階段 | |||||||||
| 驗證階段 | |||||||||
| 應急回退 |
按照這個格式整理變更方案的好處是步驟和操作內容非常清晰，任何人拿到控制表都可以操作。當然，按照這個標準準備控制表會耗費時間，有些人覺得投入太不值得，很簡單的變更，可能兩個人溝通幾句話就可以說明白，要是寫出來則要很久的時間。
從運維的嚴謹性上來講，我們要保證99.99%的系統可用性，除了在技術上不斷完善提高高可用外，在操作中一定要貫徹「審慎、細緻、嚴格、踏實」的原則，唯有這樣，才能形成良好的運維習慣，確保在自己的運維工作中不犯低級錯誤，避免損失。
驗證方案
驗證方案是在變更控制表中驗證階段執行的步驟，版本投產往往是開發項目組進行功能上的驗證，這就包含很多的方法本文不再贅述。對於非版本類的變更，運維人員盡量將驗證方案規範化、細緻化，例如本次變更是對一份有問題的數據進行清理，那就需要明確本次執行的SQL會影響多少條數據，實際執行完後，檢查是否確實修改了多少條數據。
嚴絲合縫的完成整個變更過程。
回退方案
任何變更都有失敗的可能，也隨時有可能收到回退的指令。因此一個沒有考慮回退方案的變更是不完整的。
在某些極特殊的場景下，可能確實沒有辦法做到完全回退，例如我們要對用戶系統的ID生成規則做一次轉換的變更，當數據轉換完成開始接收新的業務時，就可能無法再回退了。這種情況下，我們需要設置好必要的決策點，在決策點到來後，進行必要的技術/業務驗證，來決定是繼續還是回退。
關於變更的內容，其實還有很多實用的技巧，也歡迎大家與我溝通在實際運維過程中，如何避免犯錯。
