如何從零開始搭建一個技術平臺

鄭昀 建立於2016/3/30 最後更新於2016/4/8

關鍵詞：技術預研課題，平臺設計，應用場景，故事，信息架構，業務流程，數據流程

---

本文檔適用人員：全體研發

提綱：

1. 如何從零開始搭建一個技術平臺？

2. 應用場景其實就是咱們的願景

3. 從應用場景推導出故事

4. 從故事推導出信息架構和業務流程

---

一，如何從零開始？

若是讓你把下面這套技術體系串聯起來，從零開始構建一個技術平臺，你如何作需求分析呢，在沒有產品經理幫助你梳理的狀況下？

 

下面這些系統涵蓋了咱們研發測試運維平常工做的方方面面：

1. idCenter：它定義用戶、用戶組、權限。研發測試都有了惟一的身份和權限集合，貫穿全部系統。

2. iDB：數據庫自動化運維繫統能把數據庫建賬號、授予權限、建表、改表結構、刷庫這些平常操做都變成流程，DBA審覈經過後就能夠自動執行，以及自動回滾。

3. Touchstone：容器私有云的管理控制檯，管理鏡像庫、應用、容器、主機等。平常發佈就在這裏作。

4. JobCenter：定時任務調度和管理。

5. Summoner：大型計算任務的調度和管理。雲縱佣金計算就是在這上面跑的。

6. Notify：異步消息可靠推送。全部的異步消息都走這個中間件。

7. Discache：管理memcached和redis。

8. OAP：運維自動化系統。主要是資產管理、資源管理和發佈。

9. Secret：天機和鷹眼。數據庫、Java、PHP、業務指標，監控報警都作進來了。

 

你就是一個說故事的人，爲了保證你們對故事的理解沒有誤差，因此你們『都但願你說得具體點兒（User Story），把故事落實在產品的需求點（Product Backlog），而後在這些需求點裏面排出優先級（Sprint Backlog），而後排出版本（Version），這樣兄弟們作開發和不斷燃燒（Burn Up）』。[注1]

即，

/*

先有場景， \

再有故事， \

經過故事拆解出信息架構，即菜單結構和功能點， \

最後納入某個版本， \

在全部的故事、功能點和版本都肯定以後，咱們就進入不斷的排序優先級和循環的過程。

*/

 

二，何謂應用場景？

你們也許會注意到，當我發起技術預研課題時，我一般都會給出我想象中的、心目中這個課題的願景，以一個目標用戶是如何使用這個平臺的應用場景的方式。

 

譬如說：

本地生活服務商戶「魔鏡」計劃 願景： 爲公司分銷、共創和運營的決策提供門店數據支撐，提供（自助）可視化數據和自助數據查詢能力 應用場景舉例： 場景一： 開站決策支持：哪些城市值得開站，哪些不值得？ 背後的數據支撐： 開展過互聯網營銷服務而且經營得尚可的門店清單以及銷售狀況 場景二： 餐飲和美業品類下，優先向哪些商戶推縱橫客？ 背後的數據支撐： 門店的地址電話，用戶活躍度，門店星級，團購和外賣商品數，折扣領取次數等

這就是願景和場景。

 

咱們對於上游業務部門流轉過來的需求，也必須熟練運用下面這種逆推能力：

先構造出合乎邏輯的多種應用場景，而後回頭審視本身的概念設計、功能設計、信息架構設計是否正確。若是你的表結構等設計不符合這些應用場景，一定是你的設計不對。

WHY？

不合邏輯，必有問題。

 

再舉一個應用場景例子：

預研課題：CloudEngine

場景CE-main-004：服務器申請

服務器申請的步驟有： 選擇應用 選擇虛擬化技術（注：即容器仍是虛擬機） 填寫節點數 修改應用配置（注：可選） 分配服務器 服務器初始化 添加監控等各類運維基礎設施 部署應用 checkservice等自檢 收集監控數據 服務器申請成功提示 使用者：研發經理，配管，SA 目的：既能在環境初始化時解決 stable 環境的發佈，也能在環境就緒以後新建臨時應用時的服務器申請和發佈。

有了應用場景，就能夠針對不一樣的用戶設計故事。

 

