w

您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  要资料 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
在DevOps产品的设计和研发中,我曾犯过的6个错误
 
作者:顾伟 来源:mp.weixin.qq.com  发布于  2017-3-28
416 次浏览     评价:      
 

这10年来我一直从事中间件产品研发,从以前的UI设计器、开发工具到现在的大数据、云计算等,遇到的挫折其实并不多。但去年的DevOps产品研发,最终成果很难令人满意,到底是什么问题导致?凡事都讲天时地利人和,产品研发亦然,而作为DevOps产品架构设计者,我到底犯了哪些错误?在此,我会从架构、技术、团队等方面进行问题剖析、总结,希望能与各位大牛产生共鸣。

从去年6、7月份开始,我相继研发了普元新一代云平台(The Platform)0.1,0.2版本,预计今年年底会发布1.0版本。前两个版本都是围绕DevOps、CaaS、MicroService三个业务进行研发的,版本虽然已发布,但离既定目标尚有不短的距离,回过头来总结,我在总体设计这块犯下了6个错误,在这里与各位分享,希望能产生共鸣。

这里通过一张图,简单介绍一下平台架构:

产品以容器作为底层资源管理支撑,微服务架构作为运行支撑,形成了以三类PaaS(集成类、流程类、数据类)作为运行环境,DevOps作为全生命周期自动化支撑的云平台。

对于我们来说,希望做的是大生命周期的支撑,所以对于DevOps产品的定位如下(从产品定义到最终上线运维):

OK,回归主题,不知道各位在做大型产品的总体设计时,一般思路是怎样的?我们当时从五方面着手:

1. 概念先行。从概念模型着手,梳理产品中的核心实体对象,DevOps平台的核心是开发交付和运营反馈,具体如下:

2. 场景驱动。对DevOps业务场景进行梳理,定义平台相关角色,定义主流程。DevOps平台通过分工协作与质量管控,力求全生命周期的自助与自动,具体如下:

3. 模块划分。定义平台子系统(微服务),我们在设计时,一则是想DevOps平台本身采用微服务架构,二则是DevOps平台支撑微服务运行,最终平台形成了10个左右的子系统,具体:

上图的几个简写术语:SRM-软件资源管理,SPM-软件产品管理,SEM-软件环境管理,BPR-二级制仓库,DPR-可部署包仓库。

4. 团队分工。团队这块的划分采用了两个维度,一个是子系统责任制,一个是技术分层,将团队个人特长最大化,具体如下:

5. 规范约束。处理一些管理过程规范外,在开发规范上,定义了子系统之间的边界规范,以API和SPI的模式来实现,每个小团队与上下游团队共同制定和review接口设计,具体如下:

上面的配图是一些草图,不太严谨,我之前在另一个群分享过我们平台的总体设计,大家若对材料有兴趣,可联系我,也可从我们的公众号上获取。

从大面上粗看貌似没什么问题,但大家或许心里已经有疑问了,比如说:

数据模型在哪儿?DevOps平台本身讲究工具链的整合,对于扩展性,尤其是数据库的扩展性设计要求非常高(大家有时间可看看Team Foundation Service、Rational Team Concert这些平台的扩展性设计,非常不错)

DevOps平台本身采用微服务架构,同时支撑微服务在上面运行,难免会陷入一个鸡生蛋、蛋生鸡的问题,如何解决?

开发架构上只是定义了一些子系统边界,对于DevOps平台具体的依赖产品或框架是怎么制定标准的?

团队分工采用了两维设计,一些两维度冲突的地方是怎么解决的?

……

是的,这些都是问题,也正是这些问题以及我的经验不足,让我犯了标题中提到的6个错误:

错误1:概念耦合。最典型的就是没有将DevOps、CaaS、MicroService拆分开来看。

这是现在业界的一个普遍现象,大家会看到,很多人把微服务,Docker,DevOps都放在一起谈。比如下面这些大会分享上的截图:

当然不是说这些作者本身概念混了,而是说现在的很多讲法,容易造成读者的误解。

事实上,这三者是独立的三个领域概念,DevOps的本质是:

而微服务是一种架构风格,难点在于开发规范与运维支撑。而容器呢,可以这么说,微服务架构给容器技术的风靡加了一把火:

所以,这三者完全是可以分开建设的,DevOps平台更应该关心多工具链及应用整合,异构环境的统一管理,流程的驱动支撑。

第一个错误给我的启示是:概念模型需要从领域着手,多领域需严格分开,当然,这也符合时下DDD倡导的设计模式。

错误2:关键设计未集中来做。最典型的问题就是数据模型(ER)的设计下放到每个子系统去设计。

