1. 程式人生 > >優雲軟體葉帥:“網際網路+”時代的雲資料中心運維思辨(上)

優雲軟體葉帥:“網際網路+”時代的雲資料中心運維思辨(上)

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


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

首先,還是要先和大家分享一下我對整個行業發展的一個理解和認知,那麼隨著德國的工業4.0理念的推廣,我們從最開始的1.0的蒸汽時代,到電子化時代,資訊化時代,以及最後的這種智慧化時代,這其中人類科學技術是得到了一個飛速蓬勃的發展。但是,IT參與其中是在工業3.0到工業4.0這個期間,就是整個生產經營資訊化到後來的智慧化這樣的時間跨度裡。那麼從IT運維的生產資訊化,到數字化,以及接下來的“網際網路+”或者是移動網際網路,甚至是未來整個智慧化的趨勢,我們企業面臨的情況就是這樣的一個浪潮,適應這樣的洪流就必須要做出一些調整,那麼這種調整就會帶來一個什麼樣的問題呢?如果我們隨波逐流地選擇了一定的解決方案或者選擇一定的思路,那麼或多或少都會有這樣或那樣的不滿足,儘管如此,整個專案的運維管理還是能夠穩步的執行;但是如果選擇大破大立推翻重做這樣的一種方式,那我們不僅要付出更多的努力,還需要去承擔比較多的資本風險、人員風險、時間風險等等。

所以IT運維在這樣的一個從資訊化到“網際網路+”到未來的一個智慧化,我們如何能夠用更有效的時間、更有效的資源成本來去做好IT運維是現在要關注的一個事情。

那麼在講如何更好地做好IT運維之前,我們還是要為IT運維正名,在很長一段時間之內IT運維都被大家狹義的理解為就是做好物件之間的管理,物件之間的持續、可用、高效的交付就是IT運維。其實這個觀點並沒有錯,因為我們剛才提過工業技術的發展中最為關注的是工具的演進和發展,那麼IT管理之初,運維也是關注工具層面的內容,比方說我們最開始關注的網員管理,後續再關注相關的一些應用、資料等等,這些其實都是對工具的管理。但是隨著工具的演進和完善,我們會發現工具之間的管理已經不能夠滿足我們對IT運維的一個完全覆蓋和支援,因為工具的一個最大化之後,我們勢必要考慮到兩個問題,第一個問題是如何的做好平臺化,如何做好工具之間的一個互動。第二個問題就是在做好平臺化之後,IT運維是有人員參與的,有人員參與如何能夠再去做好人與工具,人與人之間的互動。

那麼到這個階段,IT運維就從最開始被認為是做好工具、物件的管理現在逐漸衍生成我們需要做好平臺層面的建設,做好整個的人員之間或者是整個IT運維生態層面的管理,那這個就是我們要為IT運維正名的第一點,就是IT運維在當下一個數字化或者在未來智慧化、“網際網路+”的這樣一個時代,不再單純的是一個工具層面的管理,更多的是一個平臺,更多的是一個整個頂層的,人員之間互動的一個管理。

那麼第二個,我們既然已經提到了IT運維不是一個工具層面的管理,那麼IT運維更多的是一種生態,更多是一種社會形態的管理,那麼社會形態就帶來兩個問題,第一個問題是生產力,第二個問題是生產關係。那我們生產力和生產關係如何體現在我們當前的一個企業文化或者當前的企業現狀裡呢?在IT運維領域我們過去的生產力就是管理這些系統、物件以及採取何種技術和工具去管理,那麼過去採用豎井式管理來持續的管著IT資源物件。現在隨著雲化或者容器化物件的一個引入,我們更多是要在做好基礎的資源管理情況下,還要做好我們應用層面、資料層面的管理。那麼生產力發生了改變,它也會帶來生產關係和生產的一個最終結果的改變。

