作者：网易数帆链接：https://www.zhihu.com/question/58702398/answer/235777073来源：知乎DevOps目前并没有权威的定义，网易云认为，DevOps 强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。如果从字面上来理解，DevOps 只是Dev（开发人员）+Ops（运维人员），实际上，它是一组过程、方法与系统的统称，其概念从2009 年首次提出发展到现在，内容非常丰富，有理论也有实践，包括组织文化、自动化、精益、反馈和分享等不同方面。组织架构、企业文化与理念等，需要自上而下设计，用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合，简单而言组织形式类似于系统分层设计。自动化是指所有的操作都不需要人工参与，全部依赖系统自动完成，比如上述的持续交付过程必须自动化才有可能完成快速迭代。DevOps 的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发部门和运维部门必须紧密合作。所以，我们有上面的说法。那企业为什么需要DevOps，DevOps有什么依赖？我们认为：为了抓住商业机会，业务需要快速迭代，不断试错，因此，企业需要依赖拥有持续交付的能力，这些不仅包括技术需求还包括产品的需求，如何能拥有持续交付的能力，大而全的架构因为效率低下，显然是不合适的。于是演变出微服务架构来满足需求，通过把系统划分出一个个独立的个体，每个个体服务的设计依赖需要通过12 要素的原则来规范完成。系统被分成了几十个甚至几百个服务组件，则需要借助DevOps 才能很好地满足业务协作和发布等流程。DevOps 的有效实施需要依赖一定的土壤，即敏捷的基础设施服务，现实只有云计算的模式才能满足整体要求。利益相关：以上内容摘自网易云架构团队写的《云原生应用架构实践》。

上图是一个比较典型的Devops流程。包括产品立项、需求分析、应用设计、开发、测试、持续发布、生产运维、回顾阶段。其中，Openshift可以涵盖中间5个阶段，CloudForms可以覆盖第七个阶段。只有第一个阶段目前红帽产品堆栈无法覆盖。

学习积分/结营测试成绩/学习之星/邀请数据/论坛获奖等数据已公布在活动帖留言区（置顶），点击链接查看https://bbs.huaweicloud.com/forum/thread-101458-1-1.html

DevOps的应用场景往往是一个庞大复杂的背景和流程的场景，大都包含一个持续交付流水线。开发人员：IDE、Git等开发和编译工具版本控制系统：分支策略、语义化版本构建服务器：持续集成、代码质量检查工件库：存放二进制包系统的包管理器：编译或测试环境系统上管理二进制包环境一致性预发布或生产：预发布环境与生产环境互换（蓝绿发布）发布管理：在高程度自动化测试的基础上实践自动化或半自动化（人工介入）部署问题管理系统因此，DevOps 是一个完整的面向IT运维的工作流，以 IT 自动化以及持续集成（CI）、持续部署（CD）为基础，来优化程式开发、测试、系统运维等所有环节。DevOps的技术要点由“持续集成/部署“”一线贯穿，主干开发是进行持续集成的前提，自动化以及代码周边集中管理是实施持续集成的必要条件。换而言之，DevOps 是持续集成思想的延伸，持续集成/部署是 DevOps 的技术核心，在没有自动化测试、持续集成/部署之下，DevOps就是空中楼阁。一个完整的过程开发团队接到任务，需要完成一个变更为了更加顺利地开发，将这个变更分拆为几个小变更开发人员在本地开发并且测试，如果使用了测试驱动开发，在编写功能代码之前会先编写测试，然后编写能够让测试通过的实际代码开发人员将代码提交到企业内部的Git版本控制系统上构建服务器获取这个变更并初始化构建流程，单元测试之后，变更可以被发布到二进制库里配置管理系统根据“策略”，在测试环境中安装应用了新的变更新安装触发自动化回归测试，测试成功后，质量保证团队开始做人工测试人工测试通过后，质量保证团队将“已通过”标识给予这个变革变更在预发布环境中进行验收测试验收测试完成后，预发布环境被切换成生产环境，而生产环境变为新的预发布环境

DevOps的目标不是单靠一款工具就能实现的。在各个阶段，每个都有其单独对应的目标。依赖于组织的选择，有着各种各样的工具可以在相应的背景和趋势下，实现当前业务目标，满足中远期的需求。

