〇 分享简介 〇

编码是研发过程中投入时间和精力最多的环节，编码环节的提效对于整体研发效能的提升是至关重要的。但从过往来看，针对编码环节的提效工作做的是偏少的，随着云和大模型技术的兴起，开发环境的云化、编码过程的智能化成为了行业重要的课题，

百度在多年的现代化编程现场的探索和实践中，总结了其三大特征：高效、智能、持续演进，和四大方向：在线化、一体化、数字化、智能化。并针对于此，构建了云IDE平台，当前已覆盖厂内80%的工程师，实现了开发环境的即用即得。编程现场大数据结合文心大模型，打造智能编程助手Comate，帮助工程师实时续写和生成代码、注释、单测，更快更好的完成开发任务，当前已覆盖70%工程师，高活用户采纳率将近50%，提效效果非常明显。

本次分享旨在给参加者对于现代化的编程现场一些启示，帮助参与者对于编码环节提效产生一些思路和投入的方向，使用云和大模型技术帮助企业实现软件生产力的提升。

〇 分享收益 〇

目标：

了解研发提效的关键环节，编码环节的提效方向，以及百度多年在研发在线化、编码智能化的探索和实践

成功（或教训）要点：

1、通过开发环境的云化，实现研发全流程在线，开发环境随时随地，即用即得，可以很好的解决开发环境部署困难、不一致、难复现、性能差以及跨OS开发困难等常见开发问题

2、研发工具和服务一体化集成到云IDE中，可以提升工程师的专注度和研发效率

3、基于大模型和编程现场大数据构建的智能研发助手，通过帮助工程师实时续写和生成代码、注释、单测等能力，可以极大提升工程师的编码效率和质量

启示

编码是研发过程中投入时间和精力最大的环节，编码环节的提效至关重要。开发环境的云化和编码过程的智能化可以极大的赋能编码提效，实现编程现场的现代化

〇 分享亮点 〇

1 研发提效的关键场景：编码

1）寻找研发提效的方向

2）推进编程现场从小作坊到现代化

2现代化编程现场的特征和探索方向

1）三大特征：高效、智能、持续演进

2）四大方向：在线化、一体化、数字化、智能化

3百度现代化编程现场的实践和案例

1） Dev in Cloud

2）代码智能化

3）未来的规划和畅想

4 QA

〇 分享简介 〇

DevOps第一阶段许多企业最关注提效，通过容器化，借力元原生，加强内部工具和自动化建设之后，交付的效率和质量通过度量数据(需求数、研发周期、延期需求、BUG、故障数、处理时效等指标)发现不再是我们的主要矛盾，此时次要矛盾(稳定性)会成为主要的矛盾。

应用生命周期里，从开发、测试，部署上线之后的运营，影响稳定性的因素有很多，代码质量、测试质量与覆盖面、规范与流程，操作和责任心，都会息息相关。

本次分享重点围绕着三个方面来展现稳定性建设方面的经典实践，以SRE为主导的组织升级，让部门协助的组织架构有明确管理、高效沟通、高效负责；以度量体系 建立指标体系，让发现、追踪、跟进、复盘等良性循环；以专项 治理和机制，运动式解决当前主要矛盾，同时智能监控与报警机制，不断优化召回率，以达到先于精准发现问题的能力。

〇 分享收益 〇

目标：

1、明确组织升级在稳定性建设中的价值体现 ，包括SRE职责、Oncall机制、Oncall人员能力建设及职责；

2、建设可以发现问题的方法和能力，从可观测的指标，通过专项治理的动作，定期的Review ，成解决问题的一整套机制。

成功要点：

1、打破各部门的边界，串联起测试、运维、开发、其他等多部门，都需要往前迈一步的思想和动作，同时，明确解决问题的第一负责人，从全局视角看待稳定性，不放过任何一个影响稳定性的风险点。

2、专项治理：每家企业主要矛盾不完全一样，但，寻找问题的方法是相似的，度量指标看问题，专项治理解决问题

启示：

稳定性治理关键核心要点

1、SRE，从被动支持，到主动驱动，从只看部门内，扩展到整个公司

2、流程与工具、平台约束提升稳定性至关重要，收好口，是减少误操作或乱操作的有效方法。

3、通过量化数据解决核心矛盾，结合每家实际情况。规范治理动作。

〇 分享亮点 〇

1、建立稳定性度量指标，通过指标看阶段性主要矛盾

2、从运维到SRE，完成组织升级，组织升级带来的组织变革。

