在DevOps产品的设计和研发中,我曾犯过的6个错误

2年前

能否与你产生共鸣?

blob.png

这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接口设计,具体如下:


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

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

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

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

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


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



      作者介绍

      EAII-企业架构创新研究院 专家委员

      现任普元软件产品部主任架构师,先后参与华为,中信银行,工商银行,中航信,阿里云,兴业银行等客户定制项目。擅长OSGI,eclipse插件,web前端,云计算,CI/CD等领域技术,对新技术有着浓厚的兴趣。


      EAII(Enterprise Architecture Innovation Institute)企业架构创新研究院,致力于软件架构创新与实践,加速企业数字化转型。

      eaworld项目(微信号:eaworld,长按二维码关注)

      262220453591075131.jpg

      eaworld是EAII的官方微信账号。



COMMENTS

需要 后方可回复
如果没有账号可以 一个帐号。