“DevOps的价值是又快又好地交付软件”——《凤凰项目》的作者Gene Kim和《持续交付》的作者JezHumble当前数字化转型的形势下，软件行业面临着巨大的市场机遇，而软件系统复杂度不断增加，跨地域高效协作、多环境部署等问题也逐渐突出，DevOps能帮助企业提升软件研发效率，通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加快捷、频繁和可靠。基于此，我们策划组织了2期【DevOps职业认证训练营】，并邀请到姚冬、卜汉东两位专家老师全程陪伴学习与答疑。在整理问答的过程中我们发现，学员提出的问题覆盖了规划设计、开发集成、测试、部署发布、运维监控等DevOps落地实践中的关键疑点与难点。本文从中挑选整理了60个精华问答，希望通过这些问题与解析，帮助更多DevOps实践者解决DevOps落地过程中的疑惑与痛点。（文末可下载大纲模式的pdf文档方便浏览）【一、华为端到端DevOps概览】Q1：华为端到端的DevOps工具链是如何承载敏捷和DevOps相关理念和方法的？A：敏捷和DevOps的理念其实是相通的，DevOps可以视作敏捷的延伸，敏捷思想打破了需求与开发之间的壁垒，DevOps则通过将开发与运维间的壁垒打破，打通软件交付全流程。华为云DevOps工具链DevCloud包含了从需求管理到代码托管、构建部署、测试等一系列步骤，覆盖软件开发全生命周期。理念往往需要结合实践，我们可以通过DevCloud进行需求管理、每日站会等等许多敏捷实践，通过提交代码可以触发执行流水线，让开发人员专注开发。Q2：华为云DevCloud与传统基于开源组件拼接的工具链，有什么差异优势？A：传统的由开源组件拼接而成的工具链，大部分都是使用Jira来进行需求管理、用Git来做代码托管、用Jenkins做DevOps开发，因为其组件大部分都是开源的，所以一般费用较低或者免费，其缺点是使用者需要掌握很多工具，而且这些工具并不是在同一个平台上。华为云DevCloud是一站式的软件开发平台，可以做到所有工具都在一个平台上，端到端打通覆盖整个软件开发全生命周期。用Jenkins的人都知道，在使用之前首先需要搭建一套Jenkins的环境，还需要定制化地做一些脚本、配置等，华为云DevCloud相当于是一个已经封装好了的DevOps开发工具，可以极大减少这些操作。在华为云DevCloud里，将编译构建、部署任务等做成了原子化的操作，如果我们想要做Tomcat部署，可以直接使用这些模板，只需要对里面的步骤进行细微的调整即可。而且它还使用了可视化视图，操作起来一目了然，学习成本也比较低。华为云DevCloud还支持代码检查、自定义shell、Python、脚本、自定义report展示。Q3：DevOps /敏捷和SDLC 有何不同？A：DevOps/敏捷和SDLC的角度不一样。SDLC是指系统生命周期，它提出的几种典型生命周期模型包括瀑布模型、快速原型模型、迭代模型。敏捷打破了需求和开发之间的沟通壁垒，DevOps则打通了整个软件交付的全流程。Q4：DevOps人员在与项目的结合中是否会承担更多开发、测试、运维的工作？A：DevOps不会让人去承担更多开发、测试、运维的工作。DevOps里有一个理念：让开发的人专注于开发、测试的人专注于测试、运维的人专注于运维，所有的工具层面的东西全部交给工具，只要把一切可自动化的东西自动化，所有的人忙自己手头的工作就好了。Q5：DevOps的反模式有哪些？A：参考《9种DevOps团队结构适用类型与7种反型》 Q6：DevOps适合哪些行业的业务模式？对于非软件行业是否需要调整模式?A：DevOps也好，敏捷也好，其初衷和理念适用于所有行业，但是每个行业在执行和实际落地效果上会有一些折扣，比如持续交付的生产环境、自动化部署、质量管控、自动化流转等过程的实现等。简单而言，互联网的一些应用，或者说SaaS应用，相对来说更适合DevOps的研发模式。原因是：其业务对软件更新、发布的要求较高；没有太大的历史包袱；相对更容易对标目标受众群体，包括生产环境等。传统类的业务比较重，比如银行的核心系统，实践起来相对较难，也不是说不能用敏捷或DevOps。比如持续集成、每天多次构建、多次提交代码、自动化测试、可视化等，都可以实行。对于非软件行业，如硬件、嵌入式、机械类，实践起来也比较难，比如测试自动化等，需要做一些工具或平台的适配，引进插件或工具后，流程也能够跑起来，只是会慢一些。综上，我认为敏捷和DevOps本身是一条没有终点的路，所有行业都可以到这条路上来，只是走得难易与远近的问题。Q7：在企业落地DevOps有没有什么套路？A：企业实际情况各不相同，落地DevOps没有统一的套路，但会有一些建议的方式。DevOps偏工程侧，通常建议先把版本管理建立起来，比如Git代码仓、代码分支管理等；接下来需要把流水线构建起来，在上面逐渐进行自动化测试、分层测试等。Q8：最能有效促进Scrum团队本身的持续改进的是什么实践？A：每个团队遇到的问题都是不一样的，如果一定要找一个通用的答案，首先要保证团队每日站会、评审会议等如质如期进行，以此来保持持续改进。 【二、持续规划与设计】Q9：基于DevOps实现持续有效规划应该先从哪个层面去入手呢？A：首先需要理解DevOps和敏捷的含义，我们一般说的规划与设计更偏向于敏捷项目管理中涵盖的需求和计划。狭义的DevOps主要是CI/CD，即持续集成和持续部署，是偏工程侧的。广义的DevOps，即本训练营中讲的DevOps是“端到端的DevOps”，从持续集成/持续部署，向前延伸到业务侧，向后延伸到运维/运营侧，因此也涵盖了前段的需求和设计层面。回到问题，基于DevOps实现持续有效规划，应该从需求和计划切入，包括整个的市场分析、目标客户群体的用户画像，用户的痛点是什么，针对这些痛点提供什么样的功能，然后到产品应该怎么设计，接下来才真正落到研发这个主体上。从方法论角度来看，需求和设计层面的方法论包括设计思维、精益创业等。做好需求分析后，就要进行需求拆分，排列优先级，这样就进到敏捷项目计划里，方法论包括看板、Scrum等，大规模团队敏捷框架有SAFe等。Q10：Scrum，看板和 XP 是敏捷开发的具体方式，老师能否具体讲解一下区别？A：参考文章《DevOps VS 敏捷：傻傻分不清楚》。Scrum和看板更侧重在团队级敏捷项目管理层面，XP更偏向于工程实践层面。Scrum和看板两者比较：“标准的”Scrum包括3355的框架；看板源自丰田的精益生产，其背后是精益的思想，通过可视化、限制在制品的数量，快速暴露问题和瓶颈点，集中对最严重的瓶颈点进行修复，然后去寻找下一个瓶颈点。DevOps的很多理念同样借鉴了精益的思想，个人认为，看板可以应用到很多领域。另外，Scrum和看板在实施或应用时并没有冲突，可以结合起来使用。 Q11：企业组织架构中什么角色或者部分适合推行DevOps落地？A：企业组织架构中一般都没有专门的组织来推行和落地DevOps。DevOps包括两个部分“Dev”和“Ops”，就是指开发部门和运维部门。几种常见的情况：如果是由开发部门来发起DevOps落地，就是由开发往运维去推进。我们平时看到比较多的是测试团队或传统的质量管理部门来发起，从开发到测试再往前一步到运维生产环境上去，因为这些部门本身就承担着代码托管、编译构建、自动化测试等职能。而有的公司会把内部的基础设施、IT支撑、测试等放在数据中心，往前去推把自己变成类似我们讲的DevOps工程师，然后通过自动化工具帮助开发团队进行自动化部署等，这就是从运维侧往前推进DevOps落地。还有一种情况，就是近年来比较火的云原生，架构师更多考虑采用微服务架构，通过基础设施即代码等方式自动化部署到Docker环境中去，因此引入自动化流水线、Infrastructure as Code（基础设施即代码）、接口测试等实践，这些都属于DevOps的范畴。还有一些其他的角色，比如敏捷教练、内部的技术教练等，他们本身就是在做研发管理的落地实践，很自然地转化去做DevOps推进。综上，DevOps的推进和落地不一定非要有一个DevOps工程师或独立的DevOps团队，初期引入DevOps的时候需要有一个团队或角色去承担起这个职责，进行概念和实践的导入和探索，这时更容易把DevOps工程师、DevOps团队建立起来。而后期应该把这些工程师或能力分散到各个团队中去，让DevOps在企业内有更广泛的传播和实践。Q12：请问在Scrum中，如果没有项目经理，是由TeamLeader还是ScrumMaster协调资源？A：应该由TeamLeader来协调资源，ScrumMaster不是管理角色，而更多的是一个辅助的牧羊犬的角色，在Scrum实施过程中守护团队Scrum流程不受干扰。Q13：对于非产品形态的项目，Product Owner来自哪个部门更合适？（业务部门/研发部门）A：Product Owner代表客户，一般是哪个部门更接近业务，更了解业务和系统，就由这个部门的人来担任。非产品形态项目的Product Owner，要求既了解业务又懂技术，一般可以由业务分析师、PMO等角色担任。Q14：实际开发中，客户往往无人承担PO的角色，而是领导来承担，如何破解这个问题？A：这种情况可称为“BDD”，Boss-Driven Development，老板驱动开发。好处是至少有一个人能拍板；坏处是拍板的人，你可能很难去辩驳或谈判，所以最好还是能够把客户侧的人拉进来。当然，如果老板确实对业务非常了解，也非常专业，并且是一个可沟通的人，也是可以的。PO的核心要求是需要有一个人代表客户或业务侧，针对需求或范围做决定，且当团队有问题的时候，可以随时找到这个人。Q15：影响地图主要应用于哪个环节？A：从HE2E DevOps实施框架图可以看到，在端到端的DevOps实践中，影响地图通常用于需求规划或业务规划阶段，与传统的Scrum流程相比，更偏业务侧。影响地图通过四层结构：why、who、how、what来拆解业务和需求，也可以用于运营或项目冷启动环节。Q16：请问如果一个大的Story拆分成多个小的Story，甚至再次拆分成孙子辈的Story，如何更好地表示这些关联关系？A：Story拆分有两种方式：一种是从epic（史诗故事）到feature到story的拆分，epic以月为单位，feature以周为单位，story以天为单位；另一种是平级拆分，所有拆分的故事全部叫story，只不过它们之间存在父子关系。不管是三层还是四层，我们只关注父子关系，从一个父story拆分出子story，如果粒度不够小，则以子story为父story继续拆分出它的子story。如果系统需要有层级追溯，可以用树状或脑图等结构来展现。Q17：学完课程感觉用户故事和项目管理里的工作包很像，二者有个共同的问题，拆解到什么粒度是好的用户故事？A：故事也好，需求也好，只是一个名字，用户故事之所以叫用户故事，有两点表征：1）它是站在用户的角度去看；2）它讲了一个故事、一个场景。好的用户故事遵循INVEST原则，即一个合适的用户故事应该是独立的（Independent）、有价值的（Valuable）、可讨论的（Negotiable）、小的（Small）、可估算的（Estimable）和可测试验证的（Testable）。Q18：如果采用敏捷开发，最终的用户需求如何呈现给用户？如果是需要存档的用户需求说明书、设计说明书或操作手册之类的文档，适合从DevCloud导出后再修改么？另外如果出现变更，如何确保文档与代码一致？A：如果是需求文档，可以以用户故事的形式存放，华为云DevCloud或者其他工具都提供多元的存储格式，如文本、图片、附件等，华为云DevCloud有一个帮助网站，每一个新上线的功能都会在这里进行同步和更新。也可以把词条或需求存放到wiki里，并跟前端的需求条目之间建立链接。wiki本身是可以有层级关系的，可以把需求从wiki里导出来形成文档形式，如果做得好，还会有版本计划，比如版本里包括10条需求，可以统一导出一篇需求规格说明文档。需求和代码之间的同步，可以通过流程等方式去控制，比如发版的检查点，这可能需要以人工方式去做，但也可以通过一些工具来辅助。比如提交代码的时候需要提交注释，可以把这个注释关联到一个工作项上，一个需求可能会修改多个文件里的多段代码，这其实就是一个完整的变更集的概念，这个变更是为了同一个目的，是有相关性的，如果要从代码里去剥离的话，应该会把这一次变更集统一进行剥离。在未来查看代码时，可以进行代码版本比较，看两个版本之间进行了哪些增加/修改、这些变更是为什么目的、其意图是什么。Q19：对于变化的需求或者新增的需求，是应该放到当前迭代里，还是规划到后面的迭代里，持续规划是指规划过程贯穿整个生命周期么？A：变化或新增的需求都会统一放到一个大的池子里，我们称之为product backlog（产品待办事项列表），这是一个一维的表格，所有需求按照优先级排列。我们要通过判断新进需求的优先级，看它应该放在什么位置。敏捷强调需求是动态变化的，我们会定期对需求列表进行梳理，看是否需要进行优先级排序的调整，因此变化或新增的需求不会放到当前的迭代里，因为当前迭代是一个固定的时间窗口，且范围相对固定，团队对此进行了承诺。我们会将其放入大的需求池，是在下个迭代还是之后的迭代实现，取决于该需求的优先级。Q20：对于初学者刚刚接触一个项目，但是项目的需求不明确、结构不成熟，怎么从敏捷入手？A：这里包括两种情况：初学者、项目在初级阶段。如果是初学者，应该通过获取现有资产快速熟悉和上手；如果项目处于初级阶段，需求也不太明确，可以通过敏捷的快速交付、精益的MVP等实践，快速获取反馈，对后续工作进行指导和建议。Q21：作为整个项目的入口，需求的质量如何把控和评测？A：明确定义需求可以转开发的标准，即DoR。那什么是DoR呢？敏捷开发发展了几个年头之后，人们发现进入迭代开发应当满足一定条件，否则过于模糊的需求会导致迭代的失败，在迭代内花费过多的时间去做需求澄清，因此给进入迭代设立门槛，就是Definition of Ready，简略称之为“DoR”， 最初的Ready是指准备好可以进入迭代开发。Q22：持续规划与设计有什么度量数据或指标用于衡量团队绩效或用于持续改进？如何衡量持续规划与设计的成熟度？A：度量工具推荐Scum的燃尽图、看板的累积流图。研发效能的核心度量数据指标包括团队速率、Lead time，即需求的平均交付时长。Q23：敏捷下的组织过程资产（配置、文档等）这些有好的存储方案么？A：理论上文档、资产等都存储在资产库里，常用的知识库或资产平台有Conflunce、IBM的Rational Asset Manager等。资产和知识是不同的概念，现在做资产管理的相对少一些，知识库可以用wiki等平台，便于统一维护更新和协同。Q24：DevOps 持续规划与设计在DevOps生命周期中是处于开始的时刻，为什么还说代码集成是整个DevOps生命周期的核心呢?A：“代码集成”包括两部分：代码和集成。整个软件生命周期包括三个版本：需求版本，即发版计划；代码版本；上线发布的二进制包的版本。其中代码版本处于承前启后的中间位置，且是唯一真正有价值的。需求和文档是没有价值的，只有由代码编译成二进制包并部署上线才是有价值的。在代码层面多花一些精力是非常有必要的，所有的研发其实都是在一个代码仓库里进行协同开发，包括代码版本管理、分支管理等模式，因此将代码视为DevOps生命周期的核心也是必然的。软件研发最痛苦的地方往往是在集成层面，一开始大家各写各的代码，一旦要将这些不同的代码进行集成的时候，问题就出现了。持续集成的概念来源于XP，“如果代码集成是一件非常痛苦的事情，那我们就每天多次地进行。”一切杀不死你的都会让你更强大，持续地进行集成，你会想办法去减少集成的痛苦。就像跑步一样，假如以前的集成是一块大石头，每天多次集成就相当于将这块石头变成一颗颗的小石子，大石头打在身上会非常疼，小石子就好多了。这也是我们为什么要把集成往前提，并且持续去进行的原因，所以在DevOps生命周期中持续集成也非常重要。【三、持续开发与集成】Q25：如何加强开发人员对于版本质量的信心？A：加强对版本质量的信心，不只是针对开发人员，对所有人都应该如此。整个DevOps的过程其实就是在保障整体的版本质量，包括静态代码检测、接口API测试等。另一方面，版本对需求的映射关系或完成程度，应该从业务场景往下去切，看整个需求的匹配程度。第三点应该是我们通常说的非功能性需求（Non-functional requirements），比如负载、性能、安全、并发支持等，这些要根据我们服务承诺的质量来做相关措施。 Q26：敏捷开发相比传统开发有什么优点？A：我认为最大的优点或特点是敏捷开发更真实，或者说它更愿意承认研发的本质或现状。传统的研发认为质量受三个因素制约：范围、资源、时间，且默认范围和资源投入是相对确定的，时间是变化的。然而，在真实场景或变化的市场下，时间和资源是固定的，没办法讨价还价，因为市场、业务、客户都不会等你，在这样的前提下，软件的需求或范围实际上是可以商量或讨论的，我们要以可变的范围去赢得市场、时间窗口。敏捷开发要求我们不断交付高优先级的需求，并获取反馈，不断调整。这是敏捷开发的最大的核心，承认市场是变化莫测的，需求范围是可变的。Q27：一个产品，既有主线版本，又有很多的行业定制分支（50+），适合什么样的分支策略？A：这种场景在传统的产品里比较常见，个人认为应该考虑的是产品策略而不是分支策略。如果分支非常多，会导致产品碎片化严重。我们在持续集成、持续交付的时候，推崇主干开发或短的分支，不希望这些分支长期存在，否则在产品进行合并时会非常痛苦，工作量也会随着分支的多少和分支存在的时间呈几何倍数增长，所以不建议用长期存在的分支。那可以用什么样的方式来解决呢？首先要看整个版本上是否一定要出现这么多定制化的分支，这些分支有没有可能通过配置文件、功能开放等方式处理或实现。举个例子，我们做项目管理的软件，每个客户要求的字段、功能流转的流程都不太一样，如果都通过代码实现，有多少客户就会出现多少个分支，可能都不止50个。我们是怎么做的呢？针对字段，我可以配置一个界面，里面包括常见属性的字段，这个字段可以是文本类型或下拉框等形式；功能流转的话，新进来一个需求，它的下一个状态是什么、应该触发什么动作、应该是什么样的角色来触发这个动作等这些都是可以进行配置的，这些配置信息存在数据库里，变成用户的配置数据，这样我的主代码主程序是保持不变的，只需要提供一套模型根据数据去驱动适配或实现。这是我们更推崇的方式，可以用来消灭那些分支。Q28：日常项目开发，在代码分支管理上经常疑惑用什么分支管理策略，比如是选择基于生产分支工作流，还是基于环境等等，在实际实践中，我们应该重点考虑哪些因素？既可以兼顾管理效率，又可以确保代码质量。A：个人建议采用分支开发主干发布或分支开发分支发布的分支管理策略。基于环境进行分支构建的话，以前我们会有开发库测试库等仓库管理的概念，但现在全部是持续集成、自动化部署，就没必要再基于环境去拉取分支了。如何保证代码质量，我们在CI/CD流水线、自动化部署和构建的同时需要考虑每一个环境上跑哪些测试，这些测试大部分通过自动化的方式实现，也有少量的是手工进行。Q29：像华为云这样团队成员能力超强、应用场景以线上服务为主，一般会采用什么样的分支管理模式？A：华为云团队也是采用特性分支的管理模式，同时会做多级流水线触发不同环境的流水线来做相关构建，除了开发环境的流水线以外，还有测试、类生产环境等流水线。Q30: 要做到主干上的提交始终处于可发布状态，不受隐含的代码冲突、提交的feature只部分完成等因素影响，对开发团队和基础设施有哪些要求？A：首先主干上提交的流程或质量要严格控制，真正达到DoD（Definition of Done）的标准，这里可能需要一些机制人为地进行管控，比如Committer机制等。提交的时候，除了非功能性的要求，比如跑相关的回归测试、代码检视以外，还有很重要的功能性要求，比如对需求的实现程度的检查。另外“基础设施即代码”，还要看持续集成、持续部署、自动化测试能不能快速有效地跑起来，并保持高度一致。Q31：持续集成的成功因素是什么？ A：持续集成主要包括代码仓库、自动构建、自动部署、自动测试四个方面。要求每人每天都要向主干提交代码，触发自动构建和自动部署，在类生产环境进行自动化测试，同时需要团队每个成员确保清楚正在发生的状况，以此来保证持续集成的成功。Q32：华为云上的CI/CD与K8s上搭的CI/CD有什么区别？A：华为云DevCloud打通了端到端的软件交付全流程，集成了常用的DevOps开发工具，不仅可以完成CI/CD，还可以直接在上面进行项目管理和开发；而K8s只是软件开发中一个单独的工具，没有项目需求管理等功能，需要配合其他工具一起使用才能实现完整的软件开发与交付。Q33：开发和修复bug的工时如何进行安排呢？之前迭代出来的bug是按照单独工时安排，还是统一安排在开发中？A：主要看发版的标准和要求是什么，通常来说可以带病发版，但如果是非常严重的缺陷，就不能上线，必须先修复这些bug。一般bug会跟需求放在同一个池子里，根据它的优先级和影响程度来进行排序，决定是先修复bug还是先做需求。如果修改bug是为了扫清技术债务，建议在一个迭代里固定一定比例的时间来进行。Q34：感觉SaltStack和Ansible中哪个是最好的配置管理（CM）工具？为什么？A：两者定位不一样。个人认为Ansible并不是一个标准的配置管理工具，它更多是通过自动化部署的手段去touch环境这一侧，SaltStack相对来说功能性更强一些。Q35：在代码互评审和评审流程中如何高效的提升代码质量？A：人机结合，将重复性的，比如检查代码风格、命名规则等工作交给工具；人工集中看代码实践的逻辑、对需求的匹配等。将人从重复性的工作中解放出来，节约时间和人力。华为实行代码审查Committer机制，开发人员提交代码后，会自动拉起自动化代码检查。提交一个Pull Request，工具匹配相关的review进行评审和打分，如果是重要实现还可能会有一个评审会议，然后进入最终Committer决定是否将提交的代码合并到主干上去。【四、持续测试与反馈】Q36：“通过持续测试实现快速与高质量“是敏捷测试原则之一，而测试金字塔顶端的一些测试往往依赖许多外部因素，较为脆弱，容易因被测软件之外的因素而失败；且由于这类测试同时测试了软件中的多个模块，定位问题就会更难一些。对于 Flaky tests 怎样处理比较好？删除还是进行标记使其不中断后续的测试且不影响质量门禁？A：Flaky Tests，就是指在被测对象和测试条件都不变的情况下，有时候失败、有时候成功的测试。因此，Flaky Tests实际上就是不稳定的测试，或者随机失败(随机成功)的测试。测试金字塔之所以是正的三角形，核心理念是越往上，即金字塔顶端的测试，其跨度越大，影响面越大，一旦出现问题，爆炸的半径也会更大，在这个层面做测试投入产出较小，工作量大且很难执行，比如测试故障定位等，而且自动化用例的复用程度或稳定性也较差，维护成本也比较高。当然该做的工作一定要做，但相对而言，建议这个层面的测试数量要适当减少。相反，越往底层，比如单元测试，爆炸半径相对就小一些，复用度和投入产出比也更高，而且在这个层面发现的bug应该是最多的。建议金字塔底层的测试措施应该相对多做。中间比如接口测试或跨组件的集成等，如果微服务拆分相对颗粒度小一些，各方面相对就比较好，且接口测试相应的工具也比较多，投入产出比也会越来越大。接口测试也可以多做一些，这样中间层变大，金字塔也会变成橄榄球形。Q37：构建本地持续测试和云上持续测试的对比难易程度和成本，如何选取？A：本地持续测试和云上持续测试的差异在于：本地需要自行对工具和版本进行维护，云上的环境相对快捷。从成本方面考虑，云上是按需的，性能测试、压力测试等适合在云上进行，因为自己去搭建一套10万/100万并发的环境成本非常高；越往前端的测试频度非常高，适合在本地进行构建。另外还需要综合考虑开发人员的使用习惯、公司对于数据的安全要求等进行选取。Q38：从传统的瀑布型测试到敏捷测试再到DevOps，三者之间具体有什么区别？A：瀑布型测试是在开发完成交付以后才进行完整的测试，测试主体是测试人员；敏捷测试往前走一步，做大量的持续集成等实践（如果敏捷实践不只是在管理层面的话）；DevOps是全流程测试，除了测试左移外，还有测试右移，频繁地持续部署到准生产或生产环境上去跑相关测试，甚至还有现网测试，包括混沌工程、Chaos monkey等，其概念更广。DevOps信奉Resilience（韧性），测试这件事很痛苦，我们要频繁地去做。和反脆弱的概念比较一致，“一切杀不死你的让你更坚强”。Q39 在测试自动化环节中应该如何简化测试流程又能快速发现业务风险？A：测试流程未必会简化，所谓的简化应该是指人员参与的流程减少，把大量能够让机器完成的工作交给机器、回归测试等实现自动化，将人从枯燥的重复性的测试活动中解放出来，去做一些新型测试的探索。Q40：SRE和DevOps有什么区别和联系？A：DevOps通常由两种角色去发起，Dev和Ops，即开发和运维。SRE是Google首先提出的一个概念，Site Reliability Engineer（网站可靠性工程师），从Google运维体系出来的一个角色。SRE工程师会通过自动化工具帮助开发人员，以运维的角度去参与研发并提供一些支持，包括开发一些自动化部署及运维相关的工具，通过这些工具和流程使能开发人员。两者比较而言，DevOps概念和范围相对更大一些，SRE则聚焦在开发与运维层面。Q41：在Scrum中只有 Dev team，没有专门的测试团队。“做测试者胜于做检查者”也要求测试人员不仅能发现问题更要准确定位问题。持续测试向价值流持续交付的两端延伸，要求测试人员不仅要懂业务、懂开发还要懂运维，对测试人员的要求很高。在这种背景下，测试人员该如何进行职业发展规划？A：确实测试人员的焦虑相对更多，因为不管流程也好、角色分工也好，他都处于开发和运维之间的位置，像三明治一样，比较难受。换个角度来看，测试是承上启下的活动，DevOps或敏捷在开始的时候都会相对顺利一些，短期成效很快，但等真正进入到测试层面，就像进入深水区，推进变得困难，原因可能就是自动化测试没做好。这样看来测试人员或测试活动其实大有可为，我们强调测试应该是一类活动，分配在整个研发生命周期过程中，而不是中间的某个阶段，因此对测试人员的要求当然也会更高。以往测试人员给人的印象是在研发提交后才参与进来，或者大量通过手工界面的点击去做回归等工作。现在和未来，这类测试人员存在的价值会很低，未来可能会要求测试人员懂业务，从业务的角度设计测试用例；还要懂开发，需要写测试脚本；还要懂运维。其实这些要求对所有的工程师都同样存在，包括开发工程师，要会做架构、做设计、做开发、还可能要自己做测试、部署运维等；运维工程师也是如此，如果转型SRE工程师的话，也要往前段去走。从这点来看，大家都在同一水平线上，所有人都要求往T型人才发展。综上，测试工程师应该是一个全程的质量保障人员，要从专业测试的视角对研发流程、需求、交付等进行质量控制，还需要引入相关实践、开发工具或做工具集成，去赋能开发和运维。真正好的测试对整个团队的帮助和提升应该是最大的。Q42：与传统项目比较，在敏捷项目中，测试工作在整个流程中所占的比重是否更少了，频次更高了，这是否意味着人效更高了？在DevOps流程下，产品人员、开发人员、主导测试人员的比例是否有一个新的经验参考？A：与传统项目相比，敏捷项目中，测试工作比重更大、频次更高、人效也会更高，但这个更高不是通过人去堆，而是通过自动化工具或时间来完成。在DevOps流程下，专职的测试人员数量会下降，现在大量的开发测试是由开发人员来做，在华为内部称为开发者测试，强调开发人员自己去做测试，以前开发测试比例差不多是3:1， 甚至1:1，现在可能是5：1或10:1的比例。产品人员跟以往应该没有太大差异，现在强调产品思维、运营思维，业务运营人员的人数会增加。Q43：小团队（5人，分工：2前端，3后端，没有专业测试人员）需要单独配备测试人员吗，一边开发一边测试，还是每个人对自己代码负责最后一块集中测试。这两种哪种好一些？A：个人认为5人团队没有必要配置专职测试，可以先由开发承担测试，当团队认为需要有一个专业的测试去知道或支持时，再去引入专业测试人员。那端到端的测试谁来做？建议是采用轮岗机制，类似on call，让团队成员轮流去做，这样可以让所有人对完整的测试都有了解和重视。Q44：未来是否会研测一体化？A：我认为研侧一体化会是一个趋势，开发者测试或开发测试的比例会越来越大，且不断往前端延伸，社会分工本就是合久必分分久必合，大分工衍生了一些新的概念，专业的人做专业的事，驱使我们更聚焦于自己的业务本质，比如IaaS（基础设施即服务），运维/环境管理、系统管理等会有专业的人去做，可以看看你是否就是这样一个专职的人才；测试也是如此，比如TaaS（Test as a service），也是一个非常专业的领域，要求懂开发、懂业务、懂运维。再有就是看公司的核心业务是什么，很多公司都不是专门做测试、运维或工具的，我们应该专注聚焦于公司主营业务。【五、持续安全与审计】Q45：如果组织中缺少专业的安全与审计人员，应该如何去补足这方面的能力？A：有些团队会把这个能力转移给相关的SaaS服务平台或第三方厂商。但平台只能提供问题的展现，实际的安全审计处理还需要专人进行。团队规模小时，可以通过业务上的分割和一些工具手段，尽量减轻相应人员的压力。Q46：小团队安全管控得太严格了，对开发测试都会造成很多不便，也会影响问题排除追踪，如何合理度量安全管控？A：项目进入正规化流程后会有很多环境：开发环境、测试环境、类生产环境、生产环境等，可以采用多环境不同程度安全管控的策略，比如在进行开发环境测试时安全管控力度可以松一些，类生产环境测试时安全管控严格一些。【六、持续部署与发布】Q47：持续部署是不是可以做到热部署，不暂停业务直接通过流水线进行部署、提供用户体验？A：持续部署，每一次变化都是直接部署到生产环境里，但持续交付是有一定选择性的，我们可以选择性地把一些需要的东西部署到生产环境中。如果希望可以做到热更新、热部署，不暂停业务，可以通过持续部署的方式，直接使用流水线来实现。Q48：K8s和Docker在应用上有什么区别？A：Docker是一种容器技术，在实践中可以直接使用Docker进行镜像构建等操作；K8s是进行集群管理的技术手段，华为云DevCloud的帮助中心有一个凤凰商城的实践案例，和HCIP考试中的实验一样，只是多了CI/CD的环节，在这个环节中就使用了K8s。Q49：K8S 和 云原生是什么关系？A：云原生是包括微服务、DevOps、容器化、持续交付等理念和方法，K8s只是一个集群管理的工具。 Q50：如果生产环境有等保要求，还有什么办法实现持续部署吗？A：如果生产环境有等保要求的话，不太适合直接做持续部署，这时使用持续交付的方式更好一些，我们可以先决定应该把哪些特性搬到生产环境上去。Q51：新版程序修改了数据结构，如何进行应用设计或部署方案，以应对可能出现重大问题所需要的版本回退？A：当我们做一些比较大的修改时，一般会先部署到类生产环境上，检视没问题后才会通过灰度的方式同步到生产环境中。Q52：我们已经在做持续集成了，但持续交付和持续部署应该怎么落地？A：如果已经在做持续集成，且做得比较成熟了的话，再往前落地持续交付和持续部署会相对容易。我们经常说：持续交付只是持续集成往前的一小步，最后一公里或最后一米会比较痛苦。其实更多的痛点不在于技术层面，而是在于流程、制度层面，可能很难打穿部门墙、穿透企业管控类的要求，这些都未必是技术能解决的问题。【七、持续运维与监控】Q53：通过自动化的方式实现持续集成和持续交付，中间会不会出现干扰而发生错误？A：一般来说，通过自动化的方式实现持续集成和持续交付后，不是很容易发生错误。错误的出现可能是由于配置问题导致的，在配置相应流水线时没有配置好，比如参数出现问题，版本变得不一致等。除此之外还可能会有一个意外导致的问题，比如网络故障等。Q54：如果生产环境要求网络隔离，还有什么办法实现持续部署吗？A：如果生产环境要求网络隔离的话，我们的流水线一般会搭建在公司内部，也就是从提交代码到构建部署都会在公司内部实现。这个过程中使用云上自动化产品会少一些，因为目前大部分云上构建的工具都必须访问公网才可以做到流水线的效果。因此这种环境下，建议在本地搭建自动化构建流水线，或者购买可供私有化部署的工具。也可以在公网进行代码托管和构建，只在部署的时候通过手工部署的方式将软件包放到网络隔离的机器上去。Q55：Docker与虚拟机有何不同？A：从上图可以用比较清楚的看到Docker和虚拟机的异同。左边的VM是虚拟机使用，container是容器使用，也就是我们说的Docker。两边都有server端和Host OS（虚拟机上的系统）。我们知道每个APP上都有Bin/libs，在Docker容器技术环境下，相同的APP可以共用同一个Bin/libs。大大节省了所占的资源空间。【八、DevOps实践与转型路径】Q56：到目前为止，已经学习了很多DevOps的功能，但是有一个困惑，对于使用DevOps是零代码，那么对于专业的开发人员来说，会不会慢慢降低他们的代码开发积极性？A：DevOps提供的零代码是指在整个DevOps工具链中希望是零代码的，通过将一切可自动化的工具自动化，将开发人员从各种维护工作中解放出来，使他们专注于开发。Q57：在DevOps实践中，环境差异的问题需要在哪个环节就开始着手来注意减少或者避免？A：配置即代码，在开发环节配置差异化的时候把环境差异等都配置进去。Q58：在DevOps转型过程中，对组织和团队最有挑战的有哪些？A：我认为DevOps转型最难的有两方面：一是如何争取公司高层同意推动DevOps转型；二是如果请了教练/顾问协助DevOps转型，顾问/教练走后，如何继续保持和落地DevOps实践。Q59：小团队如果想要使用DevOps需要全员学习吗，感觉每个人都学习时间成本挺高的，是否可以专人负责特定阶段？A：团队如果想要进行DevOps转型，需要专门有一个人把这些流程和工具研究明白，或者聘请一位外部DevOps顾问，再由整个专职人员或DevOps顾问在整个团队进行培训和推动。Q60：四个闭环过程中遇到困难或者难点是否可以列举？有什么避免的方案？A：先回忆一下四个闭环过程：l   第一阶段闭环：需求开发测试融合，将产品、研发、测试等角色融合，组建跨职能团队，提升产品交付价值与质量； l   第二阶段闭环：开发测试融合，组建研发部门内部的跨职能团队，提升自动化水平，降低修复成本； l   第三阶段闭环：研发运营一体化，实施产品自运营、自运维，打破了市场、研发、运维部门之间的壁垒，更多角色融入交付链路，提升业务响应力，建立价值反馈流； l   第四阶段闭环：目标是逐步实现所有业务线都以跨职能团队为最小组织单元，实现业务敏捷性，持续提升企业的市场竞争力。难点包括：l   打通需求难。产品侧和研发侧沟通难。在传统瀑布模式下产品和研发的沟通存在很多问题，比如需求沟通不明确等，引入敏捷的计划会议，在计划会议上做需求澄清，可以解决这一难题。l   开发测试融合难。在很多公司这是两个团队，还有些公司没有测试的角色，要进行人员和过程的融合比较困难。l   研发运营结合难。研发运营一体化，运营部分的内容怎么跟开发结合也是一个难点。l   组织结构管理难。整个流程打通了，人员的管理和组织结构的变动方面也可能会存在问题。以上难点需要根据公司具体情况来实践和探索最佳解决方案。+小姐姐微信加入训练营交流群

