[[394894]]

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

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

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

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

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

本文轉載自微信公眾號「楊建榮的學習筆記」，可以通過以下二維碼關注。轉載本文請聯系楊建榮的學習筆記公眾號。