講師介紹

宋輝

輕維軟體CEO

• Oracle認證大師，15年以上運維管理經驗、Oracle資料庫技術支援，支援過的資料庫超1千套
• 長期為大型企業核心業務系統資料庫提供方案設計，在效能優化、故障處理、應急容災、安裝配置等技術領域有獨到的見解和豐富的實踐經驗

大家好，我叫宋輝，目前在新炬網路旗下輕維軟體負責運維平臺的研發。從03年畢業到現在在IT行業混了有14年多了，其中有12年是在從事運維相關的工作，應該說見證了整個IT行業十多年的大發展，也經歷了許多的技術及產品的興衰起落，感觸良多。

今天主要跟大家分享一下新一代運維管理平臺的建設思路，選這個主題，一方面是因為運維在整個IT生命週期中作用越來越重要，另一方面新的技術及架構給運維帶來了新的方向與思考。如何做好運維，成為更多企業及運維人員關心的重點，在這裡結合個人在這個行業的一些經驗，跟大家做個探討。

一、運維平臺的重要性

隨著資訊化建設的不斷髮展，企業的IT已從原來的一個後臺管理職能，轉變成了生產營銷中心，IT越來越多地滲透到企業生產運營之中。同時IT技術架構也在逐步朝微服務、容器、雲化、開源等方向演進，在新的架構規劃體系下，IT系統將變得更加複雜，對於平臺的運維支撐能力、資源支撐能力等帶來更高的要求。

在當前的IT系統建設及資料中心規模擴強的速度下，沒有一套合適的運維管理平臺，運維工作將舉步維艱，因此建設一個更可靠、更智慧的運維管理平臺就顯得尤為重要。

二、運維平臺發展歷史

廣義上的運維平臺發展經歷了三個階段：

1. 第一個階段，以專業化網管工具為代表，包括網路裝置、主機、資料庫、中介軟體、儲存等進行專業監控管理的各種專業化工具。
2. 第二階段，以ITIL流程化管理為代表的綜合網管，通過事件、服務、流程等貫穿監控、變更、資產管理等一系列IT運維管理。
3. 第三階段，以敏捷、DevOps為代表的運維管理平臺，主張開發運維一體化、自動化，強調需求、資源的服務化。

目前第三階段還在迭代演進中，隨著人工智慧的新起，AIOps的概念開始盛行，因此結合敏捷及智慧，成為新一代運維管理平臺的建設的核心目標。

三、建設原則

IT運維管理是一個非常寬泛的範圍，整個IT生命週期都跟運維有著關係，運維難做，運維管理平臺更難做，這個領域缺少標準和規範，目前也就Gartner對ITOM/ITOA有一些功能範圍上的定義。

運維管理平臺包括監控、ITSM、CMDB、自動化運維操作、日誌分析、使用者體驗、APM、資料庫管理、雲平臺管理、網路管理、業務監控、撥測、運維大資料等這些類別，有些企業建設了很多專案或購買了許多工具，但仍覺得用不上、不好用、用不起來，為什麼？

個人覺得包括幾個方面原因，如管理思維的問題、技術架構的問題、組織文化的問題等。我們今天重點討論技術方面的問題，個人認為要建好一個運維管理平臺，應該遵循如下的原則：

（1）運維管理平臺包括非常多的功能和模組，不可能一步到位，建議從整體的思路構建，考慮資料上的融合和各子系統之前的協同，一個模組一個模組構建，架構清晰、穩定、方便擴充套件。模組多了就必須要考慮資料標準的問題，其實跟現在企業各系統之間的資料孤島是同樣一個問題，各平臺之間很難產生聯動的價值。這個具體的做法，會在後面講到。

（2）運維平臺的建設和落地應該由運維來驅動。運維是個非常專業的工作，雖然DevOps的理論已經非常深入人心，但真正解決和提升的更多是在持續整合和交付上的能力，對於專業的運維，滲透得並不是那麼成功，如很多網際網路公司也嘗試過由開發團隊來做運維，但也僅限在應用運維這一層，同時導致各自為政，工具建設氾濫的問題。阿里的DevOps也經歷了幾個階段，最終成型落地也是讓運維帶一群開發進行運維平臺的建設，提升運維的工具化能力。因此運維平臺還是要由運維來主導建設，雖然運維不管業務，但需要站在業務的視角來構建運維平臺。

