如何構建用戶滿意的「服務化」數據平台

前文中（鏈接：為建設四個現代化的大數據平台奮鬥終身 ）我們談到，在構建數據平台的過程中，我們要堅持四個現代化，這其中平台服務化是關鍵指導思想之一，而用戶滿意是衡量服務水平的唯一標準。

那麼這篇，讓我來具體談談如何為人民服務：）

P.S. 勘誤：上圖 「背簍精神」 實為 「背鍋精神」之筆誤，特此申明。

首先，什麼是服務？我們辛辛苦苦提供了穩定的Hadoop集群給業務方用，是服務么？我們開發了高性能的ETL工具，是服務么？我們把元數據血緣關係都收集，分析，展現出來了，是服務么？我們提供了任務調度的方式手段，是服務么？

其實，這個問題，沒有標準答案，是不是服務，取決於你所服務的對象。你所提供的內容，是不是對方最終想要的東西？好比我想享受一頓美食，你給我一條活蹦亂跳的澳洲龍蝦，一個設備齊全的廚房，甚至還有一本澳龍烹飪指南。不是不可以，但可能並不是大多數人所期望的服務。但如果我是想學習烹飪，那這種服務就再理想不過了。

所以，要談服務，首先得談你怎麼定位大數據平台的職能範圍和服務對象。很不幸，這也不是一個有標準答案的問題。

有些公司，大數據團隊只負責基礎組件的開發和運維，業務方裸用系統。有些公司，基礎組件之上的工具，平台等等，都由專門的工具團隊負責。有些公司，不同的事業部團隊會自行在基礎組件之上，各自構建自己的系統。還有些公司，大數據團隊從下到上，鏈路通吃，從集群運維一直負責到最終具體終端業務數據的產出。

但不管怎麼劃分，我想，相關係統所依賴的人力，資源和技能的內聚應該都是最重要的劃分考量因素。對於多數公司來說，相關係統和具體的特定業務知識是否有強關聯，會是一個比較合理的劃分參考依據。

凡是沒有業務強關聯的，而對大數據相關基礎知識或生態依賴又較大的系統，可能由大數據平台相關團隊統一來構建會比較合適。反之，往具體終端業務產品拓展衍生的程度，就要看各公司大數據團隊自己的實際情況和業務團隊的能力了。

而評估數據平台的服務能力，除了客戶滿意這個主觀標準，另一個偏客觀一點的標準可以是：貫穿打通上下游和周邊業務的能力，打通的越徹底，平台的服務能力基本上就越強。

比如你開發一個調度系統，系統自身的能力，大家都知道：時間／依賴觸發，任務計劃，執行流水，出錯重試，支持的任務類型等等。

那麼上下游和周邊業務關係包括什麼呢？比如：

• 後端集群流量／負載的反饋控制能力

• 和腳本開發環境的集成對接

• 和許可權系統，任務，腳本訂閱管理體系的連通

• 和元數據血緣分析管理系統的對接

• 和任務測試／發布環境的對接

• 與報警，值班，監控系統的協同

• 和其它非大數據類業務自己的工作流體系串聯

• 與數據質量監控系統的協同

類似的能力，還可以列舉很多，很明顯，上述能力越完備，調度系統的服務水平很可能就越高。但值得注意的是，能力並不等同於服務，還要看它對用戶的價值，這點我們後面再詳述

下面，基於這樣的定位來討論大數據平台團隊所提供的服務

所以，用戶需要的是什麼服務？ 按照我們服務的用戶定位，用戶需要的不是一個個具體的組件，用戶需要的服務往簡單來歸納，很明顯，就是三類：

• 存儲

• 計算

• 查詢（展示）

至於為了更好的支持這三類服務，不論是存儲計算的具體組件hdfs／hbase／hive／spark／storm／flink，還是你所需要工作流調度，許可權管控，元數據血緣分析，質量監控等等各類支撐和監管系統，都是手段而已。並不是說他們不重要，或者用戶不需要關心，而是說從用戶的角度來說，並不是他們訴求的出發點。

用戶需要的是穩定可靠高效的存儲數據，只要滿足性能指標，他們其實並想不關心底層使用的具體組件

用戶關心的是高效低成本的開發業務，鑽研和學習各類計算框架，並不是他們的初衷

