節回來梳理工作，有向好的地方，也有面臨困難的地方。好的地方，是一體化運維的建設工作己步入正軌，團隊里同學都很棒，都能以做產品的心態去拼。困難的地方，是應用一線生產保障的團隊還是面臨”被動、計劃性不夠”的現狀，尤其是看到GitLab誤刪數據，5份備份全部無效的故障事件，更有種不踏實，自己也不敢肯定團隊里的備份策略是否完整，永久備份內容是否可用，再進一步想想應用可用性的監控是否100%覆蓋，基本的應急手冊是否都完整可用、備機與災備環境是否隨時可用狀態、操作是否100%合規也都可能成為一顆定時炸彈。
為何會對這些看起來是基本共識的工作還有疑慮呢？總結起來，主要是還是因為對運維人員的工作引導不夠，主因是意識上的問題。從專業條線角度看，運維保障可以分為系統、網絡、應用運維，其中系統、網絡兩方面的運維對象往往來自大廠商、比較穩定、行業標準化程度高等特點，而應用運維的標準化則更困難，整體的工作更加被動，缺乏計劃性，所以不少一線應用運維眼中的主要工作內容可能如下：
- 故障應急——業務恢復了就算結束
- 各種業務咨詢——反饋業務了就算結束
- 各種業務工單——工單關閉了就算結束
- 監控——盡可能多配監控指標，反正就是覆蓋面越全越好
- 變更——按時把版本投上生產、技術與業務檢查通過就算結束
- ……當然，還有安全管理、配合監管、配合業務分析等工作
注：這里的一線應用運維主要指一線生產系統保障的團隊，不包括計劃性項目的團隊。
對于上面的主要工作內容與結束標志看起來也屬正常，但是進一步分析會發現這種工作導向會引發風險。比如：
- 故障應急——業務恢復了就算結束——沒有引導運維人員如何做好故障快速恢復的事前準備工作，造成被動，比如應急手冊不完善導致的延誤故障處理時間。
- 監控——盡可能多配監控指標，反正就是覆蓋面越全越好——一個應用涉及的監控面很廣，不可能把將所有點都監控上，上述對監控的認識沒有引導運維人員重點確保應用可用性監控覆蓋情況，有可能配置了上百條監控指標，但是最為關鍵的開業、服務可用性的監控遺漏帶來的重大生產問題。
那么問題來了，什么才是一線應用運維最基本的工作，或稱為一線應用運維的及格線呢？這里，不提兩地三中心、自動化、數據運營、智能運維這些思路，也不談合規操作這些基本的行為準則，只站在一線應用運維角度先歸納幾項運維最基本的運維工作，需要確保落實到位的工作職責(不同條線的運維人員會有不同的理解)：
1、備份：
“數據不丟”是運維的第一道生命線，對于數據不丟的目標，僅僅是做好架構的高可用是不夠，還要對關鍵數據進行備份。備份機制從備份對象與備份手段兩方面來看。首先是備份對象，運維人員需要確保備份策略里包括完整的應用程序、數據庫、數據庫日志、業務數據、配置數據等關鍵數據；其次才是對備份手段的保證，數據備份管理員一方面需要為備份介質、備份工具對備份策略執行的可靠性，另一方面需要牽頭核實永久備份介質的可用性。
2、主備、災備、同城環境：
負載均衡的部署架構的運行環境的正確性往往是有保證的，因為這些環境一直都在對外提供服務。但是對于備份機、災備環境、同城應急環境，可能會出現環境不一致的情況，解決這種不一致的問題，需從以下幾個維度：
– 意識：需要確保運維人員是否意識到備機是用來救命用的環境，是運維保障的底線。
– 技術：生產環境是在不斷變化的，有些變化是計劃中的，有些是非計劃或未通知的，給備份、災備系統和生產系統的一致性帶來隱患。主備環境為何會出現不一致的情況，主要原因是兩個環境之間采用人肉方式同步，這種完全靠責任心維系的方式很容易出問題，比如某一天應用運維人員實施應用變更部署到生產環境到凌晨，疲憊的他很容易忘了同步災備的環境。所以備份機、災備、同城應急環境需要采用技術方式同步，自動化實現監測，人工的同步只能作為一個臨時應急的過渡方案。
– 管控：采用自動化同步、自動化監測一致性還不夠，因為備份應急環境的啟用是流程、機制、技術等一系列組成的工作，所以，對備份環境的驗證也不是一次性的工作，需要進行實戰演練，以確保環境在需要啟用時能夠馬上就位。
3、應急手冊：
運維手冊是運維標準化最基本的工作項之一，但由于運維涉及的問題很多，運維文檔也演變成一個越來越復雜的文檔，當文檔復雜到一定程度時就會變成一個負擔，很難保文檔的及時更新。所以我讓團隊先保證應急三把斧的手冊：重啟、切換、回切涉及的應用手冊的完整(涉及的動作、協作方式等需完整)、可用(涉及的內容需保持最新)、好用(能簡則簡)，且這個應急手冊建議獨立分開。
另外，應急手冊可以通過自動化手段進行簡化，比如原來采用命令行方式進行重啟服務，在采用工具集中重啟服務后，手冊也可相應簡化。
4、監控：
很難想象，哪一天我們的監控體系(由不同層次的監控工具組成)全部停業半天，哪怕是一小時，我們的運維團隊該如何去做運維保障。監控己經深入到我們運維的方方面面，相信在過幾年監控全面實現自愈、無人值守后，監控將變為無形角色貫穿在整個一體化運維體系。
但在當前，監控主要實現“監”的背景下，則需要運維人員把握“監”的覆蓋程度。雖然我們針對生產系統的各層次都部署了監控工具，但還是有監控點不是標準化默認即插即用的指標，需要有管理員去配置�？抗芾韱T主觀能動性去讓監控實現對某個生產系統所有運行狀態進行實時監控還比較困難，所以我們需要讓運維人員明確知道監控覆蓋面的及格線，我歸納為可用性監控覆蓋面為及格線，以應用系統管理員為例，他需要保證一個對客交易應用系統的所有服務可用性、端口監聽、開業狀態可用、重要批量按時完成、應用基本交易可用、重要業務交易可用、某個服務節點整體性能大幅度下降、上下游文件傳輸成功狀態指標必須覆蓋監控(資源類、網絡等屬于默認標準的監控覆蓋)。
注：從監控平臺建設角度，監控平臺要盡可能讓需要覆蓋的監控指標從技術上落地，減少對運維人員主動性上的依靠，要快速從技術上響應新的監控指標的落地。這里最低要求是針對在面有實現完全自動化配置的情況下的要求。
5、容量：
有些人可能認為生產系統的容量問題是開發程序不夠好導致的，我的認識是突發性的變更BUG導致的性能容量問題運維人員的確很難提前發現，但是對于非突發性的性能容量問題第一負責人應該是運維人員，因運維人員手上掌握著生產系統運行的所有數據卻未發現容量不足，那是運維容量評估沒做到位。所以，我們需要讓運維人員對生產系統的主要運行指標進行數據分析，通過趨勢分析、基線比對，發現系統的健康狀況。
注：由于一線管理關注運行狀態，所以這里的容量評估不涉及資源的成本控制；
6、演練：
運維過程中，針對可能出現的問題和風險點，會制定對應的應對措施、啟用流程、操作方案，針對這些措施是否可用，需要預先進行演練。在實際的演練工作開展過程中，一是要梳理現有系統的問題、風險點；二是針對問題、風險點的應急措施；三是組織演練；四是通過演練將風險的解決方案進行沉淀與更新。演練的場景包括重啟的應急、回切的應急、重要業務運營活動前的壓測等；演練的方式包括實戰、桌面；演練的目標包括操作、流程、方案等。
7、風險跟進及架構優化：
有應急、演練、故障跟進等基本工作，就會發現運行風險(這里不提合規操作風險，合規操作風險屬基本操作準則)，運行風險則往往會有架構上的優化。我一直覺得一個好的應用運維人員至少需要是一個合格的架構師，運維人員并不要求要對每一個組件的實現方式很了解，但是需要對何時用、如何用這個技術組件要有準確的判斷。所以，應用架構的優化，什么時候優化、如何優化、如何推動也是應用運維人員的基本工作。
8、業務工單、業務咨詢：
業務工單(差錯、參數、數據提取等)、業務咨詢(服務臺、電話、微信、郵件等渠道過來的問題咨詢)屬于應用運維過程中被動的工作，這方面的工作對于一線應用管理員直接的要求是及時反饋，保證服務滿意度；深入一點要求是應用運維人員的主要負責人需要走進業務、了解業務對生產應用的具體期望，并作到反饋。
上面是針對應用一線運維人員的基本工作及格線要求的一些歸納，后續還會在實踐過程中持續的優化，調整。近期，在團隊中持續推動及格線思路的同時，對于每一項工作安排了專人橫向管理，制定方案，持續推廣落實，一方面是通過集眾人力量將工作及格線落實到位；另一方面也可以讓運維人員逐步減少重復被動的操作工作比例，做更多的事前工作。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文網址：http://www.guhuozai8.cn/html/solutions/14019320578.html
相關文章