3、专项治理实践：运动式当前主要矛盾、机制(流程、规范)和平台(约束)，让同类型的问题得到根治

其中，完善SOP，设置必要的checklist，确保从治理一刻开始，后续不再出现漏添加等问题，除监控与报警，以及异常检测中大于n秒接口、异常状态码、SQL治理、元数据治理等专项。

4、通过治理引发的效果及可复制应用实践

5、稳定性的一些发展思考

6、QA

〇 分享简介 〇

以 Kubernetes 为代表的云原生实践已经成为企业上云的最短路径，越来越多的企业开始基于 Kubernetes 在云上构建自己的基础设施。伴随企业业务规模的增长，每个企业都希望在云上通过弹性提升资源使用率，降低成本。继传统的微服务应用之后，大数据和 AI 场景的应用也开始在 Kubernetes 基础之上构建。大数据场景的 Spark 应用开始逐从 Yarn 渐向 Kubernetes 迁移，而 AI 新型场景的分布式架构生产级实践几乎都是围绕这 Kubernetes 展开。

相伴而来大数据和 AI 场景的兴起，决定Kubernetes 架构的复杂性问题和面向资源的成本控制越来越难。大数据和 AI 场景的共同特征是资源需求量是波动的，不是稳定不变的。构建 Serverless Kubernetes 产品形态，一方面是形成标准化，另一方面是与云基础设施深度整合，让技术资源可以弹性灵活选择。凭借无服务器 Kubernetes 技术，多场景需求成为最灵活的技术支撑。

本次分享将让参会者理解 Serverless Kubernetes 构建的关键难点和解法，云上应用弹性的难点和解法，以及在典型 AI 场景中挑战和应对之策。

〇 分享收益 〇

１.目标：

构建 Serverles Kubernetes 的实践路径，以及在 Serverles Kubernetes 中构建AI应用的最佳实践，包括数据管理、模型训练和推理、工作负载调度等方面的方法和工具。

２.成功（或教训）要点：

1）Master免运维的难度：Kubernetes的master节点是集群的核心，需要处理API请求、维护集群状态，管理网络规则和路由等。实现免运维的难点在于如何设计自动化工具和流程来管理和维护这些核心功能。

2）Nodeless的挑战：在Kubernetes中，Nodeless是一种新的运行模式，它的目标是在不需要预先配置节点的情况下运行Pod。要实现这个目标，需要解决如何调度和分配资源，以及如何管理和隔离Pod。

3）模型管理和镜像秒级启动：AI 场景模型和镜像都很大，GPU 资源本身又很贵，所以按需使用资源在 AI 场景是刚需，而 AI 模型文件都很大，AI 应用的镜像也很大，这就给应用启动速度带来了很大的挑战，怎么解决大文件加载的冷启动问题在 AI 弹性场景是一个要解决的挑战。

3.启示

标准化与基础设施深度融合的 Serverless Kubernetes 形态是构建 AI 和大数据基础设施的最佳实践。

〇 分享亮点 〇

1. 分享Serverless Kubernetes价值应用

2. 构建 Serverless Kubernetes 的难点和挑战

3. 在Serverless Kubernetes中构建AI应用

4. Serverless Kubernetes的AI应用实践案例

5. 总结和展望

QA

〇 分享简介 〇

ServiceMesh的发展，将RPC能力下沉到了Sidecar中，实现了应用与流量治理的解耦，应用不再需要关注限流、服务发现、服务注册等一系列复杂服务治理能力。但传统的微服务应用除了依赖RPC能力外，往往需要依赖多种分布式运行时能力，比如对象存储、消息队列、配置读写、缓存等能力。

伴随着上述运行时能力以及云服务提供商的多样化，导致了传统微服务应用在开发部署中面临了新的挑战。首先是移植性问题，传统微服务应用跟运行时能力强绑定，无法做到不同平台之间的无感迁移。其次不同编程语言的微服务应用无法共享一套SDK，需要重复性的“造轮子”。基于多运行时架构能力，可以实现将运行时能力下沉到Sidecar中，实现运行时能力与应用的解绑。

本次分享将让参会者理解多运行时架构发展建设的关键难点和解决方法，ServiceMesh与多运行时时架构的融合方案，多运行时架构落地实践中的痛点和解决方法。

〇 分享收益 〇

1. 目标：

多运行时架构和ServiceMesh的融合方案，以及如何在实际生产中落地多运行时架构的最佳实践，包括支持用户自定义拓展能力、性能优化、接口标准化定制等方面的方法。

2. 成功（或教训）要点：