活动报名链接：https://www.hudongba.com/party/fdfxa.html 活动背景现如今，软件开发和运维领域正在发生巨变，企业为了应对业务的快速变化纷纷加速其数字化转型的步伐。本次以「DevOps 转型与落地实践」为主题的技术沙龙活动由中国 DevOps 社区和华为云主办，将会邀请四位来自不同行业具有丰富经验的演讲嘉宾，共同探讨在 DevOps 潮流下，各公司如何实现转型和落地实践 DevOps，提高研发效能。活动嘉宾董鑫武华为云应用平台布道师，低代码编程技术与开发实战； 20多年软件开发，软件设计从业经验，先后从事电信业务支撑系统，企业级软件解决方案设计和应用开发，在智慧城市、园区等领域具备多个项目成功经验何文强CODING 高级解决方案架构师具有一线互联网、物联网独角兽、全国股份制银行、新型智慧交通等跨行业从业经历，历任Java开发高级工程师、DevOps技术专家、高级研发经理等职，对微服务、敏捷、DevOps、容器技术有深刻的理解和丰富的实践。现任 CODING 高级解决方案架构师，负责 CODING DevOps解决方案架构设计和技术产品布道；负责CODING 云原生技术研究与落地实践。专注于一站式研发效能平台的建设和推广，聚焦于“以应用为中心“的云原生的落地与实践。谢意中国工商银行（澳门）金融科技部技术负责人，程序员，敏捷教练，马拉松爱好者。十余年大型银行开发设计经验。先后在北京、珠海、广州、香港、澳门等地工作。关注团队成长、代码质量、效能提升。 目前致力于在企业中促进敏捷实践和转型、DevOps 落地，受到广泛好评。高俊宁某世界500强金融企业敏捷教练中国DevOps社区广州地区核心组织者，先后任职于金融、教育和互联网金融等领域的科技公司。15年软件行业经验，敏捷DevOps的忠实拥趸，近年主要负责企业和部门的敏捷转型和敏捷落地工作。活动流程 12月26日13点-18点 【13:00-13:30】签到【13:30-13:40】主持人开场及社区介绍【13:40-14:20】议题主题：《ROMA AppCube应用魔方，将复杂留给平台，让开发效率大幅提升》 主讲人：董鑫武在数字化转型大潮下，应用软件开面临构建难、复制难、缺平台的痛点，本期演讲通过从某企业开发的实际痛点切入，介绍华为云怎么解决这些问题，并通过现场实操，展示在智慧园区场景下，如何迅速的开发一个园区车辆管理大屏。听众收益：1.低代码平台如何帮助企业应对数字化场景下面临的挑战；2.低代码平台的适用场景和解决的痛点【14:20-15:00】议题主题：《DevOps 端到端价值流交付的设计、思考与实践》 主讲人：何文强DevOps被看做解放IT生产力的主要动力，从诞生之日起就备受关注并寄予厚望。DevOps经过十余年的探索和发展，涌现出了一大批优秀的工具和工程实践，这些优秀的工具是DevOps的一部分但彼此独立，导致无法形成一个DevOps整体；无法实现系统**，无法进行端到端的打通，进而无法发挥DevOps真正的价值。讲师将从DevOps全局视角出发，**对DevOps的思考和理解；系统阐述端到端价值流交付的价值意义和知识体系；并以 CODING DevOps为参照进行端到端价值流设计。【15:00-15:20】茶歇& 讨论环节【15:20-16:00】议题主题：《促进组织敏捷变革》 主讲人：谢意如何促进组织的变革，包括敏捷等思想的导入。如何让一种新的思想或产品更有效地传播和被接受。银行业敏捷导入的实践。参加 devops 活动的收获等。听众收益：一种实施变革的思路；一种思想传播的途径；参加devops 活动的意义。【16:00-16:40】议题主题：《数字化转型中的教练魔力》 主讲人：高俊宁足球场上我们有穆里尼奥、克洛普这般的足球教练，那在如今如火如荼的数字化转型过程中，教练又在其中扮演着怎样的角色呢？本次演讲将介绍在某世界500强金融企业近年的数字化转型中，各类型的教练角色和教练技能是如何发挥他们的魔力来推进这一项历程，另外还包括了在这实践过程中，有哪些好教练所必备的kata招式。【16:40-17:00】抽奖 & 讨论环节

