人內心的默契就是這樣，今天要寫的標題和幾年前一模一樣，乾脆在原來的基礎上做一些補充。

今晚是一個維護之夜，出於蓄勢待發狀態，對於我來說，每到這個時候就會想起自己這些年熬的那些夜，還是蠻難忘的。

舉幾個自己印象深刻的維護之夜吧。

1）

印象最深刻，壓力最大

的維護是多套Oracle資料庫從10g升級到11g，在前期做了多輪測試，在實際操作還是碰到了不少ORA-00600的錯誤，不過前期的問題都成功化解，而在最後啟動服務的關頭，服務丟擲了一個奇怪的錯誤，記得當時情況已經很緊急了，如果修復不了，所有的服務都要回退，當時是滿世界的打電話求救，喚醒了全球的多個技術專家，有的定位是bug，然後在建議之下打了補丁，但是還是沒有效果，還找了國內的一個前輩幫忙分析問題，最後戲劇性的是，修復的操作竟然是重新清空一下回收站，具體細節忘記了，但是這個神一樣的操作讓我們和原廠都感嘆不已，因為在當時原廠已經緊急開了case。 接下來的第二波壓力是關於業務異常，有些業務存在連線異常，導致資料庫開啟了5000連線依然連線池溢位，在這種情況下發揮了我的開發技能，快速寫了釋放連線的指令碼，同時開始了程式碼分析，因為我有開發的程式碼許可權，所以我從程式碼層面去做一些分析，沒想到竟然很快找到了導致連線異常的程式碼片段，當發給泰國的開發團隊時，他們還是很吃驚的。

2）有一次大型維護的時候，登入了一套準生產測試環境，做了下業務變更升級，沒想到線上和測試環境的模板配置不一樣，結果就想當然在線上環境點選了YES開始自動升級，沒想到整個線上環境開始了一系列的不可控操作，於是乎整個業務系統全服回退，這個事情對我們造成了

很深刻的教訓

，而我內心也是很煎熬的，在幾個月的時間裡都心神不寧。

3）在國內的一次大型維護，想想都是滿滿的使命感，差不多有13套環境是在1個多小時內完成，有切換的資料庫，有做資料庫升級的資料庫，有做跨平臺遷移的資料庫，沒想到預估的3個半小時結果在1個小時以內就全部完成了。但是

戲劇性的一幕

發生了，開服的時候，發現使用者充值失敗，結果留給我們的時間就很短了。當時記得氣氛很緊張，領導拍板，如果10分鐘內解決不了，就全服回退。當時看著同事在那裡手工敲一些系統命令，帶著壓力還多次敲錯，我趕緊在另一半開始拿出自己準備的指令碼開始快速排查，所幸的是在最後的關頭，定位到了問題，是一個db link的問題，本質上還是多套環境的關聯變更導致，修復之後大家長舒了一口氣。

4）

最無聊的一次維護

，就是在某國內客戶現場值班，被抓壯丁安排去值班，主要就是過去充人數，記得自己在椅子上擺了各種姿勢睡都不舒服，看著旁邊的外國小哥估計還沒有倒過來時差，他們在那裡看《阿凡達》，後來才知道他們是特派過來的DBA，系統遷移之後，他們負責清理資料。

5）

最帶感的一次維護

，是在一次大型遷移中，出現了效能瓶頸，導致服務回退，後來大家壓力都很大，因為是一套全新的技術方案，也是在原來方案無法滿足要求的前提下的改進，當然也受到了很多原廠的質疑，在壓力中我們開始了地毯式排除測試，記得連續幾天都是測試到後半夜，而在最後定位到問題之後，自己心裡的疙瘩算是解除了，而在第二次升級的時候，記得客戶的大boss也過來了，走進作戰室看到一切都很順暢，在第二天還發了表揚信。

6）這一次可能是

很有特點的維護

，如何擺脫常規的資料庫維護影響，比如資料庫需要重啟，可能重啟的操作需要15秒~1分鐘，如何讓業務的影響降低到2秒內即可恢復。看起來很普通的需求如何和業務密切配合來改進，對於運維同學來說，這種維護的意義是很特別的。

7）2年前的那次維護算是在公司內的一次練兵，算是MySQL方向的一次核心系統的切換，後端的運維操作是因為資料庫bug需要重啟例項，在方案設計上實現了整個叢集的切換控制在5秒之內，過程都是有條不紊，可以用完滿來解讀。

除此之外，維護時間網路故障，DDL（rename操作）無法變更，業務指令碼執行失敗，服務啟動失敗，連線池異常等問題，數不勝數，這些都是平靜表象下的風波。

當然在這之外也有幾點老司機的告誡和建議：

1）維護時開啟儘可能少的工作視窗，越是關鍵的操作，開啟的視窗數量越要謹慎，這麼考慮的一些因素主要還是跳轉到錯誤的視窗，我一般建議是開啟4個以內的視窗，而且最好是對稱的模式，方便標記和辨別。

2）做好配置檔案的備份，備份的工作在這裡是重中之重，之前還碰到過一次服務異常導致中介軟體檔案被刷的情況，所以有了備份才是救命稻草，另外有些備份需要注意不能太過於頻繁，儘量不要提前很多，最好是備份操作和後續的流程都是一個人能夠銜接起來，要不檔案命名和備份細節會存在差異，這種差異很要命。

3）保持體力，在維護前的夜晚是很平靜的，最好提前做好休息和能量補充，這個時候以能夠休息保持體力為前提，儘量不要乾坐在座位等到凌晨。

4）儘可能做到雙人檢查，凌晨的操作，如果很多同學實踐過，會發現腦子不夠使，有時候看到自己列的計劃都感覺有些懵，所以計劃內容要細，要明確，有些描述資訊的描述就要增加的清晰準確，比如中介軟體的負載均衡，有一個操作步驟是把proxy3的服務做下變更，在這裡最好把相應的服務IP埠之類的都給清晰，到了凌晨的時候再去找，去確認是很危險的，當然最怕的還是自己感覺，憑猜千萬不可取。兩個人能夠做下檢查，至少在關鍵操作的時候有個照應。

5） 對於不確定的操作，不要直接按回車，如果命令列視窗卡住或者是不確定的時候，不要先按回車，因為你不知道上一個命令是不是具有破壞力，或者是螢幕處於鎖屏狀態，良好的職業習慣應該是先按空格而不是回車。

6）通常維護操作是比較平穩的，但是一旦發生問題，那就是緊急且重要的，這種情況下一定要沉住氣，同時也要做好最壞的打算和預案。

7）大維護變更前不接受額外的變更需求，這個舉一個例子，在一次大維護前2小時，開發團隊提交了一個緊急修復，當時沒有在生產完整的測試就匆匆列入了維護清單，結果整個維護中最讓人頭痛的就是那個新增變更，新增的儲存過程執行了2個小時，而在這2個小時內我們想了無數的補救方案，而事後的分析和最佳化方案可以把這個邏輯最佳化到1分鐘以內。所以按照維護流程，我們有足夠多的理由可以拒絕這種加塞需求。

8）儀式感是我認為自己在大維護中最最重要的一個環節了，有多重要呢，我覺得準備工作做到萬事俱備只欠東風的狀態，那麼剩下的只能靠運氣了。而這個運氣就需要自己的一種儀式感或者預設的習慣規則。我在大維護的時候會去買一瓶飲料，哪怕不喝也會備著，這是在早些年維護中自己的一點潛意識暗示或者說是必備的一種儀式。

當然大多數的維護都是默默無聞的，一切正常就是最好的回答。我喜歡平靜夜晚後的清晨，陽光照進來，感覺一切都敞亮了。