迴歸一線應用運維的底線——先做好最基本的事

春節回來梳理工作，有向好的地方，也有面臨困難的地方。好的地方，是一體化運維的建設工作己步入正軌，團隊裡同學都很棒，都能以做產品的心態去拼。困難的地方，是應用一線生產保障的團隊還是面臨”被動、計劃性不夠”的現狀，尤其是看到GitLab誤刪資料，5份備份全部無效的故障事件，更有種不踏實，自己也不敢肯定團隊裡的備份策略是否完整，永久備份內容是否可用，再進一步想想應用可用性的監控是否100%覆蓋，基本的應急手冊是否都完整可用、備機與災備環境是否隨時可用狀態、操作是否100%合規也都可能成為一顆定時炸彈。

為何會對這些看起來是基本共識的工作還有疑慮呢？總結起來，主要是還是因為對運維人員的工作引導不夠，主因是意識上的問題。從專業條線角度看，運維保障可以分為系統、網路、應用運維，其中系統、網路兩方面的運維物件往往來自大廠商、比較穩定、行業標準化程度高等特點，而應用運維的標準化則更困難，整體的工作更加被動，缺乏計劃性，所以不少一線應用運維眼中的主要工作內容可能如下：

• 故障應急——業務恢復了就算結束
• 各種業務諮詢——反饋業務了就算結束
• 各種業務工單——工單關閉了就算結束
• 監控——儘可能多配監控指標，反正就是覆蓋面越全越好
• 變更——按時把版本投上生產、技術與業務檢查通過就算結束
• ……當然，還有安全管理、配合監管、配合業務分析等工作

注：這裡的一線應用運維主要指一線生產系統保障的團隊，不包括計劃性專案的團隊。

對於上面的主要工作內容與結束標誌看起來也屬正常，但是進一步分析會發現這種工作導向會引發風險。比如：

• 故障應急——業務恢復了就算結束——沒有引導運維人員如何做好故障快速恢復的事前準備工作，造成被動，比如應急手冊不完善導致的延誤故障處理時間。
• 監控——儘可能多配監控指標，反正就是覆蓋面越全越好——一個應用涉及的監控面很廣，不可能把將所有點都監控上，上述對監控的認識沒有引導運維人員重點確保應用可用性監控覆蓋情況，有可能配置了上百條監控指標，但是最為關鍵的開業、服務可用性的監控遺漏帶來的重大生產問題。

那麼問題來了，什麼才是一線應用運維最基本的工作，或稱為一線應用運維的及格線呢？這裡，不提兩地三中心、自動化、資料運營、智慧運維這些思路，也不談合規操作這些基本的行為準則，只站在一線應用運維角度先歸納幾項運維最基本的運維工作，需要確保落實到位的工作職責（不同條線的運維人員會有不同的理解）：

1、備份：

“資料不丟”是運維的第一道生命線，對於資料不丟的目標，僅僅是做好架構的高可用是不夠，還要對關鍵資料進行備份。備份機制從備份物件與備份手段兩方面來看。首先是備份物件，運維人員需要確保備份策略裡包括完整的應用程式、資料庫、資料庫日誌、業務資料、配置資料等關鍵資料；其次才是對備份手段的保證，資料備份管理員一方面需要為備份介質、備份工具對備份策略執行的可靠性，另一方面需要牽頭核實永久備份介質的可用性。

2、主備、災備、同城環境：

負載均衡的部署架構的執行環境的正確性往往是有保證的，因為這些環境一直都在對外提供服務。但是對於備份機、災備環境、同城應急環境，可能會出現環境不一致的情況，解決這種不一致的問題，需從以下幾個維度：

– 意識：需要確保運維人員是否意識到備機是用來救命用的環境，是運維保障的底線。

– 技術：生產環境是在不斷變化的，有些變化是計劃中的，有些是非計劃或未通知的，給備份、災備系統和生產系統的一致性帶來隱患。主備環境為何會出現不一致的情況，主要原因是兩個環境之間採用人肉方式同步，這種完全靠責任心維繫的方式很容易出問題，比如某一天應用運維人員實施應用變更部署到生產環境到凌晨，疲憊的他很容易忘了同步災備的環境。所以備份機、災備、同城應急環境需要採用技術方式同步，自動化實現監測，人工的同步只能作為一個臨時應急的過渡方案。

– 管控：採用自動化同步、自動化監測一致性還不夠，因為備份應急環境的啟用是流程、機制、技術等一系列組成的工作，所以，對備份環境的驗證也不是一次性的工作，需要進行實戰演練，以確保環境在需要啟用時能夠馬上就位。

3、應急手冊：

