用敏捷的DevOps拳打研发低效脚踢管控不足

Posted 2020-12-06

在为客户进行DevOps咨询和提供解决方案时，除了“又快又好”的发布之外，我们发现客户通常还有两大方面需求：开发测试管理问题和运行管理问题。以某大型金融企业为例，该企业开发测试问题主要表现为研发过程的管控不足，这带来了开发效率低、版本质量差、环境交付慢等一系列问题。另外，整个运行环境缺乏统一管理，资源申请和获取周期长，资源利用率低也是当前运行管理中频繁出现的问题。

问题1
研发过程无法清晰度量、查看和分析
流程规范不标准，各项目各自为战
缺少统一的研发管理支撑工具，已有的流程规范无法有效落实

解决方案

流程的平台化、固化，自动驱动流程运转

不同的公司有划分阶段不同，同一个公司也有可能会分为不同的阶段。在整个流程体系下，每个角色、每个人要做什么是DevOps落地非常重要的一个关键点。通过平台去把所有的规范固化，需要在流程的每个阶段，把每个人的工作职责，需要遵守的规范，甚至是考核指标、度量数据都确认下来。这样每个人能清晰的了解自己的职责，按图索骥去完成自己的工作。

规范的落地是DevOps能够正常运转的一个重点。从立项到整个需求任务、开发测试、发布上线的过程里，大概50%能规范化并落地到平台中，另外还有些工作例如会议需要人员管控。每个企业中可能有1-2套标准流程，不仅要匹配不同客户的需求，和同一企业中不同项目的需求，还有随着企业对DevOps认识的不断提升，流程也会随着认知不断演进。流程的自定义和灵活性就显得非常重要。

如何自动驱动流程也是一个关键。博云为该企业设计了自定义工作流引擎，整个流程的固化，从前期的准备到后面的需求、研发、不同的测试阶段，都可以通过devops平台上企业自定义的研发工作流来驱动。它不仅能展现当前标准流程的进度，同时企业能够用标准流程去驱动底层的工具链与整个研发管理过程。不管从需求、评审或是运维等角度，整个底层、研发流程的状态变化能够驱动流程和工作引擎的状态变化。例如从需求待开发进入开发阶段后，整个版本也从待规划阶段自动变化到开发阶段。

问题2
开发测试环境搭建交付慢，耗时长
同一业务系统跨多平台部署，效率低，耗时长，管理复杂
物理机、虚拟机、容器各自管理，没有统一视图

解决方案

多视角的环境管理

环境管理既重要又很困难。首先底层环境有很多种，可能需要与虚机环境，跟云平台、云管平台对接，还有容器化环境等不同的环境。其次，环境管理有时候是有项目视角的，有时候为这个项目分配了多少环境，同时项目里还有应用、服务、系统等概念，项目中可能有三套系统，并给这三套系统分配了不同的环境。还有一种是按最小粒度去分配，例如有5个服务，每个服务有不同的环境。这几个情况都有可能会出现。从环境角度来看，应用服务是个核心视角，也有项目视角，所以我们为客户设计了树状结构的多视角环境管理支持。这个树状结构有项目—应用—服务三级视角。

现在的研发管理流程中，包含非常多的对象。从项目视角来看，它注重的是开发阶段，需求任务缺陷和非常重要的研发管理的项。从代码提交开始，它的管理对象是应用和服务，比如代码是和哪个服务关联，制品是和哪个服务关联，pipeline和部署也是与应用服务关联。也就是说项目/版本，应用/服务是我们两个核心的管理对象，那如何才能实现兼容这两种方式？

我们在实践中发现，以应用服务视角去统一或以项目视角去统一这两点都是需要的。在代码之前需要的是项目视角，在代码之后最核心的是应用服务视角。通过应用服务去关联代码、环境、pipeline、制品，这是最自然的也是最好用的一套逻辑。还有一个就是人员，除了角色对象这些东西外，它核心也会体现在所有绩效、工作量和团队。

环境管理的落地流程从整个环境规划开始。在流程的前端，一开始就给项目申请环境与配额，最后环境细化的分配到各个项目和应用中去。然后通过pipeline的自动化把环境部署起来，由环境申请到环境释放这样一个过程，底层与各种各样的资源平台去对接。

整个资源环境管理的设计能够兼容各种各样的需求。应用本身是可能有很多环境的，我们实现了一个应用能随时创建一套自己可用的环境，在整个资源平台与不同的容器平台、虚机环境、云管平台上创建的项目相匹配，并进行多个关联。

