大數據平臺 - 整體建設思想

大數據平臺 - 整體建設思想

大數據平臺整體建設思想

• 目標
  • 爲使用平臺的用戶解決了哪些問題，掃除了哪些障礙，提升了多少工作效率，附加了哪些增值收益
  • 內部組件的橫向聯通能力
  • 業務流程上縱向貫穿打通上下游鏈路的能力
• 建設指導方針
  • 組件工具化
  • 工具平臺化
  • 平臺服務化：平臺提供的內容是不是用戶最終想要的東西？重點是用戶體驗是否夠好，用戶滿意纔是衡量服務水平的唯一標準
  • 平臺產品化：需要根據公司的業務發展階段，對現實中的各種問題進行評估、妥協和取捨。
• 建設思路
  • 垂直業務領域一站到底的建設方式
    • 優點
      • 和具體業務結合緊密，產品邏輯可以高度定製，可以做到最大限度地匹配業務的需求
      • 產品的交互流程、架構複雜度相對可控，同時可以儘可能地屏蔽與具體業務無關的內容，確保易用性
      • 無須太考慮通用性問題，也不用太考慮業務之間的兼容性，整體產品架構成型快，演進負擔小
    • 缺點
      • 系統專用性較強，可拓展性差
      • 放到多個部門，從業務的維度來看，系統之間可能缺乏考慮，存在大量重複建設的工作
  • 通用組件建設，組合支持業務的方式
    • 優點
      • 針對抽象的通用功能需求，可擴展性較好
      • 能夠減少各業務系統之前的重複建設
      • 各系統設計和架構方案有機會做得更加深入、完善和穩定
    • 缺點
      • 需求考慮通用性，設計難度較大，系統架構成型較慢
      • 各系統之間依賴相對較多，迭代演進負擔較大
      • 對具體業務場景定製成都較低，整體易用性相對較差，使用成本較高
      • 團隊承受壓力大，公司只關心最終的價值輸出

服務意識和產品思想的培養

• 大數據平臺服務能力的評估標準
  • 大數據平臺團隊的職能定位
    • 在有些公司，只負責基礎組件的開發和運維，爲業務方提供SDK、組件套餐或集羣形式的服務
    • 在有些公司，基礎組件之上的工具、平臺等，都由專門的工具團隊負責，層層分工，團隊之間較差服務。
    • 在有些公司，不同事業部團隊會自行在基礎平臺組件之上，各自垂直地構建獨立的業務系統，平臺基礎組件開發者服務與上層業務系統開發人員
    • 在有些公司，大數據團隊從下到上全鏈路通吃，從集羣運維一直負責到最終具體終端業務數據的產出，對終端使用數據的用戶負責
  • 打通上下游系統和業務流程的能力
    • 後端集羣流量／負載的反饋控制能力 。
    • 和腳本集成開發環境的對接。
    • 和權限系統、數據訂閱管理體系的連通。
    • 和元數據血緣分析系統的對接。
    • 和任務測試/發佈環境的對接
    • 與報警、值班、監控系統的協同
    • 和其他非大數據類業務自身的工作流管理體系的聯通能力
    • 和數據質量管理系統的系統能力

服務意識和產品思想的培養 — 滿足用戶真正的需求

• 用戶需要的是穩定、可靠、高效地存儲數據，只要滿足性能指標，他們其實並不關心底層使用的是hdfs、HBASE，還是你自己研發的分佈式存儲系統
• 用戶關心的是高效低成本的開發業務，鑽研和學習各類計算框架並不是他們的初衷
• 用戶在意的是方便、快速地查詢到想要的數據，結果便於理解和溝通，能夠有效地支持業務決策。

服務意識和產品思想的培養 — 認清服務的代價，做好心理建設

• 由儉入奢易，由奢入儉難
  • 首先，你要明確你所提供的服務的範圍定義和質量約 定 。
  • 然後，要儘早和用戶達成一致 。 如果可以，對用戶使用對應服務時應該承 擔的責任，也需要提前明確進行溝通。 作爲乙方，這有時候可能很難做到，但 必須要往這個方向去做 。 這麼做，不是單純地爲了降低用戶的期望值，而是爲 了統一認知一一凡事不怕標準高，就怕標準不一致 。
  • 作爲服務提供方，需要明確地告知用戶，你所提供的服務能做 什麼、不能做什麼、將來的計劃是什麼、用戶在使用過程中需要注意什麼，甚至可以包括用戶對我們的承諾和應盡的責任 。 如果用戶在使用你的服務之前或 過程中明確知道這些信息，那麼與用戶的溝通過程或許就會順暢很多。