（3）以業務為中心來進行構建，打通業務與裝置的關聯。隨著微服務及分散式架構的興起，在運維管理中，會逐步淡化系統的概念，各種微服務通過流程編排組成了各種面向使用者的業務。傳統的分層架構逐步往網狀架構轉型，對於運維平臺提出了新的能力上的要求。

（4）分階段實施，先看到成效，再進行能力擴充，不要想著一口吃個胖子，很多企業連基礎監控都還沒做好，就想著要搞人工智慧，有點不切實際。因此充分考慮未來的方向，預留髮展空間在平臺建設整體規劃時，需要充分考慮資料分析能力及運維大資料能力，AI是運維的未來。

四、建設思路：7大核心模組

新一代運維管理平臺，主要是以業務為中心，通過問題快速發現與修復、運維批量操作與自動化，保障業務系統高效穩定執行為目標，實現運維的視覺化、自動化及智慧化。IT業務系統的軟硬體裝置及之間的依賴請求關係，組成了一個巨大的多維立體網路，中間的任一個節點出現問題，都可能引發業務系統的異常。

對於運維管理平臺的目標，一方面是在系統出現問題時能找到真正根源的節點，同時也能分析出其內在的深度的原因（如除了定位到某個應用出了問題，還要能定位到是哪段程式碼或某條SQL），並進行自動有效的處理；反之要能通過所有節點蛛絲馬跡的指標變化，預測系統的執行走勢，在出現問題前能採取有效的措施進行處理。

為了達到這個目標，結合現在市面的工具，我們將其總結為7個能力的建設，包括：

1. 問題發現及自愈能力（監控告警）
2. 自動運維操作能力（自動化運維）
3. 資源配置管理能力（CMDB）
4. 使用者體驗管理能力（業務監控、使用者體驗管理）
5. 元件深度效能分析能力（如資料庫效能分析、應用效能分析等）
6. 運維大資料分析（如大資料日誌、AIOps）
7. 門戶及場景整合（資料分析、Portal，運維場景整合）。

這7模組各就其位，相互協助，構建新一代運維管理平臺的核心。

下面分別介紹每一個平臺模組的建設思路：

模組一：構建統一的監控告警平臺，實現集中採集和告警，更快速地發現和發析及處理問題。

統一監控平臺的能力要求包括：

覆蓋全面，具備統一資料採集的能力。對於監控告警平臺的建設，這個是老生常談了，為什麼還要來說？因為很多的監控平臺沒有用好或用不起來。相對於傳統的監控系統，我們更強調裝置覆蓋的完整性和指標覆蓋的完整性，強調統一集中採集平臺的能力，而不只是用來做監控和告警，更重要的是用於整個運維資料的採集中心，為後面所有運維決策、人工智慧等提供方便的資料來源。對於已經有了許多專業網管的企業，建議進行統一資料採集的融合，提升或新建一個專業網管做為一級網管，其它下沉為二級網管。

對於採集回來的指標，一般可通過閥值等配置告警，但現實系統基於閥值的方式存在一定的弊端，無法對指標的異常波動做出準確的預警，如CPU使用率從20%，突然上升到70%，雖然沒有觸發告警閥值，但實際上系統性能可能已經發生了比較嚴重的惡化，需要引起關注。我們給某些企業建設的統一監控平臺，指標量已達到200多萬，我們需要有從這200多萬的指標進行異常波動檢測及快速預警的能力。一般會利用一些大資料演算法進行智慧基線的計算及預警。

對於監控系統來說，有一個非常重要的能力，就是進行告警，但許多人都覺得告警太多，導致許多人對傳統的告警失去信心。

我們的經驗是，一方面降低對低級別的告警的關注，只對致命或嚴重級別的事件進行簡訊通知，這些告警傳送給相應專業的維護人員。另一方面，通過技術手段，建立告警依賴和告警關聯分析，只對根因告警進行通知，對被影響的告警進行遮蔽。目前基於規則的告警依賴這個實現起來複雜度非常高，而且嚴重依賴於CMDB的能力，基於演算法的告警關聯分析準確度有待考驗，我們更希望在基於演算法的方向，來解決這個問題，目前已取得初步成效，後面有機會可以跟大家做進一步的分享。

提升了問題發現的能力、預警通知的能力後，接下來就需要構建問題自愈的能力，這裡需要引用關聯我們另外一個模組的能力，就是自動化運維平臺，通過呼叫自動化運維平臺的指令碼或流程平臺，實現問題的快速自愈，即通過事件與自動化運維操作的關聯，構建IT系統的自愈能力。

