开发运维一体化工具,怎么做devops开发运维

企业微服务转型和DevOps研发运维一体化方案思考

今天重新整理下对企业微服务架构转型和DevOps持续集成和交付过程实施的方案层面的思考。可以看到微服务,DevOps和容器云正是我前面文章里面多次谈到的企业面向云原生解决方案的一个核心内容。

由于微服务和DevOps都属于技术平台和软件过程支撑方面的内容,因此要说服企业实施微服务或DevOps过程改进并不是一件容易的事情。对于小一点的企业往往根本就没有实施微服务和DevOps的潜在需求,而对于大型集团企业往往也自有IT能力自己在构建定制化的平台。

在前面有一篇文章里面我曾经提到了微服务架构转型的方案

传统企业微服务架构转型-从问题分析到规划实施

但是里面基本上没有谈到DevOps方面的内容,今天再基于微服务和DevOps实施来谈下整体的解决方案制作思路应该是如何的,在这里我们先整理一个基于当前我们已有的项目进行微服务和DevOps转型的实践案例来整理这个PPT方案。

转型前项目现状和问题分析

我们可以拿一个当前实际的单体应用系统来进行这次微服务架构转型的案例整理,因此在介绍后面的解决方案前重点还是要把当前的项目现状和背景讲清楚,把实际在开发和过程管理中的面临的问题讲清楚,有了问题才需要去思考如何解决,这样的解决方案才是和问题和目标匹配的。

  • 单体应用当前现状- 应用功能架构,技术架构,开发框架
  • 研发过程管理现状- 项目任务管理,配置管理,需求管理,测试和缺陷管理,版本发布
  • 当前已经完成实践- 开发标准化,持续集成,产品和实施版本分离,共性组件的平台化
  • 当前面临主要问题- 前期开发,后期运维,前后方协同,交付效率,系统后期扩展能力

注意,对于甲方企业如果我们在前面一件调研过具体的需求和痛点,那么我们的现状和问题分析可以更加有针对性。如果没有对甲方进行系统化的调研,那么我们必须准备一个实施过的类似参考案例供企业参考,看企业是否可以产生共鸣。

整体解决思路

对于整体解决方案,首先我们要对当前现状和问题进行分析,实际上是包括了应用系统架构层面,研发过程管理层面,还有就是持续集成和交付层面。

而这三个方面正好是对应了当前主流的几个最佳实践,即分别是微服务架构,Scrum敏捷项目管理和开发,DevOps持续集成和研发运维一体化。

基础技术知识点的介绍

那么要来讲整体解决方案,首先要做的是对三个方法论进行简单介绍,让听众要能够抓住这三个方法论中的本质,也就是我们经常说的最小化概念模型。

  • 微服务架构介绍(基本定义,和传统架构区别,主流微服务开发框架和核心组件)
  • 敏捷方法论介绍(基本定义,原则和价值观,核心过程实践,常见支撑工具等)
  • DevOps介绍(基本定义,当前成熟度模型,主流的开源工具链)
  • 云原生介绍(云原生的核心内容和企业准备上云的趋势分析)

注意意思仅仅是基础知识和概念的介绍,重点就是能够把核心的概念模型讲清楚,让客户对关键技术术语概念和技术发展趋势有一个共同的认识。

问题和解决方案对应

企业微服务转型和DevOps研发运维一体化方案思考

注意,在这里我们给出一个解决方案形成的关键思路。

这里可以是先给出总体的解决方案,也可以是先给出问题分析的思路过程再给出解决方案。不能论是哪种方式,都必须要阐述清楚的就是具体的需求问题和解决方案中关键的技术解决点之间的对应关系,或者说你需要回答:

为何你给出的解决方案能够解决前面提出的关键问题。

对应解决方案的给IC本身又包括了我们常说的思维两个维度,一个是动态的维度,一个是静态的维度。动态的重点是覆盖软件交付生命周期,静态维度是给出一个总体架构图。

  • 全生命周期覆盖:(动态构图,覆盖从需求,研发到交付运维的全生命周期视角)
  • 总体架构图:(静态构图,应该能体现出研发管理,DevOps,微服务三块内容)

