如何从零开始搭建一个技术平台？

原文地址：https://mp.weixin.qq.com/s/Oj1EouZjn0gtjr6Gv8biHA

提纲：

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？

不合逻辑，必有问题。

再举一个应用场景例子：

2. 选择虚拟化技术（注：即容器还是虚拟机）
3. 填写节点数
4. 修改应用配置（注：可选）
5. 分配服务器
6. 服务器初始化
7. 添加监控等各种运维基础设施
8. 部署应用
9. checkservice等自检
10. 收集监控数据
11. 服务器申请成功提示
使用者：研发经理，配管，SA
目的：既能在环境初始化时解决 stable 环境的发布，也能在环境就绪之后新建临时应用时的服务器申请和发布。 |

有了应用场景，就可以针对不同的用户设计故事。

三，从应用场景推导出故事

顺着场景展开，就可以得到一个又一个的故事。

譬如说，对于上面的场景，我们可以针对用户“研发经理小丁”来设计 User Story，我们看到了什么，操作了什么，又得到了什么结果：

2. 应用codename
3. 应用类型
4. 应用领域
5. 代码仓库
6. 状态
7. 创建人，创建时间
8. 最后一次维护人，最后一次维护时间
9. 更多操作
本列表页可以按应用类型筛选。
”更多操作“区域里有以下操作入口：
1. 编辑
2. 删除
点击列表页上的“新增应用”按钮
应用元数据字段有：
1. 应用中文名
2. 应用codename
3. 应用描述
4. 应用类型
5. 应用领域
6. 代码仓库
7. 应用配置信息
8. 默认访问端口
9. 状态：启用/禁用
点击新增应用页上的“保存”按钮
生成新应用，提示保存成功，一段时间后跳转回列表页 | | | | —- | —- | | | | | | | | | |

| | |

越细越好，越有助于研发同学设计页面，理解系统需要提供哪些接口和数据。

四，从故事推导出信息架构和业务流程

顺着故事，我们可以假想出人们是怎么抵达这些故事的。与此同时，即使是同一个应用场景，也会有多种进入途径。

譬如说，小丁同学既可以在首页的工作台上进入应用维护功能，也可以在二级菜单上找到对应的入口。如下图所示：

通过上图，我们可以整理出信息架构：

• 首页（工作台）：应用快捷入口，环境快捷入口，……
  
• 应用管理-应用列表（创建应用、编辑应用）
  
• 环境管理-环境列表（公共配置查看、公共配置编辑）
  

故事越写越多，进入途径梳理清楚之后，我们就能总结出需要哪些 Dashboard、一级菜单、二级菜单，进一步还能整理出业务流转流程。

以上这种思考问题和推演方法，有助于我们从零开始，一点点切入平台，而不是像下面这样“拍脑袋”地逆向设计：

1. 先构想一级菜单和二级菜单
   
2. 再构想菜单点击之后需要实现的功能点
   
3. 最后在做页面组织
   

我们的技术预研课题一般都围绕着这四个核心概念：

1. 资源
   
2. 数据
   
3. 流程
   
4. 操作
   

开始构建一个体系。

我们顺着 场景——>故事——>信息架构——>业务流程——>版本以及版本包含的功能点，就可以把我们所掌握的资源（虚拟机集群、Docker集群、物理机、……），外界采集的数据（组织架构、员工信息、有效门店、交易……），业务流转的流程，各个部门的操作，顺利地结合起来。

注1：

这段『User Story-Product Backlog-Sprint Backlog-Version-Burn Up』的文字出自于《产品的视角：从热闹到门道》（百度产品架构师鲁克著）。