当DevOps邂逅云原生

点击观看大咖分享

乌云笼罩下还敢谈创业？面对生存，小型创新企业如何把握领跑的机会? 同样面临转型，为什么别人是华丽转身响彻寰宇，而你却东张西望波澜不起。悄悄告诉你，越来越多的企业的注意力转移到了客户和业务之间的交付价值，“精益求精，降本增效”真的像躺着赚钱一样不切实际嘛？不，不是你太接地气，是你的眼神疏漏犀利。突如其来的云原生带你细化云时代下企业转型的重要支撑点，窥探开发团队低效的根本原因，和DevOps手牵手，助你一直走。

1．非软件非数字化系统性工作都在逐渐搬运至云端就需要匹配更复杂的软件

2．软件复杂度提升后上线速度变慢，稳定性堪忧，研发团队不堪重负

云原生的基本认知

云原生的概念复杂，所包含的板块如图所示，像各种平台，各种运行时，各种编排，各种分析工具，应用的定义及开发流程。

直观对比图如下：

想要理解云原生（Cloud Native）需要首先理解基于面向机器开发的应用Machine Native。例如一个程序是运行在Windows还是Linux上，是运行在X86的架构上还是小型机的架构上，用多少内存，CPU，语言，构件库等都是Machine Native。所有应用的定义是面向将来部署到的机器上的。在云时代，不再关心运行环境，Cloud Native更关注云能力。默认云上就有数据库，无需关注来源直接使用即可。云会根据所需资源自动伸缩，存储也一样。整个应用的设计，架构会颠覆Machine Native的时代。开发的资源，利用的组件都是面向云而非部署服务器或笔记本或PC上。最大化利用云服务的能力增加业务竞争力的就是Cloud Native的应用。很多企业都在逐步做云，事实上分两种情况，一是把应用搬运到云上但并没有做到Cloud Native。从基于物理的实际服务器搬至云端虚拟服务器，却除了服务器外，其他的功能都没有使用。动态的分发，缓存，数据库都还是自己承包。这种称之为“伪上云”。因此，我们仍需充分利用云能力，关注业务真正的价值，而非云能实现的基础架构能力。

DevOps与云是不可分割的整体

DevOps解决的是开发者的代码和运营者维护系统稳定的不同关注核心之间的矛盾。运维对开发者有一系列测试，审批，部署脚本等反复核查的边缘性工作浪费程序员大量时间，致使程序员真正写代码的时长不足4小时。

DevOps可以实现让开发者自己做运维，运维就可以做更基础的工作，例如提供自动化的工具，提供更稳定的基础设施，像是计算资源的稳定，网络稳定等，而非帮助开发去发布应用做更新。这是一个从本质的变革,即开发者兼顾研发部的职责，运维人员做更基层的支撑，从而提高开发效率。

关于DevOps的优良测试可根据下图衡量，就部署频率来说，多数传统软件六个月以上发布一次，互联网时代多数是从一星期，云时代可做到不到一个小时发布一次，一天可发布几十次。平均下来大概是一天至一星期。

还可根据准备变更时间（从提交代码到在生产环境中运行代码花费的时间）来衡量。这是和部署不同的衡量维度，例如可以快速部署，假设提交了很多，但每次只部署一个，可不断部署，排队提交，因此拉长了提交的部署时间。平均水平大概一周到一个月或一天到一周。

恢复时间也是衡量标准之一。问题出现的恢复时间平均在一天左右。

最后一个是变更失败率。即每次发布的成功率，例如发布100次，却总发布失败。平均失败率在20%左右。

根据部署频率，变更准备时间，恢复服务时间和变更失败率对团队进行衡量。

根据国外150多家公司的统计报告，将最优与最差进行对比，计算出最优比最差效率提高了多少倍。

如何做到像顶尖团队一样的快速部署，提高整个研发管理效率。

软件开发的发展历程虽然短，但也如同分工明确的流水线一样。产品经理，开发，测试，前端，后端，运维各司其职。

腾讯云把这个虚拟的流水线搬至云端，省去了各个公司流水线的制作步骤，直接使用腾讯云的服务即可。

大多数互联网公司的项目管理线如下：

项目管理核心部分的两个名词解释：

史诗：跨周期的规划

迭代：每周的近期规划

所以一个史诗可包含很多个迭代

迭代里包含需求，bug等。需求又会分解成子任务。这就是项目管理的核心：将一个任务通过不同维度的拆分变为清晰可追踪的事项。

以下是Coding DevOps 项目协同的截图可供参考。

当任务分解完毕后，需要做代码开发时就要提到持续集成CI。代码开发时涉及到的一些流程比如分支管理，合并请求，coding review等。持续集成流水线帮助把代码进行自动化测试，扫描，最后生成一个制品（安装包）。传统软件称exe. 安卓的apk. 和IOS的 ipa.云中Doc的镜像也可以称之为制品。制品通过CD系统可持续发布，并不是所有制品都需要发布，小版本可能不选择发布。和宏观的项目管理不同的是持续集成流水线主要侧重代码发布。

以下是Coding DevOps持续集成产品的呈现。全自动化流水线减少了人工的操作步骤，程序员的注意力可以更好的集中在代码上。

制品发布流程如下图所示，持续发布就是中间部署的过程。

以下是Coding DevOps持续部署截图。

DevOps作为提高效率的工具，可以从App-cluster1清晰看出是全自动的分批次发布。

为什么DevOps还未被广泛应用？

DevOps作为一个全新体验，很难改变分工明确的团队人员的惯性流程。像培训人员，采购工具等替换成本很高。

也并不是所有应用都适合DevOps。在云时代下，一个应用并不是一个单体应用，它涉及到大量的微服务，可能包含很多组件，每个组件的开发团队不同。组件之间如何进行更新，集成。通过DevOps可对这些应用做整个开发流程的良好管理。遗憾的是某些行业是它的应用盲区，比如机械制造业的工厂管理，地铁运行调度问题，航空航天等需要统筹规划的行业。因此还需根据需求进行选择。