什么是DevCloud？软件开发平台（DevCloud）是集华为近30年研发实践、前沿研发理念、先进研发工具为一体的一站式云端DevOps平台，面向开发者提供的云服务，即开即用，随时随地在云端进行项目管理、代码托管、流水线、代码检查、编译构建、部署、测试、发布等，让开发者快速而又轻松地开启云端开发之旅。DevCloud产品理念支持云上开发DevCloud提供基于Git的在线代码托管服务，支持代码管理、分支管理、CodeReview等功能，并增加多重安全防护功能，保证核心资产安全。DevCloud推出云端开发环境CloudIDE，集成代码托管服务，支持全容器化开发环境的快速按需获取，支持40+语言在线编码，支持主流语言（Java、C/C++、Python、Node.js等）的在线调试和运行。 实现DevOps持续交付DevCloud提供可视化、可定制的自动交付流水线，将代码检查、编译构建、测试、部署等多种类型的任务纳入流水线，并纳管子流水线，实现任务的自动化并行或串行执行，并充分利用云上资源的弹性能力，大大缩短流水线的执行时间，实现云端可持续交付。 覆盖全生命周期DevCloud覆盖软件交付的全生命周期，从需求下发、到代码提交与编译、验证、部署与运维，打通软件交付的完整路径，提供软件研发端到端支持，全面支撑落地DevOps。 为什么选择DevCloud？DevCloud提供一站式云端DevOps平台，能够管理软件开发全过程，解决了需求变动频繁、开发测试环境复杂、多版本分支维护困难、无法有效监控进度和质量等研发痛点。DevCloud实现了软件研发过程的可视、可控、可度量，让研发能力提升有章可循。管理看板功能让公司软件研发能力可视化，有助于研发能力短板浮出水面；同时支持跨地域协作，客户可以参与开发，让反馈更快速、迭代更便利。流水线功能能够可视化编排，提供一键式构建、部署；提交代码后可自动触发流水线，让软件上线提速一倍。

