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