這樣我們基本上就能構建起一個非常智慧和敏捷的監控系統，實現初步的機器管理機器的目標，達到自動的事件閉環管理。

模組二：建立自動化運維操作能力，以操作及流程或場景為閉環，構建集中運維操作平臺。

集中運維操作平臺的能力要求包括：

以集中操作中心為目標，覆蓋對資料庫、中介軟體、主機、網路裝置、儲存、雲平臺、硬體甚至應用程式介面的操作管理、批量排程、作業任務管理能力。當後面該平臺成為整個運維的操作排程中心，這樣做的好處就顯而易見了，打通所有系統軟硬體的操作能力後，將非常容易構建起基於任何流程的運維自動化的業務場景，通過技術手段貫打通原來的組織的壁壘。

舉個例子，按照原來的流程，如果需要新上線一個應用，需要涉及雲平臺劃分虛擬機器資源、安裝配置系統軟體、開通網路防火牆、進行應用部署、進行安全掃描及加固、部署接入監控等事項。在傳統企業當中，往往涉及多個部門或多個團隊，如基礎平臺、資料庫、中介軟體、網路、開發、安全、監控等，按照現有的基於流程的方式，需要提N個工單，花上1-2個月的時間才能搞定這個事情。但如果基於集中操作運維的平臺的能力，把應用上線做為一個業務場景，把所有步驟能編排成一個大的流程，自動去執行，中間的關鍵步驟前可加入審批的控制，這樣一個流程可能1-2天就跑完了。這就是技術的價值。

相對於業務化的場景，對於平臺的建設，我們要提供的就是構建這些場景的基礎能力。一方面是相容各種軟硬體裝置的操作能力。如能對防火牆執行一個策略下發，能對雲平臺執行一個新建虛擬機器的操作。目前有很多的開源工具，如Ansible、Saltstack等，在自動化運維領域做得很好，但這兩個工具核心的能力還是在對於主機的指令碼執行管理能力，需要通過自建或擴充對於各種軟硬體裝置的操作支援能力。

平臺的基礎能力除了相容各種裝置的操作能力，還包括檔案上傳、下發、指令碼執行、配置管理、軟體包管理、流程編排等基礎能力。前面提到的對各種軟硬體裝置的操作能力在平臺上就體現成一個個的原子操作，通過流程編排，可以快速將各種原子操作編排成一個一個的業務場景，如上線部署、安全掃描、健康巡檢、安裝部署、故障診斷、資源開通等各種能力。

在此基礎上，我們可以將自動化運維平臺上整合的各種操作、流程、場景封裝成API，對外系統提供呼叫及操作。如可以提供給監控平臺，進行故障自愈；提供給CMDB進行配置及關係自發現等。

對於自動化運維平臺，需要非常關注安全的管理，因為基於此平臺基本可以對整個IT系統環境執行任何操作，這個具有很大的安全隱患。當然有許多網際網路公司的運維管理理念是用人不疑，充分授權，這種方式對於效率是非常大的提升，但在傳統行業不一定能行得通。因此平臺需要有安全管理能力，能對原子操作的執行、執行的對像、時間進行許可權控制，另外支援對整個操作過程的審計，對於敏感操作能進行二次授權等。這樣安全和效率才能兼得。

模組三：構建統一資源管理能力，成為整個運維平臺的資源中心、配置中心。

要求具備的能力包括：

CMDB其實也是個老生常談的問題，各大企業做CMDB的專案非常多，但成功的不多，最主要的原因就是把CMDB當成了excel在管，搭個平臺、建個模型把各種配置資料統一錄入到系統裡面就結束了。這樣的CMDB當然會失敗。另外CMDB要以業務為中心，更多的關注在資源管理，能提供資源的整體檢視，很好的展現業務及應用與資源的關聯關係，除了系統檢視、邏輯檢視、物理檢視外，需要增加業務流程檢視，管理業務流程各節點與各服務之前的關係。

CMDB應該成為整個運維管理平臺的資源及配置管理中心，成為運維的第一入口。如監控、自動化運維等均涉及大量的資源管理，不允許各自建設一套各自的資源體系，監控和自動化運維操作的資源應該來源於CMDB。整個大的流程是應該在裝置上架開通後，錄入CMDB，再從CMDB接入監控或運維；裝置下線後，先從監控及自動化運維的平臺進行監控及運維操作下線，再從CMDB進行下線。在裝置沒有錄入CMDB時，不允許接入監控及自動化運維。這樣就可以避免CMDB資料更新不及時的問題，按照CMDB管理上的經驗，如果都不需要接入監控和自動化運維的裝置，肯定是屬於三不管的裝置，上面也不會有什麼重要的業務，就算CMDB裡面沒有資料，也無關緊要。當然這些管理上的要求，必須通過技術手段上的限制去落地。

