《平台工程 - 释放开发、测试、集成效率丨平台工程技术大会.pdf》由会员分享,可在线阅读,更多相关《平台工程 - 释放开发、测试、集成效率丨平台工程技术大会.pdf(35页珍藏版)》请在三个皮匠报告上搜索。
1、平台程-释放开发、测试、集成效率钟健鑫 软件程负责嘉宾介绍Thoughtworks EMPC 软件程业务负责总监咨询师、2014年加ThoughtWorks-曾任技术经理、席架构师、赋能业务线总监-专注:创新数据驱动研发模式、平台程、效能交付架构、规模研发组织转型嘉宾照分享路径1平台程的现在与未来2平台程的认知:是什么、能解决什么问题3借助平台程进型产品测试与集成左移4演进平台程撑多产品和业务复平台的并构建5平台程如何开始利AIGC平台程的现在平台程的现在Platform业务流团队已经开始尽可能的步交付客户价值,将部分繁琐的程实践知识下层到平台,且利平台去处理它们75%70%75%Platfo
2、rmPlatform业务流团队将交付过程中与平台具的摩擦和不匹配逐步消除,能够100%的关注再客户的价值产出上100%100%100%撑性的基础设施客户价值40%30%55%交付过程存在较多的作在些有效、但复杂的实践、具使和流程遵循上,价值产出占不理想Team 1Team 2Team 3Team 1Team 2Team 3复杂、重复实践繁琐、必要流程平台程的现在-期望解决的问题员能参差不,量技术、程实践需要学习和适配研发流程没有标准化、常作中的协作界/数/多研发平台/具的学习、使成本、为了使使研发过程是个盒,险滞后、各种问题只能靠问和最终结果判断业务-产品-研发 的协作摩擦多、需求/架构/代码
3、的知识传递效率低、失真度平台程被理解为DevOps平台体化,构建量功能,但很难被起来动化的具很多、但能效解决程问题的少,具带来很认知负担具/平台与组织流程、团队作模式不匹配,或仅部分通功能达预期与流程与平台平台与流程?如复杂系统的质量、集成,靠更多的时间和员去填补,流程重于程 2022 Thoughtworks平台程的核是产品思维对研发团队提供赋能,减少认知负荷,提升体验。减少其认知负荷的极致是去除负荷。7去中化模式中化模式助理模式替代模式混合模式平台程的未来模式:中化模式图例说明协协同作平台:需求、项、迭代、团队管理等配配置管理平台:应配置、分策略、部署配置等开统开发平台:技术栈、编码、组件
4、应等流流线平台 :构建、集成、打包、部署等测测试管理平台:测试例和数据、测试执、缺陷管理等运运维管理平台:发布、监控、运营等流程内建站式综合管理平台通过模板化流线设计,将企业的研发流程通过平台进承载,统业务团队的交付流程实践赋能采可视化,向导式设计,帮助业务团队快速将现有项迁移平台之上,复企业优秀研发实践度量改进通过持续交付平台内建的度量可视化具,引导业务团队关注交付过程中的度量指标,识别交付瓶颈并持续改进需求提出项项需求管理项创建研发管理测试管理项投产项收尾进度与变更管理协协协协协协协协运测开配流协站式研发撑平台平台程的未来模式:去中化模式Headless CMS(程平台需要的内容管理能)U
5、sersFrontendProduct teamsDeveloper portalDashboardsMonitoring&observabilityPlatform Capabilities Core ComponentsOrg taxonomyService catalog&templatesMetricsAuthentication&AuthorizationKnowledge hubCI/CD(Path to production)AlertingDelivery infrastructurePolicy&AuditingCloud cost insightsRecommendatio
6、n engine云集成SPIs&APIs开发者态集成组织内系统集成集成已经存在的内外部态CLI平台程的未来模式:去中化模式10将开发团队视为客户,为创新提供了规模。通过关注作为客户的开发员,并为他们建可重复使的能,平台团队加速了经验层的创新发展。通过遵循unix哲学,把平台能当作乐积,只做件事,且做得很好,团队可以混合和匹配乐积来完成他们的作。在整个堆栈中的许多功能,都有完整的团队访问的具。如果组织已经有了有效的具,它们可以被整合到平台上。模板和动化使变得容易,团队可以扩展这些功能,并直接访问具,以获得更级和实验性的场景。平台能开发团队B平台团队平台户能开发团队A平台程的未来模式三:助理模式L
7、LM 增强 户Copilot API数据审计/安全 操作编排LLM 检索(Retrieval)向量存储(Vector Store)成 Embedding 授权档/数据语模型(LLM)Prompt ChainLLM Agent可信数据敏感信息存储对话历史敏感数据CopilotAPIsLangChainLangChainChroma私有化部署LLM&微调 OpenAI or HuggingFace需求平台架构平台开发需求分析 Copilot产品设计 Copilot架构建模 Copilot领域模型 Copilot测试测试辅助Copilot敏感信息过滤&屏蔽现有后端服务操作步骤Prompt 成 响应后
8、处理Python三具LangChainFastAPI编程辅助Copilot集成辅助Copilot平台程的未来模式三:辅助建模和架构设计-时序图12?/TL?我在设计个 OKR 系统,请根据下的需求,根据你的理解绘制时序图,并使 PlantUML 返回。#作为个团队负责,我希望能够创建和更新团队的期和短期标,以便能够将它们转化为可量化的 OKR。作为个员,我希望能够创建和更新我的 OKR,以便将我的标对到团队和公司的标上。作为个团队负责,我希望能够分配 OKR 给每个员,并设置期限和优先级,以便能够跟踪整个团队的进展情况。作为个员,我希望能够及时更新我的 OKR 进展情况,并向团队报告我的进展情
9、况,以便能够保持团队的透明度和协同性。作为个团队负责,我希望能够跟踪每个员 OKR 的进度,并将其与他们的绩效相关联,以便能够评估每个员的绩效。作为个团队负责,我希望能够定期审查 OKR 系统的效果,并进必要的调整,以便能够持续改进整个系统的效果和价值。作为个团队负责,我希望能够提供持和指导,以帮助员达成他们的 OKR,以便能够持员的发展和团队的成功。作为个员,我希望能够获得实时反馈和持,以便能够不断地改进我的表现和达成我的 OKR#startumltitle OKR系统时序图actor 团队负责actor 员团队负责-OKR系统:创建/更新团队的期和短期标OKR系统-团队负责:标创建/更新成
10、功员-OKR系统:创建/更新的OKROKR系统-员:OKR创建/更新成功团队负责-OKR系统:分配OKR给员,设置期限和优先级OKR系统-团队负责:OKR分配成功note over 员:接收OKR分配通知员-OKR系统:更新的OKR进展情况 note over 员:实时更新OKR进展OKR系统-团队负责:更新员OKR进展情况note over 团队负责:接收员OKR进展通知团队负责-OKR系统:跟踪员OKR进度,将其与绩效相关联 note over 团队负责:审查员OKR进展情况OKR系统-团队负责:员绩效评估结果团队负责-OKR系统:审查OKR系统效果,进必要的调整OKR系统-团队负责:OK
11、R系统调整成功团队负责-员:提供持和指导,帮助员达成OKR员-团队负责:获得实时反馈和持,不断改进表现 提示词成的UML代码在PlantUML中成的可视图平台程的未来模式三:辅助建模和架构设计-领域模型设计13?/TL?AC?我在设计个 OKR 系统,请根据下的需求,根据你的理解设计领域模型,并使 PlantUML 返回。#作为个团队负责,我希望能够创建和更新团队的期和短期标,以便能够将它们转化为可量化的 OKR。作为个员,我希望能够创建和更新我的 OKR,以便将我的标对到团队和公司的标上。作为个团队负责,我希望能够分配 OKR 给每个员,并设置期限和优先级,以便能够跟踪整个团队的进展情况。作
12、为个员,我希望能够及时更新我的 OKR 进展情况,并向团队报告我的进展情况,以便能够保持团队的透明度和协同性。作为个团队负责,我希望能够跟踪每个员 OKR 的进度,并将其与他们的绩效相关联,以便能够评估每个员的绩效。作为个团队负责,我希望能够定期审查 OKR 系统的效果,并进必要的调整,以便能够持续改进整个系统的效果和价值。作为个团队负责,我希望能够提供持和指导,以帮助员达成他们的 OKR,以便能够持员的发展和团队的成功。作为个员,我希望能够获得实时反馈和持,以便能够不断地改进我的表现和达成我的 OKR#注:结合线上具绘制 http:/ 成的初步领域模型优化后的领域模型提示词平台程的认知:是什
13、么、能解决什么问题 2022 年以来,平台程在希望进 DevOps 发展下阶段的软件程组织中获得了关注。Gartner写道:“平台程正在成为趋势,因为它承诺优化开发员体验并加速产品团队交付客户价值。”他们预测,到 2026 年,80%的软件程组织将拥有构建内部开发员平台的平台团队。平台程是为应对现代云原架构益复杂的情况出现的新学科。它描述了构建和维护称为“内部开发员平台”的集成产品的实践,该平台充当开发员与其应程序底层技术之间灵活且受持的抽象层。15平台程特性-云计算作组01平台即产品平台的设计应该聚焦在业务软件研发的共性需求,以产品研发的视,抽象和复公共的能,以平台驱动团队流程趋于标准和统;
14、该产品随着组织变化演进,持续对其进管理和投资,成为企业内部的资产02开发者体验平台应提供系列聚焦于开发者体验的致性户接和具,包括UI、API、命令、开发者具的IDE和其他户级别的界03助式服务应开发者可主发现、获得、使平台层能,例如进团队研发规范学习、业务管理流程学习、动化的应资源申请、动化测试、动化运维监控等;根据团队整体情况设计向开发者的前台概念04关注点分离平台的户是软件开发者,可使其感于平台基础设施;平台程的撑团队是测试、SRE、安全等,可同时持多个多样化的产品研发团队,提供横向/端到端服务平台程特性05平台能标准化平台程抽象出标准化的模块,这些模块是可选的,可以灵活组装、快速扩展和升
15、级,在多个应之间共享和重,满上层不同场景应的交付和管理需求,避免了重复开发和维护相似的功能,最终形成应的标准化交付,提升软件研发效能06应资产沉淀与复在平台中形成应的标准化交付实践资产库,如研发档、部署架构、应架构、应模板、SaaS 服务等07险管理策略化平台程的实践应具备险管理策略化能,能够将组织定义的险防控能沉淀为应交付和管理中的SOP(标准作业程序),从保障整个应研发过程的险可控08数据驱动观测效能提升的数据,包括变更前置时间、部署频率、变更成功率、故障恢复时间、可靠性等指标,形成应交付管理的效能度量体系平台程能要求 2023年4CBSA TC1 WG5平台程的认知:是什么、能解决什么问
16、题平台程是种技术,和系统性法,并不能仅仅被看作是个结果或组织资产,因为平台程需要随着组织的发展持续演进和提供可规模化的多样性能平台程的认知:让组织将具的能最化,让具将程能最优化17平台程 作层次产品团队项管理团队开发团队运维团队架构团队系统测试团队客户交付团队架构师开发测试详设/业务分析产品经理/业务分析项经理/研发经理系统质量/测试覆盖对象程平台与具DevOps团队/基础设施团队交付/实施/线上维护测试策略的程撑能持续集成交付能架构治理能端到端研发度量能需求与研发过程可视化管理能(云)基础设施应、管理能开发者设计与程能?API?API?/?API?IDE?问?/?UI?问?/?/?Ticke
17、t?PaaS/?IaaS?改进研发价值流动降低开发者认知负担提升知识消费效率平台化的流程与实践(允许多样性)平台组织的服务运营平台能的户体验核策略(提升研发效能、加速业务发展与创新)主要段(封装程复杂度、产品思维提供规模赋能)组织与平台的鸿沟案例:某型2B产品研发组织(500+,4个地区)案例的背景:团队间协作依赖、集成险、缺陷多、投、浪费案例的挑战:架构复杂、能参差、团队规模、集成依赖复杂平台程如何应对:解耦出 团队独开发、验证的程能、依赖管理能、持续测试能、测试环境和数据构建 复能借助平台程进型产品测试与集成左移部分的问题来集成的复杂度、直接导致 难验难测测试数据?指?测试数据准备成本 测
18、试数据难以复 测试数据之间不兼容,没有关联性测试数据、测试环境难以复轻量化动化测试缺测试资源法弹性伸缩测试度量体系缺测试环境 测试环境搭建困难 测试环境不稳定 测试环境跟测试数据不兼容测试任务 测试任务执慢 测试任务难以重复执 测试任务编写成本测试资源 测试资源申请周期 测试资源紧张测试度量 动化测试效果难以度量 动化测试接程度难以有效复测试数据、测试环境,完成动化测试提供轻量化动测试能测试资源能够弹性伸缩构建完整的测试度量体系轻量化落地API测试?API?API?API?API设计开发开发测PR Pipeline代码合并需求设计DevQEArch执结束全量回归合并代码修改测试例修改API 定
19、义修改依赖数据修改 功能?API?API?API设计?定义依赖数据编写TestCase痛点:全量集成准备测试环境时痛点:准备集成环境准备测试环境时准备测试环境执测试数据集管理环境管理Mock服务平台功能Mock服务平台功能SUTMock BMock CFake DBIn Memory DBFake InfraPlatform SimulationTest Case技术案构建撑环境降低测试成本痛点:数据准备数据准备成本昂贵痛点:契约测试契约测试需要动编写,且法检查依赖的契约痛点:声明式测试写测试代码对测试员要求较,且较麻烦流量的路由与劫持平台功能流量的录制和回放内穿透inbound/outbou
20、nd流量的收集平台功能基于inbound/outbound流量的全动化契约测试基于流量的全动化API覆盖率统计声明式测试平台功能环境准备录制测代码提交PR Pipeline代码合并测QA?/?API?API?准备录制环境编辑录制配置编写声明式测试例执录制执测试进API覆盖率统计进Scheme检查执API测试全量回归合并代码检查修正录制数据Dev?动成录制数据随之,复杂系统集成带来的问题浮出复杂系统集成是每个型研发组织定会临的问题。研发组织运转得越久、系统建设得越庞,集成问题就越突出,甚对每个开发团队、每次产品迭代都会产影响。即使很成熟的、不怎么变化的系统,也会持续的遇到集成和被集成的问题。所以
21、它是个持续的、全局性的问题复杂系统集成 负反馈循环集成缺陷 暴露太晚业务还原度 没有保障占量时间集成结果 不可靠平均来看,型业务开展需要超过22种软件撑 当业务规模超过5000后,软件规模将会急剧扩到788个 为使它们效作,集成是不可避免的段项在集成上投总天的30%50%,开发新功能的天被极占据 在发现的缺陷中有4070%与集成有关 系统集成随业务规模增急速复杂化1系统集成挤占了量时间且缺陷率居不下21:摘Infographics:“Why Are IT System Integration Costs So High?”,2021;2:来Thoughtworks桌研究12复杂系统集成造成的问
22、题和应对思路警惕 Microservice Envy1 现象,将集成的代价纳架构设计的考量因素,避免出现必要的微服务拆分我们建议的策略系统集成五常痛点避免 必要 集成集成 活动 左移尽早开展集成活动,建双沟通机制,对共识并验证,避免集成缺陷暴露过晚导致的额外浪费引 平台 能为平衡集成活动左移带来的作量,引依赖模拟器和动化测试套件,减少重复联调,设置质量保障禁费时费完成的集成作却很脆弱,导致集成作要反复重来已经调好的接换个环境就出现异常(例如SIT或者UAT),导致双员不能释放,必须关关过被集成在变更中意间破坏了接的报结构或是其内部业务逻辑 导致我时有遇到意外的缺陷 集成作费时费且很琐碎,但不能
23、推迟到项后期“批量处理”项中存在量集成点,需要逐制定计划、找对接开会、阅读档、准备数据、联调接,这个过程会根据需要重复多次 IT侧来看集成接可以跑通没有异常,但不代表业务场景能正确还原 例如关键业务凭证产字段缺失或者关键业务数据计算错误等 很多集成的问题在项中后期才能发现,尤其是涉及到外部系统的集成(例如快递系统、外卖系统等),甚会流产环境,造成线上损失 12345基于沙箱技术构建动契约与集成验证?/?API?API设计开发开发测PR Pipeline代码合并需求设计定义API schema?API?ProviderConsumer开发API编写组件测试运组件测试运契约测试集成测试合并代码?A
24、PI?API?API Designer开发Consumer API编写组件测试运组件测试运契约测试集成测试合并代码?API?痛点:维护契约测试维护成本痛点:集成测试集成问题只能到集成环节暴露技术案SUT?component test?问?SUT?RequestRequestResponseResponse?API SchemaAPI Designer平台程的认知:是什么、能解决什么问题200404200?!终于接成功!组会和对系统对接了解情况200200集成时发现有个接没通.按照业务需求为集成准备好了测试例和数据录制接的输输出,成测试程线上沟通录制测试例联调接制定测试例之前 需要反复准备复杂的
25、场景和数据 互相不了解对上下,沟通时觉得拉了,但实际上还是不对,反复沟通现在 这样的过程只需要经历次,后续都可以使平台实时获得快速反馈 记录下外部系统的返回,使得对于外部系统的测试更加容易平台程的认知:是什么、能解决什么问题及时发现集成险我正在开发新功能,也需要集成这个接,并不知道接变更了开发中进集成交互模拟设置定时任务/变更触发 录制接,监控接变化现在 每天动获取最新的接返回,常开发不时时询问 平台动重置测试例所依赖的数据,降低测试可重复执的技术槛对修改了接且没有通知收到系统告警,及时发现并修复集成问题现在 在开发过程中就能发现问题,不等到集成时才暴露开发时使x进集成验证及时处理修复查看测试
26、报告收到告警案例:某多产品线研发组织(600+)案例的背景:业务复平台在构建同时、需要撑多产品线的研发、发布 案例的挑战:资源复与共享?经验复与共享?业务和程能如何复?平台程如何应对:解耦与业务关 复杂操作和成本的程能。兼顾短/期,加速研发价值流动和提升业务能复量演进平台程撑多产品和业务复平台的并构建平台研发模式的组织拓扑结构28产品多业务流团队架构委员会产品多业务流团队平台业务流团队Maintainer Group能共享社区产品线产品线程平台团队System ArchitectConsumer/ContributorConsumer/ContributorContributorMaintai
27、ner业务复平台BP TeamBusiness Partner合作伙伴ST系统测试程师平台和产品并开发、测试、集成过程实例CBS?UT/CTSprint planCBS Scrum TeamProduct Scrum TeamCBS?&Vertical?System TestSprint plan?UT/CTRC版本公业务服务独发布流CBS消费流CBS?Core repoSample Vertical?UT/CTRC版本CBS Tag 版本Tag version?CBS API TestIntegration Test End-to-end TestIntegration Test QE QE
28、Tag 版本CBS repoCBS Tag 版本?P?Bug?Fixed P0Issue ticketIssue ticketIssue ticketCBS APICBS SPI平台研发模式下的平台撑能测试策略 程撑CBS 开发、发布、协同CBS需求 与发布策略管理CBS 架构演进设计 作框架Service Hub?Consumer?CBS Proposal?CSS?Proposal?CBS?CBS?/?(?/?)?CBS?CBS?CBS?Consumer?Consumer?CBS?CBS?Contract?/?Contributor?Consumer?Consumer?CBS?Consume
29、r?Consumer?Consumer?Consumer?CBS?CBS?&?consumer?CBS?SLA?CBS?/?/?SLA?CBS ticket/bug/issue?CBS ticket/bug/issue?CBS?&?CBS?Contributor?Contributor?Onboarding?CBS?90%?0?10%?1000?313 2021 Thoughtworks Kent Beck,Smalltalk 软件的开发者,设计模式的先驱,测试驱动开发的持者,也是极限编程的创始者之。https:/ 10%2023 Thoughtworks|Confidential GenAI
30、解决了流动过程中 常的阻碍Finding informationSlow feedbackCognitive frictionDX frictionOperating model frictionTeam effectivenessValue-add delivery 30%70%Overhead/WasteValue-add delivery60%Current stateFuture state32GenAI 可能带来的影响常的摩擦示例,它们降低了产并阻碍了流程HIGHFinding information-提企业档的新鲜度和清晰度,增强可搜索性MEDDevEX friction-加速代码
31、和测试成(不解决具链复杂性和其他开发体验因素)MEDCognitive overload/task switching-些具(如JIRA虚拟助、Copilot-X)可以带来些收益,但并不能直接解决作分配问题MEDSlow quality feedback loops-对测试成提供了巨持;但是,复杂且脆弱的架构仍然很难进测试LOWOperating model friction-更好的结构化需求将有所帮助,但团队间的依赖关系仍然存在问题简单重复的任务将获得最的提升,复杂任务和专业程师的收益将会较少AI对产的影响预期33Project durationRegularGenAI AssistedSD
32、LC Impact with GenAI12mo 3.8 mo随着业对AI具的采增加,整个SDLC的各个阶段都有巨的压缩机会。根据对GenAI的初步分析,我们预测随着具的成熟和采的增加,在所有阶段的收益将达到2倍3倍以上。然,拥有重要架构和技术债务、缓慢的规划和交付模式或官僚化的组织将会获得明显较少的收益。Refer:Detailed analysis 2023 Thoughtworks|Confidential You34AutoGPT等框架展现出 企业AI技术应的新范式AI助理然语提出问题LLM Large Language ModelTasksTask 1Task 2Task 3Task nTask ChainTool aModel aTool bModel nTool/Model MeshMemoryOutput然语给出答案内部或外部的 具/模型Line of VisibilityGoalsSource:Generative AI PoV-Generative AI in Fashion