用戶在意的是方便快速的查詢到想要的數據，結果便於理解和溝通，能夠有效的支持業務決策。數據存儲在哪裡，用什麼工具查詢，需要做什麼預處理，是否需要緩存優化，這些能不考慮最好不過

當然，從業務開發的角度來說，可能對底層系統理解得越多，開發使用起來就會越順手，但從數據平台服務構建的目標來說，服務的價值，就在於能在多大程度上減少使用方對底層系統了解的必要性，降低業務開發的門檻。而不是僅僅提供組件或者孤立的系統，把組件選型評估，流程串接，方案構建的工作交給業務方去考慮。

如果你有無限的時間和無敵的能力，那麼這個問題不是問題，大無畏的去構建就是了。

但現實情況是你的時間是有限的，你的能力和經驗也是有限的，而數據平台所需要的服務，幾乎是無限的。

所以，大體看來，我覺得平台服務的構建，可以分為兩種方式：

第一種方式，是針對具體的業務場景，針對性的開發，一站到底式的支持

優點：

• 和業務結合緊密，產品邏輯可以高度定製，最大程度匹配業務需求

• 流程複雜度相對可控，可以儘可能屏蔽與具體業務無關的內容，確保易用性

• 無需太多考慮通用性問題，系統架構成型快，演進負擔小

缺點：

• 系統專用性較強，可拓展性差。

• 放到多個部門，業務的維度來看，系統之間可能缺乏統籌考慮，存在大量重複建設的工作

比較典型的，如果是業務導向的部門來構建的系統，基本是這樣的。比如廣告部門要做數據分析業務，那他一定不會優先考慮數據模型的通用性，多租戶許可權管控之類的東西，高度定製化的流程及時產出正確的計費數據和投放策略才是最核心的內容。

還有一種情況，是各個集團部門間存在一些競爭關係，或者不滿意基礎架構團隊提供的服務，所有的東西寧願自己搞一套

第二種方式：是針對抽象通用的功能需求，分別構建獨立的系統，通過各個系統的疊加配合完成對業務場景的支持

優點：

• 針對抽象通用的功能需求，可拓展性較好

• 能夠減少個業務系統的重複建設

• 各系統設計和架構方案有機會能夠做到更加深入，完善

缺點：

• 需要考慮通用性，設計難度較大，系統架構成型較慢

• 各系統之間依賴較多（相對），迭代演進負擔較大

• 對具體業務場景定製程度較低，整體易用性相對較差，使用成本較高。

比較典型的，如果是非業務導向的部門來構建的系統，往往是這樣的。還有一種情況是，基礎部門沒有自下而上的完整鏈路的掌控權，那麼也可能是基於自己的業務範圍，構建一些相對獨立的功能模塊和系統。又或者是系統的演進，是從工具向平台演變的一個過程，也很自然的是從局部向整體拓展

兩種方式沒有絕對對錯之分，取決於各公司，團隊，部門具體的實際情況

但無論使用哪種方式，都需要考慮，如何儘可能揚長避短，或者採取必要的手段去彌補缺點

比如我司之前的北京分舵，技術方案融合前，北京分舵的數據平台基本就是按照業務定製的原則來開發，在具體某類定製化的業務開發流程方面，客觀的說，易用性就比我們杭州分舵的平台要好很多，用戶口碑不錯。但帶來的問題就是，不同的業務和產品線實現類似的功能，各有一套體系，比如調度系統就有獨立的三套。各類業務之間基本沒有打通的可能性，維護成本也很高，技術迭代困難。

我司目前的數據平台服務，是採用第二種方式來演進的

早期（2014年左右）

我們的基本情況是只有最基本的功能組件，包括：定時輪詢的調度系統，hive集成開發平台，定製的報表系統，簡單的許可權系統，使用Storm開發基本的實時計算業務等。

2015年左右

我們開始添加更多的功能組件，Spark計算框架的引入，元數據管理系統的開發，自定義查詢系統的開發，Storm代碼開始模塊化構建，全站用戶頁面行為跟蹤埋點體系的構建，以及一些底層系統整理改造工作，包括公司內部底層多個集群的整合，改造，升級。數據平台各業務後台許可權管理的統一，報警服務系統的拆分構建等等

這裡面有經驗收穫也有歷史教訓