在给出了整体解决方案思路后,然后需要进一步给出实施思路。

对于实施方法论和实施思路的重点实际上包括两个方面的内容。其一是搭建好技术平台,其二是拆解现有的单体为微服务或者将新应用一开始就规划为微服务架构。

从单体应用到微服务架构

在前面整体解决方案一定要介绍清楚,通过问题分析和整体解决思路,后续的实施就是两件事情,一件就是搭建支撑平台,一个就是将单体应用拆分为微服务。

那么第3,4两个部分内容正好是这两件事情的进一步细化讲解,对于单体应用到微服务,本身又拆分为两个独立的思路,其一就是要如何拆分?其二就是拆分后选择微服务开发框架如何进行开发。那么就分开对两件事情进行讲解。

业务中台构建-对应到微服务架构如何拆分

企业微服务转型和DevOps研发运维一体化方案思考

  • 中台概念介绍(大中台小前台,业务中台和数据中台,中台如何支撑前台)
  • 中台微服务模块划分(理论方法介绍,实际最终项目划分结果一页)
  • 中台微服务接口识别(接口识别方法,实际当前识别的接口清单和目录库一页)
  • 构建中台能力中心(架构图,构建中台能力服务中心,基于API网关对中台能力进行开放)

微服务模块开发

企业微服务转型和DevOps研发运维一体化方案思考

  • 开发框架选型(介绍基于SringCLoud开发框架进行单个微服务模块的设计开发)
  • 微服务API接口设计(标准的Http Rest API接口,并说明接口设计方法,是否接口先行)
  • 开发持续集成 (介绍Jekins使用,自动构建,构建完成后自动发布到容器)
  • 多模块间协同(介绍不同小组开发的模块间如何进行接口协同,包括协同方式等)

企业DevOps支撑平台建设和实践

企业微服务转型和DevOps研发运维一体化方案思考

在第3部分的微服务架构转型和开发中,可以看到我们实际上已经做了一些研发过程改进,持续集成和容器化改造等工作,但是不系统,未集成。

而这是我们构建一个完整的DevOps支撑平台的初衷。即希望构建一个支撑平台,能够将研发过程管理,持续集成交付乃至后续的运维管控治理全部协同起来,减少在过程协同中的断点,进一步实现整个过程的自动化,灵活可配置化,进一步实现研发和测试间高效协同协同,实现研发和运维间的高效协同,实现后端产品研发和前方项目交付间的高效协同。

DevOps支撑平台核心能力

企业微服务转型和DevOps研发运维一体化方案思考

  • DevOps支撑工具链(先介绍下在整个DevOps支撑过程中涉及到的开源工具支撑链)
  • DevOps支撑平台整体架构(架构图,覆盖研发管理,微服务,DevOps和底层容器平台)
  • 研发过程管理(介绍研发过程管理方案,比如采用禅道或者Jira,还是自研实现研发过程管理)
  • 容器化PaaS(需要对Docker+K8s来实现容器化PaaS和资源调度用一页来说明)
  • 微服务或API网关(采用zuul还是开源的Kong网关定制来作为整体架构中API网关)

DevOps支撑平台对关键业务场景的支撑

企业微服务转型和DevOps研发运维一体化方案思考

在这些讲解清楚后,不用去逐个详细介绍DevOps平台的功能点,最好以关键业务场景或问题驱动介绍。这样客户更加容易理解技术平台对实际的业务需求和问题的解决对应。

企业微服务转型和DevOps研发运维一体化方案思考

企业微服务转型和DevOps研发运维一体化方案思考

企业微服务转型和DevOps研发运维一体化方案思考

企业微服务转型和DevOps研发运维一体化方案思考

企业微服务转型和DevOps研发运维一体化方案思考

