DevOps 敏捷 60 问，一定有你想了解的问题

摘要：问题覆盖了规划设计、开发集成、测试、部署发布、运维监控等 DevOps 落地实践中的关键疑点与难点。

“DevOps 的价值是又快又好地交付软件”

——《凤凰项目》的作者 Gene Kim 和《持续交付》的作者 JezHumble

当前数字化转型的形势下，软件行业面临着巨大的市场机遇，而软件系统复杂度不断增加，跨地域高效协作、多环境部署等问题也逐渐突出，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：先回忆一下四个闭环过程：

· 第一阶段闭环：需求开发测试融合，将产品、研发、测试等角色融合，组建跨职能团队，提升产品交付价值与质量；

· 第二阶段闭环：开发测试融合，组建研发部门内部的跨职能团队，提升自动化水平，降低修复成本；

· 第三阶段闭环：研发运营一体化，实施产品自运营、自运维，打破了市场、研发、运维部门之间的壁垒，更多角色融入交付链路，提升业务响应力，建立价值反馈流；

· 第四阶段闭环：目标是逐步实现所有业务线都以跨职能团队为最小组织单元，实现业务敏捷性，持续提升企业的市场竞争力。

难点包括：

· 打通需求难。产品侧和研发侧沟通难。在传统瀑布模式下产品和研发的沟通存在很多问题，比如需求沟通不明确等，引入敏捷的计划会议，在计划会议上做需求澄清，可以解决这一难题。

· 开发测试融合难。在很多公司这是两个团队，还有些公司没有测试的角色，要进行人员和过程的融合比较困难。

· 研发运营结合难。研发运营一体化，运营部分的内容怎么跟开发结合也是一个难点。

· 组织结构管理难。整个流程打通了，人员的管理和组织结构的变动方面也可能会存在问题。

以上难点需要根据公司具体情况来实践和探索最佳解决方案。

本文分享自华为云社区《【FAQ】DevOps 敏捷 8 大领域 60+常见问题解答》，原文作者：Cynthia 成。

点击关注，第一时间了解华为云新鲜技术~