教訓是，整個15年，做了大量的穩定性改進，模塊拆分，組件完善，集群融合，升級等工作，在一定程度上完善了數據平台的體系架構，降低了維護代價，提升了穩定性，這固然給平台發展打下了基礎，但是，從業務價值產出的角度來說，並不明顯，相對零散，對業務方來說，沒有從數據平台的改進工作中得到顯著的收益。團隊的壓力較大（績效方面）

從領導和業務方的角度來說，不要跟我說你們做了什麼，告訴我對公司有什麼價值？

回過頭來看，應該在業務導向方面，多做一些思考和工作，避免冰山下的工作不能給團隊帶來實際的價值回報，所以16年的工作在核心繫統改造的基礎上，開始加入更多的圍繞終端服務價值產出的內容

2016年

開始重構部分核心組件，和推進整體平台服務化的進程，包括許可權系統的服務化，構建對象存儲系統，完成了核心調度系統重構，完成了數據可視化平台核心功能的構建，實時計算平台構建，數據交換鏈路服務化，常態化業務數據大屏構建，數據質量系統的構建，開始集群配置管控平台的構建

整體來說，一方面是內部系統的服務化，比如RBAC的許可權系統，用來服務所有的業務和數據後台，比如通用對象存儲服務，用來支持其它各類有通用存儲需求的系統，比如簡歷招聘系統，小圖片存儲系統

另一方面是針對數據開發用戶或者終端數據使用用戶的服務，整體的目標是降低各項業務開發的難度，讓用戶能夠更加獨立自主的進行自我服務，減少需要平台定向支持的需求，比如通過可視化平台讓用戶以配置的方式完成數據圖表的自主開發。

2017年～

2017年目標是傻瓜化服務平台的構建，各種自助服務功能的完善，端到端整體鏈路服務的打通，專家系統的構建，進一步降低服務支持的代價，實現世界和平，人類大同。（哇噻，又吹牛了，臣妾做不到啊～～～淡定，只是願景，願景嘛。。。）

回頭小結

即使放在我司，回過頭來看，也不能說第二種方式：通用組件->平台融合就是最合理的方案，事實上對一個特定的具體用戶來說，第一種定製開發的方案可能才是他最歡迎的，畢竟，急他所急嘛，客觀上來說，短期的收益也可能是最明顯的。

所以，有時候，局部做一些妥協，可能也是你生存下去的合理舉動。人生，不就是在各種利益抉擇中度過么？

所以，這樣去做就好了么？ 用戶就會跪下來感謝你了么？你的工作生活從此就陽光快樂了么？Naive！

事實上，自打你心裡打定主意，走上這條又紅又專的服務化之路的那天起，你就走上了一條不歸路。。。

很快，你就會發現：

由儉入奢易，由奢入儉難

• 用戶對服務質量的要求，只會越來越高！

• 每每有其它公司數據團隊告訴我，他們的用戶運行任務遇到問題，都自行了斷，他們都不值班，用戶出問題，分析到原因才找他們時，我都會留下嫉妒而又悔恨的淚水。。。

你的服務口碑，取決於你服務最差的那個環節

• 可恨的水桶效應，當你盡心儘力還是被人罵的時候，有沒有六月飛雪的感覺呢 ；）

• 不過，這也是人之常情了，就好比悲劇總是比喜劇雋永，痛苦永遠比快樂來得持久。

服務越多，支持的代價越高

• 以我們的開發能力，做個服務，總會有BUG，總會有不夠靈活的地方，可是誰讓你攬過這攤事呢？

用戶：既要疾如閃電，還要天長地久！

• 用戶的需求你一定要快速響應，這個界面交互不爽，那個API不夠便利，只要用戶發起的變更需求，你就得趕緊搞定不是，否則不重視用戶這個大棒子就砸腦門上了，趕緊賠不是去 ；）

• 但是你發起的變更呢，那一定是私生子啊，待遇低下，註定招人白眼。我去，這個Button昨天還在這呢，今天怎麼找不到了？什麼？要改API，你丫之前咋不設計好呢？！操作流程變了，咋不提前通知呢？ 啥，通知過了？沒看到，這麼重要咋不直接找我溝通呢？

• 好吧，對於這兩個標準的問題，不要抵抗，都是用戶對，做好心理準備，陪個笑臉，想想怎麼解決具體問題，更容易一些 ；）