接口标准化定义：基于多运行时架构构建的微服务应用，面向的不再是传统的SDK接口，而是一套基于GRPC的标准接口，因此接口的标准化定义决定了应用后期的可移植性。

与ServiceMesh相互融合：每引入一个Sidecar都会增加系统的复杂度，增加系统的运维成本，如何实现和ServiceMesh的融合，让ServiceMesh和多运行时架构融合在一个Sidecar中，降低应用部署和运维的复杂度至关重要。

用户自定义拓展接口：接口的标准化定义是一个漫长的过程，从Proposal到最终的敲定往往可能经历数月之久，如何在标准化的同时，支持用户自定义接口是一个需要解决的挑战。

3. 启示：

通过多运行时架构，实现将运行时能力下沉到Sidecar中与ServiceMesh相融合是当前云原生背景下构建微服务应用的最佳实践。

〇 分享亮点 〇

1. 分享基于MOSN的多运行时架构价值应用

2. 落地基于MOSN的多运行时架构的难点和挑战

3. 分享基于MOSN的多运行时架构的落地实践案例

4. 多运行时架构的未来展望

QA

〇 分享简介 〇

随着企业信息化水平的不断提高，应用服务已成为现代企业的重要组成部分。对应用的有效管理，直接决定了企业业务能否顺利开展，以及能否在成本和效率之间取得价值最大化。近年来，以容器为代表的云原生技术发展如火如荼，为企业应用管理提供了新的技术体系，开拓了新的思路。但如何在成本、效率和稳定性之间平稳落地应用云原生技术、兼容已有服务管理体系依然是我们需要持续探索和解决的问题。

后起之秀的得物，在快速的业务发展过程中基础设施的规模不断增长，继而对效率和成本的关注度也越来越高。以提升资源使用率和技术交付效率为目标，开始基于云原生技术建设整个服务体系的高可用性、可观测性、高运维效率，同时要保证成本可控。容器化过程中我们遇到了很多的挑战，包括：如何将存量的服务在保持已有研发流程不变的情况下，做到容器化部署和管理；容器化之后如何做到高效地运维；如何针对不同的业务场景，提供不同的容器化方案等；此外，通过技术手段实现持续的成本优化将是长期目标。 

本次分享将结合得物在推进应用容器化过程中的容器平台建设、混部、调度和稳定性治理等相关方案和实践过程，与大家一起探讨如何在企业应用管理过程中落地云原生技术。

〇 分享收益 〇

1目标

1）分享云原生相关技术在得物内部的实践过程，供业内同行参考和交流。

2）调度优化、混部技术介绍和最佳实践。

3）容器平台/云原生AI平台建设过程分享。

2成功要点

1）在上云的同时，企业需要有核心技术方案的自建能力。

2）面向不同的业务场景，容器化的过程需要给出不同的解决方案，避免将容器属性强加给用户。

3）降本提效是云原生技术在企业中的最大价值，也应该是容器化实践的长期目标。

3启示

降本提效是容器化在企业中的最大价值，也应该是云原生技术落地实践的长期目标。

〇 分享亮点 〇

1、得物容器化推进历程

2、容器服务管理（配置管理、CI/CD流程设计、效率提升手段）

3、容器成本优化实践（画像/调度优化/混部时间/弹性伸缩方案）

4、云原生AI场景建设

5、QA

〇 分享简介 〇

随着火爆全网的GPT的出现，每个领域都开启了全新的Ai时代，越来越多的AI产品涌现出来，很多旧的工种或者能力会被AI取代，但随之而来的也会有更多新的机会涌现出来。一切的变革都是双向的，而如何将这个“危险”转化为”机会“。

在这个风口浪尖的时候如何快速将变革创新做准，做对，跑快至关重要。  在AI的行业应用层面，大家更多是聚焦在C端产品的体验和运用上，例如火出天际的midiourney，大家都在积极去探索和使用它，但真正应用在复杂的企业应用中却并不太多。

本次分享基于客户价值对复杂业务场景的B端产品智能化设计的应用进行分析及设计。从B端产品是如何将智能化的商业价值。到变化极快的时代怎样培养正确的创新思维、系统性的创新；同时，B端产品在客户旅程里的价值链，与关键业务场景怎么融合智能化设计，用产品体验能力为企业降本增效。

〇 分享收益 〇

目标：

1、了解B端产品的创新思路及系统性的创新方法；

2、了解B端产品复杂业务场景融合智能化设计

3、了解到B端的客户价值链。

成功要点：

面对B端复杂业务场景的产品进行创新设计，产品价值链条在客户旅程中，怎样让创新设计与客户价值匹配的天衣无缝。