什么是DevCloud？软件开发平台（DevCloud）是集华为近30年研发实践、前沿研发理念、先进研发工具为一体的一站式云端DevOps平台，面向开发者提供的云服务，即开即用，随时随地在云端进行项目管理、代码托管、流水线、代码检查、编译构建、部署、测试、发布等，让开发者快速而又轻松地开启云端开发之旅。DevCloud产品理念支持云上开发DevCloud提供基于Git的在线代码托管服务，支持代码管理、分支管理、CodeReview等功能，并增加多重安全防护功能，保证核心资产安全。DevCloud推出云端开发环境CloudIDE，集成代码托管服务，支持全容器化开发环境的快速按需获取，支持40+语言在线编码，支持主流语言（Java、C/C++、Python、Node.js等）的在线调试和运行。 实现DevOps持续交付DevCloud提供可视化、可定制的自动交付流水线，将代码检查、编译构建、测试、部署等多种类型的任务纳入流水线，并纳管子流水线，实现任务的自动化并行或串行执行，并充分利用云上资源的弹性能力，大大缩短流水线的执行时间，实现云端可持续交付。 覆盖全生命周期DevCloud覆盖软件交付的全生命周期，从需求下发、到代码提交与编译、验证、部署与运维，打通软件交付的完整路径，提供软件研发端到端支持，全面支撑落地DevOps。 为什么选择DevCloud？DevCloud提供一站式云端DevOps平台，能够管理软件开发全过程，解决了需求变动频繁、开发测试环境复杂、多版本分支维护困难、无法有效监控进度和质量等研发痛点。DevCloud实现了软件研发过程的可视、可控、可度量，让研发能力提升有章可循。管理看板功能让公司软件研发能力可视化，有助于研发能力短板浮出水面；同时支持跨地域协作，客户可以参与开发，让反馈更快速、迭代更便利。流水线功能能够可视化编排，提供一键式构建、部署；提交代码后可自动触发流水线，让软件上线提速一倍。