老闆：既要馬兒駝得多，還要馬兒不摔倒！

• 老闆語重心長的告訴你，要服務好客戶啊！業務第一知道么？這個工作，你敢告訴我你不接，不想混了？對了，還有那個，別和他們爭了，做掉就好了。。。

• 然後有一天，誒，怎麼出了個故障？盡給我找事，能梳理一下問題，保證一下穩定性么，穩定第一你不知道么？！

• 後來又有一天老闆問你：最近沒什麼故障，不錯，不過，今年你們好像沒有什麼產品成果啊，都在做什麼呢，有沒有一點價值導向的思想啊？你這樣不行啊。。。361績效？本來想給1+的，看你幹得辛苦，給個6-部分不滿足需求鼓勵一下吧。。。

• ：）以上情節，純屬虛構，請勿對號入座。但說實話，老闆，都是對的！

用戶的訴求和你的訴求，經常是衝突的，哪怕你的出發點是：你好，我好，大家好。

• 你要數據安全，用戶想要方便：我不就查個表么，申請許可權還找不到owner審批，影響效率啊！我沒分析出數據，明天GMV跌了你負得起這個責任么！（用戶A：我去，誰drop了我的表？？你們平台太不靠譜了，許可權也不控制？）

• 你想提高集群服務性能，敦促大家優化腳本，用戶告訴你，沒空！怎麼滴吧？（用戶B：我去，今天跑任務怎麼這麼慢？讓不讓我幹活了？）

• 你的時間不值錢，哪怕它本來可以用來解決更多的問題。用戶的時間最值錢，哪怕花一點時間可以克服的麻煩，也會來挑戰你，為什麼不能做得完善一點，再完善一點，更完善一點？（用戶C：誒，搞啥呢，一個功能拖那麼久？信不信我告你老闆去！）

最後，上述問題，基於用戶滿意是唯一衡量標準這條公理，最後一定可以推導出都是你的問題，誰叫你是服務提供者呢？ 有本事你去做甲方去啊 ；）沒有被鞭的覺悟，就不要趟這個渾水了。掙，還是不掙，問題都在哪裡，還是多花點時間想想如何更好的解決吧 ；）那麼，為什麼要提供服務？

所以，服務辣么苦，為什麼我們還要做？是因為賤么？當然不是，是因為理想！

出來混，總是要還的。換位思考一下，我們也有當大爺，使用別人的服務時候 ；）

做為有理想的青年，為了實現在使用別人的服務時，但凡不爽，也可以抱著沒有傷害就沒有進步的理念，為了世界更美好的目標，以人民的名義，語重心長，理直氣壯，毫無節操，無所顧忌地進行譴責和教育的崇高理想，這點苦，就當是卧薪嘗膽了吧。

送給各位同行一首詩，用於自勉：

「大雪壓青松，青松挺且直，要知松高潔，待到血化時 」 ：）

只談問題，不談方案，都是耍流氓！

雖然真的勇士，抱著「世界辣么殘酷，我要血債血還」的夢想，或許可以笑對慘淡的人生。然而，畢竟，追求快樂和幸福才是這個時代的主旋律

所以，接下來，談談如何在服務的過程中，儘可能過得不要那麼慘。。。

前面談到，我司走的是先搭建獨立的功能模塊系統，然後將系統組合構建成完整的數據平台這條坎坷的路，帶來的問題也很傷腦筋

需要考慮通用性，設計難度較大，系統架構成型較慢，價值產出壓力大

所以，歸根到底還是能力不夠啊～～～

能力不夠怎麼辦？那就不要不切實際，做無用功。沒有目標的攻堅工作，堅決不做。目標再通用的系統，在開發之初，也需要面向一個具體的業務，上線之初（我說的是你那完美無瑕的Alpha版）就要帶上這個業務（當然，想必這個小白鼠業務方內心一定是痛苦的，要找到這樣的小白鼠也是蠻困難的），帶著業務的痛點問題來做開發，在此基礎上再考慮如何構建通用的解決方案來適配其它業務。

簡單說，就是採用通用＋適度定製的方式來快速推進平台的構建，不怕做得不通用，就怕通用到沒有業務可以適用 ；）

各系統之間依賴較多（相對），迭代演進負擔較大

