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

鄭昀（微博：http://weibo.com/yunzheng） 創建於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：服務器申請

服務器申請的步驟有：

1. 選擇應用

2. 選擇虛擬化技術（注：即容器還是虛擬機）

3. 填寫節點數

4. 修改應用配置（注：可選）

5. 分配服務器

6. 服務器初始化

7. 添加監控等各種運維基礎設施

8. 部署應用

9. checkservice等自檢

10. 收集監控數據

11. 服務器申請成功提示

使用者：研發經理，配管，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-

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

轉載時請注明“轉載自旁觀者-博客園”或者給出本文的原始鏈接。