「DevOps 转型与实践」沙龙回顾第二讲

背景介绍

本期分享内容为《平台化 DevOps—云计算与云原生模式下 DevOps 的建设实践》。目前，DevOps 愈来愈成为你们当前建设的热点，伴随着基础设施的转型和应用框架的转型，更多的业务偏向云端和 C 端的场景，促进了 DevOps 的发展。在本次沙龙上，腾讯云 CODING DevOps 资深架构师余朋飞为你们介绍了在云计算和云原生两种模式下，如何推动 DevOps 的建设和实践。

企业 IT 架构演变历程

在 2007 年以前，企业还未产生 DevOps 的概念，大多仍是基于物理机的模式。2012-2014 年是第一波上云的热潮，企业纷纷将传统的物理硬件转换到虚拟机的结构上。以后，容器的发展推进了应用的转型，微服务愈来愈被你们所说起，对应 DevOps 这个概念也愈来愈被你们所推崇。因此第二波上云是业务从底层迁移到云上。第三波是云原生，整个 IT 基础设施，不管是从硬件端、中间件以及所依赖的数据库等资源所有可以在云上提供服务。 基于这个模式，更应该被关注的是整个软件开发自己业务需求的梳理，到整个业务的运营，这个阶段从开发态，从运营态和服务调度的模式都有新的改善。

DevOps 一直致力于怎么更好地维护应用的生命周期。在 DevOps 1.0 时代，这个时代是将基础资源作标准化，更多的是针对应用架构采起单体或服务总线的架构，对应的模式仍是以虚拟化为主。 然而在整个业务发展过程当中，更应该面向的是 DevOps 2.0 服务管理，整个应用架构和基础设施的架构随之也会变化。接下来就具体看一看在这两种不一样的管理模式下，整个 DevOps 的建设究竟是什么样的方式去推进和落地它的。

云计算模式下的 DevOps

业务上云给你们带来了什么？咱们须要解决哪些问题？如下总结了几方面目前业界比较关心的点。首先由于基础设施的爆炸式增加，致使环境配置管理和维护愈发困难，持续部署层面须要发布的节点愈来愈复杂；在业务推向虚拟化基础设施的时代下，业务架构变得更加复杂，对应部署成功率，相应的系统稳定性也会降低；另外因为底层云资源带来的便利，在流量冲击的状况下须要作好资源和应用的弹性；最后，随着业务对 IT 的诉求愈来愈频繁，须要更快速反馈整个业务的诉求。

所以， DevOps 的建设迫在眉睫，从需求到最终上线运营的全生命周期里须要进行全方位改进——好比须要更好更标准的需求管理工具，须要经过自动化手段快速管理对应的环境，可以经过自动化测试把质量创建起来，最后可以更好地处理在运营阶段的事故。在这个阶段，你们更聚焦的核心是自动化，怎么经过 DevOps 的手段来强化自动化流程。在自动化效果基础上伴随的是标准化和版本化，在自动化的同时也要作好相应的质量内建以及 DevOps 过程度量，由于只有将过程度量好以后才能评估 DevOps 建设的效果，质量内建也是保证 DevOps 建设过程当中软件的质量可以获得很好的控制。

从这几个目标来看，核心指标包括生产效率、软件研发效率，生产控制中的产品质量，对应的成本节省。在软件研发过程当中，经过可靠、可重复的流水线能够帮助咱们更快速、更高效地生产 IT 软件或对应的服务。

CODING DevOps 流水线实践

下图为当前 CODING 面向客户所推的 DevOps 流水线实践。

基于 CODING 平台，从代码拉取开始，基于内置的代码静态扫描模块来保证代码静态检查，包含代码规范、缺陷、重复率等不一样的维度，另外，云端的构建环境可以保证各类不一样的构建编译，结合基础设施的管理可以将自动化部署到对应的测试环境，帮助在整个流水线过程当中作到测试质量管理，让质量在整个流水线过程当中有比较好的保障。最后，单一的制品来源可以保证独立存储制品。到了生产阶段，咱们更多关注基于业务运营的过程怎么作灰度和 A/B Test 的部署模式。

研发规范

在创建流水线时，须要遵循一系列的研发规范。

流水线建设过程当中须要将这些规范囊括起来，流水线并不仅是打包工具，不是经过流水线将代码构建成制品就结束了，而是可以在流水线过程当中标准化整个研发过程。

了解了这些规范，实际应该怎么去落地？在建设 DevOps 的过程当中经常遇到许多使人痛苦的问题。好比，针对金融行业大量已有系统，研发管理模式不尽相同，规范过多该如何管理？新老系统和业务如何兼容？随着时间增加、流程紧急、业务压力增长，如何保证团队的热忱和规范的持久运转？规范须要对应的人员去支撑，工做场景每每至关复杂，如何作好规范的标准化工做？CODING 基于以前的经验，针对这些痛点研发了一款研发规范产品 TCMS，定义不一样的研发团队所对应的研发管理流程，可以约束对应的需求、代码、流水线管理，作标准化的约束来提高整个团队的协做效率。

