FacebookTwitterLineHatena

文 | 傅一平
源自:與數據同行

一個企業的IT部門有業務和分析系統之分,這裡就叫作OLTP和OLAP吧,IT部門一般算是業務部門的乙方,而IT部門的OLAP系統則是OLTP系統的乙方,因為OLAP系統處於OLTP的下游,一般可用性要求也不高,在傳統企業內,CRM掛了是天大的事情,但同樣的事情發生在BI商業智慧等OLAP系統上則可以容忍很長時間。

傳統企業的OLAP系統側重對內支撐,除了必須的生產報表,不是必需品,更多像是奢侈品,有了可能好一點,沒有影響也不大,比如精準行銷。

隨著大數據時代到來,企業對內數據化、精益化運營的要求越來越高, OLTP系統迫切需要OLAP的分析力,OLAP則需要嵌入到OLTP流程中發揮價值,兩者相互滲透,我中有你,你中有我,OLTP與OLAP系統融合的趨勢將越發明顯。

同時,很多企業開始推進大數據價值變現, OLAP系統的地位就發生了根本變化,即OLAP系統越來越跟企業的直接價值創造相關,比如以前OLAP掛了,只要對內部客戶做些解釋也許就能消化影響,現在則會造成外部客戶投訴,在阿里等企業大數據平台掛了肯定是不可想像的事情。

相信每年阿里雙11前大數據平台運維的人會很忙,即使如實時大屏數字顯示這類都需要強大的運維保障能力,而很多企業搞大型行銷活動往往只關注OLTP系統的穩定,OLAP系統的運維人員會悠閑的多,這是數字化企業和非數字化企業的差距。

DT的趨勢不會改變,無論是對內還是對外,打造一個健壯的大數據運維體系必不可少,由於OLAP與OLTP特點不一樣,不是簡單的照搬OLTP系統的運維方式就可以了,需要走出自己的路,這裡分享一下筆者最近關於大數據運維的一些思考。

1、數據運維的組織架構

筆者經歷過很多種BI系統運維組織架構,一種是開發和運維縱向一體化,BI沒有交維動作,開發人員直接為維護負責,在長達6-7年的時間,筆者所在的BI團隊就是這種模式,每個人按照業務條線進行劃分,為這個業務條線的所有數據負責。

這種運維的效率其實是很高的,對於個人的鍛煉價值也很大,既做需求,也做開發,更做維護,還要會交流,但其最大的問題就是缺乏標準,處理過程不透明,無法進行運維承諾,規模很難擴大。

第二種就是開發和運維完全分離,即橫向切割,很多企業發展到一定階段,系統越來越龐大,IT部門為了保障系統穩定製定了大量的標準化規範和流程,為了確保運維管理的集中高效執行,運維團隊必須從開發中剝離出來,傳統的觀點認為開發和運維的職責存在天然的衝突,需要實現制衡。

從筆者的經歷看,這種BI運維模式,從短期來看有效果,但長期看,存在著很多弊端,總體來講,並不是最好的運維模式。

開發和運維要實現理想的交接,前提是交接的東西標準化程度要高,能夠說得清楚,告訴你這個東西不會變形成其他東西,因此,越穩定,越容易封裝的東西越容易交接,也即越容易維護。

OLTP很多時候是有這個特點的,但OLAP系統則完全不同,OLTP能清楚的說清楚提供了多少種服務,這些服務之間的關係如何,也即組合是可以窮舉的,但數據的指標和維度是如此之多,相互之間的組合關係是無窮的,數據封裝本身就是個偽命題,數據要交維需要的是對於業務和數據的深入理解,而不是告訴維護這張表交給你管理,數據維護最大的一類工作數據質量稽核需要程式碼級別的溯源能力。

因此,BI要實現理想交維往往只有一種可能,維護人員跟開發人員具備同樣的技能,君不見核查數據問題基本是要開發參與的,只懂封裝的數據運維人員除了能監控、告警、作業調度啟停一下,可做的事情很少,因此,這種淺層次的運維到底有多大的價值?

隨著數據交維的東西越來越多,運維人員會疲於奔命,很多溝通協調工作只是為了轉述問題,一個問題的解決流程會拉的很長,這種運維模式滿意度其實很難提升,同時運維人員的專業技能也很難獲得增長。

第二種模式短期來看的確有效,因為其通過復用OLTP已有的機制、流程經驗來獲得價值,但長期是有致命缺陷的,其缺乏成長性,筆者一直認為運維是系統改進的核心驅動力,而不是由項目規劃人員指東打西,很多時候,規劃人員提出的東西跟解決運維的實際問題相差甚遠,誰對這個系統有真正發言權呢?也許,專業能力最強的人員應該放到運維,而不是開發、規劃或項目,如果穩定是企業最核心的工作的話。

第三種模式,筆者認為是均衡模式,維護要有的放矢,提倡中台類的系統、產品或數據進行交維,創新、探索、變動類的系統或數據不用交維,誰做的誰自己管去。

何謂中台類的系統或數據,就是企業真正沉澱下來的資產,成熟一個,納入一個,比如基礎平台、標籤庫、基礎模型、融合模型等, 對於這類系統或數據,要求能提出合理的監控和告警要求並部署,運維團隊要確保能自行處理大多數的故障,要能提出持續優化的建議,在未來系統改進上具有主導發言權。

2、故障分級和故障升級流程

