黎嘉豪-平台工程，一致性与规模化

●腾讯DevOps核心系统负责人●百度协同管理工具架构师●华为云计算高级研发工程师，负责计算、存储的设计和研发●DevOps Master认证●DevOps Enterprise Coach认证●DevOps标准核心编写专家●百度方法+持续交付联合作者、百度DevOps布道师●《Devops最佳实践》合译者 Agenda •平台工程是不是新的轮子? •探索路径与效果•发展阶段•规模化的效果 •如何提高一致性来达到规模化 •拥抱平台工程，避免踩入常见的误区 GartnerReportx平台工程是否又一个轮子 Gartner use hype circle predict platform engineering will be main-stream tech at2025and2028 Puppet Reportx平台工程是否又一个轮子 Average3 IDPSin one company PuppetxHumanitec2024 DevOpsReport 96%companies have alreadyestablished a platform engineeringteam. 78%of the teams have beenestablished for at least three years. Top benefits of platform engineering:Productivity-Quality and Stable-Reduce Lead time- Challenge for Developersx平台工程是否又一个轮子 -Netflix使用他们的平台来解决开发人员管理多种服务和软件、了解存在哪些工具以及在工具之间切换上下文的挑战。 Ref fromDaniel Bryant at PlatformCon 2022 -Nordstrom建立了一个平台，成为“自助服务的北极星”。他们的平台帮助消除了配置过程中的瓶颈，并消除了人们登录生产的需要。这些变化使组织能够更快地行动。 -Zalando利用他们的平台来统一开发人员体验，促进默认合规性，并随着时间的推移改进公司的运营方式。 FirstPrincipleThinkingx平台工程是否又一个轮子 1.⼤多数开发⼈员不喜欢处理基础设施。他们想编写代码并在某个地⽅运⾏它，但不太关⼼运⾏在哪⾥。函数即服务（例如Lambda）或平台即服务（例如Vercel）提供了这种体验。 2.随着公司/组织的发展，其需求可能会“超出”由FaaS和PaaS产品施加的限制。然后挑战变成在不离开开发者舒适区的情况下向上移动控制轴。这就是平台⼯程发挥作⽤的地⽅！ 平台工程的目标 开发人员拥有应用和应用组SDLC控制权 帮助软件团队提升和持续交付软件业务价值 灵活/规模/安全的平衡 工程上的合理性 HybridCloudManage Service (e.g.pulumi) 个人经历的三个阶段： IDP / CICD Platform /平台工程 Agenda •平台工程是不是新的轮子? •探索路径与效果•发展阶段•规模化的效果 •如何提高一致性来达到规模化 •拥抱平台工程，避免踩入常见的误区 发展阶段x探索路径 定义平台工程团队的目标 构建平台工程团队 构建平台,遵循产品方法如:用户研究/UserStoryMapping/MVP等 衡量平台工程的KPI,并监控起来。如：生产力，交付时间，部署频率，开发人员满意度，稳定性和效率 2 Different Strategyx探索路径 àMonorepo -Dictates all source code in a single source repo.-There are no versions of internal libraries, just what is on HEAD-Any code change should be compiled/tested against everything in the repositorybefore being pushed to HEAD Multiple Reposà -Share little approach(or don’t use sharedlibraries)-Services should only be coupled via theirHTTP APIs-Minimally reused CI/CD capabilities, eachbuilt independently. Monorepo Advantages of monorepo at scale Mindset: -Resolved once and for all-Who build it , who run it Advantages ofmonorepoat scale: -单一代码库、共享、横向可见性-支持代码共享和重用-改善协作，更容易重构-简化的依赖管理(配置, DDL等)-原子变化仍处于控制之中-标准的CI/CD管道-所有提交和发布都经过评审、自动化测试 人人为我，我为人人x规模化的效果 人人为我，我为人人x规模化的效果 人人为我，我为人人x规模化的效果 Changeone，changewholex规模化的效果 Postsubmit and Deploy 代码合入主干,制作制品,发布 大规模升级依赖x规模化的效果 依赖升级结合CICD标准化 •按月定期升级所有服务•依赖升级分批验证，全生命周期跟踪•依赖情况的检查•破坏性变更的检查•遇到问题，及时回滚和止损 精准构建/编译加速x规模化的效果 构建标准化覆盖三部分： 1、依赖的构建环境（包含：硬件、操作系统、开发语言、Toolchain/SDK、第三方开源代码版本等） 2、标准化编译入口 3、标准化输出、归档（产出物） -大仓编译缓存+精准测试，降低构建量94% L3/L4/L5的自动发布x规模化的效果 通过制品库，所有代码只有通过持续集成流水线验证的，才可以被打包成制品，并通过仅授权标准流水线向产出物打可信标签，实现对于被部署产出物的质量筛选。在CD环节，所有环境的晋级也是基于制品的可信标签进行流转，每个环境的验证结果都会被自动化流水线记录在制品库的标签中 提高服务部署稳定性x规模化的效果 在整个2022年某BG发布变更类导致的故障在有定级的故障里占比达到XXXX% •当前的部署服务不能执行完整的线上变更操作，对于多种配置变更的验证不足；•围绕部署变更的质量保证实践没有工具及流程支撑；•环境的使用及变更管理缺少规范及管理，变更破坏环境隔离影响线上 敏捷频繁小批量发布自动化减少或消除频繁发布的重复开销隔离力争采用模块化架构，以隔离变更，并使故障排除更加容易可靠度量关键的健康指标，如崩溃或延迟，并不断改进它们数据驱动决策对健康指标进行A/B测试，以确保质量。分阶段发布在将变更发布给所有人之前，先向少数用户发布。 需求的托管x规模化的效果 需求的标准化能让需求看板更加清晰及时反馈项目状态，潜在的场景，PMO会关注需求状态是否更新及时，业务PD会关注需求的leadtime，技术TL会关注版本发布的需求清单。 -标准化包含需求模板/工作流的标准化，同时也跟CICD过程的结合。 对于中台，平台工程赋能了平滑升级x规模化的效果 -控制panel(*)-执行panel-数据panel Agenda •平台工程是不是新的轮子? •探索路径与效果•发展阶段•规模化的效果 •如何提高一致性来达到规模化 •拥抱平台工程，避免踩入常见的误区 整体目标x如何提高一致性 如果我们想让效率不降低，就要想办法消除随机复杂性，而消除随机复杂性的必经之路就是“一致性”。而要达成一致性，大家必然要遵守相同的“道、法、器、术”。 大家都在说工程师文化，文化就深植于这三个方面，我们必须通过这三方面的建设，才能打造我们想要的工程师文化。文化是这三方面相互作用的结果，它既不是过程，也不是方法。 如果道和法不同，那么，器和术上的一致在社会性问题上也无法达成。 而道和法一致，那么，器和术就可以相互转换，螺旋上升。 引用自：乔梁老师，《一致性，是研发效能提升的必经之路！》 G O P S全 球 运 维 大 会2 0 2 4 ·深 圳 站 Metadatax如何提高一致性 建立应用-发布单元的映射 ExampleforMetadatax如何提高一致性 Rule: Define for user scenarioRule: Minimize variationRule: Monitor, TestableRule: Different PermissionRule: Easy to Scale Proto->TextProto 用户故事地图x如何提高一致性 Designfor oRDoBuild EngineeroQAoREoSREoPDoTLoSecurityoAudit 核心场景超过500+SDLC全面覆盖 SystemDesignForEveryStage(Abstraction)x如何提高一致性 Example:Presubmit 代码即将合入主干前的质量验证，在此阶段尽量模拟开发人员代码合入后主干的效果，避免提交的代码合入主干后影响其他开发人员。本步骤对任务时间、质量和并发都很高的要求，长耗时任务会被强制取消，性能不满足的任务允许用户不执行。建议执行时间15分钟以下。 执行的任务： 代码变更范围： •对于业务代码、测试代码的测试•对于配置与数据的测试•对工程文件（元数据文件、非Bazel的编译依赖等）的测试 ü业务代码ü测试代码ü配置与数据ü工程元数据文件ü基础设施 Everything asCodex如何提高一致性 Agenda •平台工程是不是新的轮子? •探索路径与效果•发展阶段•规模化的效果 •如何提高一致性来达到规模化 •拥抱平台工程，避免踩入常见的误区 拥抱平台工程，避免踩入常见的误区 You Rename Your (Dev)Ops Team to Platform Team But Still DoTicketOps No Mindset Shift to Platform as a Product Your Platform Team Builds a Platform for Ops, Not For Developers You Replace Old Tech with New Stuff for No Reason You Think Your Setup Needs to Be Special (*) You Build a Portal Developers Never Asked for You Try to Hide Sunk Costs(*) 引用自：https://platformengineering.org/blog/9-steps-to-platform-engineering-hell 适者生存x避免踩入常见的误区 融合大小仓方案，让升级可覆盖所有场景，组建企业级的质量防护体系 平台工程作为企业级DevOps成功实施的核心能力，受到广泛关注 p平台工程是一组用于设计、构建和运营支持软件价值交付和生命周期管理的平台的方法、流程和机制，具备自助式、自服务能力，能够最小化内部IT人员的认知负荷，提升DevOps/BizDevOps质量、效率与效能。p当前，在数字化转型的浪潮下，平台工程对于加强科技能力至关重要，国内多项政策文件均提及或鼓励企业建设内部开发运维平台；国际上多个权威机构都将平台工程视为关键技术趋势。 国家金融监管总局：积极引入研发运维一体化工具，完善数字化交付管理体系 中国