閱讀62 返回首頁    go 微軟 go Office


優雲軟件葉帥:“互聯網+”時代的雲數據中心運維思辨(一)

2017中國開源產業峰會暨中國國際軟件博覽會分論壇,優雲軟件葉帥在開源雲計算技術創新論壇發表了《“互聯網+”時代的雲數據中心運維思辨》的主題演講,本文根據演講內容整理而成。

我為大家分享一下目前運維的一些發展態勢,剛才主持人提到在雲環境下或者是“互聯網+”的環境下如何更好地做好運維管理是整個行業裏麵每個人都在考慮的一個問題,那麼接下來我就進入分享的議題,就是“互聯網+”的時代下雲數據中心運維管理方法論和思辨。

screenshot

首先,還是要先和大家分享一下我對整個行業發展的一個理解和認知,那麼隨著德國的工業4.0理念的推廣,我們從最開始的1.0的蒸汽時代,到電子化時代,信息化時代,以及最後的這種智能化時代,這其中人類科學技術是得到了一個飛速蓬勃的發展。但是,IT參與其中是在工業3.0到工業4.0這個期間,就是整個生產經營信息化到後來的智能化這樣的時間跨度裏。那麼從IT運維的生產信息化,到數字化,以及接下來的“互聯網+”或者是移動互聯網,甚至是未來整個智能化的趨勢,我們企業麵臨的情況就是這樣的一個浪潮,適應這樣的洪流就必須要做出一些調整,那麼這種調整就會帶來一個什麼樣的問題呢?如果我們隨波逐流地選擇了一定的解決方案或者選擇一定的思路,那麼或多或少都會有這樣或那樣的不滿足,盡管如此,整個項目的運維管理還是能夠穩步的運行;但是如果選擇大破大立推翻重做這樣的一種方式,那我們不僅要付出更多的努力,還需要去承擔比較多的資本風險、人員風險、時間風險等等。
所以IT運維在這樣的一個從信息化到“互聯網+”到未來的一個智能化,我們如何能夠用更有效的時間、更有效的資源成本來去做好IT運維是現在要關注的一個事情。
那麼在講如何更好地做好IT運維之前,我們還是要為IT運維正名,在很長一段時間之內IT運維都被大家狹義的理解為就是做好對象之間的管理,對象之間的持續、可用、高效的交付就是IT運維。其實這個觀點並沒有錯,因為我們剛才提過工業技術的發展中最為關注的是工具的演進和發展,那麼IT管理之初,運維也是關注工具層麵的內容,比方說我們最開始關注的網員管理,後續再關注相關的一些應用、數據等等,這些其實都是對工具的管理。但是隨著工具的演進和完善,我們會發現工具之間的管理已經不能夠滿足我們對IT運維的一個完全覆蓋和支持,因為工具的一個最大化之後,我們勢必要考慮到兩個問題,第一個問題是如何的做好平台化,如何做好工具之間的一個互動。第二個問題就是在做好平台化之後,IT運維是有人員參與的,有人員參與如何能夠再去做好人與工具,人與人之間的互動。

screenshot

那麼到這個階段,IT運維就從最開始被認為是做好工具、對象的管理現在逐漸衍生成我們需要做好平台層麵的建設,做好整個的人員之間或者是整個IT運維生態層麵的管理,那這個就是我們要為IT運維正名的第一點,就是IT運維在當下一個數字化或者在未來智能化、“互聯網+”的這樣一個時代,不再單純的是一個工具層麵的管理,更多的是一個平台,更多的是一個整個頂層的,人員之間互動的一個管理。
那麼第二個,我們既然已經提到了IT運維不是一個工具層麵的管理,那麼IT運維更多的是一種生態,更多是一種社會形態的管理,那麼社會形態就帶來兩個問題,第一個問題是生產力,第二個問題是生產關係。那我們生產力和生產關係如何體現在我們當前的一個企業文化或者當前的企業現狀裏呢?在IT運維領域我們過去的生產力就是管理這些係統、對象以及采取何種技術和工具去管理,那麼過去采用豎井式管理來持續的管著IT資源對象。現在隨著雲化或者容器化對象的一個引入,我們更多是要在做好基礎的資源管理情況下,還要做好我們應用層麵、數據層麵的管理。那麼生產力發生了改變,它也會帶來生產關係和生產的一個最終結果的改變。

screenshot

