運維的那點事：從0到1自動化智能運維之路

在江蘇CRM 項目經(jīng)歷了傳統(tǒng)IOE封閉的商業(yè)架構(gòu)到第三代BES開放的互聯(lián)網(wǎng)架構(gòu)的演進歷程，設(shè)備數(shù)量也從幾十臺到上千臺，客戶的運維要求也越來越精細，各類指標分析逐年增加等，給系統(tǒng)運維帶來極大的挑戰(zhàn)。

挑戰(zhàn)1：設(shè)備數(shù)量激增

系統(tǒng)設(shè)備從幾十臺小機到上千臺的虛擬機,應(yīng)用部署、版本發(fā)布、主機資源負荷分析、異常分析、應(yīng)用（配置）一致性檢查、日常維護等工作量上漲20倍+。在小機時代只需要人工定期登錄到主機進行巡檢輸出報表即可完成，故障定位時可以很快的找到故障主機；CRM系統(tǒng)割接到第三代BES互聯(lián)網(wǎng)化版本后，運維人員并沒有增加的情況下，系統(tǒng)的運維幾乎處于奔潰的邊緣，系統(tǒng)故障后問題定位緩慢，客戶滿意度下降。

挑戰(zhàn)2：系統(tǒng)架構(gòu)變化

老CRM系統(tǒng)架構(gòu)是主要圍繞以IOE架構(gòu)，采用比較閉源的軟硬件產(chǎn)品，以小型機、weblogic、tuxedo等構(gòu)建的三層架構(gòu)，這種架構(gòu)體系縱向擴展能力極強，橫向擴展能力很弱，在遇到電子渠道的營銷活動時，時常出現(xiàn)性能瓶頸不能完全支持業(yè)務(wù)的要求，每月月底月初業(yè)務(wù)量高峰期時常被客戶詬病，運維人員都處于救火的狀態(tài)。但是由于架構(gòu)限制，導(dǎo)致系統(tǒng)處理能力擴容較為困難。但是傳統(tǒng)的涉及的組件比較少，三層架構(gòu)相對簡單，業(yè)務(wù)調(diào)用、數(shù)據(jù)流向非清晰，對運維人員來說運維你能相對單一壓力較小，且有第三方的專項技術(shù)支持人員進行技術(shù)支持。

第三代系統(tǒng)上線后，系統(tǒng)架構(gòu)從傳統(tǒng)的3層變成5層架構(gòu)，引入了zookeeper、MQ、緩存、VS等開源軟件，服務(wù)間調(diào)用更加復(fù)雜，故障定界更加困難，對運維人員的要求更高，需要掌握系統(tǒng)中各個組件的特性和維護的方法或工具。

挑戰(zhàn)3：系統(tǒng)監(jiān)控

系統(tǒng)監(jiān)控方面客戶還是沿用老CRM架構(gòu)的監(jiān)控方式,完全依賴傳統(tǒng)的bomc網(wǎng)管系統(tǒng)，以點監(jiān)控為主，無法做到按照集群級、全面的監(jiān)控。由于第三代系統(tǒng)上線后設(shè)備數(shù)量激增， 導(dǎo)致bomc 性能嚴重不足，告警延遲；同時在系統(tǒng)故障時bomc 告警鋪天蓋地而來，往往將有效告警淹沒掉，導(dǎo)致系統(tǒng)監(jiān)控完全失效。

挑戰(zhàn)4：指標分析

老CRM系統(tǒng)時代，由于系統(tǒng)架構(gòu)簡單、穩(wěn)定性較高，維護人員關(guān)注的指標主要是偏向主機資源、業(yè)務(wù)調(diào)用量等，更多的是偏向；新系統(tǒng)割接后，更加關(guān)注最終用戶的體驗，客戶也對系統(tǒng)的響應(yīng)時長、故障時長等指標更為關(guān)切，面對自身維護和客戶各類指標數(shù)據(jù)的分析，每天都有相當(dāng)?shù)倪\維人員在進行指標分析，同時由于運維人員經(jīng)驗和技能參差不齊，導(dǎo)致數(shù)據(jù)分析效果差強人意。缺乏統(tǒng)一的數(shù)據(jù)采集、數(shù)據(jù)分析的方法，導(dǎo)致運維效率欠佳、效果被客戶詬病。在新系統(tǒng)上線后引入了dv,采集了大量的系統(tǒng)指標數(shù)據(jù),存放在系統(tǒng)中，這類數(shù)據(jù)就像沒有工具開發(fā)的寶藏。

