大數(shù)據(jù)運(yùn)維規(guī)劃

1、 大數(shù)據(jù)運(yùn)維規(guī)劃一個企業(yè)的IT部門有業(yè)務(wù)和分析系統(tǒng)之分，這里就叫作OLTP和OLAP吧，IT部門一般算是業(yè)務(wù)部門的乙方，而IT部門的OLAP系統(tǒng)則是OLTP系統(tǒng)的乙方，因?yàn)镺LAP系統(tǒng)處于OLTP的下游，一般可用性要求也不高，在傳統(tǒng)企業(yè)內(nèi)，CRM掛了是天大的事情，但同樣的事情發(fā)生在BI等OLAP系統(tǒng)上則可以容忍很長時間。傳統(tǒng)企業(yè)的OLAP系統(tǒng)側(cè)重對內(nèi)支撐，除了必須的生產(chǎn)報表，不是必需品，更多像是奢侈品，有了可能好一點(diǎn)，沒有影響也不大，比如精確營銷。隨著大數(shù)據(jù)時代到來，企業(yè)對內(nèi)數(shù)據(jù)化、精益化運(yùn)營的要求越來越高， OLTP系統(tǒng)迫切需要OLAP的分析力，OLAP則需要嵌入到OLTP流程中發(fā)揮價值，兩

2、者相互滲透，我中有你，你中有我，OLTP與OLAP系統(tǒng)融合的趨勢將越發(fā)明顯。同時，很多企業(yè)開始推進(jìn)大數(shù)據(jù)價值變現(xiàn)， OLAP系統(tǒng)的地位就發(fā)生了根本變化，即OLAP系統(tǒng)越來越跟企業(yè)的直接價值創(chuàng)造相關(guān)，比如以前OLAP掛了，只要對內(nèi)部客戶做些解釋也許就能消化影響，現(xiàn)在則會造成外部客戶投訴，在阿里等企業(yè)大數(shù)據(jù)平臺掛了肯定是不可想象的事情。相信每年阿里雙11前大數(shù)據(jù)平臺運(yùn)維的人會很忙，即使如實(shí)時大屏數(shù)字顯示這類都需要強(qiáng)大的運(yùn)維保障能力，而很多企業(yè)搞大型營銷活動往往只關(guān)注OLTP系統(tǒng)的穩(wěn)定，OLAP系統(tǒng)的運(yùn)維人員會悠閑的多，這是數(shù)字化企業(yè)和非數(shù)字化企業(yè)的差距。DT的趨勢不會改變，無論是對內(nèi)還是對外，打造

3、一個健壯的大數(shù)據(jù)運(yùn)維體系必不可少，由于OLAP與OLTP特點(diǎn)不一樣，不是簡單的照搬OLTP系統(tǒng)的運(yùn)維方式就可以了，需要走出自己的路，這里分享一下筆者最近關(guān)于大數(shù)據(jù)運(yùn)維的一些思考。1、數(shù)據(jù)運(yùn)維的組織架構(gòu)筆者經(jīng)歷過很多種BI運(yùn)維組織架構(gòu)，一種是開發(fā)和運(yùn)維縱向一體化，BI沒有交維動作，開發(fā)人員直接為維護(hù)負(fù)責(zé)，在長達(dá)6-7年的時間，筆者所在的BI團(tuán)隊(duì)就是這種模式，每個人按照業(yè)務(wù)條線進(jìn)行劃分，為這個業(yè)務(wù)條線的所有數(shù)據(jù)負(fù)責(zé)。這種運(yùn)維的效率其實(shí)是很高的，對于個人的鍛煉價值也很大，既做需求，也做開發(fā)，更做維護(hù)，還要會交流，但其最大的問題就是缺乏標(biāo)準(zhǔn)，處理過程不透明，無法進(jìn)行運(yùn)維承諾，規(guī)模很難擴(kuò)大。第二種就是開

4、發(fā)和運(yùn)維完全分離，即橫向切割，很多企業(yè)發(fā)展到一定階段，系統(tǒng)越來越龐大，IT部門為了保障系統(tǒng)穩(wěn)定制定了大量的標(biāo)準(zhǔn)化規(guī)范和流程，為了確保運(yùn)維管理的集中高效執(zhí)行，運(yùn)維團(tuán)隊(duì)必須從開發(fā)中剝離出來，傳統(tǒng)的觀點(diǎn)認(rèn)為開發(fā)和運(yùn)維的職責(zé)存在天然的沖突，需要實(shí)現(xiàn)制衡。從筆者的經(jīng)歷看，這種BI運(yùn)維模式，從短期來看有效果，但長期看，存在著很多弊端，總體來講，并不是最好的運(yùn)維模式。開發(fā)和運(yùn)維要實(shí)現(xiàn)理想的交接，前提是交接的東西標(biāo)準(zhǔn)化程度要高，能夠說得清楚，告訴你這個東西不會變形成其他東西，因此，越穩(wěn)定，越容易封裝的東西越容易交接，也即越容易維護(hù)。OLTP很多時候是有這個特點(diǎn)的，但OLAP系統(tǒng)則完全不同，OLTP能清楚的說清