三，從應用場景推導出故事

順着場景展開，就能夠獲得一個又一個的故事。

 

譬如說，對於上面的場景，咱們能夠針對用戶「研發經理小丁」來設計 User Story，咱們看到了什麼，操做了什麼，又獲得了什麼結果：

對應的場景：場景CE-main-001，登記和維護應用

用戶：研發經理小丁 故事CE-main-001-story-01： 小丁 CE 登陸CE，從左側菜單「應用管理」，選擇「應用列表」 展現登記備案的應用清單。 列表展現，字段有： 應用中文名 應用codename 應用類型 應用領域 代碼倉庫 狀態 建立人，建立時間 最後一次維護人，最後一次維護時間 更多操做 本列表頁能夠按應用類型篩選。 」更多操做「區域裏有如下操做入口： 編輯 刪除 點擊列表頁上的「新增應用」按鈕 應用元數據字段有： 應用中文名 應用codename 應用描述 應用類型 應用領域 代碼倉庫 應用配置信息 默認訪問端口 狀態：啓用/禁用 點擊新增應用頁上的「保存」按鈕 生成新應用，提示保存成功，一段時間後跳轉回列表頁

越細越好，越有助於設計頁面，理解系統須要提供哪些接口和數據。

四，從故事推導出信息架構和業務流程

順着故事，咱們能夠假想出人們是怎麼抵達這些故事的。與此同時，即便是同一個應用場景，也會有多種進入途徑。

譬如說，小丁同窗既能夠在首頁的工做臺上進入應用維護功能，也能夠在二級菜單上找到對應的入口。以下圖所示：

 

經過上圖，咱們能夠整理出信息架構： 

• 首頁（工做臺）：應用快捷入口，環境快捷入口，……

• 應用管理-應用列表（建立應用、編輯應用）

• 環境管理-環境列表（公共配置查看、公共配置編輯）

故事越寫越多，進入途徑梳理清楚以後，咱們就能總結出須要哪些 Dashboard、一級菜單、二級菜單，進一步還能整理出業務流轉流程。

 

以上這種思考問題和推演方法，有助於咱們從零開始，一點點切入平臺，而不是像下面這樣「拍腦殼」地逆向設計：

1. 先構想一級菜單和二級菜單

2. 再構想菜單點擊以後須要實現的功能點

3. 最後在作頁面組織

 

咱們的技術預研課題通常都圍繞着這四個核心概念：

1. 資源 

2. 數據 

3. 流程 

4. 操做 

開始構建一個體系。

咱們順着 場景——>故事——>信息架構——>業務流程——>版本——>功能點，就能夠把咱們所掌握的資源（虛擬機集羣、Docker集羣、物理機、……），外界採集的數據（組織架構、員工信息、有效門店、交易……），業務流轉的流程，各個部門的操做，順利地結合起來。

注1：

這段『User Story-Product Backlog-Sprint Backlog-Version-Burn Up』的文字出自於《產品的視角：從熱鬧到門道》（百度產品架構師魯克著）。

 

延伸閱讀：

技術高手如何煉成

 

技術平臺方案集：

#研發解決方案#分佈式並行計算調度和管理系統Summoner

#研發解決方案#iDB-數據庫自動化運維平臺

#研發解決方案#基於Apriori算法的Nginx+Lua+ELK異常流量攔截方案

從宏觀到微觀——天機與鷹眼聯手

#研發解決方案介紹#Tracing（鷹眼）

#研發中間件介紹#異步消息可靠推送Notify

#研發解決方案介紹#IdCenter（內部統一認證系統）

#研發解決方案介紹#基於持久化配置中心的業務降級

#研發中間件介紹#定時任務調度與管理JobCenter

#研發解決方案介紹#基於StatsD+Graphite的智能監控解決方案

#研發解決方案#discache-分佈式緩存查詢與管理系統

#研發解決方案介紹#基於ES的搜索+篩選+排序解決方案

#數據技術選型#即席查詢Shib+Presto，集羣任務調度HUE+Oozie

 

-EOF-

歡迎訂閱個人微信訂閱號『老兵筆記』，請掃描二維碼關注：