这是一个创建于 1530 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景介绍
本期分享内容为 《平台化 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 敏捷也是为了让大家的工作效率协同模式得到更好的保障。随着对于应用质量的管控，将质量管理做到流水线过程中，能够让问题发现的环节更加前置，花更小的成本去修复问题。
目前尚无回复
Select Language