5、楚提供了多少種服務(wù)，這些服務(wù)之間的關(guān)系如何，也即組合是可以窮舉的，但數(shù)據(jù)的指標(biāo)和維度是如此之多，相互之間的組合關(guān)系是無窮的，數(shù)據(jù)封裝本身就是個偽命題，數(shù)據(jù)要交維需要的是對于業(yè)務(wù)和數(shù)據(jù)的深入理解，而不是告訴維護(hù)這張表交給你管理，數(shù)據(jù)維護(hù)最大的一類工作數(shù)據(jù)質(zhì)量稽核需要代碼級別的溯源能力。因此，BI要實(shí)現(xiàn)理想交維往往只有一種可能，維護(hù)人員跟開發(fā)人員具備同樣的技能，君不見核查數(shù)據(jù)問題基本是要開發(fā)參與的，只懂封裝的數(shù)據(jù)運(yùn)維人員除了能監(jiān)控、告警、作業(yè)調(diào)度啟停一下，可做的事情很少，因此，這種淺層次的運(yùn)維到底有多大的價值？隨著數(shù)據(jù)交維的東西越來越多，運(yùn)維人員會疲于奔命，很多溝通協(xié)調(diào)工作只是為了轉(zhuǎn)述問題，一個問

6、題的解決流程會拉的很長，這種運(yùn)維模式滿意度其實(shí)很難提升，同時運(yùn)維人員的專業(yè)技能也很難獲得增長。第二種模式短期來看的確有效，因?yàn)槠渫ㄟ^復(fù)用OLTP已有的機(jī)制、流程經(jīng)驗(yàn)來獲得價值，但長期是有致命缺陷的，其缺乏成長性，筆者一直認(rèn)為運(yùn)維是系統(tǒng)改進(jìn)的核心驅(qū)動力，而不是由項(xiàng)目規(guī)劃人員指東打西，很多時候，規(guī)劃人員提出的東西跟解決運(yùn)維的實(shí)際問題相差甚遠(yuǎn)，誰對這個系統(tǒng)有真正發(fā)言權(quán)呢？也許，專業(yè)能力最強(qiáng)的人員應(yīng)該放到運(yùn)維，而不是開發(fā)、規(guī)劃或項(xiàng)目，如果穩(wěn)定是企業(yè)最核心的工作的話。第三種模式，筆者認(rèn)為是均衡模式，維護(hù)要有的放矢，提倡中臺類的系統(tǒng)、產(chǎn)品或數(shù)據(jù)進(jìn)行交維，創(chuàng)新、探索、變動類的系統(tǒng)或數(shù)據(jù)不用交維，誰做的誰自己

7、管去。何謂中臺類的系統(tǒng)或數(shù)據(jù)，就是企業(yè)真正沉淀下來的資產(chǎn)，成熟一個，納入一個，比如基礎(chǔ)平臺、標(biāo)簽庫、基礎(chǔ)模型、融合模型等， 對于這類系統(tǒng)或數(shù)據(jù)，要求能提出合理的監(jiān)控和告警要求并部署，運(yùn)維團(tuán)隊(duì)要確保能自行處理大多數(shù)的故障，要能提出持續(xù)優(yōu)化的建議，在未來系統(tǒng)改進(jìn)上具有主導(dǎo)發(fā)言權(quán)。2、故障分級和故障升級流程運(yùn)維最核心的就是故障管理流程，這里從應(yīng)用分級，故障等級，升級流程等方面給出一個實(shí)踐案例。首先，數(shù)據(jù)運(yùn)維涉及平臺、應(yīng)用和數(shù)據(jù)等管理對象，這些對象又可以根據(jù)重要性劃分為核心、重要及一般三個等級，以下是一個劃分示例，供參考：每個企業(yè)應(yīng)該根據(jù)自身實(shí)際劃分等級，諸如BDI是基礎(chǔ)平臺，掛了數(shù)據(jù)就沒法采集進(jìn)來了

8、，因此是最重要，這里劃分為核心等級，數(shù)據(jù)類里有重要和一般之分主要是這些數(shù)據(jù)跟重要應(yīng)用相關(guān)，必須劃分為同一個等級，這個時候血緣分析就很重要，需在知道哪些數(shù)據(jù)跟這個應(yīng)用相關(guān)從而判定這個數(shù)據(jù)的重要等級，體現(xiàn)的是數(shù)據(jù)和應(yīng)用一體化的思想，數(shù)據(jù)變現(xiàn)事關(guān)直接收入，因此這里也劃分為重要等級。這張表的設(shè)計(jì)其實(shí)涉及了很多的原則，包括平臺保障原則，收入優(yōu)先原則，數(shù)據(jù)與應(yīng)用一致性原則，表也是需要動態(tài)維護(hù)的，每次納管一個平臺、數(shù)據(jù)或應(yīng)用，就應(yīng)該同步更新。其次，就到故障的具體分級了，我們將其劃分為灰、藍(lán)、黃、橙及紅五個層級，首先要考慮時間維度，即異常的持續(xù)時間，以下是一個示例：時間維度顯然還不足以表示故障的嚴(yán)重程度，還需