研发管理包括几个部分。首先定义研发工做流，须要定义代码能拉出哪几个分支，容许哪些对应的合并策略，而且每次合并必需要有对应的规范和理由；第二，不一样的合并规则意味着不一样流水线的执行，在合开发分支的时候，开发人员作了一次本地提交可能只须要运转开发流水线，只须要对代码的质量和单元测试作一些约束便可，一旦涉及到 release 分支或 MR 的合并，这时候意味着功能合流了，基于合流规则来关联流水线，在流水线过程当中去约束这个合流所对应的业务规则；第三，自动化工具辅助分支管理，若是定义了一个分支只能拉出来一周，一周以内必须合并进去的话也会作一些约束；第四，将对应的分支和需求管理关联起来，分支在合流的时候可以很清晰地从需求管理追溯到代码开发，从代码开发再追溯到整个业务合并，全生命周期管理是可控制和便于查阅的。

下图为 CODING 的标准化流水线：

云原生带来的改变

从 CODING 当前服务的客户，一块是移动端的业务，当前移动端 APP 已经愈来愈多的企业重视云原生，针对移动端也是可以基于云让开发速度获得更好的保障另外一块是从金融行业，有些营销类业务更多适应云原生的场景。不管是营销类也好，仍是 APP 类也好，核心挑战是 C 端用户过多的状况下业务会受到较大制约，好比收集更多的用户数据，更快速地对用户诉求获得反馈。单单经过流水线建设是没法达到这个效果的，流水线只能帮助咱们更快地实现代码到构建到部署这一段的效率，可是以后怎么基于部署的应用来提高业务价值，就涉及到价值交付的过程。在当前的 DevOps 2.0 里面，运营过程和业务分析过程被归入到 DevOps 体系里面去实现相应的价值交付。

那么怎么作价值交付？CODING 第一步会作自动化，第二步会作敏捷。至于为何把敏捷放在 DevOps、自动化以后去建设，CODING 发现，在国内、尤为是大型机构和金融企业里面，敏捷没有推得像你们想象的那么好。自动化设备没有作到必定程度的时候是不足以支撑过于短平快的迭代的。因此 CODING 首先经过可靠可重复的流水线创建自动化的应用交付体系，帮助代码可以更快上线；而后基于敏捷的思惟和实践对业务需求作拆分和管理，经过迭代作增量式开发。另外随着对迭代的要求愈来愈高， CODING 天天都会进行发布，敏捷已经不足以支撑业务需求的增加，所以 CODING 团队更加贴合互联网模式去作微服务改造，应用架构变化以后，应用更小更细，就能更快地实现迭代。最后，业务上线以后运营过程也能够归入到对应的 DevOps 体系里面来。

下图为 CODING 在价值交付体系下的组织结构转型：

在价值交付体系里面，CODING 从组织、流程、能效和工具四个层面作梳理。基于对应的 DevOps 指标可以评估团队对应的 DevOps 能效如何，怎么基于这些指标进行提高。

经过 DevOps 的建设，企业可以经过容器化构建和开发环境管理，下降资源利用率和节省成本。CODING 提供了构建的资源池，你们在作开发的时候不须要本身管理服务器；另外，经过 CODING 流水线建设作到对应的持续交付的效果；基于 CODING 的实施也能更好地建设符合 DevOps 文化的度量体系；标准化制品管理可以管理制品模板、流转和进阶的过程；最后，基于研发规范的约束可以让整个团队在落地 DevOps 的时候更加无感，你们自觉遵照约束以提升开发标准化。这是 CODING 的愿景——让开发更简单。

Q & A

Q：落地 DevOps 必然会面临团队成熟度的问题，包括团队技术水平，敏捷意识和能力，如何保证标准化的产品在每一个团队作更灵活的适配？
A：从 CODING 的角度来看，规范有两个不一样的角色，规范的制定者和使用规范的人。只有对业务有深入了解的人可以制定规范。一些经验不足的同窗，只须要基于当前制定的规范使用这个产品就能够了。

Q：在小公司里面，如何在成本控制和 DevOps 的落地之间取得平衡？
A：DevOps 从某种程度上是下降成本的。CODING 可以提供虚拟化的空间资源池让开发资源获得更好的利用。推进 DevOps 敏捷也是为了让你们的工做效率协同模式获得更好的保障。随着对于应用质量的管控，将质量管理作到流水线过程当中，可以让问题发现的环节更加前置，花更小的成本去修复问题。

点击观看课程录播并下载 PPT