启示：

建立从创新思维，到创新方法，典型产品应用场景的设计的整体设计思路全流程。

〇 分享亮点 〇

1    AI变革之下如何进行产品创新

1）AI时代交互变革分析

2）如何培养正确的创新思维

2）系统性的创新方法论

2    B端产品的客户价值链分析

1）B端产品与C端产品的差异化特性

2）B端产品客户画像特性

3）B端产品客户旅程价值链

3   B端产品基于客户价值的智能化设计

1）通用性场景智能化设计

1）财务场景的智能化设计

2）业务场景的智能化设计

〇 分享简介 〇

近些年DevOps在众多企业内进行了落地，用以提高业务交付的速度和质量，从而提升企业的竞争力。传统安全开发模式因跟不上DevOps的快速的交付模式，成为业务交付速度进一步提升的瓶颈。为了解决这一问题，DevSecOps应运而生。DevSecOps通过安全左移，实现了安全和软件开发过程的完美融合，在保证业务交付速度的同时，使得软件开发更安全。

目前的DevSecOps安全左移主要集中在开发和测试阶段。然而，许多安全风险和威胁并非直接产生于开发编码阶段，而是项目设计阶段。在软件开发的生命周期中，任何风险与漏洞暴露的越晚，其修复成本和修复难度也就越高。因此，我们需要在 DevSecOps 的实施过程中去引入一整套适合DevOps模式的安全风险评估体系，让安全进行更彻底的左移，帮助项目团队进一步实现高质量和更安全的持续快速的交付。

本次分享将通过实际案例，讲解在技术，流程和人等各个维度的改变，最终实现安全架构设计在DevSecOps模式下左移的具体实现。

〇 分享收益 〇

目标：

1. SDLC安全左移中的安全架构设计

2. 安全架构设计在DevSecOps中进一步左移的具体方案和应用 

成功要点

1加速现代化开发，成熟的DevSecOps实现将具有坚实的自动化，配置管理、编排、容器、不可改变的基础架构甚至无服务区计算环境。

2将安全集成到开发过程的所有阶段，形成完善的防御技术，提前发现并修补安全漏洞，从而降低了团队在产品开发周期中花费大量时间调整和修复的需要，成本效益更高。

启示

架构安全左移让DevSecOps团队及早发现潜在的安全风险，并在开发初始阶段确保消除安全威胁，从而进一步保障了产品的安全性并且减少了修复成本。

〇 分享亮点 〇

1 DevSecOps的行业价值解析

2  SDLC安全左移

3  DevSecOps技术和工具实践

4  经典案例： DevSecOps模式下进行安全架构设计左移

5  QA

〇 分享简介 〇

AIGC正在给软件研发的形态带来根本性的改变。分工越来越细、框架、基础设施越来越复杂的趋势，将会被从根本上扭转。具有业务能力，同时，有效掌握了架构技术和实现能力的超级团队和超级个体，生产力将会获得数量级的提升。在这样的时代，我们需要更多架构能力支撑战略。

本次分享将从软件开发的价值创造过程出发，结合一线实践，分享AIGC在精益需求分析、领域建模、接口和契约以及演进式设计等若干方面将会带来的关键变革，以及软件架构师和开发人员应该为此奠定诸多良好技术基础。

〇 分享收益 〇

1. 目标

(1) 建立大语言模型时代的软件开发人员能力图谱。

(2) 理解价值为导向的精益软件设计方法论的关键实践和实践之间的联系。

2. 成功要点

在AIGC时代，建立高效的方法论，更有效地和大模型协同，发挥架构师的核心价值，有效提升生产力。

3. 启示

(1) 探索和发现仍然是软件开发的本质问题。AIGC可以加速探索和发现，但是人类仍然是探索和发现的主体。

(2) 围绕业务目标的快速构建和探索将会更加高效。领域模型在其中将扮演重要的角色。

契约是设计的核心，需要予以更多的关注，技术细节的影响将会弱化。

〇 分享亮点 〇

1. 审视软件设计的全过程：以探索和发现为中心

(1) 案例研究

(2) 领域模型、由外而内和设计契约

(3) 组件开发和复用

2. 利用好第二大脑：软件各个环节的副驾驶

(1) 需求分析和迭代规划环节的辅助

(2) 领域模型作为输入还是输出？

(3) 围绕设计契约的自动化构造和契约管理

3. AIGC时代的精益软件设计方法论

4. 未来探索：应用生态和应用架构的范式迁移

QA