挑戰(zhàn)5：日志分析

系統(tǒng)日志的分析一直以來是一線運維人員的痛，只能憑借運維人員的經(jīng)驗來發(fā)現(xiàn)系統(tǒng)中的錯誤日志，在出現(xiàn)問題時由為嚴重。新系統(tǒng)上線后每天業(yè)務(wù)報錯日志有4億條，全部都采集到dv中，提供日志查詢服務(wù)，而維護人員真正使用日志服務(wù)的場景屈指可數(shù)，使用頻率并不大，沒有真正的發(fā)揮出海量日志應(yīng)有的作用。維護人員想對日志進行優(yōu)化往往也抓不住重點。

挑戰(zhàn)6：思維模式

傳統(tǒng)運維模式主要是依賴bomc的網(wǎng)管系統(tǒng)進行，以被動響應(yīng)的模式進行系統(tǒng)故障的處理與干預(yù)，運維人員每天只需要看管好自己負責(zé)模塊的運行情況即可；新系統(tǒng)上線后,x86架構(gòu)的故障率更高，老的運維方式已經(jīng)不滿足新系統(tǒng)的模式，如何實現(xiàn)自動化和高效的運維成為一線運維人員的首要任務(wù)。

同時也有來自客戶的聲音：系統(tǒng)上線后如何評價新版本對系統(tǒng)的影響；dv中大量的指標數(shù)據(jù)如何發(fā)揮其功效；日志服務(wù)器中的大量日志如何利用大數(shù)據(jù)物盡其用。同時客戶也在積極尋求運維上轉(zhuǎn)變，多次要求協(xié)調(diào)大數(shù)據(jù)、智能運維的專家到場交流。

面對上述問題，我們也在積極的轉(zhuǎn)型，逐步向自動化運維邁進，積極向智能化運維探索；我們主要從如下幾個方面提升系統(tǒng)的自動化、可視化運維，提升系統(tǒng)運維效率：

基礎(chǔ)平臺運維方面：拉通客戶推動bomc對基礎(chǔ)平臺的監(jiān)控進行改造，要求bomc 的監(jiān)控方式嚴格參照BES系統(tǒng)的集群組網(wǎng)重新構(gòu)建bomc的監(jiān)控平臺，實現(xiàn)基礎(chǔ)資源平臺和業(yè)務(wù)集群相互對應(yīng)，快速實現(xiàn)基礎(chǔ)資源性能、故障對業(yè)務(wù)集群影響的分析判斷。

應(yīng)用版本發(fā)布方面：BES主要是使用df 的版本管理和版本發(fā)布能力，在此不再進行詳訴；由于江蘇CRM應(yīng)用為全部割接到bes系統(tǒng)，還有一部分在老icrm系統(tǒng)運行，針對老icrm業(yè)務(wù)，我們也在構(gòu)建自己的自動化發(fā)布平臺，實現(xiàn)界面化操作，目前已進入測試階段。

應(yīng)用服務(wù)運維方面：我們從宏觀的集群維度進行自動化、可視化監(jiān)控；從微觀的server實例維度進行監(jiān)控：

宏觀的集群維度：

2016年引入維優(yōu)的orpt（oracle report）工具對bes系統(tǒng)的關(guān)鍵集群進行指標的可視化展示，提升了系統(tǒng)故障定位的效率。缺點是無法實時監(jiān)控系統(tǒng)各集群的運行指標，在業(yè)務(wù)人員報障后運維人員才介入處理故障。

2017年年初，維護聯(lián)合DV研發(fā)在江蘇推出監(jiān)控大盤，將bes系統(tǒng)營業(yè)廳、電渠、客服等集群的響應(yīng)時長、調(diào)用量、成功率在監(jiān)控大盤中展示，監(jiān)控性能達到分鐘級，可以快速發(fā)現(xiàn)系統(tǒng)中問題集群和問題主機，實現(xiàn)故障主機快速隔離（停止服務(wù)、服務(wù)隔離），實現(xiàn)故障集群的流量切換（集群切換）。

