系統維護(系統維護中by西西特)

IT 運維服務體系的建議追從“易使用、易匯總、易管理”的先后順序，由重到輕的依次解決客觀存在的問題，以便最大程度的加快 IT 運維服務體系的建設的目標。運維服務體系由運維服務制度、運維服務流程、運維服務組織、運維服務隊伍、運維技術服務平臺以及運行維護對象六部分組成，涉及制度、人、技術、對象四類因素。

運維制度是規范運維管理工作的基本保障，也是流程建立的基礎。運維服務組織中的相關人員遵照制度要求和標準化的流程，采用先進的運維管理平臺對各類運維對象進行規范化的運行管理和技術操作。

IT故障定位指診斷故障直接原因或根因，故障定位有助于故障恢復動作更加有效。故障定位通常是整個故障過程中耗時最長的環節，定位的目標圍繞在快速恢復的基礎上，而并非尋找問題根因，后者由問題管理負責。通常大部分可用性故障，要借助運維專家經驗的假設判斷或已知預案的執行得到解決，但仍有部分故障，尤其是性能、應用邏輯、數據故障需要多方協同與工具支持。

在數據中心里，很多技術運維人員往往能夠對已知的故障有敏銳的發現能力，可以根據自己遇到過的故障現象快速找到問題的根因。更為資深的專家能夠從一些普適性的故障現象中通過系統的內在原理猜測出某個現象背后可能的原因。根據故障的表象判斷可能的診斷路徑是一個運維技術專家所必須具備的能力，這些能力往往是通過大量的運維案例不斷的積累下來的。這也是專家有別于普通運維人員的地方。準確的數據采集實際上也是需要依靠運維知識的。

例如，如果我們要做故障分析，其中需要使用到CPU資源的使用情況，我們該如何采集數據呢？找某段時間里CPU的使用率的平均值還是最高閾值？如果出現CPU使用率100%就一定有問題嗎？實際上并不是這么簡單的，CPU突然出現的尖峰實際上大多數是無害的，不一定會對我們的系統產生不利的影響。只有長期CPU使用率都處于接近高位，此時CPU才有可能存在資源不足的瓶頸，影響系統的性能。

一、運維處理原則

IT系統運行過程中，難免會出現問題或故障，故障處理的原則歸結起來就是兩個：

? 所有措施或方法都是以迅速恢復業務優先

? 系統BUG或匹配需要及時升級并優化

1.1. 恢復業務優先

恢復業務優先是指，不管在任何情況下，也不管任何級別的故障，都要先做到恢復業務，這個和故障定位不同，也有很多人會產生歧義，覺得如果不找到問題的根源，如何能恢復業務，下面我舉一個例子簡單的例子：

如果應用A和 B系統聯調時，如果最終是失敗的，這時我們要如何尋找問題并解決？

（1）從A應用的服務器去ping B應用的網絡，如果端口，網絡聯通，那么直接綁定B服務器的hosts。

（2）排查問題，尋找A到B之間會經過哪些環節，找到其中的出問題的環節，包括跨服務器區、跨網段等，比如HA連接異常，進行重啟或者擴容恢復。

通常情景，第1種方法時間會短，如果A和B之間是跨機房訪問，那么方法一排查時間會更長，雖然破壞了A到B之間的架構平衡，但是能馬上見效，這就是我們所說的以恢復業務優先。

1.2. 及時升級

這個比較好理解，任何故障在發生時，對故障的影響任何人只能做一個簡單的預測，所以要及時升級到你的領導那里，讓他掌握第一手的信息，協調資源，如果有如下情況，那么必須馬上上升：

非常重要的業務的嚴重以上的告警故障，比如網銀交易系統、主機CPU超閾值等等；

2. 有明確業務影響，例如雙11或618促銷、國慶或重要節假日等業務突發指標波動；

3. 處理時效明顯超長（時效參考故障處理時效定義）；

4. 安全升級包或設備或方案廠家已經大的升級系統；

5. 系統性的問題、監控中心或者關聯系統已經關注到并受到這個故障影響。

二、運維方式

根據運維工作的需求和運維響應時間要求決定建設完整的運維計劃并確定服務的標準，以現場軟硬件巡檢為主，增強運維計劃的執行力，通常數據中心等的運維工作流程如下：

（1）建設完整的運維計劃：在整個運維過程中，計劃是整個工作流程的核心，按照計劃先行的原則，依據本年度工作計劃制定分項工作計劃和時間維度計劃，并按流程、按計劃進行實施和保障。

（2）現場巡檢的重要性：現場巡檢計劃是運維工作計劃的重點，通過現場巡檢能夠發現系統薄弱環節、關鍵業務節點、存在的隱患，尤其是對制定應急預案及備品備件計劃至關重要。

（3）執行力的重要性：運維計劃的執行是運維工作的重點，在運維計劃執行過程中，應嚴格按照流程規范開展運維，并注重控制以降低運維風險。針對運維執行情況，應定期向用戶進行反饋。

（4）運維服務標準：簽訂售后服務承諾函，與客戶約定服務級別，對于所承諾的服務級別包括提供的資源（備品和備件等）、提供的方案應嚴格按約定執行

三、運維處理方法論

IBM在云時代的新運維方法論叫做CSMO（Cloud Service Management and Operations），這個方法論有四個主要的來源：