生產關係在IT運維領域的最直接的一個投影就是我們IT運維的方法論。那麼,我們最開始如何來做好穩定架構下IT管理?用ITIL個最佳實踐去做穩定架構下的一個管理。那麼現在雲化、大數據等技術的引入,我們如何用ITIL這些概念去更好的適配、滿足瞬時產生、敏捷產生、順發資源產生的這樣的一個IT管理訴求,那這其實就是我們當下ITIL在很多運維管理的企業或者是穩態企業不能夠完全應對的一個現狀。那麼隨之而來引入DevOps這樣的一個伴隨著研發、快速交付、持續交付的方法論。
在IT運維領域裏麵是不是說純ITIL或者純DevOps就能夠完全地滿足用戶或者整個行業客戶的需要呢?其實我們參與了很多項目建設,無論是企業,還是部委、軍隊等等,我們發現大多數情況下,並不是單一的方法論就能夠滿足用戶的一個整體需求。尤其是現在既有穩態架構,也有雲化、容器化的敏態架構下,更是需要一種雙態的融合,那麼這對於傳統的穩態架構更多的是采取一種實施管控、高穩定的這種方式來做管理,那麼對於雲化、虛擬化、容器化的敏態架構下,我們更多采取的是一種持續交付、敏捷、快速等等這種方式來去幫助用戶進行更多的一個持續的產出。

screenshot

那麼如何能夠幫助用戶從傳統的穩態架構衍生到敏態架構?如何幫助用戶跨過這個鴻溝?這其實就是我們廣通軟件在做整個IT運維管理軟件的時候特別加入了一些互聯網思辨的一些內容,需要一個能夠持續演進的一個IT運維方法論,廣通軟件提出了一個新的理念,這個理念就叫做軟件定義運維。大家參加這個開源大會聽了太多的軟件定義,比方說軟件定義網絡、軟件定義存儲、軟件定義計算資源、軟件定義數據中心等等,那麼什麼又是軟件定義運維呢?類似軟件定義虛擬化一樣,軟件定義運維就是通過平台化、組件化的這種方式來重塑當前運維場景和需要,那麼行業用戶可以通過運維的這個訴求或者原始的這種需求,按序或者是按組件的方式,從運維基礎平台中拿到所需要的數據,這個就是我們從整個概念上來重新打造、重新定義當前IT運維的一個方法,軟件定義通過一個基礎的運維管理平台,按照標簽,這種標簽包括場景化、標準化、自動化、可視化以及智能化來為用戶提供他們所需要的一個內容。

screenshot

那麼用戶如何能通過軟件應用來實現雙態或者實現“互聯網+”的雲數據中心的運維管理呢?那麼我們通過這麼幾個場景來為大家介紹一下,首先第一個就是大家非常熟悉的資產管理,就是所謂的集中的資產管理,那麼在傳統的穩態架構下,資產管理更多的是側重IT資產的基礎架構,以及種集中化的這種管理,通過人工的方式來去記錄、審核每一項資產變更,為什麼會有這樣的一個情況呢?因為我們說傳統的資源管理或傳統的IT架構並不複雜,它有二三十台服務器或者有不到一百台服務器就是一個比較大的龐大係統了,那麼現在的一個“互聯網+”或者一個敏態架構下,我們發現這種資源的申請、變化都是非常頻繁,那麼我們更多的不再關注於傳統架構,更多關注容器以及數據架構下,整個的IT資源是什麼,IT架構是什麼樣的。
第二個就是通過劃組的方式,通過成立工作組來去按組分拆整個資源管理的過程。以前,資源管理的任務是一兩個人管二三十台服務器,那麼如果一個係統有一千多台服務器,可能需要50多人去維護和管理,但是數據中心的人員配置可能還隻有十個人或者還有幾個人,那麼他們就需要按照組的方式來進行一定的管理,這樣就會產生另外一個問題,就是沒有人如何能夠去做好這些事情,這就需要通過一定的自動化手段,所以說對於現在敏態架構下,資源數量跟資源發生變化這個頻度非常高,勢必要通過一定的自動化的手段來去做資源的發現,所以說當前的敏態架構是關注數據應用、資源分組來去做好整體的資源導入,不僅有配置管理員,也有庫管審計人員,最後配置管理能夠完全應用出來,它會有兩個方向,第一個方向配置管理一定要以一個資產或者一個資源分組的方式去進行一定的配置數據的輸出;第二個它的輸出形式不再是過去的一張表或者單純的一些數據數據的這種矩陣,它更多的能夠以一個平台化、數據的OpenAPI方式來為更多的業務係統持續不斷推送數據,其他的係統也到我的配置管理裏麵去讀數據,這是配置管理在雙態環境下的一個場景。

screenshot