• 服務口碑取決於服務最差的環節
  • 注意管理好用戶期望和 引導用戶，不要盲目地被用戶牽着鼻子走。至於最終的口碑，由它去 吧 ，那不 屬於你可以隨意控制的範圍。
• 服務越多支持的代價越高1. 一個系統服務難免會有 Bug， 也總會有不夠靈活的地方 ，提供的服務越多 越全面， 日常維護的代價就越高 。
  • 用戶在使用服務的過程中遇到的問題，很多時候未必是系統自身邏輯的問 題，也可能是使用姿勢問題、業務邏輯問題等 。
  • 事實上，在多數情況下，不是用戶懶，而是他們不具備解決問題的能力， 沒有足夠的知識儲備。又或者即使他們具備相關的知識能力，也可能在出現問 題時，因缺乏明確的故障反饋、無法查看問題日誌、沒有性能數據、缺乏修復 的手段等各種原因，而不得不依賴服務開發者來幫忙定位和解決。
  • 我們需要考慮將運維手段工具化、 最佳實踐文檔化，降低用戶自主定位和解決問題的難度：更理想的做法是可以通過構建一個專家系統來幫助 缺乏經驗的用戶發現和診斷問題。
• 需求響應要疾如閃電，功能服務要天長地久1. 需求快速響應，功能長久不變
  • 如果可能，制訂班車式開發計劃，按固定的週期和預訂的計劃更新系統和服務 ， 如非特別必要，不做計劃外臨時更新 。
  • 進行服務變更和系統更新迭代等時提前和用戶溝通， 就可能造成的影 響明確告知，寧濫勿缺 。這本質 上還是一個用戶預期管理的 問題。
  • 對用戶可能造成較大影響的變更，確保你有灰度發佈和回滾的方案。
• 既要馬兒駝得多，還要馬兒不摔倒1. 系統穩定和需求快速響應的矛盾
  • 這同樣是一個預期管理的溝通問題，也叫向上管理，只不過面向 的對象是 老闆。
  • 我個人還是傾向於要堅持特定的原則一－把團隊的利益放在自身利益之 上。 如果有壓力 ， 不要簡單地做二傳手向下傳遞壓力，別把問題和責任拋給團 隊， 而是面對問題，把目標和方案拋給團隊。另外，遇到難題時，還要適當反 饋客觀存在的困難，比如：“老闆，招不到人啊，這活沒法幹”之類 的 。總之， 不求老闆舒坦，但求問心無愧 。
• 用戶的服務訴求各異，衆口難調1. 不同的需求之間互相矛盾
  • 凡事可以堅持原則 ，但是沒有必要苛求立場。
  • 需要多動腦筋，多溝通，多講道理。沒有必要追求大家對所 有工作真心贊同，而是要求同存異，解決核心矛盾，尋找一個雙方都可以接受 的妥協點。這個妥協點一定存在，如果沒找到，不是方案還不夠好，還有改進 的空間，就是溝通不充分，道理沒有講明白。
  • 服務從來都不是一件單向承諾 的事情。選擇什麼樣的路線，以什麼樣的方 式對待大數據平臺的用戶，遇到問題時如何解決，其實都是可以選擇的。關 鍵是作爲開發者，需要明確自己所做的每一個選擇的理由，積極地面對問題， 關注解決方案，並與用戶保持緊密聯繫，積極溝通，爭取得到用戶的理解和 支持。
• 提供服務那麼難，爲什麼我們還要做

服務意識和產品思想的培養 — 尋找解決服務代價問題的方案

• 首先，系統組件設計，需要考慮通用性，設計難度相對較大，系統成型比較慢，業務價值產出的壓力很大。
  • 在開發之初，也需要面向一個具 體的業務，最好上線之初就帶上一個真實 的業務 。
  • 帶着具體業務的痛點問題來做開發，在此基礎上考慮如 何構建通用的解決方案來適配其他業務。採用“通用＋適度”定製的方式快速推 進平臺的構建，不怕做得不夠通用，就怕通用到過於抽象，沒有業務可以快速 適配 。
