【.com原稿】随着互联网行业的快速发展，IT研发的工作方式变得更加灵活多变。从应用的角度来看，从最初的单一服务应用到现在的微服务应用，处理的数据量和类型也在不断增加。图片来自Pexels从团队的角度来看，不仅包括开发人员和测试人员，还包括运维、安全、系统、网络等各个专业的人员。所以在新时代，我们如何用DevOps（开发运维）方法论来指导交付流程就显得尤为重要。我们将从DevOps的两大要点和三大原则入手，看看组织、团队、流程的最佳实践。DevOps的两大要点和三大原则做任何事情都有它的价值。做事的过程就是“将经营理念转化为客户价值的过程”，我们称之为价值流。对于研发团队来说，还有一个技术价值流。就是通过“开发+运维”的敏捷迭代，为用户提供价值。技术价值流是第一点。通过开发维护的方式，帮助商业创意触达客户需求。如果我们把创造价值流的工作分为两个阶段：第一阶段是设计和开发，第二阶段是测试和运维。价值流创造的两个阶段在这个阶段，交货期是客户提出需求的时间总和，我们创建工单来解决这个需求，然后处理工单，直到工作完成。作为第二点的交货时间是值得我们关注的。部署工作的前置时间和处理时间通常需要经历从设计、开发、测试、运维等诸多复杂而漫长的过程。交付过程复杂而漫长。我们要实现的是在代码版本控制中不断提交小批量的代码，每次提交都会做自动化编译、自动化测试、手工测试（探索性测试），然后部署到生产环境。为了实现这一目标，需要尽可能地缩短设计、开发、测试、发布时间，为客户提供最大的技术价值流。基于以上两点，以下三个DevOps原则是最好的选择。流动原则为了缩短从开发到上线的时间，提高服务质量和可靠性，我们将加快开发（Dev）和运维（Ops）之间的流动。让我们来看看需要注意什么。①岗位可见度与传统行业相比，软件开发行业的岗位可见度不高。通常只有完全完成后才能看到可以使用的用户界面，有些后台服务甚至连完成后的样子都看不到。但是人们很难控制看不见的东西，所以我们需要将工作可视化。在敏捷开发中，我们会划分每个阶段的任务，协助完成项目推荐和软件开发。开发、运维、UAT、交付过程同时，我们要告诉团队，我们的工作还没有完成，直到软件交付给用户，为用户带来价值。②限制每个人同时承担的任务数量。你是否经常遇到这样的场景？当你在开发某个功能的时候，你的测试同学给你报了个bug，急需解决，同时产品经理过来说这个需求可能需要再改，架构师会也跟大家聊聊重构。这导致一个人同时处理许多事情，每件事情都很重要，需要立即完成。就像摊了一个大馅饼，什么都做好了，什么都做不好。你会经常被打断，在任务之间切换，从而降低工作效率。因此，需要用看板来控制每人的任务量，使任务数量保持合理，从而保证质量和效率。一个人承担多个任务③降低batchsize我们在开发过程中经常会遇到这种情况，一件事情包含四个步骤，我们需要完成100个这样的事情。所以，按照抽象分工的原则，我们把这件事情分成了4个步骤，每一步都分配给一个人来完成，这样每个人每个步骤完成100次，这件事情就完成了。这种方法没有错，但是在做的初期，最好先一个人完成这件事的四个步骤，看看有没有潜在的问题，看看有没有什么结论是可以的可以在完成过程中总结经验和需要踩的坑。这样来来回回好几次，解决了一些问题之后，再一步步找其他人帮忙。这种方法广泛应用于快速试错的互联网公司。先完成闭环流程，再复制经验④减少交接次数我们在完成一项任务时，往往会与其他团队和人员进行大量的沟通、请求、授权、通知、协调等工作。例如：在软件发布过程中，需要面对功能测试、集成测试、环境搭建、服务器配置、存储管理、网络等工作。如果凡事都需要审查，协调必然会降低工作效率。互联网公司的扁平化管理在这里可以借鉴。每个团队包括技术、业务、管理等不同领域的人员，减少了跨部门的沟通，提高了工作效率。减少交接⑤识别和改进约束在软件开发和交付过程中存在很多约束，包括：人员、时间、软件、服务器、网络等。在DevOps中也是如此。我们需要不断地识别这个约束，并不断地改进这些约束，以推进整个开发的进程。允许约束点和环境构建之间平滑过渡：推荐使用自动环境部署，利用现在的容器技术（Docker）来提高整个环境的构建速度。代码部署：推荐自动化代码上传、编译、部署。软件交付团队每天都在执行这些操作。开发团队的人越多，这项工作就越需要完成。测试执行：这是上一点的后续。软件一旦发布，就需要跟进自动化测试。使用自动化脚本测试至少20%的核心功能，然后让测试人员冒烟测试特定功能。随着软件功能的扩展，测试工作量也会相应增加。如果不使用自动化测试，靠人工测试工作量很大。解耦架构：随着微服务的流行，设计基本都是组件化的。如果某个组件出现问题，采用了故障隔离和熔断机制，所以也需要针对该组件进行释放。反馈原则如果说流程原则是指从开发到运维的快速流动，那么反馈原则就是从运维到开发的快速反馈。这两个原则反复运作，以向客户提供最好和最快的软件服务。①及时发现问题一个服务/产品的交付经历了从需求分析、原型设计、架构设计、编码、测试、发布、集成测试、验收测试到上线等诸多过程。工人参与每个阶段。任何问题都是有原因的。即使无法避免问题，也可以在第一时间发现并暴露问题。比如产品经理分析不透彻，在开发的时候就会遇到需求不明确的问题。这时候程序员可以提问，产品经理需要明确需求。发现问题，反馈问题，解决问题流程图②解决和分析问题有这样一种情况，开发中发现的问题，在需求和设计中没有提到。如果置之不理，显然会影响系统的运行。如果我们采取与自己无关的态度，那么问题永远不会被发现，那么我们应该如何处理问题。第一，上游环节出现问题，一定不能带到下游环节。解决上游链路问题。上行链路有问题。二是暂停上游环节工作，避免新问题继续出现。发现问题及时处理第三，建立PDCA循环，计划（Plan）、实施（Do）、检查（Check）、改进（Action），避免此类问题再次发生。建立PDCA机制③从源头保证质量什么是源头，相比下游，上游才是源头。产品经理是开发的源头，需求质量不够会影响代码。程序员是测试人员的来源，如果程序质量有问题，就会影响测试；测试人员是客户的源头，如果所有的问题都被忽视，那么就无法为客户带来价值。因此，保证货源就是保证交货质量。要注意监控每个过程和阶段：需求阶段：需求评审、需求确认、需求呈现。开发阶段：代码审查、结对编程、单元测试。测试阶段：冒烟测试、回归测试、验收测试。发布阶段：自动配置、自动部署、自动检测。溯源图④客户同理心客户分为两种，内部客户和外部客户。外部客户就是通常意义上的客户。我们为客户提供软件交付，满足客户需求，为客户创造价值。内部客户是我们的下游。产品经理将开发人员视为客户，开发人员将测试人员视为客户。当我们做出任何行动，发现任何问题，做出任何决定时，我们都必须考虑我们的“客户”是否对他们有利。我们要站在客户的角度看问题，很多问题马上就解决了。客户在哪里，从客户的角度学习原理。学习原理是对前两个原理的支持，是基本原理。无论你在工作中踩了多少坑，无论你在编码过程中遭受了多少失败，都不要忘记学习。不断学习使人更强大，团队逐渐成熟。①建立学习型组织架构在服务传递过程中，再细心也难免出错。每个人都有背锅的经历。比如产品经理没有说清楚某个需求，程序员在实现的时候忽略了。交付时，这是程序员的错。之后，项目经理会发誓批评开发商。这种场景在我早期的工作中经常遇到。后来随着越来越多的项目被带进来，我发现这种“指责”的解决问题的方式是不对的。我们应该从问题本身出发，找出问题的原因。综上所述，明确的流程和机制将防止兄弟们犯类似的错误。如果把组织分为三类，我希望我们应该是有机的（学习型）组织。组织类型分类病态的：组织成员感到极大的恐惧和威胁（害怕做错事）。为了自保，大家都不愿承担责任，甚至隐瞒真相和事实。官僚型：规矩多，流程死板，每个人自己刷门。活力型（学习型）：不断从错误中总结，不断学习，不断进步。大家积极探索，勇于承担，乐于分享。有机组织是我们的目标②日常工作制度化这里的制度化不是官僚的繁文缛节，相反，这些制度的出现是兄弟们在工作中总结的经验教训，转化为制度的。原因是希望其他兄弟不要再踩这些坑了。比如我们之前发布的时候，总是忘记发布数据库脚本，导致生产环境的程序无法运行。后来，我们把更新数据库的脚本写进了发布系统，作为发布前必须做的事情。后来在自动化发布中写成自动化脚本。其实在工作中也有很多好的经验。如果我们注意，我们可以建立这样一个持续改进的机制，成为一个默契的系统。其实在我们平时的编码中，有很多东西是可以很好总结的。例如：编码规范、命名规范、标准MVP/MVC/MVVM编写、发布流程、测试用例、测试脚本。系统为流程服务③本地化体验全球化在开发/运维的过程中，我们经常会遇到各种事件（坑）。这些事件要么很容易解决，要么困扰了我们很长时间。但是在最终解决之后，我们希望把这些经验放到知识库中保存下来，这是我们共同的经验财富。其实一个项目做完之后，问问自己在这个项目中学到了什么，就是这些经验的积累。当你在寻找下一份工作时，面试官问你遇到的最困难的问题是什么，你可以自豪地分享那段经历。再小的经验，放到大局中，对其他技术人员，甚至跨部门的技术人员，都会有启发和帮助。运用知识库管理的经验④注入弹性模式这里说的弹性有两个意思，一个是指人员的弹性，一个是指我们维护系统的弹性。项目冲刺需要人员的灵活性，需要长征的韧劲，需要冲过大渡河的勇气。在项目不忙的时候，也需要不断的总结和学习新的知识。每个人的成长都可以带动整个团队的成长。为了项目的灵活性，采用压力测试的方式，对维护的系统进行正负压力测试，探索我们系统的承受能力的极限，从而进行改进。团队弹性和系统弹性DevOps组织结构根据康威定律，软件架构与软件团队结构是一致的。这就是康威定律对团队和架构的诠释。我经历了团队从小到大的发展历程。早期人少的时候，工作流的概念不强。一个人做多个角色的事情，基本没有沟通成本。软件架构基本上是一个单一的应用程序。后来随着开发、测试、运维人员的增多，整体要处理的工作量也随之增加。为了便于管理和项目推进效率，将人和事进行分工，规定团队间的流程和沟通方式。架构也从原来的单体应用变成了后来的微服务，数据库也从原来的单体数据库变成了分表分库的模型。组织结构决定了软件架构开发、测试、运维的集成度。在开发过程中，开发、测试、运维属于不同的专业，在项目推进过程中各司其职。在DevOps的组织架构中，三者需要相互融合。开发完成后，需要通过单元测试和结对编程，以保证代码的质量。测试需要发现/验证bug，配合运维完成压测/性能测试。你会发现现在很多大厂的一线运维人员都来自于开发团队，甚至很多公司都鼓励开发人员和测试人员参与运维工作。让他们感受到自己的工作对下游工作的影响。开发、运维、测试相互融合。DevOps团队建设团队成员相互依赖。了解了DevOps的组织结构之后，需要团队哪些成员参与呢？产品负责人：业务方的代表，你可以把他想象成客户。开发组：负责具体的功能开发。QA团队：负责质量保证。运维团队：维护生产环境，配置，发布。信息安全团队：负责系统和信息安全。当然，你可以根据自己公司的需要，在此基础上增加一些管理和支持团队。对于初创公司，如果没有运维和信息安全团队，建议找开发组的小哥。团队价值流多个团队协同工作，沟通和统一认知存在问题。价值流图就是为了统一大家的思想，让每个团队成员都知道在什么阶段需要做什么。其实这些图在之前的文章中也有介绍，无非就是配合团队和舞台。团队价值流图在线工作如果团队要站在同一个平面上，使用高效的工具是必不可少的。例如：Confluence、GraphiteDocumentation、Jira、ZenTao、ProcessOn、Jenkins、Bamboo、Git、JMeter、LoadRunner。它们可以帮助我们提高设计、开发、测试和发布各个阶段的工作效率。保持团队高度统一，所有工作保持在线。让工具为团队服务，在线工作DevOps流水线部署团队的宗旨是为客户创造价值。那么将软件交付给用户的过程就像是工厂的流水线。流水线的上游是原材料，经过加工后输出的就是产品。作为DevOps的流水线部署，这个过程需要自动化。作为交付团队，每次写完代码，都需要提交版本库。提交后，repository将编译（build/Build）整体代码并执行单元测试代码。如果失败，错误信息将返回给交付团队，程序员修正错误后重新提交代码。通过后才发布到测试环境进行自动化脚本的测试。另外，如果自动化测试失败，还是会送回开发团队重新修改。这个过程会不断重复，直到它通过用户验收测试并被发布。DevOps流水线提交阶段：是从技术角度判断系统能否工作。此阶段编译并运行单元测试脚本，通常由程序员自己编写。另外，对于具体的代码，有经验的程序员会进行代码走查或者代码互检。这里可以使用Junit单元测试工具。自动化验收测试阶段：从功能和非功能的角度断言整个系统在工作，即从系统行为的角度，满足用户的需求，满足客户的要求。人工测试阶段：用于判断系统是否可用，是否满足其系统要求，并尽量发现自动化测试无法捕捉到的缺陷。这部分测试内容比较复杂，步骤较多，甚至需要多系统切换。这个阶段通常包括探索性测试、集成环境测试和UAT（UserAcceptanceTesting，用户验收测试）。测试人员根据UAT的用例测试系统。发布阶段：目的是将软件交付给用户。就是直接将其应用部署到生产环境中。部署完成后，进入运维阶段。按流水线部署的好处是可以控制每个阶段的交付质量，逐步建立交付方的信心，通过层层筛选将问题拒之门外。同时，也是对开发、测试、运维人员的考验。他们需要大量的协同工作，不断让应用在流水线上流动，并及时反馈给不同位置的玩家。在熟悉了流水线的几个阶段之后，我们来看看每个阶段产生什么数据，数据是如何流动的。①流程的起点是开发人员向代码库提交代码。在Checkin代码之前，开发者需要将代码库中的相关代码和组件下载到本地，以保证修改后的代码能够在本地编译。比较规范的公司需要申请CodeReview，让其他同事走一遍代码。虽然Checkin到代码库后，平台会自动运行单元测试。但是我建议你先做单元测试。因为，一旦进入验收阶段，编译就会耗费大量的时间。如果出现问题，系统会生成错误报告并发送给TeamLeader或项目组。如果你当时改了代码，恐怕大家都知道这个bug是你出的。因此，最好先在本地运行单元测试。它的范围包括您在其中修改代码的模块，以及其他模块。事实上，对代码的任何修改都可能影响其他模块，即使您不修改其他模块。持续集成管理系统响应这次代码提交，从指定的代码库中拉取代码，编译，运行单元测试，进行代码分析，组装打包。如果单元测试通过并且代码符合编码标准，则可以将其打包成可执行文件并放置在工件存储库中。今天的持续集成服务器提供这些功能，并允许用户和管道的后续阶段以简单的方式进行。此外，还有Nexus和Artifactory等工具来帮助管理流程工件。目前比较成熟的产品。例如Bamboo和Jenkins可以通过配置代码库、成品库、脚本命令来完成上述操作。②第二阶段通常由运行时间较长的自动化验收测试组成。这些测试的主要内容是针对一些API和模块的测试。一些项目组也用它来做页面测试，但我个人不建议做页面自动化，尤其是在页面设计的初期，页面元素变化频繁，自动化脚本变化大，效果不是很好。在此之后，部署流水线可能会分支，这样构建就可以独立部署到几个不同的环境，比如用户验收测试环境、容量测试环境和生产环境。还有DEV（开发）环境、INT（集成测试）环境、MO（准生产）环境、Prod（生产）环境等系列实例。通常我们希望测试人员或者运维人员能够做到自助服务，即手动选择自己需要的某个版本。例如：可以使用Bamboo或Jenkins在成品库中选择应用版本，然后发布到指定环境。所谓自动化部署脚本就是可以在服务器上运行的一行命令，执行命令完成部署工作。测试人员应该能够看到所有需要手动测试的构建，它们的状态，然后单击一个按钮运行适当的部署脚本，将选定的构建部署到选定的环境。提交验收阶段总结DevOps模型需要遵循三个原则，快速流动，及时反馈，持续学习。因此，DevOps的组织架构需要开发、测试、运维的紧密配合。按照这个标准建设团队，让团队产生价值流，通过线上工作为用户提供价值。DevOps的价值体现在流水线的部署方式上，需要合理配置提交、验收、人工测试和发布阶段。让应用快速流动，让团队得到及时的反馈，从而稳步推进软件交付。作者：崔浩简介：十六年开发架构经验。曾在惠普武汉交付中心担任技术专家、需求分析师、项目经理，后在一家初创公司担任技术/产品经理。善于学习，乐于分享。目前专注于技术架构和研发管理。【原创稿件，合作网站转载请注明原作者和出处为.com】