運維手冊是運維標準化最基本的工作項之一，但由於運維涉及的問題很多，運維文件也演變成一個越來越複雜的文件，當文件複雜到一定程度時就會變成一個負擔，很難保文件的及時更新。所以我讓團隊先保證應急三把斧的手冊：重啟、切換、回切涉及的應用手冊的完整（涉及的動作、協作方式等需完整）、可用（涉及的內容需保持最新）、好用（能簡則簡），且這個應急手冊建議獨立分開。

另外，應急手冊可以通過自動化手段進行簡化，比如原來採用命令列方式進行重啟服務，在採用工具集中重啟服務後，手冊也可相應簡化。

4、監控：

很難想象，哪一天我們的監控體系（由不同層次的監控工具組成）全部停業半天，哪怕是一小時，我們的運維團隊該如何去做運維保障。監控己經深入到我們運維的方方面面，相信在過幾年監控全面實現自愈、無人值守後，監控將變為無形角色貫穿在整個一體化運維體系。

但在當前，監控主要實現“監”的背景下，則需要運維人員把握“監”的覆蓋程度。雖然我們針對生產系統的各層次都部署了監控工具，但還是有監控點不是標準化預設即插即用的指標，需要有管理員去配置。靠管理員主觀能動性去讓監控實現對某個生產系統所有執行狀態進行實時監控還比較困難，所以我們需要讓運維人員明確知道監控覆蓋面的及格線，我歸納為可用性監控覆蓋面為及格線，以應用系統管理員為例，他需要保證一個對客交易應用系統的所有服務可用性、埠監聽、開業狀態可用、重要批量按時完成、應用基本交易可用、重要業務交易可用、某個服務節點整體效能大幅度下降、上下游檔案傳輸成功狀態指標必須覆蓋監控（資源類、網路等屬於預設標準的監控覆蓋）。

注：從監控平臺建設角度，監控平臺要儘可能讓需要覆蓋的監控指標從技術上落地，減少對運維人員主動性上的依靠，要快速從技術上響應新的監控指標的落地。這裡最低要求是針對在面有實現完全自動化配置的情況下的要求。

5、容量：

有些人可能認為生產系統的容量問題是開發程式不夠好導致的，我的認識是突發性的變更BUG導致的效能容量問題運維人員的確很難提前發現，但是對於非突發性的效能容量問題第一負責人應該是運維人員，因運維人員手上掌握著生產系統執行的所有資料卻未發現容量不足，那是運維容量評估沒做到位。所以，我們需要讓運維人員對生產系統的主要執行指標進行資料分析，通過趨勢分析、基線比對，發現系統的健康狀況。

注：由於一線管理關注執行狀態，所以這裡的容量評估不涉及資源的成本控制；

7、演練：

運維過程中，針對可能出現的問題和風險點，會制定對應的應對措施、啟用流程、操作方案，針對這些措施是否可用，需要預先進行演練。在實際的演練工作開展過程中，一是要梳理現有系統的問題、風險點；二是針對問題、風險點的應急措施；三是組織演練；四是通過演練將風險的解決方案進行沉澱與更新。演練的場景包括重啟的應急、回切的應急、重要業務運營活動前的壓測等；演練的方式包括實戰、桌面；演練的目標包括操作、流程、方案等。

8、風險跟進及架構優化：

有應急、演練、故障跟進等基本工作，就會發現執行風險（這裡不提合規操作風險，合規操作風險屬基本操作準則），執行風險則往往會有架構上的優化。我一直覺得一個好的應用運維人員至少需要是一個合格的架構師，運維人員並不要求要對每一個元件的實現方式很瞭解，但是需要對何時用、如何用這個技術元件要有準確的判斷。所以，應用架構的優化，什麼時候優化、如何優化、如何推動也是應用運維人員的基本工作。

9、業務工單、業務諮詢：

業務工單（差錯、引數、資料提取等）、業務諮詢（服務檯、電話、微信、郵件等渠道過來的問題諮詢）屬於應用運維過程中被動的工作，這方面的工作對於一線應用管理員直接的要求是及時反饋，保證服務滿意度；深入一點要求是應用運維人員的主要負責人需要走進業務、瞭解業務對生產應用的具體期望，並作到反饋。

上面是針對應用一線運維人員的基本工作及格線要求的一些歸納，後續還會在實踐過程中持續的優化，調整。近期，在團隊中持續推動及格線思路的同時，對於每一項工作安排了專人橫向管理，制定方案，持續推廣落實，一方面是通過集眾人力量將工作及格線落實到位；另一方面也可以讓運維人員逐步減少重複被動的操作工作比例，做更多的事前工作。