那麼對於這個場景舉一個例子,為大家介紹一下整個配置管理從數據從無到有到最後數據消費的一個全生命周期的過程。那麼首先第一個,配置管理是由管理員去創建當前的麵向於基礎資源架構、應用容器、業務方麵的這樣一個IT資源模型,那麼創建好模型之後,就根據模型的內容盡可能通過自動發現的手段,能夠主動上報和進行全方位的一個掃描,之後就對網絡進行一定的判斷,比如說這兩千多台服務器中有一千台是windows,有一千台是Linux,那麼剩下的幾百台或者是還有幾個比較少屬於一些小眾的這個OS等等,那麼當發現這些設備之後會對這個設備進行詳細判斷,就是發現哪些設備上有Oracle或者哪些設備製作了虛擬化,就會對它進行一個標識,標識之後就構建了一個基礎的配置管理倉庫,通過一個自動化或者流程或者通過其他的任務驅動來保證整個配置管理的數據持續不斷的輸出,那麼數據消費,第一方麵是麵向於我們的一個實時監控,當產生了一個資源或者容器資源的時候,通過配置管理定位到這個資源為哪個係統提供了基礎數據服務之後,那麼對它進行一定的監控手段的配置;第二個是自動化的納管,可以判斷自動化應用以及自動化版本等等一些發布。第三是我們的一個合規性檢查,第四是集群環境一致性檢查。
那麼合規性跟集群環境一致性檢查更重要的是體現在我們接下來的一個例子,前不久發生了一個勒索病毒,在勒索病毒的這個全球性的攻擊浪潮下,很多行業都不幸的被打的滿目瘡痍。那我們一起來看一下,比如說公安或者銀行的一些移動終端,當勒索病毒產生之後,首先是要去判斷哪些windows服務器容易被勒索病毒攻陷,比方說xp、window8等等,我們就會定義這些windows服務器都用了哪些應用誰在管,接下來會進行了一個廣範圍的撒網之後收集到了寥寥數張的一個excel殘本,之後進行逐項清點,清點之後去關閉端口,然後進行程序的手動發布和整個應用的重新部署,這個是我們在公安經常麵臨的一個情況。
在勒索病毒發生的當天,公安人員成立一個專項的小組,花了三天時間抽調了20多個人,包括一些駐廠人員就把一百多台服務器進行逐項的排查,清點。那麼在一個信息化相對來說比較好電網行業,它們就不一樣了,通過整個配置管理進行全網範圍的一個掃描,掃描到哪些設備是服務器以及哪些設備是windows服務器,那麼這些windows服務器上麵運行了哪些應用?這些應用為了哪些業務服務,定位到這些windows服務器之後,通過了這個人工或者自動的手段,快速的去把整體的服務進行一定的升級,最後保證我們整個的一個版本是可控的,所以當下一次安全生產危機到來的時候,在兩個不同的部門,兩個不同組織形態的這樣的一個IT管理模式下,我們看傳統的體係還是按部就班去執行,又是幾天抽調了幾十個人去做。而在一個相對信息化程度比較不錯的企業,用幾個人去做這樣的一個快速高效的恢複,這其實是一個值得我們深思的事情,那以上主要就是麵向於資源管理的介紹。

screenshot

第二個就是非常常見的,在IT運維領域最被大家廣泛接受,其實就是監控告警。我們發現隨著雲化或者容器化對象的引入,監控告警也不簡單,監控報警也跟過去有了不同,不同點在於過去的這種傳統穩態架構下,對於整個監控報警或者整個關注對象來講,它更多地關注物理設施,網絡,基礎架構以及應用,這個應用是以進程或者日誌文件為單位的一個關注對象。采取一個分鍾級的或者小時級的方式來去對這些對象進行維護,這是我們傳統架構下比較常見的內容。比如說我們在09年做的中國聯通的一個係統,他們就是通過這樣的業務監測的方式來去模擬在線充值係統與一卡通係統,一分鍾或者五分鍾交易處理的一個情況,隨著雲環境或者容器計算資源變得更加複雜,敏態架構下關注的對象就不單單是穩態環境下的這些技術資源了。我們更關注的是雲虛擬化容器對象應用服務調用的情況,甚至是我們最終的用戶體驗,以互聯網公司業務特征為代表。
比如說我們在16年的12月,支付寶推出了一個圈子,推出以後產生了一些負麵效應,很多用戶在支付寶上進行操作或者留言的時候,支付寶就會及時發現和處理,這其實就是通過了整個用戶體驗,去進行詳細的用戶回溯,進行這種數據的一個處理和還原,這是我們整個的一個敏態環境下的一個監控管理範疇。

最後更新:2017-08-23 15:32:37

  上一篇:go  Linux服務器管理控製麵板wdcp安全設置,讓你的後台,隻有你自己能訪問!
  下一篇:go  ARMS最佳實踐- 零售業績實時數據展示