通過把CMDB做為整個運維管理平臺資源的入口（其實這也是CMDB資料消費的非常大的一個場景），可以解決CMDB裝置資料不完整的問題，甚至說不費吹灰之力。CMDB的配置資料及關係資料，可以通過監控或自動化運維平臺去進行自發現，確保資料的完整性。

對於CMDB資料的完整性，需要除了管理上的要求，需要構建自發現的能力，對於配置項的屬性及關係，大部份可以通過自發現來實現。CMDB應該與監控系統及自動化運維平臺保持非常好的聯動關係，監控及自動化運維的資源資料來源於CMDB，同時監控及自動化運維作為CMDB配置項屬性及關係資料自發現的最主要的來源。這樣無須獨立為CMDB構建複雜的自發現模組。

CMDB關係資料不完整，另外有很大一個方面的原因是，裝置量太多，維護團隊很難知道哪些配置項關係有問題，無從下手。平臺應該提供業務視角的資料校驗的能力，如一個業務系統，包括應用、資料庫、中介軟體、主機、儲存、網路等很多裝置，這些裝置構成了一個拓撲關係，但如果資料不完整，這個拓撲關係就是不完整的，我們很容易看到哪裡出現了中斷，去把這個關係補上就好了。所以我們雖然很難發現一個完整的業務系統拓撲，但通過資料校驗，能發現拓撲關係的缺失，再提供快速便捷的修復能力，這樣關係就能慢慢完整了。這也符合CMDB的資料眾包修復原則。

關於CMDB的資料消費，資料越完整消費價值越大，把資源資料提供給監控、自動化運維平臺進行接入，把關係資料提供給監控平臺進行基於規則的告警關聯分析、根因分析等。與監控資料結合進行維保分析，對於低頻使用的機器，可以降低維保級別等。對於低頻使用機器，結合上線時間，進行裝置下線、退網提醒等。CMDB結合監控、自動化運維等平臺，可以不斷完善資料，也可以構建更多更有價值的消費場景。

CMDB一半是技術，一半是管理，成功的CMDB需要重視CMDB看不見的能力與價值。

CMDB資料消費場景（基於規則的告警根因分析）

模組四：關注使用者體驗，運維需要重視和關注業務及使用者。

之前很多企業的運維是不關注業務的，只是在業務反饋使用者投訴或系統出現故障時，才會響應分析系統平臺的問題。這種方式是非常不合適的，往往只能做到被動響應，無法做到主動預防。使用者體驗包括以下幾個部份的內容：

1. 瀏覽器、APP上終端使用者的真實體驗，這部份資料可以通過流覽器插碼及APP SDK收集。如現在比較流行的APM for APP及Browser模組。
2. 通過應用撥測的方式，在各IDC部署撥測終端，模擬使用者對系統平臺進行撥測，對響應時長，錯誤率、成功率等進行分析。
3. 業務系統平臺數據側的統計與分析，如基於流程資料的統計、基於應用日誌的統計，對系統業務量及響應時間等使用者體驗資料進行統計與分析。
4. 利用抓包解碼的方式，對網路流量資料進行解碼，分析與統計終端使用者的體驗資料。

實際落地時需要結合企業使用的技術架構進行選擇，也可以採用多種技術手段結合的方式進行。在這個領域網際網路公司有非常成熟的經驗值得借鑑。

模組五：新一代運維管理平臺，需要引入對使用者體驗資料的監測與分析，結合系統平臺數據，真正做到端到端的監測與分析能力。

應用元件深度分析能力，通過監控或智慧告警等一般可以定位到一個軟硬體裝置的狀態出現異常，但異常的真正原因是比較難排查的。重啟、擴容應用或許可以短期內解決問題，但真正的原因可能是程式碼的缺陷或低效的SQL語句或資料庫本身的資源爭用導致的。

目前大多數的應用還是屬於資料密集操作型的，也就是重資料庫的，對於這些應用、應用本身程式碼級的診斷和資料庫的深度診斷分析能力要求更高。應用元件深度分析能力主要體現在：