運維最核心的就是故障管理流程,這裡從應用分級,故障等級,升級流程等方面給出一個實踐案例。

首先,數據運維涉及平台、應用和數據等管理對象,這些對象又可以根據重要性劃分為核心、重要及一般三個等級,以下是一個劃分示例,供參考:

FineReport報表與BI商業智慧軟體-大數據運維該怎麼做

每個企業應該根據自身實際劃分等級,諸如BDI是基礎平台,掛了數據就沒法採集進來了,因此是最重要,這裡劃分為核心等級,數據類里有重要和一般之分主要是這些數據跟重要應用相關,必須劃分為同一個等級,這個時候血緣分析就很重要,需在知道哪些數據跟這個應用相關從而判定這個數據的重要等級,體現的是數據和應用一體化的思想,數據變現事關直接收入,因此這裡也劃分為重要等級。

這張表的設計其實涉及了很多的原則,包括平台保障原則,收入優先原則,數據與應用一致性原則,表也是需要動態維護的,每次納管一個平台、數據或應用,就應該同步更新。

其次,就到故障的具體分級了,我們將其劃分為灰、藍、黃、橙及紅五個層級,首先要考慮時間維度,即異常的持續時間,以下是一個示例:

FineReport報表與BI商業智慧軟體-大數據運維該怎麼做

時間維度顯然還不足以表示故障的嚴重程度,還需加上影響範圍,這裡特別增加了數據完整性這個影響指標,因為如果數據大範圍的延遲,我們也認為是個較大的故障,即使沒有一個投訴:

FineReport報表與BI商業智慧軟體-大數據運維該怎麼做

有了這些判定標準,維護在出現故障時就有章可循,可以根據這些標準明確最後的故障等級,然後依據不同的故障等級走不同的升級流程。

最後,是一個故障處理升級流程示例,明確了什麼時刻需要做什麼事:

FineReport報表與BI商業智慧軟體-大數據運維該怎麼做

以下是故障簡訊發送對象的一個示例,故障嚴重的時候,需要讓老闆知道:

FineReport報表與BI商業智慧軟體-大數據運維該怎麼做

3、數據採集保障

BDI(數據採集平台)當前採集介面2000多個,其中分鐘/小時/月介面400多個,日介面1500個,日介面中重要介面300多個,採集介面涉及155個數據源(庫),複雜度是比較高的,必須根據介面重要性及時間要求進行及時性保障。

以下是一個示例:2點前完成58%的「重要」級介面,4點前完成78%,6點前完成85%,8點前完成88%,12點前完成100%,鑒於集群計算性能時有波動,數據採集及時性保障目標設定各時段達成率90%以上,再不重要的介面,也要有個保障底線,用數據來說話,很多企業的數據幾個月沒採集都不知道,是由於缺乏明確的保障要求。

數據準確性方面也類似,每個數據介面採集設置數據量波動性檢查、空值檢查等。

FineReport報表與BI商業智慧軟體-大數據運維該怎麼做

4、數據作業保障

我們將大數據模型和應用數據的生成都納入到DACP管理,包括融合模型、挖掘模型和數據應用大作業共計762個,其中月作業189個,日作業573個,日作業中重要級作業333個,根據作業重要性及時間要求進行及時性保障,其中4點前完成15% 的「重要」級作業,8點前完成65%,12點前完成85%。

FineReport報表與BI商業智慧軟體-大數據運維該怎麼做

針對重要應用涉及的作業,設置了應用結果數據的質量檢查機制,以便提前發現問題,這裡針對所有變現類應用的數據做了波動性等告警設置,做這個事情主要是由於對外變現出現了多次數據異動客戶投訴的情況,因此盡量做到末雨綢繆,雖然不能解決所有問題,但能做一步算一步。

5、平台保障

基礎平台牽一髮而動全身,企業已經將大數據處理平台納入私有雲統一運維體系,其他諸如採集平台和數據管理平台,必須具備高可用,並能在短時間內進行容災切換,這是運維的底線。

在大數據運營剛開始的時候,我們在數據管理上還是側重於去解決採集、建模等問題,往前沖的比較多,在創新上花了不少心思,但隨著運營深入,運維逐步成為數據管理最為核心的工作,因為如果沒有這個健壯的「1」,所有的工作都將失去意義。

談一點體會

和我們走過的路一樣,很多企業BI的運維仍然像個羞答答的姑娘,很多沒有明確規範,比如每個介面的及時率要求,很多雜亂無章,比如不知道某個數據的影響大小,很多規範沒有真正落地,比如投訴的統一歸口,大多時候還是需求或開發人員去直面業務人員的問題。

雖然其實處理的效率也不錯,但作為管理者心是不安的,因為很多投訴變得沒有痕迹,很多問題已經被掩蓋,意味著很難去評價真實的運維水平,也意味很難去提升,數據管理者就這樣被過頂傳球了。

數據運維最怕的也不是出事情,而是完全的事務驅動,總是去救火,投更多的人去救火,卻很少有人能從運維的角度提出真正的問題和改進要求,這個可比救火難多了, 100個介面的時候,如果我們不去做規劃和管理,到1萬個介面的時候,可能已經來不及了,所謂積重難返。

大數據是新的機會,對於運維也是重新的開始,未來的挑戰很大,與大家共勉吧。

喜歡這篇文章嗎?歡迎分享按讚,給予我們支持和鼓勵!

熱門文章推薦

立即試用,可獲取更多 報表範本和案例

免費試用