一、云原生缘起云原生的概念为何在近两年突然兴起？商业模式决定了产品形态，产品决定了研发模式，研发模式又决定了需要采用什么样的技术。传统应用、互联网应用、VUCA时代的应用，所处的不同时代引发的不同需求，由此带来对技术的不同要求。以往传统的应用需求是相对固定的，通常以项目化运作，用户的访问量可以预测，容量是有限的，对停开机的要求也没有那么严格；而互联网应用的特征是，需求持续发展，产品化而非项目制（产品与项目的本质区别是什么？留给读者探讨），用户量并非线性往往会有陡增陡降，7x24小时是基本要求；到现在我们经常讲的VUCA时代，商业边界，业务层面是完全不可预知的，即便是对于互联网原住民都是巨大的挑战，要求快速地尝试、快速探测、快速的感知，应用是服务化的方式提供（服务与产品的本质区别又是什么？同样留给读者探讨），业务敏捷性前提之下，对技术体系的持续发布、分布式海量并发、灰度发布和线上测试都是基本诉求。业务的敏捷性持续发布，应用平台的弹性诉求，商业环境的变化，这是整个云原生产生的时代背景。二、企业应用架构发展历程微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上，其特点有：组件化、松耦合、自治、去中心化 一组小的服务独立部署运行和扩展独立开发和演化独立团队和自治企业的应用架构的演化路径，从单体到网状集成，再到ESB的出现，以至微服务架构分布式集成。架构是服务于应用的，而应用是服务于业务的。整体架构的演进过程，就是前面讲到业务环境变化的体现。三、微服务有高度，采纳需谨慎 Martin Fowler撰文说，You must be this tall to use microservices。微服务诸多的好处不必强调，但微服务并非包治百病，也并非任何阶段任何团队都应该或者可以采纳的。微服务有高度，采纳需谨慎。微服务化所带来架构和开发阶段的便利性，其代价是部署时和运行时的管理复杂性极度增加；整体复杂度不变，只是由开发时转为运行时，此外还带来分布式系统的设计和管理的复杂性。服务拆分解耦的结果，服务可以独立的部署与发布，但运行时服务的治理，包括注册、发现、熔断等，都是需要思考和精心设计的。此外，微服务的小而自治的团队应该如何管理？多小算小？如何定义自治？在架构的去中心化和分布式趋势下，团队的去中心化管理对传统的管理理念则是巨大的挑战。四、云原生能力构建真正做到云原生的成功，我的总结是一个中心三个基本点：1、 一个中心以业务的价值交付为中心，达到快速与高效的交付价值，并且在规模化扩展的同时，兼顾可靠性、灵活性等。2、 三个基本点1）架构层面采用服务化架构/微服务架构实现全面解耦：把系统划分多个功能内聚、粒度合适、业务边界清晰、独立自治的服务/微服务。以（微）服务为单位演进系统架构，演进式的以绞杀者模式，而不是革命式的一次性改造；单个（微）服务以大于一个的无状态进程运行，实现自身的高可用和负载均衡；把业务数据分布到不同的（微）服务中实现数据的垂直切分；通过API，重用云原生公共服务提供的基础能力和架构能力：内部每个（微）服务须充分利用原原生的公共服务提供底层基础能力，例如微服务管控与生命周期管理服务、数据库服务、消息队列服务、缓存服务等；内部每个（微）服务须充分利用应用与资源编排服务，实现部署、配置自动化；通过API，打造生态化经济：API是非常重要的方式，除了定义服务之间的业务边界，更重要的是可以通过API的方式做整个生态，数字化转型中比如开放银行，都是这样的思路，搭一个平台，通过各种合作伙伴在不同的行业、不同的领域提供相关的服务，这些服务是相互进行连接，通过链接和网络的思维来去做这个事情。华为云也在打造自己的API生态。2）工程层面系统与环境、流程、配置解耦：与架构层面解耦相匹配，系统和环境、流程、配置等等需要解耦，工程层面也需要去相应的匹配跟解耦。开发、测试、生产环境等价，屏蔽环境差异性；采纳不可变的基础设施（immutable infrastructure）；构建端到端的DevOps研发体系：研发流程标准化、敏捷化；严格的区分构建、分布、运行的准入准出，并进行版本化和自动化；全自动化测试（单元测试、集成测试、自动生成Mock依赖服务）；一切皆代码，代码、配置与环境严格分离，并进行版本化和自动化；（微）服务持续交付流水线（按需发布版本）；研发运维一体化：运维和开发互相融合，高度协同，共担职责；自动监控，持续可视化反馈，并最终传导到开发团队；按需实时部署、配置热加载实时生效；使用自服务、敏捷的云化基础设施服务：基础设施以自服务的方式对开发团队提供。依赖底层云化基础设施的计算服务、存储服务、网络服务提供基础运行资源；使用云监控服务监控自身的运行状态包括基础资源使用状态、自身业务运行状态，同时根据自身运行状态触发相应的运维事件，实现弹性伸缩、故障自愈等关键架构特征；核心度量外部指标：业务层面的核心的一个业务指标叫TTM，在DevOps有另外一个词叫Lead Time，就是你的前置时间，从业务需求提出来那一刻起，到这个业务需求上线的时间叫前置时间，这个是可以被客户可知的，所以是端到端的业务指标。技术层面，对应的有多个前置时间，工程这一侧的，则是从提交代码那一刻起，一直到代码上线，这段时间是完全工程可控的，理论上应该是控制在分钟级。这个指标，也是华为云最为看重的一个。3） 组织层面遵循康威定律：应用的架构和组织架构之间是高度的匹配，单体的应用，逐渐到服务化的方式，到逐渐分布式的模式。组织架构也是转移到自组织，没有一个唯一的中心在里面，自组织团队的敏捷性与多样性需要兼顾。整个团队的规模，典型的就是5-10人规模。全功能团队：从全功能团队一直到云化的运维团队。以服务为单位组织整个团队，涵盖设计、开发、测试、发布、部署、运维全流程职能；开发人员、发布工程师、IT和运维之间可信合作云化运维团队：基于云平台的提供的监控、报警等能力，成立专门的团队负责系统运行时的质量，保障系统可用性和业务无中断的升级、回滚自主经营，面向服务的全生命周期：逐渐转型为自主经营的全功能团队。除了技术栈是全功能以外，每一个服务化的团队都需要面向服务进行全生命周期的考虑，除了技术层面的怎么样去产品的设计、开发出来部署，架构层面保持优美，更多的还需要去考虑商业层面的东西，需要考虑服务定位，考虑产品上线以后，运营层面应该做什么事情，应该做什么样的拉新的活动，怎么样促活，怎么样留存。整个团队都需要有商业思维和产品运营的思维。这是整个思维上的转变，去考虑这个服务为什么这么做、谁去用、用的场景是什么，怎样完成商业的闭环。五、持续交付实施框架关注七大领域，持续优化交付粒度，加快交付速度，提升交付质量。云原生架构与DevOps的落地与转型，需要从团队模型、分支模型、测试模型、技术架构、部署模型、基础设施、数据库模型等七大领域进行相应的匹配。上图是以发布频度为抓手，从100天发布一次，逐步的十倍速增长，到10天发布一次，在两个阶段点，从七个维度来看，需要匹配与采纳的实践是什么。所以这是一张能力演进的地图，我们可以清晰的看到自己业务当前所需要的发布节奏是怎样，当十倍速的走到下一个节点，方向在哪里，有的放矢的进行相应的采纳。与此同时，这也是一个量变到质变的过程，持续优化交付粒度，加快交付速度，提升交付质量。从100天发布1次，到最后的1天发布100次，10000倍的增长，回过头来看，就是一个升维的过程。六、云原生时代的DevOps体系框架云原生时代的DevOps体系框架，也需要从商业决策上由基于Gate（Charter/DCP）的业务决策，转变为基于OBP的周期性审视；从服务化组织上，支持E2E全功能团队，开发运维一体化，对团队充分授权；从架构上进行服务化解耦，支持按服务小包独立交付；从开发和运维流程上，加强开发与运维的协同，支持更短的周期，更快的反馈； 从IT工具环境上，重用已有的成熟工具，引入先进的开源和商用软件，实现轻量级端到端DevOps工具链；从服务流程上，支持服务的独立交付，自动化的环境部署。作者简介姚冬华为云应用平台部首席技术布道师，资深云计算、DevOps与精益敏捷专家。中国DevOps社区核心组织者，IDCF社区联合发起人，《敏捷无敌之DevOps时代》，《DevOps业务视角》，《敏捷开发知识体系》《DevOps最佳实践》等书作（译）者。华为云HCIP DevOps Engineer构建者, SAFe SPC规模化敏捷咨询师, CSM, Management 3.0，Facilitation for Agilists，DevOps沙盘官方授权教练，埃里克森认证教练。

【HCIP职业认证专场】DevOps之持续测试与反馈将在今天16号晚上20:00精彩开启！大咖讲师+干货实战+惊喜抽奖价值300USD职业认证考券，荣耀魔方蓝牙音箱，折叠背包，京东卡，丰厚好礼等你来拿！立即点击，码上报名！直播间地址https://bbs.huaweicloud.com/live/DevRun_live/202012162000.html训练营链接：https://edu.huaweicloud.com/activity/Career-Certification.html有抽奖的哦！快来！快来来！！！！

