普元DevOps5.2版本新特性发布

转载本文需注明出处:微信公众号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)。

原文发布于微信公众号 - EAWorld(eaworld)

原文发表时间:2018-09-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏ThoughtWorks

致测试同仁们:让我们做安全测试吧!|洞见

本文首发于InfoQ: http://www.infoq.com/cn/articles/to-test-colleagues-let-us-do-a-safe...

37840
来自专栏WeTest质量开放平台团队的专栏

月活8.89亿背后:微信工程师细数兼容测试经验

2017年4月,企鹅智酷公布了最新的《2017微信用户&生态研究报告》。报告数据显示,截止到2016年12月微信全球共计8.89亿月活用户,新兴的公众号平台拥有...

17130
来自专栏子勰随笔

SDK之我理解的SDK

314100
来自专栏大数据文摘

超贴心 :一份简单明了的营销分析软件包测评

21950
来自专栏携程技术中心

干货 | 携程运维工作流平台的演进之路

作者简介 徐豪杰,携程旅行网技术保障中心流程工具团队资深软件工程师,于2013年加入携程,主要负责携程工作流平台架构设计与建设,在流程建设方面有着比较丰富的积累...

66690
来自专栏SDNLAB

SDN实战团分享(十四):网络设备自动化遇到的问题与思考

我一直是做网络的,而且是大家常说的物理网工。 干了16年。虽然,刚刚毕业哪会干了几年的DBA 和SA 的工作。后来就一直在做网络。 企业网,城域网,骨干网都算是...

40260
来自专栏java一日一条

并发用户数与TPS之间的关系

在做性能测试的时候,很多人都用并发用户数来衡量系统的性能,觉得系统能支撑的并发用户数越多,系统的性能就越好;对TPS不是非常理解,也根本不知道它们之间的关系,因...

25710
来自专栏云计算D1net

混合云的性能管理状态

混合云的性能管理 如今,IT管理员在如何运行关键业务的工作负载方面比以往任何时候都有着更多的选择。其中包括物理,虚拟,本地,云计算,或一些组合。这就是为什么找...

32950
来自专栏云计算D1net

云原生机制的三个核心思想及其未来之路

摆脱临时性自动化方案之定位,发挥优势以实现可预测功能。 ? 您能否以每周为单位向客户发布各类新功能?甚至进一步达到以每天乃至每小时为单位?新晋开发人员能否在上班...

26940
来自专栏云计算D1net

私有云和混合云成功的四个关键因素

许多企业希望获得云计算基础设施的敏捷性和成本效益,但是在部署实施云计算时,在复杂性和成本方面受到阻碍。此外,企业需要将云部署扩展到任何级别的能力,以及管理许多类...

34680

扫码关注云+社区

领取腾讯云代金券