简介：云计算产品大多都会与云原生产生关联，云原生正在重塑整个软件的生命周期。但到底什么是云原生？云原生带来的最大技术创新和将来机会是什么？围绕云原生，是否能够构建出一套云上的开发 & 运维体系，打造新一代研发平台，实现研发效率的最大化？
作者 | 神秀
起源 | 阿里技术公众号
云计算产品大多都会与云原生产生关联，云原生正在重塑整个软件的生命周期。但到底什么是云原生？云原生带来的最大技术创新和将来机会是什么？围绕云原生，是否能够构建出一套云上的开发 & 运维体系，打造新一代研发平台，实现研发效率的最大化？
咱们邀请了阿里云云效研发平台负责人神秀，分享团队对于高效研发运维体系构建的流程和方法论。文章包含三个局部：首先从问题登程，剖析在团队业务逐渐壮大的过程中可能会遇到的问题，以及这些问题对团队效力的影响。而后联合问题看下什么样的效力体系可能满足团队效力晋升的诉求。最初介绍阿里云云效团队对效力晋升办法的一些总结。
一 团队效力的影响因素
1 团队效力的影响因素
首先探讨下企业人员规模增长对效力的影响。刚开始公司初创期，十几二十人组成全功能团队，此时团队分工边界并不明确，大家在一个十分麻利的状态下工作，相互会进行一些补位，比方技术去做一些产品的事件，开发去做测试和运维。这种状况下团队合作起来基本上没有太多沟通损耗。往往瓶颈在集体能力上。此时初创团队为了更快的实现业务需要，在效力工具抉择上更关注单点效率，比方好用的流水线工具、测试工具等等，上手门槛是第一思考的因素。
当团队逐渐扩张，人员分工开始专业化，多职能协同的问题开始凸显进去。如何单干，权责如何调配，大家之间的合作流程是怎么的，是团队十分关怀的问题。此时团队并不太会因为集体能力而决定产品的成败，如何晋升中位能力是关键问题。此时在效力工具的抉择上会更偏差于有肯定解决方案的产品，比方分支管理模式，测试环境管理模式，DevOps 如何落地等等。这些工具的应用能够很大水平去晋升团队之间透明度，晋升沟通效率。比方分支管理模式的抉择，解决开发与测试团队沟通的问题，DevOps 模式更是将绝大部分运维工作交给开发独立实现，从而通过缩小沟通来晋升效率。
随着团队业务进一步扩充，开始呈现有显著业务边界的产品，此时在沟通合作老本会被进一步放大，大家更加器重指标、共识和后果。当然能够以战斗模式去承载指标、共识和后果，是十分好的一种汇聚人力资源，topdown 的晋升执行效率的伎俩。从另一面也要意识到，战斗并不能解决所有边边角角的跨产品、跨团队协同问题，如何在日常状态上来解决这种兵力调配、业务技术拉通的问题才是要害。
2 软件服务架构对研发效力的影响
接下来看另一个问题，就是服务架构对研发效力的影响。服务架构其实和组织架构有很强的关联关系，比方在扁平化架构下，团队各自独立相互关联性不强，有很高的自给率，这里的自给率是指独立实现某个需要的能力。
在网状架构下组织模式往往是一体式的，由同一个部门老大率领，团队之间紧密配合，我中有你，你中有我。在这个阶段架构复杂度高，不足形象。然而因为业务流程绝对简略，做起需要来各团队点对点沟通也不是太大问题，决策链路短，共识快。从另一方面看，技术债权也在累积，当业务之间耦合到肯定水平的时候就会呈现保护债权的人力投入开始大过新需要人力投入。中台架构是解决此问题的一个门路。
到中台模式下，各种业务模块开始被形象进去，随之技术侧也须要组建技术中台，将原来各自团队持有的工具开始收敛，流程开始对立。不过随着前台和中台呈现分工后，各自倒退路线独立设计，此时就会呈现部门墙、前台业务自给率低、达成优先级、交付工夫等共识很艰难的问题。
通过这三种产品架构、技术架构、组织架构的剖析，置信大家能够了解团队一直演进过程中面临的效力困局。
3 技术演变带来的效力变动
说完了合作问题，再来看技术的演变是如何影响研发效力的。先粗略的看看过来几年的几个技术变动。在 2008 年开始业界提出了微服务、继续交付、DevOps 等等一系列的概念，连续至今。与此同时阿里巴巴也对电商外围零碎进行了服务化革新，起初又发现服务多了，治理呈现了难题，只有 DevOps 能够打消瓶颈，开释生产力。这几件事其实外部是有肯定逻辑的，也就是业务驱动技术改革，技术促成架构改革，架构又推动研发模式改革。
再看最近几年日益昌盛的 k8s 生态，大致相同，新技术的利用，造就了很多新的架构模式比方 serverless，小程序等，这些新的架构给原有的研发模式也带来了微小挑战，比方在 Function as Services 模式下如何治理代码分支和环境，测试工具和办法会不会发生变化，测试团队的职责会不会发生变化等等。当然，大家能够再构想下，当将来服务数量进一步爆炸，架构复杂度进一步晋升，这种复杂度超过人的掌控时，会呈现什么样的变动，咱们须要应用怎么的工具去解决那个时候的效力问题。
4 企业研发效力的制约因素
联合下面从人员、架构、技术三方面的剖析，在进一步提取两头的关键因素，会造成这样的一个环。这三个关键因素就是老本、人、和人与人之间的协同损耗。老本是不可能有限放大的，所以是这个环外面的最要害束缚。另外因为人的能力参差不齐，那么就无奈发明出完满的架构和完满的组织设置，这外面就会呈现大量的协同耗费。方才也提到了，技术债权是会累积的，协同耗费往往会随着工夫一直放大，耗费更多的人力，在固定的老本束缚下会导致更少的业务人力投入。这个环就会呈现负反馈，也就是越来越差。所以才有了探讨研发效力这个问题的必要性。
通常会采纳技术去武装人，晋升集体能力下限，这是笔者认为的重要破局点。接下来须要适应以后团队组织和架构现状的协同流程，去升高损耗。须要留神的是这往往只能带来改良，在固有架构和组织模式不变的状况下很难基本上扭转场面。最初能够应用一些工具去让咱们的工作更有效率，以前手工做的当初自动化去做，能够腾出更多工夫去聚焦业务价值输入。
三管齐下后就能够无效驱动这个环进入正反馈，团队效率更高，技能晋升更快，协同更加顺畅，业务倒退好了又能够投入更多的人力老本。
在阿里本身的实际中发现，就是在在一直地扭转这些因素，遇到瓶颈投入改良，走出负反馈，进入高速倒退，而后又遇到瓶颈。
那么这些问题如何系统化的被晋升或者解决，就须要一套适宜的效力工具体系。
二 效力工具体系的建设思路
1 三种典型的研发团队
在咱们的实际中会能够演绎出以下三种典型的研发团队。
- 第一种是前后台的利用开发，电商、SaaS 等都是典型的状态。这种业务状态在工程侧比拟容易标准化，工具比较完善，尤其是云原生技术的倒退，让业务的关注点更加向上转移，底层技术越来越云化，越来越黑盒。
- 第二种是底层根底软件研发，业务特点是用户交互简略，但技术深度和复杂性较大。这种软件往往是有状态服务，并且对硬件基础设施有强依赖，以至于在运维侧就较难标准化。另外在开发侧也存在技术栈简单，多人在一个模块集中研发的状况，较难像前后台利用那样通过服务拆分进行解耦放慢迭代，同时也衍生出比方分支治理、二进制版本治理等新问题。这种开发态和运维态的差异性导致了工具体系的差别。
- 第三种是线下交付型的大型软件研发，以混合云、行业软件为代表的。因为零碎耦合简单，叠加客户专有环境因素，对多团队协同能力和交付运维零碎能力要求很高。绝对于第一种前后台利用开发，对版本治理、集成降级、近程运维能力特地关注。
2 分层建设效力体系匹配简单协同场景
因而，面对不同的研发场景，不同的侧重点，须要对效力体系进行分层和形象。在这里能够把整个体系分为 4 个档次，从下到上是根底底座、工具层、协同层、场景化。
在根底底座中应该关注产研外围资产的数据积淀，确保整个体系的数据一致性，通常会提取研发体系中外围对象进行下沉，比方团队、我的项目、利用、代码、制品等。
之上是最要害的工具层，工具定义为解决单点问题的自动化伎俩。其中开放性和被集成性应该是工具最重要的能力。比方常说的 api first 就是这个情理。
再往上是协同层，这一层产品聚焦于解决人和人之间的信息传递问题，以及将这种协同流程进行线上化、标准化。通过对不同畛域协同关系的形象，并且串联单点工具，最终让使用者们能够在线实现一个残缺的工作。
通用性、可配置性和体验有时候是矛盾的，因而还须要场景化层的产品去解决各自畛域的精细化用户体验问题。能够看到最近几年业界的趋势就是如此，通用的研发平台在一直成熟和做深，而场景化研发平台一直产生，通过集成上层工具能力，疾速笼罩细分研发场景。
目前云效正是依照这个分层思路在建设研发工具体系，心愿能够将更多开发者纳入到这个体系中来，一起构建这个简单的生态系统。
3 每个团队定制本人的效力计划
公司除了提供标准化的研发流程体系以外，每个团队都应该有本人的效力计划来满足本人团队的文化和习惯。在这里能够有这两三个层面能够去提供定制。
一个是团队工作台，这是团队的常识积淀场合和协同空间。外面提供多种视图来浏览工作状态以及待办事项、进度等。还会为 leader 提供一些列管理工具。
另外两个是团队协同流程和工具，举荐大家深刻学习效力晋升办法、团队治理办法，并且联合团队现状，个性化到零碎中，甚至翻新出更适宜业务特点的工具，逐渐开释团队生产力潜能。
通过对立平台能够守住团队效力的上限，然而效力下限须要团队本身的致力来冲破。
4 进一步的效力晋升倡议
基于以上剖析，笔者提出以下三个倡议：
- 第一个是团队须要着眼于从指标、业务、产品、研发全流程进行效力晋升。举个例子，一个问题：测试团队如果成为交付瓶颈，是不是齐全是测试团队的责任？很显然，这外面可能是需要侧用户链路剖析不全面，或者开发团队交付品质差，更或者是架构设计不合理导致可测性不强等等，这些都会减轻测试团队累赘，让测试团队成为瓶颈。因而团队负责人须要端到端的去思考，把握办法并具备宏观视线，而不是头痛医头脚痛医脚。
- 第二点是团队须要为本人的效力负责，是第一责任人。本人最理解本人的团队，往往采取的措施也是最无效的。
- 第三点是晋升团队产品设计能力、技术能力，缩小技术债权，构建内建品质对效力晋升十分重要。效力工具体系只能提供最根底保障，要让团队效力更衰弱，须要从最根底的软件工程细节动手，逐渐改善，在这方面没有银弹。
三 效力办法体系的演进
1 从强调工具流程走向强调价值交付
当团队分工开始细化当前，从组织角度更加专业化，资源效率更高，然而从业务价值交付的角度来看，周期十分长，而且两头还随同着各种期待。
因而能够得出这样一个论断就是部分效率，并不代表能够高效的交付业务需要。部分效率有很多工具和伎俩去晋升，这是一个绝对收敛的问题，甚至能够通过加班去补救效率的有余，然而高效的交付用户可能感知到的业务价值并不容易做到，下面这张图就阐明了这一点。同样也并不代表能够继续的高效交付，因为从根源上没有方法保障永远用全局最优的组织和架构以及流程去对应，甚至没有机制去发现瓶颈问题。当然也并没有方法去答复业务胜利问题，因为业务团队与产研团队间隔过远，这种部门墙阻断了产研去思考和了解业务胜利与本人产出的关系。
2 实现端到端可见的业务价值
所以笔者认为效力晋升首先要做到的就是端到端可见的业务价值。从业务团队到产研团队有以下几个施行门路。首先是建设以业务价值流为视角的合作链路。以往多半是通过项目管理软件解决产研团队的合作问题，以一个产品或者团队为单位组织需要、缺点、工作等等。在新的体系中须要将业务团队也纳入其中，并且拉通业务价值与产品研发需要、工作之间的关系，从而实现端到端通明可视。
在产研侧驳回大量自动化工具依然是根底工作，除此之外须要将工具产出的数据可能链接到价值流上，并且尽量积淀到数据平台。这里能够采纳比较简单的评判办法，比方有多少百分比的工作是在线实现的，是否有对立的数据模型去积攒数据。
在后面两步实现后，依然要解决对齐业务、产品、技术团队指标的问题，比方业务诉求的优先级是什么，工夫点是什么，其中的各环节瓶颈是什么，并且在过程中实时追踪。各环节负责人能够感知到异样事件和资源瓶颈，第一工夫去着手解决，达到高效的目标。
第三步要做到继续高效，肯定要基于后面积攒的数据去量化剖析，此时数据的魅力失去展示，越多的工作在线，剖析会越精确。哪个团队在积攒债权，哪个团队在积攒资产，哪个团队是阻塞点，是调整架构还是调整组织分工，这种决策会更加有效率。
3 ALPD—新一代的精益产品开发方法
基于以上的剖析，再联合了精益思维、云思维、以及架构设计思维等多方面，能够构建进去的一套办法体系。
这个图蓝色局部是本文关注的重点。其中分为三个局部，全链路数字化的精益合作，解决业务和产品技术协作问题。第二局部是畛域驱动为外围的技术实际，解决日益简单的架构问题。第三局部是云原生的工程实际，用这套工程实际去进一步开释云原生对每一个业务开发者的红利。
4 全链路的精益合作
首先全链路的精益合作。之所以称为全链路是在这个办法中将业务、产品、技术等多种角色全副纳入。最要害的是分层理念，分为业务、产品和技术三局部。别离对应业务和指标治理、需要和产品治理和团队交付视图。
在这个模型下，配合一系列高效率在线化工具，让尽可能多的工作在线实现，数据以价值流为外围串联和透明化，最终达成精益合作的指标。
5 畛域为外围的技术实际
再来看畛域为外围的技术实际。这里分为三个局部，剖析、架构以及对应的实现。别离为业务引领的领域建模、畛域驱动的微服务架构、以及契约导向的软件实现。
畛域模型的设计是产品以及架构设计的外围，良好的设计能够轻松地解决技术团队的变更、测试、交付耦合问题，晋升零碎可测性和可运维性，并且通过一些防腐设计，升高技术债权对整个零碎的影响。
6 云原生的工程实际
最初是云原生工程实际。这张图把工程实际分为了三个局部，最底层是不可变基础设施，两头是继续交付流水线，最上层是品质守护体系。
重点在两头红色局部，也就是 GitOps Engine，用这个引擎来全面落地所谓的以利用为核心的 IaC 体系。笔者认为 IaC 的设计是开发者对云的运维界面和应用办法的重大重构。通过代码这种最合乎开发者习惯的模式，叠加凋谢更多自定义能力，能够进一步开释云原生的技术红利。
原文链接
本文为阿里云原创内容，未经容许不得转载。