生產關係在IT運維領域的最直接的一個投影就是我們IT運維的方法論。那麼,我們最開始如何來做好穩定架構下IT管理?用ITIL個最佳實踐去做穩定架構下的一個管理。那麼現在雲化、大資料等技術的引入,我們如何用ITIL這些概念去更好的適配、滿足瞬時產生、敏捷產生、順發資源產生的這樣的一個IT管理訴求,那這其實就是我們當下ITIL在很多運維管理的企業或者是穩態企業不能夠完全應對的一個現狀。那麼隨之而來引入DevOps這樣的一個伴隨著研發、快速交付、持續交付的方法論。



在IT運維領域裡面是不是說純ITIL或者純DevOps就能夠完全地滿足使用者或者整個行業客戶的需要呢?其實我們參與了很多專案建設,無論是企業,還是部委、軍隊等等,我們發現大多數情況下,並不是單一的方法論就能夠滿足使用者的一個整體需求。尤其是現在既有穩態架構,也有云化、容器化的敏態架構下,更是需要一種雙態的融合,那麼這對於傳統的穩態架構更多的是採取一種實施管控、高穩定的這種方式來做管理,那麼對於雲化、虛擬化、容器化的敏態架構下,我們更多采取的是一種持續交付、敏捷、快速等等這種方式來去幫助使用者進行更多的一個持續的產出。

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



那麼使用者如何能通過軟體應用來實現雙態或者實現“網際網路+”的雲資料中心的運維管理呢?那麼我們通過這麼幾個場景來為大家介紹一下,首先第一個就是大家非常熟悉的資產管理,就是所謂的集中的資產管理,那麼在傳統的穩態架構下,資產管理更多的是側重IT資產的基礎架構,以及種集中化的這種管理,通過人工的方式來去記錄、稽核每一項資產變更,為什麼會有這樣的一個情況呢?因為我們說傳統的資源管理或傳統的IT架構並不複雜,它有二三十臺伺服器或者有不到一百臺伺服器就是一個比較大的龐大系統了,那麼現在的一個“網際網路+”或者一個敏態架構下,我們發現這種資源的申請、變化都是非常頻繁,那麼我們更多的不再關注於傳統架構,更多關注容器以及資料架構下,整個的IT資源是什麼,IT架構是什麼樣的。



第二個就是通過劃組的方式,通過成立工作組來去按組分拆整個資源管理的過程。以前,資源管理的任務是一兩個人管二三十臺伺服器,那麼如果一個系統有一千多臺伺服器,可能需要50多人去維護和管理,但是資料中心的人員配置可能還只有十個人或者還有幾個人,那麼他們就需要按照組的方式來進行一定的管理,這樣就會產生另外一個問題,就是沒有人如何能夠去做好這些事情,這就需要通過一定的自動化手段,所以說對於現在敏態架構下,資源數量跟資源發生變化這個頻度非常高,勢必要通過一定的自動化的手段來去做資源的發現,所以說當前的敏態架構是關注資料應用、資源分組來去做好整體的資源匯入,不僅有配置管理員,也有庫管審計人員,最後配置管理能夠完全應用出來,它會有兩個方向,第一個方向配置管理一定要以一個資產或者一個資源分組的方式去進行一定的配置資料的輸出;第二個它的輸出形式不再是過去的一張表或者單純的一些資料資料的這種矩陣,它更多的能夠以一個平臺化、資料的OpenAPI方式來為更多的業務系統持續不斷推送資料,其他的系統也到我的配置管理裡面去讀資料,這是配置管理在雙態環境下的一個場景。