9、加上影響范圍，這里特別增加了數(shù)據(jù)完整性這個影響指標(biāo)，因?yàn)槿绻麛?shù)據(jù)大范圍的延遲，我們也認(rèn)為是個較大的故障，即使沒有一個投訴：有了這些判定標(biāo)準(zhǔn)，維護(hù)在出現(xiàn)故障時就有章可循，可以根據(jù)這些標(biāo)準(zhǔn)明確最后的故障等級，然后依據(jù)不同的故障等級走不同的升級流程。最后，是一個故障處理升級流程示例，明確了什么時刻需要做什么事： 以下是故障短信發(fā)送對象的一個示例，故障嚴(yán)重的時候，需要讓老板知道：3、數(shù)據(jù)采集保障BDI（數(shù)據(jù)采集平臺）當(dāng)前采集接口2000多個，其中分鐘/小時/月接口400多個，日接口1500個，日接口中重要接口300多個，采集接口涉及155個數(shù)據(jù)源（庫），復(fù)雜度是比較高的，必須根據(jù)接口重要性及時間要求進(jìn)

10、行及時性保障。以下是一個示例：2點(diǎn)前完成58%的“重要”級接口，4點(diǎn)前完成78%，6點(diǎn)前完成85%，8點(diǎn)前完成88%，12點(diǎn)前完成100%，鑒于集群計(jì)算性能時有波動，數(shù)據(jù)采集及時性保障目標(biāo)設(shè)定各時段達(dá)成率90%以上，再不重要的接口，也要有個保障底線，用數(shù)據(jù)來說話，很多企業(yè)的數(shù)據(jù)幾個月沒采集都不知道，是由于缺乏明確的保障要求。數(shù)據(jù)準(zhǔn)確性方面也類似，每個數(shù)據(jù)接口采集設(shè)置數(shù)據(jù)量波動性檢查、空值檢查等。4、數(shù)據(jù)作業(yè)保障我們將大數(shù)據(jù)模型和應(yīng)用數(shù)據(jù)的生成都納入到DACP管理，包括融合模型、挖掘模型和數(shù)據(jù)應(yīng)用大作業(yè)共計(jì)762個，其中月作業(yè)189個，日作業(yè)573個，日作業(yè)中重要級作業(yè)333個，根據(jù)作業(yè)重要性及

11、時間要求進(jìn)行及時性保障，其中4點(diǎn)前完成15% 的“重要”級作業(yè)，8點(diǎn)前完成65%，12點(diǎn)前完成85%。針對重要應(yīng)用涉及的作業(yè)，設(shè)置了應(yīng)用結(jié)果數(shù)據(jù)的質(zhì)量檢查機(jī)制，以便提前發(fā)現(xiàn)問題，這里針對所有變現(xiàn)類應(yīng)用的數(shù)據(jù)做了波動性等告警設(shè)置，做這個事情主要是由于對外變現(xiàn)出現(xiàn)了多次數(shù)據(jù)異動客戶投訴的情況，因此盡量做到末雨綢繆，雖然不能解決所有問題，但能做一步算一步。5、平臺保障基礎(chǔ)平臺牽一發(fā)而動全身，企業(yè)已經(jīng)將大數(shù)據(jù)處理平臺納入私有云統(tǒng)一運(yùn)維體系，其他諸如采集平臺和數(shù)據(jù)管理平臺，必須具備高可用，并能在短時間內(nèi)進(jìn)行容災(zāi)切換，這是運(yùn)維的底線。在大數(shù)據(jù)運(yùn)營剛開始的時候，我們在數(shù)據(jù)管理上還是側(cè)重于去解決采集、建模等問題，往前沖的比較多，在創(chuàng)新上花了不少心思，但隨著運(yùn)營深入，運(yùn)維逐步成為數(shù)據(jù)管理最為核心的工作，因?yàn)槿绻麤]有這個健壯的“1”，所有的工作都將失去意義。最后談一點(diǎn)體會。和我們走過的路一樣，很多企業(yè)BI的運(yùn)維仍然像個羞答答的姑娘，很多沒有明確規(guī)范，比如每個接口的及時率要求，很多雜亂無章，比如不知道某個數(shù)據(jù)的影響大小，很多規(guī)范沒有真正落地，比如投訴的統(tǒng)一歸口，大多時候還是需求或開發(fā)人員去直面業(yè)務(wù)人員的問題。雖然其實(shí)處理的效率也不錯，但作為管理者心是不安的，因?yàn)?/p>