转载本文需注明出处微信公众号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任务监控包括单元测试、持续集成等包括定时任务是否正常发起发起是否执行成功主机资源使用情况等
4iimp同步监控监控和iimp交互的数据
5可用性探测通过可用性探测获取服务可用性指标包括可用时长不可用时长等
答这些都要一个个谈了不太清楚你的现状。持续集成耗时是通过jenkins集成回调来实现的jenkins有pipeline的超时设置能力服务耗时监控是通过我们的微服务平台能力来做的类Hystrix任务监控就杂了主机资源通过zabbix定时任务目前没有
可用性探测是发布时提供健康探测入口定时探测可用不可用是基于定时探测数据来计算没有那么精确网络监控和数据同步没有做接口耗时histrix就可以如果是长链路我们目前是通过skywalking的APM。
推荐阅读
DevOps 5.0版本的150天历程
万达网络科技的DevOps平台架构解析
DevOps驱动的人保微服务平台建设之路
关于作者顾伟现任普元信息主任架构师长期致力于IT技术研究、产品设计与开发、架构咨询等工作擅长Web、OSGI、CI/CD、服务治理、云计算等领域技术对DevOps、自动化运维、微服务架构有着浓厚的兴趣。
关于EAWorld微服务DevOps数据治理移动架构原创技术分享