基于云效落地平台工程企业级最佳实践
内容介绍
一、平台工程是DevOps演进的必然方向
二、建设平台工程所面临的挑战
三、云效作为团队建设平台工程的基础设施
四、基于云效建设平台工程的两个案例
五、平台工程的演进方向
本次分享的主题是基于云效落地平台工程企业级最佳实践，由阿里云智能集团云原生高级产品专家张裕和碧桂园生活服务集团股份有限公司技术总监余俭分享。
今天交流分享的主题是平台工程相关。去年云栖大会，同事陈星放了卫星。首先介绍平台工程在一年中实现的真正落地。今天分享了解在平台工程有什么思考，以及具体有哪些非常典型的实践以及案例，它是何形式的，之后会邀请来自毕福的余总，分享一下自己内部做平台工程的实践，以平台方的视角了解内部的视角是何形式。
今天的内容大纲，首先介绍平台工程与DevOps的关系，以及过程中有遇到挑战。之前一篇文章讲了最近有十几年看到了DevOps各种范式，发现平台过程是方向性的东西。第三，介绍云效是如何定位，以及想做什么。第4部分会重点讲两个案例，200人的案例，2000人的案例在规模的企业中，平台公司如何做，以及中间遇到了什么问题和思考，最后会看一看未来是何形式。
一、平台工程是DevOps演进的必然方向
1.DevOps想解决什么问题
首先了解第一部分，云效DevOps目标是促进业务成功，在当下场合，觉得最重要的是什么？DevOps最重要的关注的问题是交付，如何做高效高量的交付，是关注的真正的核心问题。在此基础上，发现所要解决问题是各职能角色和工作流程以及工具的非常良好的协同问题。
2.随着DevOps实践成熟，研发平台会自发成长
随着企业的发展，尤其是企业规模的增加，研发平台一定会建立起来。在两年的时间，通过与云效的客户沟通交流，发现基本上来讲规模上到一两百之后，企业里会自发的产生平台，平台有可能是自建的，有可能是新开的，有可能是通过外采再修改过来的，但一定会有而且规模越大，平台会越多。
举例：2000人的企业，平台内部已经建设平台，可能有超过10个，在此情况下，会发现企业的研发平台才是真正企业各业务开发团队和管理团队所真正面对的主体。主体不是云效，阿里云和云上的各服务。主体自己内部研发平台是工作的主要的对象。在该基础上，跟一站式有区别，一站式的出发点是开发者直接的面向工具平台，而平台工程的出发点，开发者是间接的面向云效平台，直接面向是内部的企业研发平台。在此基础上了解达成什么目的，建平台是解决什么问题。通过与不同角色客户交流，了解实践情况下，发现抛开隐藏在外面的概念，主要解决两问题，是如何把价值交付给凸显出来，一是关注价值交付，第二是如何把团队的心智负担降下。
3.平台工程的建设目标
新加坡阿里云的突发情况使团队在过程中发现有很多的应急的事情要处理，在中间有非常重要的事情即有没有相应的平台来支撑，还是都是临时的串各工具。当需要临时串各工具，对于应急的响应的同学来讲是非常大的心智负担，有可能做坏了，或者做错了会出现故障。
4.企业研发平台的发展趋势
观察一下平台工程年的发展趋势。基本上三趋势，首先建设的越来越多，成熟度提升，企业规模增加都会进行相关考虑。第二发现平台工程的关注点的范围开始关注整价值链交付，而不仅仅是开发。最早在电信行业，当时的所谓的讲平台的，基本上也把包发给测试为结束，以收到需求为开始，主要都是在开发态。目前基本上来讲是从端到端的考虑问题。第三统一的趋势为2000多号人的客户，原来有十几平台，几年基本收缩大概在3~5倍，会有收拢的趋势，而且特点为在其它平台工程的调研中，发现当平台收敛，整体的效率会上升。
二、建设平台工程所面临的挑战
该情况下需要做事。当做事情时会遇到很多的挑战，挑战无提前准备。主要分为外部的和内部。
1.外部挑战
首先是外部的挑战，做平台工程就必然会有平台团队，但很多的平台团队的研发效率跟不上业务团队的要求，包括多原因。第二挑战为平台做了之后价值是什么，度量事情难，很有可能会沦落到为了度量而度量的怪圈。存在为了证明的价值找指标的现象。第三平台工程本身平台会面临质疑，现在有非常多的开源的工具，在企业存在为什么要再建平台，为什么不能直接用开业工具组装质疑，以至于很多企业就在中间摇摆，即外部的挑战。
2.内部挑战
内部的挑战。作为平台，如何解决不同的阶段和不同的角色，关注点的差异问题为非常难的点，需要非常多的软件上的考量。
第二平台团队，要连接各工具，随着AI的产生会有发展的趋势：越来越把API的重要性提上来了，AI的连接更多的通过API的方式连接各工具，API多之后，必然会出现问题，工具链会散，各样专门的工具被AI调用，或者被平台调用，此时如何把连接起来有很大的挑战。
第三企业规模扩大后，团队的情况差别很大，不同的团队诉求不一样，如何很好的支撑各团队的需求是很大的问题。当外部的技术和团队发生变化的，或业务发生变化的，如何很好的灵活的适应。
举例：当3G的网络架构到4G时有变化，到后来5G的又发生很大的变化，企业开始推敏捷研发，开始各流程，包括组织架构的调整，就会发现原先的产品研发所设计的平台，在新的场景下会完全不一样，挑战是非常大，且存在很多问题。
3.低成本、高效率地适配团队场景，提升团队对外交付效率和质量
在此基础，解决问题需要进行样纵向和横向的分层考量。横向，即从基础设施，数据工具集以及核心对象接口到最后的开发者界面上，把做很好的切分，最终面向的是开发者，或者测试人员以及各类型的开发者，是有不同的切面的，不能把切面一杆子打到工具集，一定要有层次的封装，并且保证层次间的干净和解耦。第二层面，需要有纵向的场景化的抽象能力，比如做 2 b 2c的两业务场景，所要的平台是完全不一，情况下如何解决，一定是横向和纵向的两层切分。横向是通过在各关注层面的区分，纵向是场景的区分。
三、云效作为团队建设平台工程的基础设施
1.平台工程基础设施的必要条件
基于该设计的理念，了解云效如何考虑问题。首先，云效平台工程要做基础设施，想做平台的基础设施，在要提供何能力，本文认为具有三能力。
一为工具，提供各基础的工具，比如代码制品，像流水线，是非常基础的工具，无论是做什么，都需要。其次是提供连接能力，把从需求到工具到代码到的交付到外面的基础设施，包括资源能够连接起来。第三，给把数据背后的数据关联整合起来，到最后一定要衡量的做的如何，是否可预警，有风险以及如何改进。数据重要但难度较高。
2.云效作为平台工程的基础设施
在此基础上云效按逻辑做了层级的切分。首先，最底层为基本数据和开发能力部分，会有各数据和各开发能力透出来，并且中间可以连起来，可以知道的对象之间和行为之间的关系。再往上，会提供各类的基础工具，并且提供跟外部工具的连接，为第二层。第三层，会抽象出非常重要的核心对象，为项目与应用。方便做组合整理和管控，再往上会通过模板的形式透出各最佳视角，而模板是可定制和可配置化的。该情况下基于此就可以长出自己的研发平台来，是云效的初衷。把模板把平台把各连接，都把主动权都交给各企业的平台建设者，团队只提供底层基础设施的能力。
四、基于云效建设平台工程的两个案例
1.案例
首先是200人规模的研发规模，是互联网企业平台建设的事件。企业是非常典型的2c场景的互联网企业，研发规模200多人，项目协作和各工程交付已经做了很多的尝试了。有很多的规范，规范写的非常的详细。有平台团队人数为2-3。团队有很明确的目标：如何通过全自动化的研发平台来解决企业研发的高效交付的问题。要面对整企业200多号人，平台团队想通过平台让整两三百号人能够很好的工作，并且是自动化的工作，降低关注点如何做。把整流程拆下来看，发现与其他企业都具有共同特点：明显的两流程。流程1是需求交付流程，另外流程叫代码上线的流程，两流程非常的在互联网企业非常的典型。两流程中，有各自的工具，需求的交互流程是非常收敛的，会有项目管理工具，有像钉钉M工具进行整合。到了代码上线就会非常的分散。比如，自建了代码的托管，自建了流水线，自建了制品库，有配置管理工具以及监控告警，可能还有安全的扫描代码的检测， API测试等等各工具，要把两者之间建立很好的自动化的连接是非常大的挑战。
由此产生的第一问题为从需求出发中间链接太多工具，工具之间的连接方式没有统一，需要自己组合。第二问题为组合过程中，协同成本高，串起来开发者需要知道在哪地方创什么分支，并且到哪边跑流水线，再到另外地方管配置，并且配置的发布可能还要跟代码的发布有耦合，在情况下成本很高，关注点很难。第三数据是断开的，连不起来，要做度量，作为平台上来讲，要知道做了事情的提效效果以及是否有瓶颈。当下架构基础上，会发现要做事情会很难，尤其是到第三点的，几乎做不到。核心问题是如何解决整改，在流程上并没有大的变化，变化主要在把变更上线流程或者代码上线流程做了聚拢。
2.建设方案
首先，需要有对象承载，云效认为有两个核心的对象：项目与应用。为什么觉得应用比代码会更好。代码库跟应用服务是，对不上的而且很多的资产性的东西，在代码库边是承载不了的，需要有叫应用的概念承载，在情况下，会把分成两层，一层是项目的协作，一层是应用的交付，此时会将代码流水线制品，包括其工具，藏在应用的后面。都是研发的资产研发的资产一般都能归属到某应用上，比如知道应用用哪代码库有哪制品有哪配置有哪环境，哪资源，哪人以及什么角色都可以聚拢起来之后，对于开发者来讲，关注点就会回到唯一的对象：应用。应用上会有自己的应用的研发流程，研发内容是可以被定义出来的。
平台团队所要关注的是如何帮助各业务团队定义自己的应用的流程和应用的规范。规范最后形成模板，在基于该假设，前面有协作的流程，下面有应用的流程，应用和流程和协作之间的串联和连接，就可以通过API和web hook做到了完全的自动化，而且是解耦的，可以只用一半，也可以两都用，也可以把其中一部分做调整，都没有任何问题。
此时可使需求开始的交付流程变成自动化的了，而且在需求的层面，也可以看到的软件的交付的阶段到了哪里有什么风险，过程完全透明，在后面，如何把后面其工具给连接起来会发现大部分的工具的连接都是链接流水线上的，考验的是流水线的开放性能力，是要做好流水线的开放性，让用自己的开放性的组件连接各样工具。基于该方案，分为三团队，业务团队，面向的基本上是以项目协作的流程为主。研发团队，会跟项目协作的需求做关联。关注的主要是应用交付。平台团队主要建设好下面的底层的工具链和平台，而把上面的交付流程留给研发团队自己定义管理。
通过此方式，无论是平台团队还是研发团队，关注度都减少了，不需要关注原来的概念，也不需要了解的工具性的关系，包括对工具做替换和升级的，也没有以前麻烦。
总结：三工具。技术工具，提供最下面的技术工具，端到端连接，基于中间的统一的连接方式，连接的对象叫应用把资产和各的流程连接了起来，把工具连接了起来。第三，东西被连接起来，而且连接的对象是同一，即数据也能够被收集和串联起来。
举例：有应用维度应用能够聚合到owner是团队。应用上面能够知道做哪代码的开发做了哪流行的构建做哪环境的部署，可以按照应用，按照团队，按照环境等等各维度聚合，度量过程中的行为和数据，以及效能，提供了度量极限之后。作为平台团队，就可以拿数据按照自己的需求跟别的系统，比如HR系统，风险管理系统等等各项系统做集成，就可以拿到更高维度的度量的场景。相当于云效提供了基础的数据，跟其东西做集成。
3.持续改进：业务团队将最佳实践沉淀为模版
总结：当平台建设好，后续的演进主要变成两方面。一是演进的项目的协作流程，但最终会形成项目模板。项目模板可以持续的更新和迭代。另外是应用的变更流程，同会形成的应用的模板，在模板会包含的变更过程，峰值模式，环境的管理，角色权限的组织分配以及对资产的审核卡点等。通过该方式，形成了应用模板，反向又能够同步到应用模板的所有的应用，就达到了企业级的更新升级管控的目的，包括后续资产管理，也可以通过此方式统一的纳管，而不需要通过更多的旁路手段。基于两手段，业务团队可以自己沉淀业务的各模板，包括应用的模板，并不依赖于平台团队。而平台团队本身就关注如何把语言基础能力建设就可。
此为第一案例的最终的形态，也是目前正在进行中的事情，已经在逐步的沉淀各模板和用板出来。
了解另一案例。此为偏向于安全，金融行业的，国内为Top的保险行业的科技企业平台建设的实践。规模较大，有2000多号的原厂的研发，人数超几千人。价格划分非常的细，首先有众多业务团队，比如不同的保险形态或者不同的金融形态，都有各自不同的业务团队，业务团队之间的差别非常大，会有专门的pass团队管理pass的基础设施，比如像中间件如像服务网格，像配置中心，都有相应维护，有单独的质量团队，质量团队在上面建设了测管平台，建设了自动化平台。同时拥有安全团队，项目管理团队，和专门的生产部署团队。
在金融行业非常明显的特点生产和测试是绝对的隔离的，生产的部署和测试的测试开发是不同的人负责的，会有专门的生产，不同的做生产的部署操作，也会有自己的版本的流程和发布流程，发布的力度就不是应用了，必须是系统，系统会包含多应用，针对业务的属性上线发布，在协作也不是需求，而是版本。版本会包含很多需求。此为典型的金融行业的例子。
了解企业目标。金融是国内在大型企业中对前瞻性的研究和科技投入较多的行业。行业探讨如何把现在分散在整研发中心的多交互平台，管理平台，测试平台做整合，做自动化的串联，并且能够做到版本交付的自动化，把生产也能够自动化的串联起来，为后续想做架构升级。做服务质量也做基础。是很大的目标，在中间是有非常大的挑战。首先为平台概念的不对齐，在运维侧的平台，对应用的认知，对服务的认知跟在开发测和测试不一。中间可能王网格边又不一样，有自己的概念，概念无法对齐会发现非常难以串联。第二挑战是有很多的持续交互平台，已经在建了，业务平台有可能自己做的，要串联起来，整合起来，如何避免重复建设也是很大的问题。
第三流程跟业务形态有很多的耦合，耦合的过程中如何做架构升级和服务治理是很难的。第四如何把开发态和运维态能够连起来是很大的挑战。
4.步骤一：收敛研发元数据模型及其唯一Owner
了解相应步骤。首先第一步做元数据收敛，研发的元数据应该能够收敛到同一地方，把收敛的地方叫做应用元数据平台。此为自己建的平台，每个企业应用元数据的管理是不同。在应用元数据平台，会定义系统应用的资源以及服务几者的关系，所有其他系统平台都会从应用元数据平台同步元数据，同步对应的建立对应的对象。比如云效有交付平台是云效提供的，云效上面建立的系统和应用不是手工建立的，是通过应用元素与平台同步过来的。当系统和应用发生变化了之后，会同步信息自动创建对应的平台和应用，并且把对应的代码库包括制品库都做关联，元数据的管理本身并不在直销平台做，而在上面做。项管平台专注于项目管理，项目管理，会定义非常重要的对象，叫版本。版本跟项目一一对应，项目再跟系统的发布一一对应，做了么约束，约束之后就可以通过项目版本到项目到发布串联整的发布流程了。
通过两约束后，就会发现整的协作的流程变得非常的清晰，后续的建设方向就很清楚了，元数据不用自己管，不管是测试的还是生产的，都来自于同一地方。
5.步骤二：确定各个工具的边界和集成方式
第二步为如何确定各工具的边界和集成方式。把生产和开发测试和生产区首先做了划分，哪在生产区，哪在开发测试区。把生产区收敛到只有持续交付平台，别的都在开发测试区。在开发测试区上层的东西管控层的东西，是项管平台，元数据中心和效能度量平台。更多的是企业特有的是管控层东西，中间红框的是持续交付平台，所有的箭头就指向的都是从上往下的，除了像统一登录，可调用方式不太一样，基本上都是同样往下的，由上面的管理管控平台来约束下面的区域交互平台，往下为连接各独立的工具平台，把自动化不要变成平台，把收敛成工具就收敛成非常独立的工具。在该情况下，不要想着长大成平台，就变成工具，但是解决特定的问题，由持续交互平台来串联，做好自己工具本身的事情。在中间，通过市场代理网关，单向的网关做从测试到生产的打通，无论如何都需要通路把测试的制品往生产同步。网关做约束，网关的约束几东西会做三事情，元数据的同步就把应用元数据同步到生产。第二发布的创建，发布从测试往生产的发布创建是从网关走。第三制品库的同步，而且只同步生产的制品。网关是自研的，在自研网关上，可以做很多安全的约束，可以做很多的高级的特性限制危险操作，在网关上做了非常多事情，逻辑也在网络上处理。再往下为制品同步。到了生产区发布是由测试串联起来的，生产的发布人员拿到的是完整的待发布的版本，版本包括所有变更的所有内容，包括制品配置，也包括环境定义等。生产的部署人员要定义生产的环境的东西，比如生产可能有5套环境，但是不知道的，市场要决定变量，但是整流程也是来定义，但是源头都是开发给，按照流程发到环境上，当时拿的源头是开发给的，而整体进度是在左边的持续交易平台是可以看到的，在左边可以知道到底生产发到了哪一步了，还有多少时间，还有什么问题卡哪里了，并且当发布完成的，可以反向的回调，项管平台更新项目的状态做对应的消息通知以及对应的集成对应的审批流等等。通过该方式，从项目立项开始，到最后上线完成验收。过程都是事件驱动的，无人人来触发某节点的情况了。做到完全的自动化，是实践的特点。
6.步骤三：面向业务研发团队的开发者界面
第三开发者界面本身，2000人的规模较大的团队，业务形态差别非常大，需要为每一业务形态定义自己特有的开发的界面，以及满足特有的业务场景，场景是不适合平台自身的，是需要由业务团队扩展的。在该情况下，通过叫三方应用的方式支持。三方应用是从UI到互改到API到事件的全方位的能力，可以完全是藏在后面的必要的事件处理或者hi调用，也可以是直接对界面UI的扩展和修改。发现在实际情况下，三情况都会出现，尤其是对于界面的情况下非常常见。比如会有叫临时项目环境的场景，在各业务团队不一样，就会自己写三方应用挂在当前的主页面上，实现业务流程。此为完全定义的，可以限制可见范围，使得业务团队可见。
下面是自定义步骤，就云效本身会提供自定义步骤的脚手架，可以自己编写，并且在计算各代码。
五、平台工程的演进方向
两案例能看到在对未来的思考方向。五年前处于中台提的很火热的，后来又开始对中台开始各质疑，最近在AI开始越来越盛行的手机API开始越来越关注，反过来重新再想问题，觉得有可能组件化的开发可能会在AI时代又会慢慢的被会提起来。
1.云战略技术趋势：平台工程
现在做的东西是开发者平台的，下面两层和最上面一层，但中间没有叫组装式的概念，或者组件的概念。以前中台想干的事就各扩展点的概念，为什么会有问题，扩展点的维护本身就有非常强的业务语义和业务场景，适用性是有限的，维护成本是高的。但如果随着 AI编程以及AI agent能力的提升，当对于业务的抽象和业务的维护能够做好之后，编码不再是大的挑战的很有可能中间一层会长出来，如果专业能长出来之后，像2000多号人的头上，会长成自己特有的组装式的东西，又放到中间，在中间之后，再在上面才是开发的门户，开发的门户就会分成两类，一类还是像以前像做云原生应用开发，另一类可能偏向于低代码或者是AI应用的场景，是做组装，做串联，做集成就能够把业务可以组装起来了，是很有可能会发生的事情。再往上，企业可能会基于基本的能力形成各业务。不管是AI的数据的业务，普通的业务应用都会产生，基于此会发现很有可能会在现在的所做的能力之上，又会有一拨人抽象出组件和技术能力。
2.阿里云数字化应用研发平台工程体系
基于此，把阿里现在的组装式工艺也平台工程体系梳理，发现除了云效之外，在网上其它在逻辑上，是天然的可以跟云效做整合。云效在下面是作为基本的平台过程的基础设施。在之上，如果有业务应用，有AI应用，有数据应用的场景的，组装式的东西可能会变成另外基础设施，最后形成平台。所有都基于逻辑认为还是从原子的工具再组装平台的成本太高了，而且重复建设没必要的，在节点上可以根据现在业务的特点选择每一独立的模来丰富的平台工具的基础设施链，是做整的基本的假设。当然还有AI相关的影响，工具一定是会存在的，连接，一定会存在，AI可能在中间会是加速的变量，但又很可能会要求更严格的API定义更严格的需求描述，以及更严格的流程，反而会促进产生，AI才能更好的理解的意图，也为什么像最近觉得API force的理念可能会越来越重要的原因。
六、碧桂园服务平台工程技术的演进和实践
接下来由余俭分享碧桂园余总会正在企业如何鉴定的过程思路更好的给企业的实践的案例。站在企业方视角来介绍一下碧桂园服务在平台工程领域上面的演进和实践的分享。
1.数字化转型的背景与挑战
今天分享的内容主要会分成4部分，首先会介绍一下碧桂园服务在整数字化转型的背景，和为什么会关注到平台工程能力的建设。
第二是在平台工程上面的建设和规划的思路。第三是在特定的原则之下，关于平台工程的落地的实践分享。第4关于平台工程，在未来的思考。对外服务在物业行业一直处在头部和领先的位置。
包括今年集团也提出来了可持续发展的战略，在新的战略方向之下，科技赋能是站着很重要的支撑的板块，在企业未来发展当中，会遇到很多的挑战问题，比如在发展过程当中会遇到规模化的发展带来的运营的挑战，如何利用集约化的管理来提升的运营效率，是会给到很大的挑战。第二是并为服务，除了物业主业务之外，也有很多新的业务，比如像零售，像充电桩，像洗护新的业务也会给在管理上会带来非常大的挑战。第三物业行业本身是服务型的行业，碧桂园服务作为拥有将近1000万业主的企业，在未来如何应对不同的业主不同的个性化的需求，也会带来非常重大的挑战。基于以上挑战，认为数字化的技术能力，是解决挑战的最优解，碧桂园服务是很早就开始了做整数据化转型，从15年到现在，数据化转型的路上也大概是分成了三阶段，从最开始的线下的作业管理至线上的信息化，到第二阶段，是通过数字化的工具产品来匹配到整业务的快速的增长。在第三阶段是希望利用新的技术，比如AI大模型，大数据以及物联网的技术来跟业务来共同融合，创造以及变革，给企业经营带来更好的增长。
2.碧服平台工程的规划和演进思路
在数字平台就数字化体系的建设过程当中，始终非常关注平台工程的能力的建设。平台工程本质上是为了提升开发者的体验，以及加速价值交付的效率。但是又会有不一样视角，就在企业还是会根据自身的阶段和的业务的特性，觉得可能不是要建大而全的平台，能够解决所有的研发侧面临的挑战平台，觉得应该把精力会聚焦在核心的技术，以及关键场景的应用上面建设平台的工程能力，比如在底层，会有工具链的组合，基于云效或内部的管理的工具，利用连接的能力来建设底层的工具。工具链的平台来支撑到上层的应用，以及业务的需求。再往上，也会建数据化底座的能力，把核心的能力做抽象来避免在研发交付过程当中的重复建设，再往上，也会长出自身的技术能力的平台，比如会做极限平台开发平台，还有数据平台以及AI平台。最终，能力平台最核心的为了支撑上层业务，能够得到快速的响应。在整建设的过程当中，一直在思考，也会遵循几原则，首先还是会关注在流程的自动化和标准化来解决的效率上的问题。第二是在技术能力的抽象上构建核心的技术能力，第三原则是在整系统的可用性可靠性，可扩展性上来做整体的保障。第四始终认为平台工程在未来，必然会就有 AI或者是智能化场景的融入，希望在未来在构建平台工程能力的，也要考虑到场景的智能化。
3.围绕4大原则下的平台工程落地实践经验分享
首先是关于自动化和标准化，核心依赖的是工具平台的能力，利用云效作为的核心的工具的底座来打通内部的可观测平台也还是的自动化运维平台也打造端到端的敏捷交付的链路，来支撑到的整规范的标准化，以及流程的自动化，在最上一层在标准化层面，做了什么，主要做了两点，第一点构建了整开发过程的模型的标准，在碧服内部有很多不同的项目形态，有不同的交互模式，比如会有敏捷的产品迭代形态，也会有相对稳态的项项目的交付的形态，也会有自研的产品也会有外采产品，针对场景之下，研发过程的模型管理，把一套东西给标准化下，结合前面云效也有具备项目模板，能力最终能够把落下来。第二在做标准化，核心还是围绕着整软件研发全生命周期的标准化，比如会有需求管理的规范，会有架构的规范，会有安全的规范，会有开发的规范，规范流程标准化核心的能力不是要输出多少的文档，输输出多少的指引，而是要把标准化，规范化的东西落到的工具平台上面，跟真实的研发过程深度融合在一起。做完标准化之后，还有的流程自动化，流程的自动化实际上是把管理线下的管理动作过程，把放到线上化，利用工具的可视化的配置，把所有的整流程能够自动的串起来，过去需求的评审可能都是线下的模式，现在有了工具的支撑，把评审的动作也搬到线上，而且沉淀评审的数据，而且每一环节也是基于工具能够自动的运转起来，在流程过程当中会有需求协同的自动化，也会有质量内建的自动化，也会有运维发布的自动化最终，通过标准化的能力和流程自动化的能力，沉淀在平台上面，最终能够在整平台上面能看到过程的数据以及结果的数据，最终可以给研发管理带来运营的指标，参考，可以基于数据把可量化可视化的数据作为整研发运营的分析的依据，就能够在平台上面看到团队的交付需求，交付的周期是何的，缺陷修复的时长是如何的，构建的时长是如何的，最终来给到研发管理的精进来提供参考。
第二介绍内建的bp的平台，是大前端的平台。核心想解决的是两问题，是一致性的问题，是协同效率的问题，过去从产品的原型到设计稿的输出到开发的前端开发的组件，实际上都是都是线下运转的。实际上没有在平台视角上考虑过问题，会给带整交互带来效率上，或者是沟通上的成本，通过该平台构建了，产品设计和开发三位一体的么协同的知识，最后通过平台沉淀，在产品一侧圆心的组件沉淀设计的组组件，以及在开发前端的组件，最后能够端到端的串联起来。
同时，在一次性上面，又能够保证内部的产品，比如在碧服内部，会有适当的产品也会有b端的产品，会有web端，也有小程序端，未来可能也会有鸿蒙版的APP端等等能够通过b平台，来保证品牌上的一致的输出，在最终呈现给到客户，给到员工，体验是一致的，交互是一致的，视觉上的效果是一致的。通过组建沉淀，也能够给到最终的产品的设计以及开发提供技术式的服务，业务需求来了，就根据的组件主题能够快速构建的原型，构建开发的页面，来提升整体的交付的能力。
包括前面亚信科技的专家老师也有提到，未来关于bep平台，也会融入智能化的能力实现更好效果。
第三是关于整可扩展性和可靠性，重点讲解serveless应用。举的案例是物业主营收费的场景。
在很多物业公司，物业收费是占企业营收大概起码百分之五六十以上，实际上如果收费系统出现问题，给企业带来是巨大的损失。假如碧服如果收费服务，如果是挂掉了10分钟，有可能影响的是百万级别的收入，在场景之下对系统的可靠性稳定性的要求特别高的。场景面临的是会面临两挑战，会有无规律的流量的波动，有规律的周期性的流量波动。无规律的比如可能会做临时性的预存的活动，会做营销的活动等等，会带来不可预测的流量的增加。另外周期性比如可能每月底，季度末以及半年或者是全年在业绩冲刺的，有流量，还是有规律的，可以预测出来的，过去依赖于人工干预，比如针对没有规律的业务流量，波动，更多是依赖可观测的平台，当指标达到临界值的，可能会通知到的运维的同学会人工给服务区扩容，针对周期性的业务，可能是会在活动或者是业务开展的前一周提前预设资源，会带来来是运维成本的浪费资源的浪费，人工手工的操作会带来失误的风险。在往serverless上面做迁移之后，就会降低解决问题，在收费的场景之下，采用的策略也是针对的突发流量和潮汐流量的两场景来做了预设，比如针对突发流量，可能就利用serveless的观测近15分钟的数据情况来实现自动的弹性伸缩，针对超新星的场景，可能就会根据最近7天的流量数据，历史数数据来做预测，最终来实现弹性伸缩。通过社会来使的应用，最终带来了效果，确实在资源上面得到了节省，第二降低了人工干预的失误的风险，第三是确实也在系统的可用性上面得到了很好的保障。
场景的智能化，讲解碧服服务内部在通义零码上面的应用，在平台工程有非常非常重要的点，核心是要提升整开发者的体验，认为要提升开发者的体验，但开发有百分之五六十的时间都是在code上面，认为引入通用通义灵码，核心也是为了要提升开发者的体验。
从今年从试点团队情况来看，效果是会超出预期，看到在代码生成占比一，在8月份是能到25%，从开发同学的反馈来看，在很多的场景下面通义灵码是给到很大的辅助，比如在生成优化的建议上面生成代码，还有开发者比较头疼的生成单元测试的场景之下，都有很好的推荐和辅助，核心的观点通义灵码是更多的辅助开发者开发的效率，提升的开发效率，让开发人员可以更加聚焦在业务逻辑的实现上面。
4.总结与展望
最后讲解平台工程未来的建设思考，过去一直觉得不管是戴尔还是平台工程，很多还是围绕着工具，往往会忽略流程上或者管控上的规范上面的思考，过去在平台工程更多是聚焦在工具的建设上面，第二，平台工程也没有站在全局的思考层面，造成更多的有节点依赖于员工。
在未来，会有三点思考，第一点，认为平台工程未来一定是和软件开发过程是有机融合的。关于开发过程，所有的标准，所有关于代码规范包括安全的要求，质量的要求最终会和平台工程深度融合起来，第二，平台工程未来建设必然是产品化的设计，而不是像零散式的产品设计的方式，最后认为平台工程未来的建设一定是要有敏捷的组织和敏捷的文化来支撑，这样才能够配到未来更复杂的开发环境。总的来说，平台工程是渐进式的演进过程，企业要根据自身的情况思考自己的平台工程应该用什么样的思路来建设，建议围绕实际的场景出发，聚焦在关键的技术和领域上面做平台工程的建设。