DevOps开发正在成为热点与趋势，你对DevOps开发了解多少呢，快来完成测评吧~（1-15为单选，16-20为多选，每小题5分，满分100分）活动时间：12月16日-12月31日点击参与测评赢码豆-＞＞DevOps开发者测评：初级能力测评③大福利福利1：答题得60分即可获得200码豆 → 问卷提交后自动显示分数，码豆自动发放，点击会员中心查看码豆-＞＞https://devcloud.huaweicloud.com/bonususer/home/converge?from_region=undefined福利2：邀请≥5人完成测评还可再得1000码豆→提交问卷后，点击分享按钮，按照步骤提示生成专属邀请海报，邀请好友完成测评，参与者可看到邀请数据实时更新~完成问卷提交即可发起邀请，与本人测评分数无关，奖品数量有限先到先得哦~此奖项不可累计获得。（生成邀请海报步骤往下看~~~）福利3：加入DevOps职业认证训练营，专家讲师全程陪伴学习，还可打卡赢300美金考试券&码豆等大礼→想学习更多DevOps开发的理论和实操知识，加入DevOps职业认证训练营吧，持续规划与设计、持续开发与集成、持续测试与反馈、持续安全与审计、持续部署与发布、持续运维与监控等6大板块内容覆盖端到端DevOps开发全流程，还有DevOps专家全程1V1辅导，每日打卡赢积分换奖品，还还有机会获得300USD考试券哦~了解详情戳＞＞DevOps职业认证训练营↓↓↓ 添加助手小姐姐 回复“DevOps”进课程群或了解更多活动信息~会员中心入口：https://devcloud.huaweicloud.com/bonususer/home码豆奖励活动规则：1）码豆可在码豆会员中心兑换实物礼品；2）邀请好友参加的码豆奖励将于1月11日前充值到账，请到会员中心的“查看明细”中查看到账情况；3）码豆只能用于会员中心的礼品兑换，不得转让，具体规则请到会员中心阅读“码豆规则”；4）为保证码豆成功发放，如果修改过账号名还请向工作人员提供修改前后的账号名。活动规则补充说明1.若转发他人分享的专属海报，则本人无法享受邀请奖励。2.被邀请好友必须完成测评（完成测评后点击提交即可，得分多少不限制），每个华为云账号只能被邀请一次。3.本活动需要邀请人和被邀请人正常访问评测页面完成活动，使用非正常途径或手段（如写脚本等方式）获得的奖励无效，且一旦发现作弊行为，将取消对应人员的活动资格、冻结违规账号。4.最终邀请奖的获奖名单将于1月5日公布于活动帖中，奖励码豆将于1月11日前充值到账。5.任何问题反馈请添加小助手微信咨询。*活动解释权归华为云开发者社区所有。附【邀请好友方法】生成邀请链接和邀请好友参加方法如下（以下截图以另一活动为例）第一步：完成问卷填写，并提交。第二步：在问卷结束页，点击下面那个黄色按钮“邀请好友答卷 免费领取...”第三步：点击之后，会提示你需要在浏览器中打开分享页面，请点击右上角“...”按钮，选择“在浏览器打开”第四步：在浏览器中打开会显示如下页面，保存您的专属海报图片，分享出去即可，只要有朋友也答卷完成，即可获得相应的礼品和抽奖资格。后续也可以再打开此页面，查看你的邀请进度（页面最下方）。

 摘要：架构的选择对于DevOps的实践是至关重要的，从某种程度上来说，架构就是DevOps这场战役的粮草，它是支撑着DevOps成功落地的重要前提。善用兵者，役不再籍，粮不三载。取用于国，因粮于敌，故军食可足也。——《孙子兵法》在古代，带兵作战的将领，不仅要能善于用兵，而且要能保障粮食的充足。正所谓兵马未动，粮草先行。粮草永远摆在第一位，因为在冷**时代，战争中的将士都是在拼力气，吃饱才有力气打仗。在今天互联网的“战争”环境中，我们为了能更快的应对市场变化，一直以来不断调整着作战的方针和打法，也从传统的开发方式转变为了敏捷开发，由敏捷开发又过渡了到DevOps。在2019年的中国DevOps行业报告中指出：“尽管受访企业期望 DevOps 能够带来更高效的交付效率，提升客户满意度，创造更多的商业价值，但成功实践 DevOps 依然是一个难题 。”其中28.22% 被调查者认为自己组织的 DevOps 实践是不成功的， 41.13%的被调查者不清楚如何衡量自己组织的 DevOps 实践是否成功。如果以一个更加直观的数据来展示，就是在接受调查的企业中有69.35%是没有能很好的了解和实践DevOps的。也许，在实践DevOps的这几年来，并没有多少公司是真正知道什么是DevOps的。DevOps只是从字面上理解的打破部门墙的一键发布的工具链吗，是否有了这个工具链就是DevOps？答案是否定的。那么，DevOps是什么？DevOps 是集文化理念、实践和工具于一身，可以提高组织高速交付应用程序和服务的能力，与使用传统软件开发和基础设施管理流程相比，能够帮助组织更快地发展和改进产品。这种速度使组织能够更好地服务其客户，并在市场上更高效地参与竞争——AWS从AWS给出的定义来看，好像也还是比较的抽象。那如果简单的来说，DevOps就是让软件过程既“快”又“稳”。何为快和稳，这个快和稳体现在，部署频率、交付周期、平均修复时长、变更失败比例这4个维度上。在2018年的DevOps调查报告中基于上述4个维度，由于仅有6%达到了所规定的高性能指标，为了避免特殊原因造成数据过低，所以放宽的条件，并给出了准高性能DevOps指标。从达成这一准高性能DevOps指标的团队分析来看，其具体体现在三个方面：一方面是自动化、标准化、质量保证、敏捷方法的实践活动上；一方面是DevOps各个阶段的对应工具上。除此以外就是，团队正在开发应用的架构上。架构的选择对于DevOps的实践是至关重要的，从某种程度上来说，架构就是DevOps这场战役的粮草，它是支撑着DevOps成功落地的重要前提。受访的准高性能DevOps指标的团队将“使用微服务框架”作为团队正在开发应用的架构上的Top1。什么是微服务是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。微服务的起源是由 Peter Rodgers 博士于 2005 年度云计算博览会提出的微 Web 服务 (Micro-Web-Service) 开始，Juval Löwy 则是与他有类似的前导想法，将类别变成细粒服务 (granular services)，以作为Microsoft下一阶段的软件架构，其核心想法是让服务是由类似 Unix 管道的访问方式使用，而且复杂的服务背后是使用简单URI来开放接口，任何服务，任何细粒都能被开放 (exposed)。这个设计在 HP 的实验室被实现，具有改变复杂软件系统的强大力量。2014年，Martin Fowler与James Lewis共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通信。同时服务会使用最小的规模的集中管理 (例如Docker) 能力，服务可以用不同的编程语言与数据库等组件实现。微服务的特点根据Martin Fowler的分析，微服务架构有以下的一些通用特性，但并非所有微服务架构应用都必须具备所有这些特性：通过服务实现应用的组件化(Componentizationvia Services)：微服务架构中将组件定义为可被独立替换和升级的软件单元，在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。围绕业务能力组织服务(Organizedaround Business Capabilities)：微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的（如：既管应用，也管数据库）、强搭配的DevOps开发运维一体化团队，通常这些团队不会太大（如：亚马逊的“Two pizza team”- 不超过12人）。产品而非项目模式(Productsnot Projects)：传统的应用模式是一个团队以项目模式开发完整的应用，开发完成后就交付给运维团队负责维护；微服务架构则倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期，倡导“谁开发，谁运营”的开发运维一体化方法。智能端点与管道扁平化(Smartendpoints and dumb pipes)：微服务架构主张将组件间通讯的相关业务逻辑/智能放在组件端点侧而非放在通讯组件中，通讯机制或组件应该尽量简单及松耦合。RESTful HTTP协议和仅提供消息路由功能的轻量级异步机制是微服务架构中最常用的通讯机制。“去中心化”治理(DecentralizedGovernance)：整体式应用往往倾向于采用单一技术平台，微服务架构则鼓励使用合适的工具完成各自的任务，每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。微服务的技术标准倾向于寻找其他开发者已成功验证解决类似问题的技术。“去中心化”数据管理(DecentralizedData Management)：微服务架构倡导采用多样性持久化(PolyglotPersistence)的方法，让每个微服务管理其自有数据库，并允许不同微服务采用不同的数据持久化技术。基础设施自动化(InfrastructureAutomation)：云化及自动化部署等技术极大地降低了微服务构建、部署和运维的难度，通过应用持续集成和持续交付等方法有助于达到加速推出市场的目的。故障处理设计(Designfor failure)：微服务架构所带来的一个后果是必须考虑每个服务的失败容错机制。因此，微服务非常重视建立架构及业务相关指标的实时监控和日志机制。演进式的设计(EvolutionaryDesign)：微服务应用更注重快速更新，因此系统的计会随时间不断变化及演进。微服务的设计受业务功能的生命周期等因素影响。如某应用是整体式应用，但逐渐朝微应用架构方向演进，整体式应用仍是核心，但新功能将使用应用所提供的API构建。再如在某微服务应用中，可替代性模块化设计的基本原则，在实施后发现某两个微服务经常必须同时更新，则这很可能意味着应将其合并为一个微服务。微服务适用的场景基于微服务的优势，我们可以看到，微服务比较实用于以下场景：对于业务流程较为复杂，且业务会变得逐渐复杂的项目，可以考虑使用微服务架构项目存在多个团队（公司）多种开发语言时核心业务和非核心业务变得泾渭分明需要平滑升级时（服务无中断、客户无感知）想对系统进行细粒度监控时 （bug调查困难或性能等问题）既然微服务有其使用的场景，那么也一定有其优缺点。微服务的优势微服务的诞生正是在互联网高速发展，技术日新月异变化以及传统架构无法适应快速变化等多种因素共同推动下的必然产物。从一个网站的演变可以看到使用微服务后带来了很多优点，总结如下：逻辑清晰：这个特点是由微服务的单一职责的要求所带来的。逻辑清晰带来的是微服务的可维护性，在我们对一个微服务进行修改时，能够更容易分析到这个修改到底会产生什么影响，从而通过完备的测试保证修改质量。简化部署：微服务则可以只对一个微服务单独进行部署，不影响其他功能的同时，在效率上也得到了提升，从而快速的发布新的功能。可扩展性强：在分布式系统中，采用微服务的系统相对单块系统具备更好的可扩展性。灵活组合减少浪费：在微服务架构中，可以通过组合已有的微服务以达到功能重用的目的，减少了重复浪费。技术异构：微服务间松耦合，不同的微服务可以选择不同的技术栈进行开发。微服务的缺点以往单体应用，排查问题通常是看一下日志，研究错误信息和调用堆栈。而微服务架构整个应用分散成多个服务，定位故障点非常困难。在微服务架构中，一个服务故障可能会产生雪崩效用，导致整个系统故障。微服务架构虽然逻辑设计上看是完美的，但就像积木搭建的华丽宫殿一样，经不起风吹草动。微服务架构虽然解决了旧问题，也引入了新的问题：提高了系统的复杂度，此外还有：服务的注册与发现问题；服务之间的分布式事务问题；数据隔离再来的报表处理问题；服务之间的分布式一致性问题；服务管理的复杂性，服务的编排；不同服务实例的管理。微服务在使用上是一把“双刃剑”，这就像粮草如果在搬运的过程中被敌方夺取，那可能会是毁灭性的。所以DevOps团队在微服务的架构上需要非常的重视，一个成熟度高的微服务框架才是实现其DevOps的重要前提，反之亦然。

01  课程介绍《软件开发平台DevCloud介绍及实战》  课程简介本课程主要内容包括：软件发展历史及趋势，华为敏捷开发、DevOps实践。  课程目标通过本课程学习，使学员：1、熟悉软件行业趋势挑战及软件开发云解决之道；2、熟悉敏捷开发DevOps知识体系；3、通过应用开发场景，熟悉软件开发云产品功能。课程大纲   第1章 软件开发云概览   第2章 软件开发平台 DevCloud详述《7天玩转性能&接口测试实战营》及实操课程简介：本期课程依托华为云DevCloud，以实践操作为课程基础，使学员掌握DevOps持续自动化测试、接口测试、单接口测试、多接口组合场景、网站性能测试、CI/CD持续自动化测试等能力。体验性能和接口测试的整体流程，汲取自动化测试的核心知识。课程大纲：第1章 Day1 DevOps持续自动化测试概述第2章 Day2 接口测试基本原理第3章 Day3 设计单接口测试第4章 Day4 设计多接口组合场景测试第5章 Day5 性能测试基本原理第6章 Day6 性能测试策略和指标分析第7章 Day7 测试金字塔原理和CI/CD持续自动化测试《黑白棋沙箱实验》通过动手体验，学习基于华为软件开发服务DevCloud构建部署黑白棋游戏应用。使用软件开发服务DevCloud实现代码仓库管理，使用软件开发服务DevCloud实现编译、构建、部署。02 学习任务&奖励要求【学习完成时间】 2020.12.5 -2020.12.31【学习任务】参与训练营，必须先开通DevCloud套餐获取实操资源！！点击直达DevCloud基础套餐订购地址>>>序号任务详情课程入口1完成《软件开发平台DevCloud介绍及实战》课堂进度任务完成方式：在本帖中，回复自学课程完成进度回复格式：课程名称+华为云ID+课程完成截图（露出右上角华为云ID）点击前往2完成《7天玩转性能&接口测试实战营》课堂进度任务完成方式：在本帖中，回复自学课程完成进度回复格式：课程名称+华为云ID+课程完成截图（露出右上角华为云ID）        点击前往3完成课堂作业任务完成方式：在classroom课堂提交7天作业点击前往4完成《黑白棋实时对战游戏开发沙箱实验》任务完成方式：在本帖中，回复沙箱实验完成进度回复格式：华为云ID+沙箱完成截图每日名额有限，请尽早完成。实验环境暂时存在问题，建议于12月14日后再启动。       点击前往03  直播预告12月5日 10:00-12:00开班直播课-软件DevOps开发之项目管理>>>12月13日 13:30-14:30直播课-软件DevOps开发之代码协同开发之如何优雅的解决校园小团队的代码协作问题12月16日  20:00-21:00直播课-DevOps之持续测试与反馈