微觀的server實例維度：

系統(tǒng)割接初期，運維人員通過編寫腳本采用curl http://ip：port/health.jsp的方式探測生產(chǎn)環(huán)境所有節(jié)點的運行情況，發(fā)現(xiàn)異常節(jié)點后就已短信告警的方式通知維護人員對異常節(jié)點進行人工干預(yù)。在單節(jié)點故障時可以有效的發(fā)現(xiàn)故障節(jié)點，在系統(tǒng)大面積異常時會導(dǎo)致短信風(fēng)暴。

2017年推出撥測大盤后，將生產(chǎn)系統(tǒng)的所有server 節(jié)點配置到撥測平臺進行主動探測，參照生產(chǎn)集群進行分組，將所有server劃分到各自所屬的集群中。通過撥測大盤可以很清楚的知道各個集群中server的健康度（server響應(yīng)時長和server存活率）.

同時根據(jù)日常的故障處理得經(jīng)驗，將系統(tǒng)故障時的關(guān)鍵字進行腳本固化，在系統(tǒng)日志中定期進行匹配并告警，提前發(fā)現(xiàn)系統(tǒng)異常節(jié)點并提前規(guī)避。

業(yè)務(wù)維護方面：業(yè)務(wù)維護主要是從業(yè)務(wù)指標運維和業(yè)務(wù)投訴運維兩個方面。

業(yè)務(wù)指標運維主要是根據(jù)維護人員經(jīng)驗將系統(tǒng)中的核心指標進行監(jiān)控和分析，系統(tǒng)上線初期主要是將系統(tǒng)監(jiān)控的指標配置到bomc告警，由于bomc系統(tǒng)不支持可視化展示，體驗性較差。我們嘗試自己開發(fā)工具進行數(shù)據(jù)的采集和展示，當(dāng)時完成了訂單、批量、數(shù)據(jù)庫性能的采集監(jiān)控，效率較低；2018年嘗試使用DV的自定義采集功能，將生產(chǎn)250+指標數(shù)據(jù)實時采集到dv中，進行性能趨勢的展示。

業(yè)務(wù)投訴運維主要是業(yè)務(wù)運維人員接受各個渠道的業(yè)務(wù)投訴工單，不同投訴人員對相同的業(yè)務(wù)報錯采用自然語言表述各不相同，導(dǎo)致問題分析和統(tǒng)計非常耗時，運維效率低下；后面和客戶多次討論推出了“智能機器人”，業(yè)務(wù)投訴人員通過“機器人”將業(yè)務(wù)投訴錄入到系統(tǒng)中，同時“智能機器人”對自然語言進行解析并快速將問題進行聚類，極大是提升了系統(tǒng)問題的分析統(tǒng)計和收斂。

業(yè)務(wù)連續(xù)性方面：由于新系統(tǒng)上線后，運維人員對系統(tǒng)中新增軟件的特效不熟悉，在故障定位和故障處理的效率都比較低下，每次在故障恢復(fù)后，會分析該故障是否可以進行故障演練，如果滿足演練條件就會聯(lián)系客戶進行評審，每月安排一次模擬故障演練和故障快速恢復(fù)，截止目前已經(jīng)對zk、vs、nginx等組件安排了20余次故障演練，通過故障演練提升運維人員的應(yīng)急能力。同時根據(jù)江蘇bes應(yīng)用的多中心組網(wǎng)情況，構(gòu)建了多中心一鍵切換的能力，單中心故障后將流量導(dǎo)入其他中心即可，可實現(xiàn)故障快速隔離。

日常保障方面：學(xué)習(xí)SRE引入輪值on-call機制， 應(yīng)對系統(tǒng)中全天候的突發(fā)性的、臨時的事件（規(guī)范化的例行事情、告警、故障等），重大故障升級到維護組內(nèi)重點保障。釋放其他維護人員的碎片化時間，重點關(guān)注系統(tǒng)重要問題分析解決、運維自動化等效率提升性工作。

人員技能方面：我們要求運維人員熟悉shell和python腳本能力，通過自動化腳本實現(xiàn)icrm版本發(fā)布、版本檢測；服務(wù)隔離、日志系統(tǒng)自動維護、異常日志異常監(jiān)控、數(shù)據(jù)采集等工作，將日常簡單的判斷邏輯全部實現(xiàn)自動化操作，減小人工運維的成本。

