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

时间：2016-04-15 12:17:28 阅读：189 评论：0 收藏：0 [点我收藏+]

标签：

关键词：技术预研课题，平台设计，应用场景，故事，信息架构，业务流程，数据流程

本文档适用人员：全体研发

提纲：

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

应用场景其实就是我们的愿景

从应用场景推导出故事

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

一，如何从零开始？

如果让你把下面这套技术体系串联起来，从零开始构建一个技术平台，你如何做需求分析呢，在没有产品经理帮助你梳理的情况下？

下面这些系统涵盖了我们研发测试运维日常工作的方方面面：

idCenter：它定义用户、用户组、权限。研发测试都有了唯一的身份和权限集合，贯穿所有系统。

iDB：数据库自动化运维系统能把数据库建帐号、授予权限、建表、改表结构、刷库这些日常操作都变成流程，DBA审核通过后就可以自动执行，以及自动回滚。

Touchstone：容器私有云的管理控制台，管理镜像库、应用、容器、主机等。日常发布就在这里做。

JobCenter：定时任务调度和管理。

Summoner：大型计算任务的调度和管理。云纵佣金计算就是在这上面跑的。

Notify：异步消息可靠推送。所有的异步消息都走这个中间件。

Discache：管理memcached和redis。

OAP：运维自动化系统。主要是资产管理、资源管理和发布。

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、一级菜单、二级菜单，进一步还能整理出业务流转流程。

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

先构想一级菜单和二级菜单

再构想菜单点击之后需要实现的功能点

最后在做页面组织

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

资源

数据

流程

操作

开始构建一个体系。

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

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

标签：

原文地址：http://blog.csdn.net/chenning5252/article/details/51155076

踩

(0)

评论一句话评论（0）

分享档案

更多>

2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)

周排行