返回 登录
1

给DevOps打上最佳实践的标签

阅读979

本文转自微信号EAWorld。扫描下方二维码,关注成功后,回复“普元方法+”,将会获得热门课堂免费学习机会!

本文目录:
一、 再谈DevOps定位
二、谈谈几个实践设计
三、普元DevOps核心

越来越多的厂商开始研发DevOps产品,有的基于项目管理工具衍生,有的从运维工具或容器云过渡,不管怎样,大家都是为了给客户带来一条全新生产线,支撑其数字化运营。

记得2015年初产品刚起步时,我们也是从CICD开始、变更触发代码构建、再到自动化部署到容器云;随着不断地客户实施,普元对DevOps的定位、价值、特性等有了更多的认识,借本篇文章,与大家分享我们的持续认知和改进。

经过一段时间的实施与改进,本月底我们将正式发布DevOps的5.0版本,相比于常规功能,DevOps更重要的是一些最佳实践的引入,真正对企业IT的生产起到精益运营的效果。

一、再谈DevOps定位

之前我们同事已经谈过DevOps的定位,但随着越来越多的交流和实施,我们发现大部分客户会提出这些要求:
图片描述

很显然,这些想法都很实际,又都存在着一些问题,拿第一个说法(给一些工具或系统做统一门户)举例:

很多客户企业确实已经用了不少开源或商业产品,只是现在都是一个个独立存在,没有统一登录、认证,使用起来比较麻烦,所以提出了第一个要求,并认为这就一定程度上实现了DevOps。

但事实上,这个做法对旨在精益的目标来说,显然是不够的:
1. 我们还是不知道某个系统需求最终跑在了哪些机器上
2. 我们也不知道现在并发的20个项目中哪些项目存在风险
3. 同样我们可能基于现有的信息,也不知道敏捷发布火车一年能开几回
图片描述

所以,在我们定位里,DevOps不是简单的集成或整合,而是一条数字化生产线,覆盖从需求到最终运营的全周期;

当然也少不了对于质量、安全方面的支撑,为IT运营提供足够的保障。

想一次性从需求做到运营往往是一个理想,更多的是选择生命周期中最需优化的点来逐步建设,但现在也看到一个现象:

越来越多的厂商开始研发DevOps产品,有的基于项目管理工具衍生,有的从运维工具开始,有的从容器云过渡,有的从开发平台着手,貌似大家把所有工作都归结为DevOps。

显然在定位上犯了一个问题,就像之前很多人说一切皆代码、一切皆*的,而忽略了DevOps的初衷(当然我们不排除丰富一切对IT生产线有用的能力,但不能把一切都强行说成DevOps)。

其实SAFe中给了DevOps一个比较有原则、并且接地气的定义:
图片描述
DevOps重在快速交付,通过将研发管理与部署交付的紧密结合,驱动企业敏捷。

所以,我们应该首先着眼在交付流水线上,通过可视化协同、标准化、一定的自动化等手段,让企业、让团队在流水线上更好的协作。

接着在运营并持续产生数据的基础上,通过各维度的度量手段,快速发现瓶颈,逐步优化,迭代建设并形成企业数字化标准。

绝不是不管三七二十一,上来就买个容器云、或者智能调度、或者自动运维、甚至是不切实际的“零运营”产品,然后考虑怎么迁移。

二、谈谈几个实践设计

回到今天的重点,分享一下我们在DevOps实施中的一些实践设计。

回想起2015-2016年初,我们也很喜欢给客户讲:开发者如何通过提交代码到git,触发jenkins开始构建,打包出镜像,通过与配置管理配合,一键发布到容器云。

就像下面的阿里云的这张图:
图片描述

但是当我们拿着初期产品(可能叫原型更合适),去POC和客户实施时,往往面临的是这些业务问题:
图片描述

比如很多集团要支持二级单位模式,那应该是什么样的部署要求,如何做数据的隔离?

