任務：凌晨遠端對idc的一台伺服器進行維護。
風險點：維護過程中要遠端重啟作業系統，系統重啟時間可能會很長或系統無法啟動。
準備工作：
1.定製應急預案
2.細化操作流程
3.申請停機維護時間
4.發維護通知
5.問題分析與總結
在正常關閉應用後如果系統超過了規定的時間未完成重啟，可能需要人工關閉電源重啟。如果系統重啟失敗，短時間內無法恢復，則需要啟動應急預案。
公司到idc之間還有一定的距離，如果在重啟過程中發現有問題，在趕去idc處理問題，時間上不能接受。如果提前派一位同事在idc等候，則第二天會多乙個人休息，可能會導致第二天工作的人手不夠。一般我們都是給idc的客服打**，申請在出現問題時讓他們現場的技術人員幫我們做一些簡單的工作。
重新找同事獲取**後，很快聯絡到了idc的技術人員，答應晚上幫我們做這件事情。一會idc的技術支援打**過來，要確認機器的位置。提供技術人員需要的相關資訊後找到了那台機器，同時發現了一塊硬碟燈顯示橙色。這表示可能是硬碟出問題了。聯絡硬體廠商來解決這個問題。硬體廠商發來乙個檢測工具，檢測報告的結果表示確實是硬碟壞了。由於機器還在保修範圍內，可以給換一塊硬碟。同時還表示這個型號的機器可以對韌體進行公升級，降低硬碟出問題的概率。公升級韌體會有風險嗎？需要多長時間？如果公升級失敗怎麼辦？硬體廠商表示：公升級韌體大約需要6分鐘左右。公升級韌體大部分不會有風險，但不排除例外。如果公升級失敗可能導致硬碟的所有資料丟失。跟領導溝通後，最終我們決定只換硬碟，不公升級韌體。
這次維護在規定的時間內完成了相關的工作，硬碟更換的也比較順利，沒出什麼問題。
有個問題需要思考一下：
如果不提前跟idc的客服聯絡，會出現什麼情況。
1. 不能及時發現同事給的**號碼是錯的。
2. 不知道**號碼是錯的，就不能發現硬碟壞了。
3. 沒發現硬碟壞了，就不能及時聯絡廠商更換硬碟，就可能直接重啟系統。
4. 直接重啟系統，可能導致系統無法啟動，資料丟失。
5. 系統無法啟動，資料丟失，就會導致系統停機時間增加，就會演變為乙個生產事故......
由於提前打了乙個**，上述的假設都不存在，也避免了一次生產事故。有些時候，只需要多準備一點點。
一次生產事故的優化經歷
跟蹤web伺服器業務日誌，發現在資料庫更新層報請求不到新的資料庫連線或者資料庫連線已經用完，認為是資料庫的最大連線數太小，於是調整mysql資料庫最大連線數為以往的3倍 下次搶標的時候繼續觀察業務日誌，發現已經不報資料庫鏈結的相關錯誤了，但還是很多使用者反饋搶標時候打不開頁面。在搶標過程中繼續觀察，...
一次生產事故的優化經歷
原 一次生產事故的優化經歷 跟蹤web伺服器業務日誌，發現在資料庫更新層報請求不到新的資料庫連線或者資料庫連線已經用完，認為是資料庫的最大連線數太小，於是調整mysql資料庫最大連線數為以往的3倍 下次搶標的時候繼續觀察業務日誌，發現已經不報資料庫鏈結的相關錯誤了，但還是很多使用者反饋搶標時候打不開...
一次生產事故的優化經歷
分析過程 跟蹤web伺服器業務日誌，發現在資料庫更新層報請求不到新的資料庫連線或者資料庫連線已經用完，認為是資料庫的最大連線數太小，於是調整mysql資料庫最大連線數為以往的3倍 下次搶標的時候繼續觀察業務日誌，發現已經不報資料庫鏈結的相關錯誤了，但還是很多使用者反饋搶標時候打不開頁面。在搶標過程中...