企业微服务转型和DevOps研发运维一体化方案思考

  • 持续集成和交付(重点讲解整个流水线设计和自动化编译,构建,打包过程)
  • 研发和测试协同(重点讲解研发管理工具和DevOps平台间的协同)
  • 测试自动化实现(重点讲解下测试自动化如何实现的)
  • 环境迁移和前方发版(重点讲解环境迁移,版本提前,灰度发布等)
  • 研发过程度量(重点讲解研发过程度量,当前做了哪些内容,后续还准备做哪些内容)
  • 后期性能监控(重点讲解后期的性能监控,服务链监控,日志采集和分析)

项目实施完成收益分析

企业微服务转型和DevOps研发运维一体化方案思考

对于DevOps支撑平台实施收益和价值,今天再从业务和管理层容易理解的视角来进行下阐述。

企业研发管理过程的标准化和规范化

注意,在DevOps实施过程中,我们会协助企业进行研发管理过程的规范化和流程化,不论是传统的研发过程管理模式,还是敏捷开发思路,都需要对研发过程进行标准化和流程化,再进一步的自动化。这里面涉及到最基本的开发框架,开发规范,配置管理,变更和缺陷管理,测试管理,版本发布等诸多关键过程域,而这些在我们进行DevOps支撑平台实施的时候会协助企业进行这方面的优化和改进。

企业研发资产的可视化

在DevOps里面我们会强调研发和运维一体化,研发和质量管理一体化,这些都没有问题。但是DevOps有一个关键就是本身是完全包括覆盖了传统的持续交付和持续集成最佳实践的。即整个研发生命周期过程应该进一步的可视化,同时通过微服务架构设计和模块拆分,进一步的实现短周期迭代开发。

迭代开发最终交付的用户可以使用的功能,而不是中间的半成品。但是如果半成品的输出过程不可视,如何确保最终的功能输出没有问题?

不论是甲方企业,还是软件企业本身,都需要对研发过程可视化,即对研发过程的关键中间节点做到完全可控,可视,而这里面最重要的就是做到中间输出结果本身的可验证。注意在整个DevOps流水线作业中,增加的代码入库和静态检查,构建,自动化的单元测试等都是确保这些中间件节点可视,确实研发检入的代码是完整并可以编译通过的。

从整个项目一开始研发资产就是可视的,那么最终研发完成后资产本身也是完整和可视的。研发资产应该是属于企业资产而不是个人资产,对于甲方企业来讲,研发资产的交付应该是在整个项目或研发过程中持续交付,而不是最终项目完成后一次性交付,只有这样甲方对乙方的IT管控能力才能够提升。

协助企业进行微服务架构转型的关键支撑

在传统企业进行IT架构转型,或者说转向微服务架构后,带来的一个关键问题就是微服务模块会越来越多,模块之间的接口越指数级增长。这就导致我们在进行模块构建,模块部署,单元测试等工作的时候耗费大量的人力。而DevOps支撑平台本身就集成了持续交付和集成各种关键工具集,通过平台可以高效自动化的完成代码检查,编译,构建,打包,部署,环境迁移等各类工作。极大的节约人力投入并提升过程效率。

原来传统模式下你部署一个业务系统可能感觉不到大的工作量,但是实施微服务架构后一个业务系统可能已经被拆分为了10多个微服务模块,那么要部署这些微服务模块,要准备应用服务器,要进行打包部署工作量都会指数级增长,而这些完全可以由DevOps支撑平台来帮你完成,同时在设计好流水线作业模板后,所有过程都是自动完成,而且在执行过程中可以做到完全可视,可管控。

在实施微服务架构的时候,我前面谈到过两点,一个就是前面的容器化技术支撑和持续集成自动化,一个就是后续的运维监控能力要跟上。这两个能力跟不上,那么微服务架构实施将由于企业本身的IT信息化成熟度不足导致大量的问题。

本站部分内容由互联网用户自发贡献,该文观点仅代表作者本人,本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规等内容,请举报!一经查实,本站将立刻删除。
本站部分内容由互联网用户自发贡献,该文观点仅代表作者本人,本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。

如发现本站有涉嫌抄袭侵权/违法违规等内容,请<举报!一经查实,本站将立刻删除。