问题3

缺乏开发测试发布环境的质量管控
缺乏开发规范或者规范难落地，代码质量差
编译打包部署自动化程度低，效率低，易出错
解决方案

以版本为核心的过程管理和追溯

以版本为核心的过程管理和追溯，我们理解是整个DevOps管理设计或是研发管理过程的核心的需求。从需求开始，代码、制品、包括线上的实例，都是能与版本进行关联。但一直以来，很多企业的研发管理过程是做不到这点的。

我们通过DevOps平台的整体自动化驱动，以版本为核心，从整个的从需求到代码、制品、构建、部署和实例的管理过程给支撑起来，将它与关联项进行匹配，使信息实现同步。这样能实现线上运行的版本对应它的需求，能够清晰的了解制品关联哪些需求和版本。这样能够解决整个线上版本和线下版本或不同测试环境里的版本不一致的问题。

这里关键的核心点是研发提测过程。整个研发过程中，研发提测把需求圈出来告诉测试，圈完之后就会走自己的pipeline，pipeline最后生成制品，这样就实现了制品与需求的关联。平台还有提测单，提测单中不仅有制品和需求的信息，还会有质量检查的信息。这个信息会一直跟着流转到整个的版本测试报告中，也就是说我们不但知道这次测试的报告，还能知道所有中间过程中安全检查和自动化测试的结果，是清晰可见的，这是一个关联和信息匹配的过程。

另外一个就是以版本为桥梁打通开发测试和生产环境。在开发测试和生产的过渡过程中，版本包含提测单、需求，也包含制品、配置、脚本这些所有的信息，这样从开发测试转化生产时，不仅是把制品转过去，也包含了整个配置和脚本信息，这样不仅能实现制品包移植，它的配置信息、脚本信息与开发测试环境也是一致的。

问题4

企业或项目个性化的问题和需求如何满足

解决方案

强大的配置能力，适应当前与未来

不管是驱动团队运转的自定义工作流，还是自定义的度量指标等功能，DevOps平台都能够随着客户内部团队的演进适应当前的需求还有未来的变化。另外，前台的自定义DevOps门户能够把整个DevOps流程驱动起来并可视化展现出来。

对开发人员来讲，接收到的需求能在界面上看到，做代码也能在同一个界面上看到，制品、部署发布上线，需要处理的流程的工作，都能在门户中心看到。这样就不需要用许多工具和每天登录十多个系统，就按看到的流程走。

整个工具的驱动也是一个重点与难点。工具较多，每个客户使用的工具也不一样。不管是对接还是纳管，通过工具链和门户的能力，把各种不同的工具驱动和管理起来，为开发人员和管理人员带来价值。

问题5

平台可用性差

解决方案

灵活与可用

目前市场上开源的或一些工具最大的特点就是能力很强，不管是插件化还是配置化，能力很强但是可用性比较差。所以在这个方面，我们花了巨大精力考虑如何实现产品可用性和灵活性的平衡，让可用性强但又很灵活，适应客户的不同需求及特性。

整个DevOps实施落地包含三个关键因素——人、流程、工具，博云从团队协作，流程再造和工具集成三个方面，帮助某金融企业实现了业务驱动型团队和标准化规范的敏捷流程，形成持续完善能力。由点及面，循环迭代完成研发测试运维的持续交付转型，打造能够真正落地的DevOps研发运维体系。

将原有的团队转变为以产品组和能力组共同组成的业务驱动型团队；

落实敏捷支撑的标准化规范，简化流程从而实现快速迭代；

打通应用全生命周期工具集成，形成DevOps的工具链。

通过一套敏捷作业管理框架，一组IT工具链和一个能展示所有环节和过程的可视化平台，博云帮助企业实现面向需求-开发-测试-上线等全流程的端到端自动化流水线，驱动整个研发测试管理流程运转，提高企业内部IT资产能力和开发质量管控水平，从而解决开发测试及运行管理中的种种问题，最终使得研发运维团队业务支撑水平能力得到提升。

随着企业数字化转型的加速推进，DevOps将持续发展，BoCloud博云将继续探索用户真实需求，提升产品能力，为用户提供更加灵活、可用性更强的DevOps平台，帮助企业真正建立DevOps文化，推进业务部门与开发团队深度配合，提升研发运维效能，专注创造价值。