• 其次，相對於一站到底的垂直系統，在組件服務式構建的系統中，各個系 統之間的依賴關係相對複雜，選代演進的時候負擔較大。
  • 適度地拆分服務，做到鬆輯合強內聚， 一定是服務建設的首要 目標。
  • 要儘量考慮保障系統具備灰度發佈的能力，組件依賴多 ，出問題難 以避免； 關聯繫統多 ， 系統更新可能也無法一蹦而就，那就需要儘可能降低變 更過程的風險，用灰度的方法去做局部驗證，控制風險範圍，知錯就改，別做 一錘子買賣。
  • 敏捷開發的目標就是不做過度設計， 而是按需快速構建系統 。但要平衡好設計 、實現和重構的代價。
    • 我們能做的就 是做好各個服務組件的模塊化工作，提供所依賴功能的插件封裝機制，適當考 慮向後兼容的可能性，以及降低系統的禍合度。
    • 不只是代碼 的精合，硬編碼依賴系統的地址之類問題無疑應該避免，更難的是要避免業務邏輯流程上的過度搞合。
• 最後，對具體業務場景定製程度較低，整體易用性相對較差，使用成本 較高。
  • 對於一個 通用平臺，或者不能滿足業務方的定製需求，被業務方抱怨流程長、操作複雜、 交互不友好、開發效率低 ；
  • 或者把各種需求都集成進來 ，但是一堆旨在提供便 捷的功能反而很容易讓系統變得更加複雜，最終的結果就是導致整個系統瞬腫 不堪 。
  • 這個問題更多時候無關服務，而是一個產品設計問題，不過從服務路線 的角度來說，一種可行的方式是針對具體業務的 場景需求，在通用服務的基礎上二次垂直封裝，適度定製和簡化業務流程。從 通用服務衍生出 專用服務，來屏蔽和特定業務場景無關的系統複雜性。不過代 價當然也是有的，那就是你又多了一個系統，又多了 一層依賴關係需要維護。

服務意識和產品思想的培養 — 大數據平臺的產品化思想

• 概述
  • 服務化的本質思想是幫用戶解決問題 ， 是"爲人民服務"的態度在你的平臺中的具體化體現。
  • 產品化，關注的重點是大數據平臺所提供的服務的具體內容是什麼， 展現形式如何，能不能吸引用戶 。 再說得直白一點 ： 有沒有價值，或者說作爲 商品，我們提供的服務能否賣得動，能否賺錢？
• 從用戶體驗的角度談產品設計
  • 核心思想
    • 別讓用戶有挫敗感
    • 提供差異化、階梯式的產 品服務
    • 構建反饋式的產 品服務
    • 確保你的產品具備可持續改進的能力
  • 你愛用戶， 用戶卻不愛你問題的重 點是 ： 別讓新用戶有挫敗感 ！ 至少， 在他嚐到甜頭之前不要有挫敗感。比如說文檔對於小白來說，不具有可操作性
    • 不要認爲用戶和開發者一樣具備所有的背景知識， 用戶的環境設定和你的一致 ，想要更好地減少用戶的挫敗感，一個小白用戶的角度，完整地去體驗自 己的產 品和服務 ，發現和思考需要改進的地方。
  • 提供差異化、階梯式的產品服務用戶的需求是多樣化的， 能吸引用戶羣體 A 的產品， 未必能滿足用戶羣體 B 的 需求， 比如讓熟練的專家級用戶滿意的產品設計， 對於剛入 門的小白用戶來說， 學習門檻可能就會太高 。甚至 同樣的用 戶 ， 求也可能是不同的 。
    • 要麼針對用戶各自的訴求， 提供差異化的服務 ；
    • 要 麼根據用戶不同的知識背景， 提供抽象程度不同的服務， 不要企圖用同一個產品覆蓋所有需求。
    • 提供簡易操作版和深度定製版
  • 構建反饋式服務
    • 比起響應遲鈍的系統，更讓人崩潰的是完全沒有響應的系統。至於以什麼樣的形式反饋給用戶 ， 是界面變化、彈窗提示、引 導查詢、定時提醒，還是放在一個角落讓用戶自己發現，這就要因地制宣了 。
  • 確保產品實現可持續改進
    • 要確保產品可持續改進，收集用戶意見固然重要，但這往往是不夠的。你 需要主動收集產品使用過程中的相關數據和信息，除了 一些客觀指標，比如運 行／加載／響應時間、服務負載、流量 QPS 、錯誤統計，還可以包括系統交互是否 流暢、哪裏用戶容易犯錯、哪裏容易導致用戶流失，以及用戶訪問頻率和複用 率之類的數據 。
• 從價值和利益的角 度談產品思維