第一，是ITIL特別是ITIL 4，ITIL4是國際IT服務標準在新時代的最新版本，也是面向敏態IT的全新版本，它在囊括了ITIL V3的特色基礎上加入了對于DevOps等的支持；

其次，是敏態IT運維方法論SRE（Site Reliability Engineering，站點可靠性工程），這是互聯網及公有云的運維服務方法論；

第三，是Infrastructure as a Code即將基礎設施自動化過程、運維以及全球最佳實踐和案例等進行整合；

第四，是加強了運維與開發的關聯，將IT服務管理的組織、文化、流程與DevOps進行結合。

運行維護服務包括，信息系統相關的網絡設備、安全設備、機房基礎設施、主機設備、操作系統、數據庫和存儲設備及其他信息系統的運行維護與安全防范服務，保證用戶現有的信息系統的正常運行，降低整體管理成本，提高網絡信息系統的整體服務水平。同時根據日常維護的數據和記錄，提供用戶信息系統的整體建設規劃和建議，更好的為用戶的信息化發展提供有力的保障。

用戶信息系統的組成主要可分為兩類：硬件設備和軟件系統。硬件設備包括網絡設備、安全設備、主機設備、存儲設備等；軟件設備可分為操作系統軟件、典型應用軟件（如：數據庫軟件、中間件軟件等）、業務應用軟件等。

故障處理一般會分為三個階段，故障前，故障中和故障后，故障前是指故障的定位分析，故障中是指故障處理過程，故障后是指故障總結，故障總結很重要。

（一）從故障服務來看運維處理故障方法

如果從故障服務來看，運維恢復業務最重要的三個方法是： 隔離 重啟 降級

（1）隔離

隔離是指對故障的對象從集群中抽離的過程，目的是讓故障對象不在提供服務，隔離的方法包括以下兩種，按照常用頻率排序：

調整上游權重為零，如果架構上有自檢測機制，那么也可以直接停止故障對象的服務，讓上游健康探測時效。

通過綁定hosts或者配置路由的方式，繞開故障對象。比如智能路由管理域關閉某一條線路。這里需要注意的是，防止雪崩效應。

（2）重啟

重啟包括服務重啟和服務器重啟（os重啟）兩種，在發生故障中，任何中涉及到的環節，都可以重啟來完成，重啟的一般順序是，故障對象>故障對象上游>故障對象下游，一般離故障對象越遠，重啟順序越靠后。

（3）降級

降級是指為了防止產生更大的故障所采取的一種預案，一般而言，降級一定不是當下生產的給用戶的最優狀態，即使沒有技術影響，也會或多或少帶來一些業務的影響，雖然用戶可以通過其他方式臨時回復一些業務，但會帶來不好的用戶體驗和一些用戶影響。

降級不僅僅是運維的事情，要聯合業務研發或者說推動業務研發一起去實施，因此做任何一個項目時，首要考慮的不是這個項目能取得多少業績，而是要考慮的是，如果出現異常怎么辦？

項目如此，核心應用和組件也要如此，作為應用負責人，必須要考慮的是，如果這個對象發生重大故障時，是否有預案可以使用，并且要把這些預案觸發條件，執行人等都要明確下來。

降級，從某種角度來說，是運維的最后保命手段，必須要注意。

上述操作方法，尤其是重啟和隔離有一個重要的前提，那就是，對象必須是無狀態的，如果需要開發重試，那么要求必須是冪等的。對象無狀態除非是非常特殊的業務，可以臨時存在外，其余是不可以的，所以生產上對象應該只有三種狀態：

無狀態，這個要占大多數臨時有狀態，需要整改有狀態，少量的

（二）從故障影響方去看運維故障處理方法

首先，故障處理過程中會遇到系統故障所涉及的各個內部或外部組織架構，故障處理一般需要有以下三類人同時進行：

? 信息傳遞者：他們的職責是對故障處理，故障定位傳遞有效信息，同時對外部傳遞故障進展信息；

? 故障定位者：他們的職責是當故障處理者方法失效或者需要查找問題根因時，解決故障；

? 故障處理者：他們的職責就是盡快恢復業務。

對于IT運維系統來說，這三類人往往不會同時出現，比如在凌晨值班時，只需要故障處理者處理即可，恢復業務后，第二天由故障定位者去找根因及優化措施。

另外，一個故障發生后，影響方會分為兩類：

（1）內部用戶

內部用戶包括內部應用自身調用問題和內部使用人員發現問題，方法類似外部用戶。

（2）外部用戶

外部用戶的處理會比較麻煩，處理的思路是，如何把外部用戶轉變成內部用戶，比如，一個供應商打不開公司的網站，這時要做的是有兩個方面：

自己在本地模擬是否可以重現，如果可以重現，那么就不是用戶到IDC之間公網問題，是內部系統問題，那么變成內部用戶處理。如果自己在本地模擬不能重現，那么多找幾個內部用戶模擬，防止自己環境問題，同時，讓用戶進行hosts綁定到其他入口，排除DNS，一些外網鏈路問題，如果這時用戶在綁定hosts后，訪問正常，那么恢復業務，同時可以確認大概率是外部問題。

如果上述兩個方面都不行，那么就比較麻煩了，這時要收集一些必要的外部用戶信息才能進行處理，比如出口IP，所用客戶端版本等等，這里建議收集信息有個模版，一次性完成，因為外部用戶處理時效往往會花在溝通成本上。

更多相關大咖視頻課程請在蘋果App Store 或各安卓市場下載“技福小咖App”學習。