又比如客户办公网和测试网肯定是单向的,那对于自动化测试(尤其是带设备的,比如手机真机测试肯定是放在办公网的),该如何应对自动部署和测试用例的推送执行?

类似问题一实施起来就遇到很多,这个片子先准备了下面几个实践:
图片描述

  1. 刚才一直在说需求跑在哪些机器上,这是个典型的数据打通的问题,或者叫数字化问题,那数据关联我们怎么考虑的

  2. 版本,现在不同于以前单块架构,微服务架构下,有着各类都叫版本的元信息,比如发布版本、api版本、快照版本、产品规划版本等,是否建立了规范机制和关联性管理能力

  3. 看板,做DevOps的自然之道看板的重要性,但不同的角色,期望从看板中看到的信息肯定是有所区别的,该如何设计看板

  4. 租户的问题对于很多大集团运营是不可避免的,平台该如何考虑租户的数据隔离,被集成的系统又改如何配合

  5. 安全,这个领域比较大,我这边谈到的只是平台本身的一些安全处理,应对合规审计等要求

先说说数据关联性处理的实践:
图片描述

要想需求知道运行在哪里,至少必须打通上述的几个环节:

1. 需求到任务的拆分,这个很简单,无论jira、禅道,这都是必须支撑的

2. 任务到编码的关联,或者可以这么说,提交的代码必须知道是完成了哪个或哪些任务,这个有几种实现方式,一则是完成任务时,输入commitid,一则是提交代码时,统一模板,再通过hook将关联关系持久化。显然第二种更优。

3. 编码与构建的关联,本质上是要建立每次构建涵盖了哪些新增的Commit信息的管理,这个也有几种实现方式,一则是编译信息体现到库上,后续远程获取增量,一则是完全自身存储,相当于完全接管commit信息的存储。两者没有太多优劣,都可以。

4. 构建与部署的关联,其实是每次部署关联的工件信息的持久化,这个倒不是难事。

基于上述环节的打通,当然还要把变更、升级等结合进去,想做到信息打通就不难了。

再说一个关联的例子,之前我们有同时讲过我们平台上的部署三部曲:部署设计、部署转换、上线运维。不仅仅是部署,为什么要做在线的很多设计呢?
图片描述

传统模式下,架构师写架构设计文档,包括应用架构、部署架构、数据架构等,但随着项目的执行,后续实际开发、构建、部署和文档上难免有偏差,好像也很少有人再反向更新文档保持所有同步了。

那为何不将设计放到在线,同时提供多版本管理,支撑优化变更,指导后续工作呢?
比如部署架构,后续可生成部署计划;

比如接口设计,后续可查看变更,在线文档化;

比如应用架构,后续指导构建依赖,某个构建应该触发哪些构建;

这就是我们为什么要把设计阶段很多工作在线化的关起来的原因,做到各阶段的关联性驱动和管控。

接着说说第二个实践,现在对于版本这个词的管理,比以前复杂太多了:
图片描述

记得万达客户实施时,客户自身就把这些版本规则、信息等做了严格的规范,什么地方用几位表示,何时变更。

那对于DevOps平台来说,重在建立关联信息的看板,为不同的角色提供不同的信息图,看板的实践中正好也提到了一些版本的问题。

我们就接着来说说看板的实践,很多人第一反应是需求或任务看板,这个当然是必须的,不过可视化协同的不仅仅是需求或任务,很多信息都需要看板的方式呈现。

比如:
图片描述
这是面向交付的看板,可以清楚的看到本次发布到底已经过了哪些环境的验证,最终走到PROD的,事实上就是发布的版本。同时对于发布的版本,内部对应的组件(或服务)具体的版本是什么,也要呈现出来。

这个看板对于项目经理和架构师很重要,可清楚看到版本一次次持续交付的过程。

再比如:
图片描述
这个看板其实做的不太好(正在改),其实应该是一个项目环境全集的展示,体现出目前项目的所有环境中到底部署的是什么版本,运行状态如何。

