共计 15065 个字符，预计需要花费 38 分钟才能阅读完成。
摘要：问题笼罩了规划设计、开发集成、测试、部署公布、运维监控等 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 成。
点击关注，第一工夫理解华为云陈腐技术~
