如何从零开始搭建一个技术平台
2016-04-26 09:53
691 查看
郑昀 创建于2016/3/30 最后更新于2016/4/8
关键词:技术预研课题,平台设计,应用场景,故事,信息架构,业务流程,数据流程
本文档适用人员:全体研发
提纲:
如何从零开始搭建一个技术平台?
应用场景其实就是我们的愿景
从应用场景推导出故事
从故事推导出信息架构和业务流程
一,如何从零开始?
如果让你把下面这套技术体系串联起来,从零开始构建一个技术平台,你如何做需求分析呢,在没有产品经理帮助你梳理的情况下?
下面这些系统涵盖了我们研发测试运维日常工作的方方面面:
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?
不合逻辑,必有问题。
再举一个应用场景例子:
有了应用场景,就可以针对不同的用户设计故事。
三,从应用场景推导出故事
顺着场景展开,就可以得到一个又一个的故事。
譬如说,对于上面的场景,我们可以针对用户“研发经理小丁”来设计 User Story,我们看到了什么,操作了什么,又得到了什么结果:
越细越好,越有助于设计页面,理解系统需要提供哪些接口和数据。
四,从故事推导出信息架构和业务流程
顺着故事,我们可以假想出人们是怎么抵达这些故事的。与此同时,即使是同一个应用场景,也会有多种进入途径。
譬如说,小丁同学既可以在首页的工作台上进入应用维护功能,也可以在二级菜单上找到对应的入口。如下图所示:
通过上图,我们可以整理出信息架构:
首页(工作台):应用快捷入口,环境快捷入口,……
应用管理-应用列表(创建应用、编辑应用)
环境管理-环境列表(公共配置查看、公共配置编辑)
故事越写越多,进入途径梳理清楚之后,我们就能总结出需要哪些 Dashboard、一级菜单、二级菜单,进一步还能整理出业务流转流程。
以上这种思考问题和推演方法,有助于我们从零开始,一点点切入平台,而不是像下面这样“拍脑袋”地逆向设计:
先构想一级菜单和二级菜单
再构想菜单点击之后需要实现的功能点
最后在做页面组织
我们的技术预研课题一般都围绕着这四个核心概念:
资源
数据
流程
操作
开始构建一个体系。
我们顺着 场景——>故事——>信息架构——>业务流程——>版本[b]——>功能点[/b],就可以把我们所掌握的资源(虚拟机集群、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-
欢迎订阅我的微信订阅号『老兵笔记』,请扫描二维码关注:
关键词:技术预研课题,平台设计,应用场景,故事,信息架构,业务流程,数据流程
本文档适用人员:全体研发
提纲:
如何从零开始搭建一个技术平台?
应用场景其实就是我们的愿景
从应用场景推导出故事
从故事推导出信息架构和业务流程
一,如何从零开始?
如果让你把下面这套技术体系串联起来,从零开始构建一个技术平台,你如何做需求分析呢,在没有产品经理帮助你梳理的情况下?
下面这些系统涵盖了我们研发测试运维日常工作的方方面面:
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:
| ||||||||
四,从故事推导出信息架构和业务流程
顺着故事,我们可以假想出人们是怎么抵达这些故事的。与此同时,即使是同一个应用场景,也会有多种进入途径。
譬如说,小丁同学既可以在首页的工作台上进入应用维护功能,也可以在二级菜单上找到对应的入口。如下图所示:
通过上图,我们可以整理出信息架构:
首页(工作台):应用快捷入口,环境快捷入口,……
应用管理-应用列表(创建应用、编辑应用)
环境管理-环境列表(公共配置查看、公共配置编辑)
故事越写越多,进入途径梳理清楚之后,我们就能总结出需要哪些 Dashboard、一级菜单、二级菜单,进一步还能整理出业务流转流程。
以上这种思考问题和推演方法,有助于我们从零开始,一点点切入平台,而不是像下面这样“拍脑袋”地逆向设计:
先构想一级菜单和二级菜单
再构想菜单点击之后需要实现的功能点
最后在做页面组织
我们的技术预研课题一般都围绕着这四个核心概念:
资源
数据
流程
操作
开始构建一个体系。
我们顺着 场景——>故事——>信息架构——>业务流程——>版本[b]——>功能点[/b],就可以把我们所掌握的资源(虚拟机集群、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-
欢迎订阅我的微信订阅号『老兵笔记』,请扫描二维码关注:
相关文章推荐
- 我们应当怎样做需求分析--之一
- 我们应当怎样做需求分析--之二
- 需求分析的定义(转)
- 需求分析的定义(转)
- 需求分析的定义(转)
- 收集需求:知道客户想要什么
- 【P000-000】第一个项目,暂定为android手机上的简单证券交易费计算系统(源码列表统一在此更新)
- 用例描述表
- 功能性需求与非功能性需求
- 我们应当怎样做需求分析
- 需求了解要做什么?
- 需求分析和系统分析的区别
- 软件开发之文档的重要性
- 软件工程---软件需求分析
- 软工学习——文档总结(一)
- 连载:面向对象葵花宝典:思想、技巧与实践(15) - 需求详解
- 连载:面向对象葵花宝典:思想、技巧与实践(16) - 需求分析终极目的
- 连载:面向对象葵花宝典:思想、技巧与实践(17) - 需求分析518方法
- 连载:面向对象葵花宝典:思想、技巧与实践(18) - 用例分析
- 连载:面向对象葵花宝典:思想、技巧与实践(20) - 用例图的陷阱