再比如:
图片描述

这是流水线,涉及到了多个环境部署、测试知道最后生产上线,这是团队成员在稳定期到最终发布的中间迭代环节,不同的人关注不同的活动,项目经理关注执行阶段与执行情况。

再比如:
图片描述

面对PMO,可能有些企业是CTO,会关注当前所有项目的状态,这张图与IBM的JAZZ中的一个图类似,显示一些项目处于预警状态,另一些是健康状态,椭圆大小代表项目的计划人月多少,越大的越要关注。有这种看板,就不用找每个项目经理沟通或开会了,只要关注有风险项目即可。

再比如:
图片描述

这是项目的基础信息看板,项目经理关注里程碑的情况(延期、进行中、完成等),由此再深入到具体的需求、任务、Bug等具体信息。

很多企业都有二级单位,DevOps同样会开发给二级单位使用,这就涉及到了对于租户能力支撑的实践:
图片描述
业界租户方案主要是应用隔离和数据隔离,对于devops产品来说,显然数据隔离足够了,对于数据隔离,又有逻辑数据隔离(每张表带租户字段)和物理数据隔离(分库)两种方式。

目前我们的产品设计是两者都支持,前者应对数据量不大的情况,后者应对隔离要求很高且量很大的情况。
图片描述
上图应对的是第二种租户设计,更多的通过申请+初始化的方式,同时绑定不同二级域名,解决入口问题。

除了DevOps平台本身,对于集成的三方系统,也要考虑租户能力的支撑:
图片描述

比如Jenkins,建议共享,通过给work node打label,来区分租户;

再比如Nexus,建议每个租户三个独立产品库,当然,如果采用artifactory则更好了
再说说今天的最后一个实践,关于安全的问题,首先DevOps本身定位在管理了多套环境,那平台本身该如何部署:
图片描述

DevOps本身一般部署于生产环境中,通过部署引擎与各环境打通;而对于nexus、或者harbor,目前实施客户中既有可多环境共享的,也有通过多环境同步的。
图片描述

对于平台本身,也要注意:

可用性:支持可靠的部署架构
机密性:对于日志、数据表中的敏感信息,一定要支持不同级别的加密配置
可控制:数据权限、操作权限、api权限等,都要进行严格控制
还要完整性,审计等等

三、普元DevOps核心

一个是领域概念的设计:
图片描述

还是从产品、项目、组织、集成、部署领域考虑,通过流水线将能力串联

另一个是我们的核心观点:

DevOps平台需覆盖产品、项目的全周期
DevOps平台更重要的是提供最佳实践
DevOps平台,重在让所有角色在流水线上协作,共同驱动过程的精益
DevOps平台,管理前移,有效指导和约束后续工作
所谓打通,不是一味的打通部门墙,更重要的对于各阶段管理对象的关联性打通
对于已有系统,DevOps平台不仅仅是通过新的工具链实现快速交付,更是一种驱动优化的变革
DevOps平台,并不是自动化一切,而是在可控中有选择的自动化

最后,对于最佳实践这种东西,仁者见仁,每个企业都有不同的需求和想法,需要在建设期一步一步的做进来(当然,这就要求产品本身的延展性设计等)。
图片描述

作者介绍
顾伟
现任普元信息主任架构师。长期致力于IT技术研究、产品设计与开发、架构咨询等工作,擅长Web、OSGI、CI/CD、服务治理、云计算等领域技术。对DevOps、自动化运维、微服务架构有着浓厚的兴趣。

图片描述

关于EAWorld
微服务,DevOps,元数据,企业架构原创技术分享,EAii(Enterprise Architecture Innovation Institute)企业架构创新研究院旗下官方微信公众号。

扫描下方二维码,关注成功后,回复“普元方法+”,将会获得热门课堂免费学习机会!
微信号:EAWorld,长按二维码关注。

图片描述

评论