那麼對於這個場景舉一個例子,為大家介紹一下整個配置管理從資料從無到有到最後資料消費的一個全生命週期的過程。那麼首先第一個,配置管理是由管理員去建立當前的面向於基礎資源架構、應用容器、業務方面的這樣一個IT資源模型,那麼建立好模型之後,就根據模型的內容儘可能通過自動發現的手段,能夠主動上報和進行全方位的一個掃描,之後就對網路進行一定的判斷,比如說這兩千多臺伺服器中有一千臺是windows,有一千臺是Linux,那麼剩下的幾百臺或者是還有幾個比較少屬於一些小眾的這個OS等等,那麼當發現這些裝置之後會對這個裝置進行詳細判斷,就是發現哪些裝置上有Oracle或者哪些裝置製作了虛擬化,就會對它進行一個標識,標識之後就構建了一個基礎的配置管理倉庫,通過一個自動化或者流程或者通過其他的任務驅動來保證整個配置管理的資料持續不斷的輸出,那麼資料消費,第一方面是面向於我們的一個實時監控,當產生了一個資源或者容器資源的時候,通過配置管理定位到這個資源為哪個系統提供了基礎資料服務之後,那麼對它進行一定的監控手段的配置;第二個是自動化的納管,可以判斷自動化應用以及自動化版本等等一些釋出。第三是我們的一個合規性檢查,第四是叢集環境一致性檢查。

那麼合規性跟叢集環境一致性檢查更重要的是體現在我們接下來的一個例子,前不久發生了一個勒索病毒,在勒索病毒的這個全球性的攻擊浪潮下,很多行業都不幸的被打的滿目瘡痍。那我們一起來看一下,比如說公安或者銀行的一些移動終端,當勒索病毒產生之後,首先是要去判斷哪些windows伺服器容易被勒索病毒攻陷,比方說xp、window8等等,我們就會定義這些windows伺服器都用了哪些應用誰在管,接下來會進行了一個廣範圍的撒網之後收集到了寥寥數張的一個excel殘本,之後進行逐項清點,清點之後去關閉埠,然後進行程式的手動釋出和整個應用的重新部署,這個是我們在公安經常面臨的一個情況。

在勒索病毒發生的當天,公安人員成立一個專項的小組,花了三天時間抽調了20多個人,包括一些駐廠人員就把一百多臺伺服器進行逐項的排查,清點。那麼在一個資訊化相對來說比較好電網行業,它們就不一樣了,通過整個配置管理進行全網範圍的一個掃描,掃描到哪些裝置是伺服器以及哪些裝置是windows伺服器,那麼這些windows伺服器上面運行了哪些應用?這些應用為了哪些業務服務,定位到這些windows伺服器之後,通過了這個人工或者自動的手段,快速的去把整體的服務進行一定的升級,最後保證我們整個的一個版本是可控的,所以當下一次安全生產危機到來的時候,在兩個不同的部門,兩個不同組織形態的這樣的一個IT管理模式下,我們看傳統的體系還是按部就班去執行,又是幾天抽調了幾十個人去做。而在一個相對資訊化程度比較不錯的企業,用幾個人去做這樣的一個快速高效的恢復,這其實是一個值得我們深思的事情,那以上主要就是面向於資源管理的介紹。



第二個就是非常常見的,在IT運維領域最被大家廣泛接受,其實就是監控告警。我們發現隨著雲化或者容器化物件的引入,監控告警也不簡單,監控報警也跟過去有了不同,不同點在於過去的這種傳統穩態架構下,對於整個監控報警或者整個關注物件來講,它更多地關注物理設施,網路,基礎架構以及應用,這個應用是以程序或者日誌檔案為單位的一個關注物件。採取一個分鐘級的或者小時級的方式來去對這些物件進行維護,這是我們傳統架構下比較常見的內容。比如說我們在09年做的中國聯通的一個系統,他們就是通過這樣的業務監測的方式來去模擬線上充值系統與一卡通系統,一分鐘或者五分鐘交易處理的一個情況,隨著雲環境或者容器計算資源變得更加複雜,敏態架構下關注的物件就不單單是穩態環境下的這些技術資源了。我們更關注的是雲虛擬化容器物件應用服務呼叫的情況,甚至是我們最終的使用者體驗,以網際網路公司業務特徵為代表。

比如說我們在16年的12月,支付寶推出了一個圈子,推出以後產生了一些負面效應,很多使用者在支付寶上進行操作或者留言的時候,支付寶就會及時發現和處理,這其實就是通過了整個使用者體驗,去進行詳細的使用者回溯,進行這種資料的一個處理和還原,這是我們整個的一個敏態環境下的一個監控管理範疇。