业界现在有很多总体设计的方法,比如4+1模式(一般不带数据架构)、再比如togaf模式(一般包括数据架构),其实最关键的是哪种最适合现在的产品及团队。当时拆成小团队后,把数据模型的设计完全交给子团队在详设里去做了,造成了诸多设计不一致性。大家都知道,在DevOps这样的很难标准化的平台中,数据模型的扩展性设计要求非常高,比如对横表、拉链表、历史表的使用会特别频繁。

再者还有些细节问题,总体设计虽然定了表命名、列命名、主键类型、索引策略等规范,但是还是出现了一些问题,比如同样是某个实体的唯一代码,这边叫ID,那边叫CODE,还有两者做冗余都有的,造成API参数传递时,尤其是跨子系统传递时,参数命名很不一致,再者就是下游往上游系统返回数据时,上游系统还要做额外的映射处理。

第二个错误给我的启示是:在一些传统的管理域系统中,像ERP,OA这种,数据模型往往是重中之重,必须集中来做,完全扁平化的设计下放,是一个风险非常大的行为。

错误3:MVP未深思熟虑,未采用最工程化方式来实现。

这应该是我最大的一个错误,对MVP的理解过于肤浅。MVP一般有很多路可走:

比如:你要解决交通问题,那可以先造一辆自行车,再造一辆三轮车,再造小汽车……

再比如:同样你要解决交通问题,你可以先造非常裸的小汽车(四轮子、发动机、无内饰、无空调、手动等),然后逐步加配件、升级系统……

上述的两个都是MVP,但却完全是不同的执行路径。所以对于DevOps平台的MVP之路,应该是什么样子?

我之前的理解:先做了一个比较裸的微服务框架,包括rpc调用,服务注册与发现,上下文处理,token处理等,基于这个框架来进行DevOps平台开发,同时在DevOps平台研发中,先做产品管理、持续构建和持续发布。

但上述这个做法忽略了一个关键问题,我们的最终目标是DevOps的全生命周期支撑,到底是先做生命周期中的部分阶段,还是先完成整个阶段的驱动,再丰富每个阶段的血肉。

现在看来,全生命周期打通才是最重要的,定义阶段与阶段间的输入输出,也许某些阶段还是手工方式,但不影响整个DevOps的理念的渗入和逐步精益的大原则。

同时,大家知道,作为第一个版本,采用一个全新的架构,而且是还不完善的架构(比如缺了微服务架构的数据一致性支撑能力),风险是很大的。更何况我们普元做了16年的中间件,很多技术平台和框架的积累,在DevOps产品研发中都没有使用,而是采用了纯开源模式新做,这一点大大违背了IT工程化的建设思路。

第三个错误给我的启示是:MVP并不是功能的MVP,是实践之路的MVP,每个产品都有自己的最核心理念,再小的MVP也要能阐述理念。MVP的实施要用最稳妥的方式,切勿激进,市场、尤其企业市场绝不会像很多互联网宣传那样,给你试对试错的机会,即使你的速度和反应再快也不会。

错误4:没有引入流程引擎作为底层支撑,更何况是我们有流程引擎成熟产品的前提下。

现在谈DevOps平台的最佳实践维度,很多会用这张图:

不难看出,流程部分是非常重要的部分,其实引入流程引擎的好处,不仅仅是用来做简单的状态流转(比如bug、任务等),更可以用流程引擎来编排不同子系统提供的能力,即使编排的都是自动活动。因为:

首先,流程引擎一般本身提供足够的API能力,统计分析能力,适配能力等,为后续优化、反馈、变更提供了足够的底层支撑。

再者,从扩展性来考虑,举例子,同样做敏捷,Agile、Scrum、CMMI流程,以及其workitem状态流都是有区别的,如果通过对各个模式的硬编码,后续的变更是非常麻烦的,同时还要建立在对这些模式的充分理解的前提下(说实话,现在的很多模式分支实在太多了),而流程的好处在于快速调整适应,同时,即使流程定义后变更很难,还可以用自由流等手段来实现,一般现在的流程引擎都是有自由流能力的,以前做过厂商,这种特殊能力通过编码实现的话还是非常难的,很难做的完善,尤其上下文的管理。

第四个错误给我的启示是:DevOps产品(这里说的是产品,不是某个企业的特定项目),一大难点在于流程差异性的屏蔽和流程快速调整的支撑,大到企业部门间协作流程,小到活动状态流转,所以流程引擎的引入会对产品的持续发展提供积极作用。

错误5:康威定律的实践问题,异地团队与子系统的结合方式有些欠妥。

