转载本文需注明出处：微信公众号EAWorld，违者必究。
作者自白：
伴随新版本的发布，我们团队也对这次迭代做了些回顾，有值得分享的新特性与设计，也有一些需加强的能力，借此与大家分享。
主题大纲：
一、新特性部分
1、安全提升，更细粒度的流程与权限控制
2、企业级中间件支持，更匹配普元现有客户需求
3、全新看板，更精益的度量并指导优化
4、UI大升级，提供To C的互联网体验
5、监控增强，围绕应用视角的运行监测
6、流水线与工单结合，向一体化工作台演进
二、待提升部分
1、自动化测试体系的完善
2、预警能力的建设
3、流水线任务的持续丰富
DevOps产品，从定位上来看，仍旧保持初衷不变，要建立一条从业务需求到最终线上运营的IT生产线。
之前的版本其实已经形成了从项目管理->组件设计->代码管理->持续集成->自动部署->度量优化的能力，所以在5.2版本需求范围定义时，更多的是从流水线丰富、实施模板、API扩展、安全可靠几个方面着手的，在此分享以下6个特性：
特性一：安全提升，更细粒度的流程与权限控制
DevOps平台相对特殊的定位（跨部门、跨环境、长周期）使得平台在安全上需要更加去关注，这个版本从以下三个方面进行了加强。
1、围绕功能码的菜单、操作（API）、环境的三类授权
第一个方面：仍旧是从RBAC着手，考虑到DevOps至少是有两层权限的：
并且在第二层权限中，会随着项目类型的不同，拥有的菜单集、功能集范围也不相同。所以需要在两级都提供面向菜单、功能码、环境的细粒度权限配置能力，才能保证满足各类客户要求。
2. 充分考虑安全隔离、单向通信的部署架构
第二个方面则是部署架构的安全，参考下图：
比如一般企业，开发测试区和生产区都是完全隔离的，介质共享传递更多是拷贝或者堡垒机完成，在DevOps平台上，要注意的就是如何能在最小开放的情况下，完成上述不同环境的完整流水线。
一般来讲我们在客户那边是通过部署多套任务引擎来解决这类问题的，devops门户只与各环境中的任务引擎打交道（相当于拿任务引擎作为agent入口），而不去和各个环境中的其他任何机器交互。
但到了有些客户那边，多部署引擎是允许的，但是必须只是单向通信。考虑到devops一般都会集成不少中间件或开源工具，比如为了实时看到部署的执行状态，需要通过回调接口形成与任务引擎的双向通信，这个就会受到限制，所以又需要其他的部署架构或技术方案来解决，这里就不一一赘述。
3. 其他安全示意
第三个方面，更多的是一些琐碎的安全控制（因为安全这个领域，本来就是琐碎的，要持续修补的，最明显的就是杀毒软件的病毒库）。所以我们平台还做了如下的一些事情，像密码强度、定时备份、审计日志明细化等：
特性二：企业级中间件支持，更匹配普元现有客户需求
第二个特性则是后续的每个版本都会做的，针对不同中间件的集成能力，任务化封装。
毕竟我们主要关注的还是企业市场，企业市场里不可能完全抛弃传统的应用服务器、数据库等。
所以在这个版本里，增加了像ear、数据脚本等CI的能力，同时也补充了weblogic、websphere、oracle存储过程，以及普元自有产品上的发布回退等能力。
不仅仅CICD，产品里还做了传统中间件本身的安装部署运维等能力。
特性三：全新看板，更精益的度量并指导优化
第三个特性是重构了原有项目Issue看板的能力，之前我们更多的是纯粹的集成，比如集成jira、禅道都完全是API导向，在DevOps产品里并没有一套自己的清晰模型，这就使得每次使用标准的变更，都需要对产品进行深度代码定制，非常不友好。
在这个版本里，我们新抽象了模型，抽象的要点包括：
如何保证看板适应不同客户、项目的要求？
将不同的几种项目Issue模型进行抽象，包括看板泳道、issue流转flow、issue的一些状态数据集等。
所以上面这张图无论是泳道、还是具体的story、bug、task的流转与关联，都可以通过模板来进行客户化配置。
看板这块还解决了需求与后续代码、介质的信息断层问题 ：
现在可以通过需求追溯代码提交历史，自动统计一个需求所花的代码行等，并与后续的工件形成关联，为度量提供更多原始数据。
特性四：UI大升级，提供To C的互联网体验
第四个特性则是UI的升级，这里要感谢两位前端同事在短短一个多月，将整个技术栈从NUI（一套基于jquery的UI）彻底升级为基于Vue.js的全新门户。
同时前端提供的很好的动态表单能力，使得以后扩展一个流水线上的任务（包括任务对应的表单、控件、验证、级联等），只要通过配置就可直接展示。
现在增加一个流水线上的任务，前端要做的就是提交图片资源、部分表单控件之间的特殊事件联动处理、再重新打包就足够了。
特性五：监控增强，围绕应用视角的运行监测
第五个特性则是发布后的监控能力，借助我们的微服务、容器云等其他平台，此版本可以看到如下一些监控视图：
这是针对应用产生日志的滚屏展示与检索。
这是对于应用运维的timeline图，以及每次运维操作的具体执行信息。
还有像上图这种，与我们其他平台集成的系统调用拓扑、业务请求链路、进程资源信息、长sql语句等。
特性六：流水线与工单结合，向一体化工作台演进
第六个特性则是一直犹豫要不要做的工单能力，因为在以前的项目实施中，很多企业客户是要求与其ITIL进行集成。但是在最近的几个实施项目里，大家都希望把devops向真正的一体化工作台演进，所以在这个版本中提供了独立的流程任务与工单管理能力。
举个例子，如上图，通过设置流水线上某个环境的审批人（支持多人，比如一般生产环境都要有发布评审与执行审批），最终在执行过程中，会产生相关的工单并通知到干系人，由相关人进行线上审批，触发流水线的继续执行。
目前平台提供的工单包括：项目立项单、代码merge单、环境部署前审批单、环境部署后确认单、人工任务单（用于更细粒度的一些确认事宜）等，且此模块可支持快速纳入新流程与工单类型。
待提升部分
自动化测试：虽然现在平台做过了jmeter、以及我们公司的自动化测试产品（UTP）的集成，但是在一些具体细节上打磨的不够，需要好好考虑测试能力集成的正确模式。
预警能力：平台现在的度量更多是给出结果统计，并没有建立完善的指标预警策略，这块需要形成对应能力（当然，具体指标值是要经过长期运营才能定，我们也只能给出我们公司的参考值）。
流水线任务的持续丰富：每个版本都要持续做的，流水线上任务的丰富，现在虽然各类构建、部署任务都很多了，但是一些细节还不够，就比如应用数据备份、滚动升级过程的流量切换，这些都是要去补充的。
本文分享的相对简单，没有做技术实现的深入，需要了解产品具体能力、功能实现细节的，可通过其他渠道与我们团队建立长期沟通机制。
精选提问：
问1：看板这块还是集成JIRA来做么？
答：现在产品默认带是Jira，刚才也提到了，本次把issue和workflow模型都抽取出来了，形成自己的一套，这样在集成其他的项目管理工具时，就变得相对容易了。在客户那边也已经集成过zentao了，其他几个暂时还没有。
问2：没看到 codereview 部分的细节。请问这个系统中，有 codereview 的位置吗？codereview 对培养工程师编码能力还是非常必要的。
答：codereview确实是很重要的一环，gerrit我们集成过，但没有放在产品中，原因是gerrit的主要是人工+自动的评价模式，流程相对固化。但人工其实通过gitlab flow的merge request等手段已经可以解决，自动通过hook我们也提供了，所以就没有带在里面，而且gerrit的权限管理我们在集成时遇到了一些小问题。所以总得来说，codereview我们同gitlab的一些flow模式支持了，但没有做到gerrit那样的强流程模式。
问3：任务引擎有什么作用么？在网络隔离的时候，安全性是如何保证的？
答：任务引擎是我们的流程引擎+jenkins，网络隔离时，通过开唯一交互端口，并且限进出口流向来控制的，在一个客户那边还使用过专用跳板机。
问4：请问应用服务监控是如何实现的？:
（1）持续集成耗时监控：持续集成各节点耗时，超过阀值告警
（2）服务耗时监控：监控超过指定时间的接口耗时
（3）任务监控：包括单元测试、持续集成等，包括定时任务是否正常发起，发起是否执行成功，主机资源使用情况等
（4）iimp同步监控：监控和iimp交互的数据
（5）可用性探测：通过可用性探测获取服务可用性指标，包括可用时长，不可用时长等
答：这些都要一个个谈了，不太清楚你的现状。持续集成耗时是通过jenkins集成+回调来实现的，jenkins有pipeline的超时设置能力；服务耗时监控是通过我们的微服务平台能力来做的，类Hystrix；任务监控就杂了，主机资源通过zabbix，定时任务目前没有
可用性探测是发布时提供健康探测入口，定时探测，可用不可用是基于定时探测数据来计算，没有那么精确；网络监控和数据同步没有做；接口耗时，histrix就可以，如果是长链路，我们目前是通过skywalking的（APM）。
推荐阅读
关于作者：顾伟，现任普元信息主任架构师，长期致力于IT技术研究、产品设计与开发、架构咨询等工作，擅长Web、OSGI、CI/CD、服务治理、云计算等领域技术；对DevOps、自动化运维、微服务架构有着浓厚的兴趣。
关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享
扫一扫
1388
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