GitOps通过使用成熟的DevOps优秀实践（包括：版本控制、代码审查、以及CI/CD管道等），提供了一整套自动化的管理方法。本文向您介绍GitOps基本原理、组成与优势。如今，许多团队都在各种项目中争相使用着诸如：版本控制、代码审查、以及CI/CD管道等，与DevOps有关的优秀实践。不过，您是否注意到，这些方法主要针对的是软件开发生命周期中的自动化。而在涉及到基础架构的设置和部署时，项目团队仍然主要依赖的是手动的过程。对此，GitOps提供了一套管理基础架构的自动化方法。项目团队可以借助GitOps，并通过使用各种声明文件，将基础架构编写为代码(infrastructure as code，IaC)，进而自动化配置的过程。也就是说，我们可以像存储应用程序的开发代码那样，将基础架构存储放在Git存储库中，以提高整体的交付能力和产品质量。GitOps的工作原理GitOps的概念最初是由Kubernetes管理公司--Weaveworks(请参见https://www.weave.works/)提出的。众所周知，基于容器的应用往往比较复杂，而且难以进行配置和管理。因此，GitOps主要针对的是：在Kubernetes背景下，如何将编排平台转换到运行在容器中的微服务上，并采用DevOps领域的成熟技术，来协助简化该过程。下面我们将深入讨论GitOps的各个主要组成部分：基础架构即代码(IaC)如前所述，IaC可以通过将各种声明性文件存储为代码，进而实现基础架构的配置和管理。据此，通过利用IaC和版本控制，项目团队可以优化当前的各项操作进程。此处提到的声明式(Declarative)，意味着您的配置将不再是一组命令，而是对某种预期状态的声明。例如，在Kubernetes中，您可以在清单文件(manifest)中定义服务所需的Pod数量。系统将通过自行处理，获取所需的容器编号，而无需工程师额外编写命令脚本。在此，任何符合声明性模型的云原生软件，都可以被视为代码。通常，我们会将各种所需的状态声明为代码，并通过系统应用的更改，以自动化的方式实现目标状态。例如：我们可以使用诸如AWS CloudFormation之类的声明性工具，来编写AWS的基础架构。拉取请求(Pull Requests)GitOps概念背后的主要思想是：版本控制系统是唯一的来源。我们既可以将Git用作应用代码的变更管理系统，通过拉取请求来实现各项操作性的变更，又可以将其用于基础架构的代码上，以便将整个声明文件集中于一处。在应用开发的工作流中，我们需要将某个主分支作为发布分支。在此基础上，开发人员会从主分支处创建各个功能性分支，以便开发出特定的功能或故事线。而在功能性分支上，一旦完成了更改，他们会通过创建拉取请求的方式，重新合并回主分支。这样一来，我们就可以在方便实现协作的同时，透明地获悉到谁在何处进行何种更改。而且，由于所有更改都是在Git处被提交的，因此这对于开发团队从根本原因处进行问题的跟踪，也是非常实用的。可见，创建拉取请求的好处在于，我们可以让代码在被集成到代码库的另一个分支之前，事先经历代码的审查过程。而代码审查恰好能够阻止各种不良的代码，进入测试或生产环境。显然，这对于故障的消除，以及基础架构代码而言，都是非常重要的。Git的组成GitOps并不依赖于任何工具或技术。它可以与诸如：GitHub、BitBucket或GitLab等，任何基于Git的系统协同使用。而在部署过程中，GitOps至少需要两个存储库，即：包含了应用源代码、及其部署清单的应用程序存储库;和使用着每个环境的声明性规范描述的，包含了整个系统目标状态的环境配置存储库。您可以在代码存储库中将目标环境定义并描述为开发环境、测试环境、生产环境、或是包含了运行着特定版本的应用和基础架构服务的环境。CI/CD要实现完整的GitOps，您势必需要一个CI/CD管道，以实现Git存储库在每次发生更改时，开发团队都能将对应的基础架构变更交付到指定的环境中。该自动交付管道能够将Git的拉取请求连接到编排系统中，以便通过请求来触发管道，并让编排系统执行指定的任务。一般而言，GitOps有两种可能的部署策略：推送管道和拉取管道。您可以根据当前架构需要部署的实际环境，在两者间做出选择。下面我们来具体看看两种策略的各种特点：推送管道(Push Pipelines)目前，许多流行的CI/CD工具都在使用这种策略。开发人员通常将应用程序的源代码、及其部署清单存储在一个存储库中。当应用代码发生变更时，管道将触发容器映像的构建，并将变更推送到相应的环境中。由于该策略支持任何类型的基础架构，因此它具有较大的灵活性。不过，其缺点是：它会赋予CI/CD工具对于目标环境的写入权限。基于推送的DevOps部署拉取管道(Pull Pipelines)在开发者社区中，人们普遍认为：对于GitOps的拉取管道方法是一种更安全的策略。这种方法引入了操作符(operator)的概念。它是管道和业务流程工具之间的组件。操作符能够不断将环境存储库中的目标状态，与已部署的基础架构的实际状态，进行比较。如果操作符检测到任何修改，那么它就会更改基础架构，以适应环境存储库。同样地，它也可以监视镜像注册表，以识别出需要部署的镜像新版本。基于拉取的DevOps部署可见，在GitOps中，只有在环境存储库中出现修改时，对应的环境才会更新。相反，如果已实施的基础架构在环境存储库中并未定义任何方式的修改，那么系统将会自动还原。在实际项目中，大多数应用程序都会同时涉及到多个环境。对此，GitOps允许您创建多个管道，以同时更改多个环境存储库。当然，您也可以在环境存储库中使用单独的分支，来管理多个环境。我们既可以通过将操作符部署到生产环境中，来对单个分支的修改及时做出反应，又可以通过部署到测试环境中，来响应另一个分支。GitOps的优势由于GitOps专注于Git工作流、IaC、CI/CD管道，不可变服务器(immutable servers)、跟踪、以及可观测性等优秀实践模型，因此它代表了对于Kubernetes云原生应用管理的高级状态。据此，开发团队可以从如下方面受益：简化持续部署顾名思义，持续部署(https://microtica.com/cracking-the-continuous-deployment-code/)意味着更快、更频繁的部署。通过GitOps，部署操作符提供了必要的结构和自动化，而且这一切都在版本控制系统中发生，因此我们无需各种工具，便可管理系统的状态、停机时间、上游/下游依赖关系、以及其他与组织相关的流程。此外，GitOps不但提高了项目团队的生产率，而且加快了他们的平均部署时间(Mean-time-to-deployment，MTTD)。有证据表明，自动化持续部署能够确保团队每天触发30到100次以上的变更，并将生产环境的性能平均提高2到3倍。缩短平均修复时间(Mean-time-to-repair，MTTR)MTTR是衡量DevOps团队绩效的一项关键指标(https://microtica.com/13-devops-metrics-for-increased-productivity/https://microtica.com/13-devops-metrics-for-increased-productivity/)。由于GitOps保留了版本控制系统中的所有修改，并且能够实现自动化的管理，因此，开发团队能够全面了解目标环境中的变化，轻松发现和修复错误，从而显著降低MTTR。简化Kubernetes管理在无需透彻了解Kubernetes的情况下，开发人员可以使用Git等较为熟悉的工具，更加轻松地管理Kubernetes的升级和各项功能。据此，新加入的成员也能够在几天时间快速上手Kubernetes。全面掌握并标准化工作流由于GitOps提供了一站式的应用程序、软件、以及针对Kubernetes修改的框架，因此开发团队可以清晰地洞悉整个项目的端到端工作流，并能通过Git来完全复现日常的业务运营活动。GitOps的实现建立稳定的代码审查与测试过程。通过仔细地检查代码的更改，我们能够及时发现诸如全局变量的添加等操作，并且可以通过提交拉取请求(而非直接提交更改的方式)，来验证代码。而在拉取请求被检查与合并之后，管道才会被触发。此举在避免发布错误的代码的同时，有效地保持了高标准的代码，以及系统后续的稳定性。持续测试。合并到GitOps中，往往意味需要通过高级的自动化机制，对待发布的应用程序进行彻底的测试。有了GitOps，我们不但能够相对轻松地实现回滚，还能够通过良好的测试用例，保障代码的质量和可靠性。专注监控。GitOps允许开发人员重复各项操作流程，改进、发布并回顾各种可追溯的系统状态。而通过专注于监控，我们可以识别并防止任何意外的漂移(drift)、以及系统配置的变更。因此，在开始使用GitOps之前，开发团队有必要检查自己的监控水平，以及处理变更的能力。拥抱文化。作为目前在开发领域的优秀战略，DevOps文化能够促进团队的共同协作，更有效地管理基础架构的稳定性，更快、更流畅地执行应用程序。而GitOps又能够让我们在此基础上，进一步理解开发和运营的协同价值，提供一整套自动化的管理方法。小结作为一种非常好的工作流模式，GitOps不但可以帮助我们有效地处理云基础架构，还能够为工程团队提供：更好的协调性、透明度、稳定性、以及系统耐用性等方面的诸多好处。原文标题：GitOps – DevOps for Infrastructure Automation，作者：Sara Miteva   来源：51CTO.com  陈峻