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

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

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

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

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

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

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

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

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

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

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

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