在日志運維上面：對運維人員來說，系統(tǒng)中的報錯日志太多，運維人員想通過日志的聚類分析發(fā)現(xiàn)哪些日志是系統(tǒng)正常運行報錯的日志，哪些日志是系統(tǒng)故障時會出現(xiàn)的日志，各類日志出現(xiàn)的頻率是什么樣的？包括新版本上線后是否有出現(xiàn)新增類型的日志報錯等。這些問題在17年系統(tǒng)轉(zhuǎn)維時和dfx兄弟進行交流時表達了一線運維的述求。18年研發(fā)開發(fā)出基于機器學(xué)習(xí)的日志分析工具（SLA），在江蘇現(xiàn)場的使用效果很明顯，可以在十幾萬條日志中聚類分析出有幾條日志是異常，經(jīng)分析這幾條日志是因為表字段不一致導(dǎo)致。該工具極大的提升了現(xiàn)場維護通過日志分析輔助問題定位效率，在給客戶的演示效果后，客戶對改工具非常感興趣（客戶將所有系統(tǒng)的日志采集到了bomc系統(tǒng)中進行大數(shù)據(jù)分析，目前日志分析效果不明顯）。

在指標運維上面：我們和客戶對系統(tǒng)共同制定了各種各樣的SLI（服務(wù)質(zhì)量指標：成功率、時延等），并對各類指標制定了各自的SLO（務(wù)質(zhì)量目標: 服務(wù)的某個SLI的目標值，或者目標范圍），開發(fā)工具對系統(tǒng)的各類指標的服務(wù)質(zhì)量目標進行實時度量，每天安排專人對系統(tǒng)出現(xiàn)的故障進行分析定位，逐步提升系統(tǒng)SLA目標。

我們在分析這類指標時需要根據(jù)運維人員的經(jīng)驗為每一個指標項制定參考值，嚴重依賴運維人員的經(jīng)驗，無法根據(jù)系統(tǒng)的歷史指標數(shù)據(jù)設(shè)置動態(tài)的預(yù)值。18年引入了研發(fā)的的KPIcheck工具，對系統(tǒng)的指標智能檢測。該指標檢測工具具備學(xué)習(xí)能力，能將對應(yīng)指標項的歷史數(shù)據(jù)進行學(xué)習(xí)并提取特征數(shù)據(jù)，然后根據(jù)歷史的特征數(shù)據(jù)準實時對生產(chǎn)的指標進行異常檢測。目前江蘇主要用于業(yè)務(wù)集群的性能指標檢測，徹底擺脫了依賴運維人員設(shè)置大量的靜態(tài)規(guī)則，提高了系統(tǒng)周期性實時檢測的能力，根據(jù)工具檢測出來的結(jié)果準確率達到90%以上。

江蘇現(xiàn)場結(jié)合KPIcheck智能異常檢測的算法的和dv的故障診斷能力，進行2次開發(fā)實現(xiàn)了AI診斷的能力《江蘇BES依托AI算法構(gòu)建故障診斷能力》，在此不在詳訴。19年我們計劃將更多的系統(tǒng)和業(yè)務(wù)的指標進行量化，納入到KPICHECK工具的異常檢測范圍內(nèi)；同時也會豐富我們的日志檢測范圍，及時發(fā)現(xiàn)我們系統(tǒng)的隱患和問題。

同時為了便捷運維人員的效率，我們使用python實現(xiàn)微信聊天機器人，實現(xiàn)隨時隨地查看系統(tǒng)運行情況，極大提升客戶感知。

我們離全量自動化運維、智能運維的理想王國還有很長的路要走，我們現(xiàn)階段還處于建設(shè)階段，我們將以始為終將，不斷完善系統(tǒng)的自動化運維能力、智能運維能力、可視化運維能力。在當(dāng)前大數(shù)據(jù)和AI大行其道的環(huán)境下，智能運維和數(shù)據(jù)挖掘是我們的工具，如何從運維到運營，通過數(shù)據(jù)挖掘成就客戶價值，也是我們未來發(fā)展的方向。

運維 大數(shù)據(jù)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。