• 應用端的深度分析，利用應用探針技術或應用日誌埋點，對應用程式碼級的方法、請求進行分析，實現程式碼級的診斷，在應用請求量、成功率、響應時間等出現異常時能快速定位問題節點及程式碼。這個在當前的微服務和分散式架構下顯得尤為重要，蜘蛛網式的應用架構，在出現效能問題時，如果沒有明確的呼叫鏈路分析手段，將是非常致命的。
• 資料庫的深度分析，對於目前企業大多數應用來說，資料庫仍處於非常核心的地位，對於資料庫的維護管理顯得尤為重要，一條SQL語句搞跨一個系統的事經常出現，不管是Oracle，還是DB2、MySQL，SQL Server，這些資料庫都需要最高級別的深度監控和分析，包括資料庫低效SQL的分析、一鍵式的效能診斷、SQL語句的自動優化、SQL上線前效能稽核、SQL版本比對分析等。許多企業都有好幾種關係型資料庫，構建一個有強大SQL效能管理為核心的資料庫統一管理平臺非常關鍵。我們在為許多大型企業構建新一代運維管理平臺時，都會重點考慮構建資料庫的深度分析管理能力。

一鍵式的資料庫深度分析

模組六：大資料日誌分析及運維大資料能力

前面已經提到AI是運維的未來，任何現象都可能跟某個隱含的資料有密切的關係。因此依賴於大資料、人工智慧等新型的技術，將人對問題、故障分析的經驗移植到程式碼上，甚至在不久的將來，對於運維，機器幹得比人還要出色。當然對於真正的AIOps我們還處在很初級的階段，但必須從現在開始準備。

第一步先要把資料集中起來，建議先構建大資料日誌分析平臺，形成大資料分析能力，把裝置日誌資料、應用日誌資料集中起來，提供基本的關鍵字搜尋、統計、告警、趨勢分析等能力。這些是對於傳統監控告警一個非常重要的補充。

依據日誌資料中的標籤、埋點及關係，構建基於日誌資料的場景分析能力。應用場景包括業務指標分析、業務鏈路分析、介面效能分析、使用者體驗分析、故障隱患分析、故障根因分析等。

接下來考慮基於大資料日誌分析平臺構建運維大資料分析能力，將統一監控平臺的海量指標資料同步到日誌分析平臺，構建成運維大資料平臺，一方面，基於這些資料可以進行大量主題的分析，如容量分析、效能分析、事件分析、隱患分析等。另一方面，利用監控告警事件、CMDB資源關係、裝置及應用日誌，進行關聯分析，同時利用各種人工智慧、機器學習演算法，進行基於人工智慧的運維分析與診斷。

模組七：整合平臺構建運維場景整合能力

如前面的架構圖所示，整個平臺分為三個層次：監控及運維操作、運維大資料分析及門戶與整合平臺。整合平臺主要用於下面兩層能力的自定義構建與場景化，通過下面兩層的服務化介面，構建面向不同維護人員的運維場景，以支撐更多的個性化應用。利用各種報表工具，進行多維度的自定義資料分析與運維能力整合。通過整合平臺，構建運維一體化PaaS平臺，提供面向業務的運維監控、運維操作及決策分析平臺。

整合平臺通過呼叫平臺服務化API介面，提供自定義場景整合能力，快速構建各種應用場景。如下圖所示，通過CMDB的資料查詢介面在平臺自動構建一個系統拓撲，通過採集監控模組的API介面把系統執行指標資料、告警事件對映到拓撲圖上，通過自動化運維模組API，把常見的運維操作能力整合到拓撲圖上，這樣可以快速構建一個視覺化的智慧運維場景，這些都無須運維人員有任何開發能力，大大降低運維開發的難度。

五、小結

建設一個具有先進性、擴充套件性及未來性的新一代運維管理平臺非常重要，但同樣難度也不小，個人認為整體上的規劃至關重要，有了清晰的戰略才能有良好的落地與效果。7種能力就像7種武器，互相搭配，各舞所長，才能發揮最大作用。

今天給大家講的主要是思路，很少涉及具體的技術，裡面包括了許多的內容，每個企業的實際情況及IT發展階段、甚至管理模式都不太一樣，大家可以選擇性的參考與借鑑。運維是企業IT的基礎，未來運維的挑戰只會比現在更大，及早構建一個新一代的運維管理平臺意義非凡，我們在此方面積累了許多成功的經驗，也具有了一定的產品體系，歡迎大家與我們進行更深入的探討。

直播連結回放

https://m.qlchat.com/topic/details?topicId=2000000218877425&null