你看，好容易把各個系統拼湊起來成為一個平台，生命不息，折騰不止的你們，就忍不住就要重構升級其中的一個系統。。。

幹嘛呢，幹嘛呢～～～

好吧，就算你不主動重構，當你完美的通用服務平台的在遇到第二個用戶的時候，也會大概率發現，我去，好像不重構一下就搞不定啊。。。

所以這個問題會永遠存在，我們能做的，就是做好各個系統的模塊化工作，提供所依賴功能的插件封裝機制，適當考慮Fail Back的可能性，降低系統耦合度，我說的不光是代碼的耦合，什麼硬編碼依賴系統的地址之類的無疑應該避免，但更難的是避免過度的業務邏輯流程上的耦合。

兩個系統如果交叉依賴，一個流程要是你調我來我調你，循環不止，生生不息的話，你的麻煩就大了。

然後，就是盡量考慮保障系統具備灰度發布的能力，依賴多，出問題難以避免，關聯繫統多，系統更新可能也無法一蹴而就，那就儘可能減少變更過程的風險代價，知錯就改還是好孩子，別做一鎚子買賣。

對具體業務場景定製程度較低，整體易用性相對較差，使用成本較高。

說到我們的痛點了。既要馬兒跑得快，又要馬兒不吃草，一個通用平台，或者，不滿足業務方的定製需求，讓業務方抱怨流程長，操作複雜，工作各種不高效。或者，把各種需求都拼進來，但是一個不小心，一堆旨在提供便捷的功能，反而會讓系統變得更加複雜，最終的結果就是導致整個系統不再便捷。所以，簡單和通用往往是矛盾的。

這個問題，有時候，更多的就無關服務，而是產品問題了，所以，放下一篇文章再討論把。不過，從路線上來說，一種可行的方式，是針對具體業務場景需求，在通用服務的基礎上，二次垂直封裝，適度定製和簡化業務流程，從通用系統衍生出專用系統，來屏蔽和特定業務場景無關的系統複雜性，不過，代價當然也有，那就是你又多了一個系統，一層依賴關係需要維護。

技術問題，都好辦，服務，更多的是針對人，而人的問題，從來不簡單。下面觀點，只是個人淺見，如有不妥，歡迎討論。

由儉入奢易，由奢入儉難

一旦用戶對你的定位認知是服務提供者， 那麼從情感上說，用戶一定會希望你的服務盡善盡美，搞定一切，從理智上來說，多數用戶也能夠理解服務的構建不是一蹴而就的。但人天生就有以自我為中心，高估自己的需求，低估它人的困難的本能。

所以這裡關鍵是如何與用戶的認知達成一致。

說好不打臉

你看12306那愚昧的流程和讓人崩潰的圖片驗證機制，同樣是買東西，換做我們大電商行業敢這麼做，那用戶轉換率就不要想了，分分鐘倒閉的節奏。但對於12306，能買到票就好，你應該不會奢望它提供什麼車次收藏，票務購物車，路線智能推薦之類的功能吧 ；）

套個術語，這叫QOS（Quality of Service）約定，往我們的主題上靠，也可以叫用戶預期管理。首先，你要明確你所提供的服務的範圍定義和質量約定，然後，要儘早和用戶達成一致。如果可以，對用戶使用對應服務時應該承擔的責任，也需要提前明確的進行溝通（好吧，我知道，做為乙方，這個有時候很難）。這麼做，不是為了降低用戶的期望值，而是為了統一認知。凡事不怕標準高，就怕標準不一致。

你說我的用戶都是在服務推廣過程中接入的，用你的服務就是看得起你，哪有機會對標期望值啊？而且系統總是迭代更新，哪有固定的標準。

說的很對，這件事情操作起來並不容易，但形式可以有很多種，我知道你沒法簽訂一個免責協議，但比如：產品定義，路線計劃，已知問題列表，最佳避坑實踐，FAQ，在產品使用過程中提供即時的反饋／提示／警告信息等等，這些工作或多或少總是能做到一些的。 簡單的說，明確的告知用戶你能做什麼，你不能做什麼，你計劃做什麼，你希望他們注意什麼，或許事情就會好辦很多。

服務越多，支持的代價越高