以前一直和别人说康威,做着做着才发现自己的理解是多么片面。先说下我们的团队情况,我们的研发团队分在西安和上海两地,有一段时间甚至是三地(还有北京),整个团队偏新,之前共事较少。

在出现异地的时候,其实技术特长不应该作为分组的首选条件,因为这样很可能会出现某个小团队跨两地,这是一个很不好的状态,因为沟通才是异地的最大挑战。所以在分组之初,尽可能让异地的交集工作最少、沟通最畅,最理想的情况是做到两地分别只有一个接口人,其余人完全不存在异地沟通。

第五个错误给我的启示是:单管道模式虽然有瓶颈,但比起多管道模式来说,更易治理,所以异地协作我更推崇单管道模式。

错误6:架构师的参与度不足。

总体设计离最终落地往往都还有一段距离,这个距离是需要架构师在后续过程阶段去弥补的,这就是概念到落地的距离,也是很多架构师的瓶颈所在。

一个很形象的说法,架构师是做拍板的,要对任何决定负责。说这句话突然想到了最近的美国大选,从两个候选人的辩论中,感觉都挺缺乏担当的,呵呵,扯远了!

许多细节的设计是要逐步完善的,举个我们做的不好的例子,在Git库主干与分支的使用模式上,我们在前期VCS子系统设计时就没有考虑清楚,当时只考虑了常用TBD模式的支撑,后续架构师在这个子系统上的投入太少,使得后续在对客户需求的应答上能力缺口太大。既然提到版本控制库使用问题,有不少不错的blog大家可参考,比如阮一峰大侠的:http://www.ruanyifeng.com/blog/2012/07/git.html

这里我有两个建议:

首先,架构师不要过早撤出项目。当然,很多架构师可能身兼数职,在某一个具体项目中的投入很难保障,如果是这样,只能说高层对这个产品的重视度不够,或者这根本就不是个明星产品,其造成风险会很大。

其次,架构师尽可能参与核心部分开发。前段时间圈里总是在吵CTO该不该编码的问题,我个人觉得CTO可不参与,但架构师还是要参与的,不能只是简单的预研、设计、验证等工作,容易造成与实际落地的脱节。

第六个错误给我的启示是:架构师作为现代IT中一个蛮有争议的角色,需主动寻求更多的价值点。而在DevOps产品研发中,作为架构师,需非常了解各工具链原理、整合方案等,才能有机串联整个平台。

现在,我们1.0版本的研发中,做了这样的一些调整,来应对上述的一些发现的问题。

组织架构的调整,拆成了独立的三部分来做,分成DevOps团队、容器云团队、微服务团队。

引入EOS(开发平台)、BPS(流程引擎),支撑平台下一个MVP的工程化交付。

概念模型到数据模型的总体设计,将DevOps分为产品管理、项目管理、交付中心、代码&构建、权限管理五部分。

不再自己杜撰需求(当然之前也不是杜撰的,只是与实际结合还不够紧密),结合灯塔客户的具体需求与状况,来辅助完成产品研发。

团队分工,异地做一定牺牲,前期需求与设计阶段在一起办公,同时独立分出架构师,全职参与DevOps产品研发和实施。

对今天的分享做个总结,在DevOps产品研发中,因为总体设计不够充分,技术选型过于激进,对异地团队协作的困难预估不足,本身的参与度不够等问题,使得产品质量目标未能完全达到。目前已通过一定手段有效解决,并希望通过灯塔客户需求的实施,完成产品能力的改造与完善。

 

   
 订阅
  捐助
相关文章

DevOps转型融入到企业文化
DevOps 能力模型、演进及案例剖析
基于 DevOps 理念的私有 PaaS 平台实践
微软开发团队的DevOps实践启示
相关文档

DevOps驱动应用运维变革与创新
运维管理规划
如何实现企业应用部署自动化
运维自动化实践之路
相关课程

自动化运维工具(基于DevOps)
互联网运维与DevOps
MySQL性能优化及运维培训
IT系统运维管理
 

itil五大流程图
ITIL流程管理六步走
使用ITIL V3作SOA治理的基石
IT服务管理的实践与总结
借鉴ITIL架构理念提升信息化
ITIL流程总结
更多...   


基于ITIL的IT服务管理
ITIL认证
ITSM/ITIL基础
IT规划管理
IT外包管理
IT成本管理

中国移动通信 网络规划与管理
某航空公司 IT规划与企业架构
某金融公司 IT服务管理(ITIL V3)
中国联通集团 IT前沿知识概述
中海油 企业IT架构设计
更多...   
 
 
 

 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号