深圳网站搭建电话,目前流行的网站开发工具,网站建设合理流程,个人域名备过案了做电影网站会查吗简介#xff1a; 本次分享主要由四部分组成#xff1a; 1、企业在成长过程中遇到的研发效能困境#xff1b; 2、研发管理从信息化走向数字化的路径#xff0c;以及背后的逻辑#xff1b; 3、云原生和 AI 两项新技术在研发平台上的落地#xff1b; 4、结合阿里巴巴自身案例… 简介 本次分享主要由四部分组成 1、企业在成长过程中遇到的研发效能困境 2、研发管理从信息化走向数字化的路径以及背后的逻辑 3、云原生和 AI 两项新技术在研发平台上的落地 4、结合阿里巴巴自身案例分享如何进行研发管理数字化落地。 2020 年 12 月 23 日阿里巴巴资深技术专家陈鑫神秀在“2020 云原生实战峰会”的“互联网 CTO 数创先锋营”闭门会议中为现场的数十位互联网公司 CTO 及技术专家分享《数字化时代如何构建下一代研发协作工具平台》。本文整理自神秀的现场分享为方便阅读内容有删减
本次分享主要由四部分组成 1、企业在成长过程中遇到的研发效能困境 2、研发管理从信息化走向数字化的路径以及背后的逻辑 3、云原生和 AI 两项新技术在研发平台上的落地 4、结合阿里巴巴自身案例分享如何进行研发管理数字化落地。
1 企业成长与研发效能
**
企业研发效能的制约因素 在“互联网 CTO 数创先锋营”闭门会议分享中阿里巴巴资深技术专家陈鑫神秀从人员规模增长、软件服务架构、技术演化三方面系统地分析了企业研发效能的制约因素并从中提炼出三个关键因素成本、人以及人与人之间的协同损耗这三个因素构成一个“环”。 如下图所示 陈鑫认为成本是不可能无限放大的所以它是这个“环”中最关键的约束。而因为成本原因企业往往不能雇佣足够优秀的工程师甚至需要采用外包团队去完成业务开发因此人员的技能不足是常态。又因为人员的能力参差不齐甚至无法满足技术要求的所以就无法创造出完美的架构和完美的组织设置这就会出现大量的协同消耗。技术债务是会累积的协同消耗往往会随着时间不断放大消耗更多的人力在固定的成本约束下会导致更少的业务人力投入。这个环就会出现负反馈也就是越来越差。
那么如何走出负反馈进入高速发展呢通常我们会采用技术去武装人提升个人能力上限这是重要破局点。接下来需要适应当前团队组织和架构现状的协同流程去降低损耗。需要注意的是这往往只能带来改进在固有架构和组织模式不变的情况下很难从根本上改变局面。最后可以使用一些工具去提升工作效率以前手工做的现在自动化去做就能腾出更多时间去聚焦业务价值输出。
三管齐下后就可以有效驱动这个环进入正反馈团队效率更高技能提升更快协同更加顺畅业务发展好了又可以投入更多的人力成本。
寻找下一阶段效能突破的路径
从本质出发去思考以上提到的“研发效率”问题可以拆分为“协作效率”和“单点效率”两方面的问题。解决“协作效率”问题我们需要去思考如何找到组织瓶颈做到有的放矢组织和架构复杂度发展到一定程度后就会形成盘根错节的协作问题。此时改进的重点其实并不是如何解决而是找到优化的重点方向并且能下钻到具体问题进行突破最后能看到所采取措施的结果。小团队的问题显而易见而大团队的问题仅靠感性认知判断往往无法直达本质。
“单点效率”方面很好理解其突破核心在于新技术和新工具的应用如何释放新技术带来的效能红利是技术团队始终要去做的事情。
结合以上两个方面阿里云云效产品的使命就是让企业能具备研发敏捷和组织敏捷的双敏能力。做到这一点的路径就是研发管理数字化转型。
二、研发管理从信息化到数字化
研发管理的信息化与数字化 先抛出两个问题什么是研发管理数字化以及研发管理数字化与信息化的区别。
如下图所示左边是目前各企业通常的做法第一部分项目协作在这个版块主要解决的是多工种的信息流转问题和知识沉淀问题。第二部分是软件开发开发测试人员会采用各种各样的工具去完成手头的工作比如编写、评审、联调、测试等等。第三部分是交付运维需要把编写好的软件顺利的发布到线上给用户使用。 当前有很多工具可以完成这些工作按照这个流程从上到下逐步推进即可。但这里面有两个问题 这些工具都是人参与其中的人在推进这个流程中起到了关键作用而工具只是优化了人的一部分工作。
我们更关注过程而不关注这些过程所产生的数据对企业的价值。这些信息成为了一个一个孤岛散落在各处。其实在业务领域做数字化转型时核心本质问题都大体类似。
陈鑫认为 打破信息孤岛是研发管理数字化的关键具备以下几个特征 首先是面向业务价值的这是企业做所有研发活动的终极目标。
第二是全局透明化不管是业务还是产品、技术都可以掌握全局信息这也是打破信息孤岛的直接好处。
第三是加速信息流转提升协作效率。
第四是度量驱动可以全局的看到效率瓶颈并有效去解决避免头痛医头、脚痛医脚。
第五是智能加持这也是数字化后的一大魅力人工智能技术辅助甚至代替人去工作可以从根本上提升效率。
从强调工具流程走向强调价值交付
如下图所示当研发团队分工开始细化以后从组织角度来看更加专业化资源效率更高但是从业务价值交付的角度来看周期非常长而且中间还伴随着各种等待。 因此可以得出一个结论局部效率高并不代表我们可以高效的交付业务需求。 我们有很多工具和手段去提升局部效率这是一个相对收敛的问题甚至可以通过加班去弥补效率的不足。同样也并不代表可以持续的高效交付因为从本源上没有办法保障永远用全局最优的组织和架构以及流程去对应甚至没有机制去发现瓶颈问题。
实现端到端可见的业务价值
陈鑫认为 研发管理数字化首先要做到的就是端到端可见的业务价值。从业务团队到产研团队有以下几个实施路径。首先是建立以业务价值流为视角的协作链路。以往我们多半是通过项目管理软件解决产研团队的协作问题以一个产品或者团队为单位组织需求、缺陷、任务等等。在新的体系中需要将业务团队纳入其中并且拉通业务价值与产品研发需求、任务之间的关系从而实现端到端透明可视。 在产研侧采用大量自动化工具仍然是基础工作除此之外需要将工具产出的数据链接到价值流上并且尽量沉淀到数据平台。这里可以采用比较简单的评判方法比如有多少百分比的工作是在线完成的、是否有统一的数据模型去积累数据。
在前面两步完成后仍然要解决对齐业务、产品、技术团队目标的问题比如业务诉求的优先级是什么、时间点是什么、其中的各环节瓶颈是什么并且在过程中实时追踪。各环节负责人可以感知到异常事件和资源瓶颈第一时间去着手解决达到高效的目的。
第三步要做到持续高效一定要基于前面积累的数据去量化分析此时数据的魅力得到展现有越多的工作在线分析就会越准确。哪个团队在积累债务哪个团队在积累资产哪个团队是阻塞点是调整架构还是调整组织分工这种决策会更加有效率。
基于价值流理念构建产研数字化体系
如下图所示是构建数字化体系的一个大致框架在工具侧可以将从需求到交付的过程划分为三段需求分析阶段、代码开发阶段、交付运维阶段这三段分别对应以需求为中心、以代码为中心、以及以变更为中心的三个工具平台。 这三个工具平台会将数据沉淀到统一的数据中台之上。而对工具的选型原则就是是否可以构建出完整的价值流生命周期。而这些数据的再次应用比如需求智能排期、代码智能应用、效能透视等等会将企业组织管理推进到数字化阶段。
数字化落地的路径和关键要素
在企业要落地研发管理数字化路径和关键要素是什么 第一步 以价值流为核心。拉通研发效能各个阶段打通工具孤岛进行能力和数据的链接。 第二步 建立研发链路核心数据模型。通常会以产品、需求、代码、应用、制品为核心来构建数据模型。完成这一步后我们会拥有一个研发数据中台。 第三步 数据驱动。根据价值流各阶段定义度量指标洞察出真实的价值交付时间和损耗。可以进一步下钻到各个阶段、团队的细节对症下药。 第四步是 智能化应用。以研发数据中台为基础扩展上层数字化应用比如代码智能推荐、智能监控、无人值守发布、智能测试等能力。充分发挥数据价值代替人力工作从根本上提升效率。
研发信息化是解决企业研发效能的基础有了扎实的基础能力和数据以后数字化才有可能。
以上内容讲述了陈鑫对研发管理数字化的目标、红利、路径的理解接下来会针对单点效率问题讲述云原生和智能化这两个新兴技术如何在工具体系中落地。
三、云原生与 AI 在研发平台中的应用
云原生对研发效率的本质影响 以云原生技术带来的应用变化举例。如下图所示左边是传统应用的研发过程开发者的代码会深度耦合中间件需要关注服务发现、分库分表、消息处理等多方面。往下也同样需要关注软件部署在哪需要多少容量甚至还需要关注操作系统、存储等问题。 在云原生时代则很不一样中间件核心能力会下沉到云基础设施中一些常见的限流、降级、鉴权等能力都无需关心数据库、运行环境等都是动态伸缩的常见的运维问题也不需要关心。只需要开发好代码通过软件交付平台自动化的发布到云端就好。软件开发的复杂度其实不会消失而是换一种方式存在。云原生技术下这种复杂度会下沉到云基础设施层通过云去屏蔽这种复杂性。在采纳云原生技术以后大家会发现中小企业也可以轻松获得以往“互联网大厂”才能拥有的分布式、高可用、自动化能力。
因此陈鑫认为 卸载“offload”是效率提升的关键。回想下企业落地 DevOps 的关键要素是什么绝对不是简单地把 Ops 的工作交给 Dev毕竟运维是一个高风险、专业化的工作。要落地 DevOps首先要有一套自动化工具和标准化流程去卸载常见的 Ops 工作比如部署、扩缩容、故障排查等。
再进一步思考从汇编到高级语言从物理机到虚拟机从虚拟机到容器化基础设施在不断地进行标准化。因为标准化后才能够有足够的人才投入其中去完善碎片化市场很难做大。成熟的技术才能够做到完全黑盒化才能放心的去采纳。因此 只有标准化技术才能卸载技术复杂度而正是因为标准化才有了数字化可能。在云原生下我们拥有业界统一的技术标准比如中间件标准、容器标准等。拥有了规范的数据我们就有机会去创造出各种智能工具去代替人力劳动从根本上去解决效率问题。
通过 IaC 构建 DevOps 人机新界面 如何让研发工具释放云原生技术红利经过过去一年的探索陈鑫认为 IaC 是一个非常好的选择。IaC 全称是“Infrastructure as Code”中文是“基础设施即代码”指的是用代码定义和变更基础设施。这个概念其实在 2014 年就被提出了随后也出现了 GitOps也就是把代码放到代码库中使用代码库的版本管理能力来完成基础设施变更控制。 IaC 和 GitOps 的模式对比传统 DevOps 工具最大的区别是什么是 用户关注切面的变化。传统模式需要使用多运维系统、多控制台、熟悉多种交互方式。使用命令式模式操作基础设施变更此时下层工具只提供原子能力而人去控制原子能力的执行顺序以及观测、回滚等等。这就像开一个手动挡的车一样需要了解如何换挡转速控制以及油离配合。而新模式下可以通过代码去统一定义基础设施只描述终态。此时有一个高度自动化和智能化的运维系统可以帮助我们去安全高效的完成变更。就像在开一个有自动驾驶功能的汽车一样只需要告诉他要去哪。
但很遗憾目前为止IaC 模式都只是被少量运维人员用于编排云资源来使用。而广大开发者群体都在老的模式下工作。这项技术的广泛应用不但需要 DevOps 工具平台的升级而且需要一个高度自动化和智能化的运维系统进行匹配。在过去一年里阿里巴巴就在建设这个系统。
基于 GitOps 模式的应用平台设计
接下来陈鑫简要介绍了如何将 GitOps 模式落地到 DevOps 工具中。如下图所示展示的是云效新一代应用交付平台的架构示意图。 先来解释下什么是应用应用一般包含多个组成部分比如一个服务进程、一个数据库、再加一个 Nginx。而且一个应用可以被部署在多个环境比如测试、预发、正式环境等。
用过 K8s 的同学应该都知道本质上 K8s 就是面向终态的 IaC 模式定义资源都是用一段 YAML 文件来描述。但是 K8s 都是面向资源来设计的主要服务对象是运维人员而应用这个概念是为开发人员设计的。所以需要在 K8s 概念之上扩充出这个工具体系。大家可以关注下 kubevela 这个开源项目这就是阿里 GitOps 方案的开源实现。
接下来简单介绍下这个应用平台的组成从上到下第一层是用户界面层开发者可以通过界面 UI或者 cuelang 一种脚本语言来对应用进行编排其中 cuelang 模式是显性的代码化而 UI 是帮助用户生成代码。 下面是应用的静态编排需要描述应用的组成比如可以是 K8s pod也可以是函数或者是虚拟机或者是多种组合。再下面是环境以及机器组的配置描述环境资源所在的物理地点。
当我们要执行一次代码发布或者扩缩容甚至是更复杂的运维变更时用户会通过 UI 或者代码对应用描述进行变更App GitOps Engine 会将变更内容通过 Cloud Provider 进行下发到云去执行最终自动化的完成变更操作。
研发管理数字化的愿景 “讲完云原生的例子我们再讲下智能化。这是我心中关于研发管理数字化的一个愿景。”陈鑫介绍说。
首先从协作、编码、测试、交付、应用运维可以全面使用云化工具一站式完成。先进的工具加上先进的理念可以帮助企业构建透明高效的组织。 当我们不断生产和积累知识后研发数字化的魅力开始展现。 在未来智能化研发管理助手将成为承载我们最先进的软件工程技术和能力的化身它会承担两大职责 代替人去完成繁琐的工作比如缺陷排查、故障发现、持续监控、协助沟通等等。
成为软件交付专家根据每个企业的实际情况推送最优质的代码最合适的编程框架最适合团队的流程改进建议等等。
接着他简单介绍了阿里巴巴在代码领域数据智能工具落地的方向比如在代码效率、质量、安全方面阿里云云效分别开发了代码缺陷预测、敏感信息扫描、智能评审、代码补全、代码库异常行为监测等产品。
四 、阿里巴巴的工程实践
阿里巴巴面临的效能问题 前面介绍了解决协作效率和单点效率的一些思路接下来看一下阿里巴巴面临的效能问题及解决问题的方法。 阿里巴巴面临的效能问题是什么呢我们从业务侧和技术侧两方面来看。 从业务侧看阿里为避免业务团队重复建设从而导致数据不统一、业务流程混乱等问题发明了业务中台这个概念。业务中台其实并不完全是通用性逻辑它是通用逻辑和各个前台业务定制化逻辑的结合体因此就产生了一些新问题比如业务中台中的通用逻辑和一些前台业务定制逻辑迭代速度不一致从而出现部门协同、排期、优先级问题互相影响效率。有些前台业务还对应多个中台产品多方协调存在一个巨大的沟通成本。 从技术侧看阿里在服务化架构下发展多年虽然在高可用方面顶住了历届双 11 的考验但也带来巨大的副作用比如应用运维工作开始变大调用链路开始变长而且都是分布式服务问题排查难度变大。打个比方大家在淘宝上买一个商品这个链路会跨越多个 BU比如淘宝业务、共享业务、支付宝业务等涉及的团队一线开发者很难讲清楚。不管是完成一个业务需求还是排查一个问题都需要大量沟通。现在还面临 PaaS 层上云考验如何用好众多的云产品是个很大的问题。
阿里一直以来希望通过技术和组织的变化来做一些解耦让不同团队掌握自己的业务发展节奏分开来跑。但是这种解耦并不能完全消除协作的复杂性架构的复杂性而是换了一种方式存在。当我们面对这种业务爆炸、应用爆炸、协作研发成本日益增高的情况时如何去破局是个非常大的挑战。
破局路径上的挑战
解决问题之前除了刚才的定性分析还需要更多的定量分析来洞察关键瓶颈。
如下图所示是目前阿里在用的一个研发阶段度量模型。先粗略的观察目标 BU、团队的效率关键节点然后再下钻到具体问题分析是协作还是技术问题解决什么具体的场景可以打破瓶颈。如果大家对这里指标感兴趣可以进一步了解。 结合定性、定量和调研分析可以得出了以下三个关键方向如何解决中台协作问题、如何解决日益复杂的架构问题、如何进一步释放云原生红利。
面对如此复杂的问题如果直接去解决单点问题必然是只见树木不见森林。在这里给大家介绍阿里最近在解决集团效能问题过程中总结的一套方法 ALPD。
ALPD—新一代的精益产品开发方法
这是阿里云云研发团队结合了精益思想、云思想、以及架构设计思想等多方面构建出来的一套方法体系。 这个图蓝色部分是我们今天关注的重点。其中分为三个部分全链路数字化的精益协作解决前面讲的的中台协作问题。第二部分是领域驱动为核心的技术实践解决日益复杂的架构问题。第三部分是云原生的工程实践用这套工程实践去进一步释放云原生对每一个业务开发者的红利。
云化一站式 DevOps 平台的发展趋势
“好方法的落地永远离不开工具”陈鑫说“而我本人的职责就是用工具去承载方法用工具去链接开发者和云基础设施为企业研发管理数字化发展做一些事情。” 当前阿里云云效推出了一系列好用的工具可以帮助企业快速上云包括项目管理、知识库、代码平台、自动化流水线、制品管理等等。阿里巴巴集团依靠云效平台完成了从手工到自动化的转变从传统运维模式到 DevOps 的转变从虚拟机到容器化的转变相信云效的经验和产品可以帮助到大家让各位不再为研发效率问题发愁。
五、 总结
最后陈鑫表示当然我们现在做的还远远不够结合我前面对研发数字化路径分析和方法的总结在这里讲一下我对未来趋势的一些判断。首先是 ALPD 钉钉的云端协作体系这是解决持续高效交付业务价值的基础。其次是基于场景化的云端编程体系比如小程序、Serverless 各种新的编程框架日益增多一招鲜的玩法会逐步被替代。第三是基于 IaC 理念的云原生研发模式第四是研发数据中台这是从简单度量指标分析转变为数据洞察决策分析的基础。最后是智能研发的全面落地。
作者Yvonne
本文为阿里云原创内容未经允许不得转载
作者Yvonne
原文链接
本文为阿里云原创内容未经允许不得转载