服務多了，肩挑手扛肯定不行，在實現並上線完一個服務之後，不是萬事大吉了，要及時考慮如何降低維護成本。這不光是說系統自身的維護成本，還包括技術支持的成本。出了問題，用戶能否自主定位和解決？

多數情況下，不是用戶懶，想要躺在你身上，而是他不具備解決問題的能力，沒有足夠的知識儲備，即使有相關知識能力，可能也因為沒有明確的故障反饋，沒有問題日誌，沒有性能數據，沒有修復的手段等等而不得不依賴你來支持。

這時候，一方面你需要考慮將運維手段工具化，最佳實踐文檔化，另一方面，你可能需要一個專家系統來幫助用戶診斷問題。

總之，服務做得多固然好，但做完一個服務，就能撒手不管一個服務才是做服務的最高目標。

這個還用說么，服務的評判標準，是用戶，哪裡差，哪裡補，不過，注意管理好用戶期望，注意引導用戶，不要盲目的被用戶牽著鼻子走就好了。 至於最終的口碑，由它去吧，那不在你的控制範圍之類。

可能，你要說，有時候用戶就是不講理，我非聖人，我的服務好不起來啊。這是人之常情，的確當你設身其中之時，做為當事人，有時很難保持良好的心態，這時候，你需要置身事外。

我曾經一度對團隊的同學說，對待用戶，你們的態度一定要好，一定要熱情！只管了解需求，討論方案。做不了的事，不想做的事，人力，資源等等，都推給我，你們唱紅臉，我來唱黑臉。 這還真不是我有多麼高風亮節，主要是做為非一線直接開發對應項目的同學，罵在身上就沒有那麼切身的痛，所以心態有時可能會好一些。唱黑臉，講道理的時候，可能稍微淡定從容一點，（當然，也不排除被用戶說服了。。。）另外，從用戶體驗來說，更多的時候接觸的還是直接負責項目開發的同學，保持這部分同學關係融洽總不是壞事。

服務的快速迭代改進和服務的穩定可靠，必然是矛盾的。這個矛盾無法解決，只能緩解。我能想到的方法也只有：

• 如果可能，制定班車式開發計劃，按固定的周期和預定的計劃更新系統，如非必要，不做火線更新.

• 提前溝通, 就可能影響，明確告知，寧濫勿缺，Again，這又是一個預期管理的問題。

• 影響面大的變更，如果必要，確保你有灰度過渡和回滾的方案。事前的溝通很多時候因為各種原因，不能觸達用戶（比如用戶不在意，或者在沒實際執行前，壓根沒仔細想會不會有問題等等），那麼過渡和補救的手段就很重要了。

這個，向上管理？我不擅長。做好工作計劃溝通吧。

然後，如果有壓力，不要簡單的做二傳手向下傳遞，別把問題和責任拋給團隊，把目標和方案拋給團隊。

另外，遇到難題，適當反饋（老闆，招不到人啊～～～）

總之，不求老闆舒坦，但求問心無愧 ：）

就這一點，我很贊同一個說法：凡事可以堅持原則，但是沒有必要苛求立場。

多數情況下，你和用戶的訴求衝突，並不是目標，而是在實現這個目標過程中的遇到的問題。或者說，由於立場的不同，你們的側重點是一件事的不同方面。

比如，用戶在意自己的作業跑得快，而你在意它不要影響其他人，希望集群的整體效率高。用戶希望便捷，你希望安全。本質上，這些都是兩件獨立的事情，但最終目標，其實是一致的。所以他們未必非要衝突。只是，如何兼得，有時的確很困難。

所以，怎麼辦？動腦筋，講道理唄，沒有必要追求大家對所有工作真心贊同，求同存異，解決核心矛盾，尋找一個雙方都可以接受的妥協點就好，這個妥協點一定存在，如果沒找到，要不方案不夠好，要不道理沒講夠 ；）

服務，從來都不是一個單向承諾的事情，選擇什麼樣的路線，以什麼樣的方式對待你的用戶，如何面對遇到的問題，都是有得選擇的，也可以溝通的，只要你明確這麼選擇的理由，並且願意承擔由此帶來的後果 ；）

那你問我所做的選擇，後果慘不慘？咳，咳，這個，還是讓我想想下一篇文章該寫點什麼吧。。。

常按掃描下面的二維碼，關注「大數據務虛雜談」，務虛，我是認真的 ；）