首次分享！滴滴国际化出行的建站实战经验

滴滴技术

于 2024-09-12 21:04:56 发布

阅读量721

点赞数 9

文章标签：运维 devops

本文链接：https://blog.csdn.net/DiDi_Tech/article/details/142198240

版权

背景介绍

从2018年开始，滴滴国际化出行业务陆续进入巴西、墨西哥等多个海外国家市场，而伴随着业务的扩张，出于稳定性、成本、合规等要求，业务系统需要频繁在不同地区、不同基础设施环境的机房内进行大规模建站交付，例如自建 IDC、AWS、GCP 等公有云环境。

经过几次新机房交付后，我们发现，出行业务包括业务系统在内，有上千个模块与存储实例以及数万张表，业务架构复杂、链路长、依赖多，导致当前建站效率非常低，从建设开始到正式提供服务，需要全链路业务 RD、SRE、QA ，大量团队的数百位同学参与支持，前后耗时 3 个月以上，严重影响了正常业务功能的迭代，同时由于整个交付过程极高的复杂度，异常问题及风险频发，对线上业务造成预期外的影响。在低效的建站交付也会对业务的决策造成严重影响，错失关键的市场窗口。

因此我们在 2021 年 Q4 正式开始立项解决上述的建站提效问题。在进行问题分析及解法设计之前，我们先展望一下理想中的建站交付应该是什么样的：

建站交付过程应该是高度自动化的，交付动作收敛在少量 SRE 人员内完成，减少大规模的各团队人员参与，交付时间缩短至周级别
建站交付结果是高度可信赖的，有自动化验收能力，减少预期外线上业务影响
建站交付能力应该是平台无关的，支持混合云环境，在自建 IDC 与公有云之间、不同公有云厂商之间，均可完成自动交付
建站交付能力应该有足够强的防腐能力，因为建站交付的频率相对较低，一般以年为周期，两次交付之间的大量架构变更不能导致建站交付能力失效

带着这些目标，在接下来的系列内容中给大家介绍一下国际化出行在建站提效方向的一些核心思路、关键技术方案以及经验总结，整个系列包括三篇文章：整体方案及实战经验、环境差异配置管理，以及应用交付。

本文为第一篇综述，重点介绍建站提效的整体架构以及在国际化出行业务的落地路径与效果。

问题分析&拆解

我们先拆解一下国际化出行建站的全过程，分析当前建站低效的根因。

整体建站流程大致可拆分为上图所示五个阶段：

基础设施搭建：该阶段主要由基础平台团队负责在新建站环境进行业务模块依赖的各类基础设施的适配与搭建，例如网络设置、K8S 集群搭建、各类基础组件部署（例如接入层、存储系统、MQ 等）、各类运维设施部署（例如服务树、可观测系统、预案平台等），耗时约 30 人*周；
集群环境搭建：该阶段主要由 RD 梳理建站过程中待交付的服务范围，然后由SRE进行服务节点、集群及相应的运维配置交付，耗时约 40 人*周；
依赖资源申请：该阶段主要由 RD 梳理建站交付过程中服务依赖的各类资源范围以及交付目标，包括存储、中间件等，然后由 SRE 按资源类型进行批量交付，耗时约 40 人*周；
服务改造部署：该阶段主要由 RD 根据阶段 3 交付出的资源详情信息在代码中进行相应配置及逻辑改造，以及在各平台中更新集群配置，并进行线上部署与联调，耗时约 60 人*周；
业务流程测试：该阶段主要由 QA 在阶段 4 服务部署联调完成后进行完整业务流程的测试回归，以及全链路压测，由于测试过程容易出现交付异常导致的预期外问题，RD 需要配合进行 bug 修复，耗时约 40 人*周；

为了便于理解，这里看一个基础设施搭建的实际模块交付 CASE：

在上述各阶段中，基础设施搭建阶段相对业务不敏感且流程固定，可以收敛在基础平台内部完成，当然目前也存在效率提升的空间，可应用 IAC(Infrastructure As Code) 的思路优化，本系列不展开讨论。相比之下，后面几个环节的效率问题更为严重，核心原因在于这几个环节目前都需要业务 RD 的直接参与，这样导致了交付效率与业务复杂度正相关，需要全链路上的各服务负责人介入，而由于各自服务间的复杂依赖，这个过程中产生的沟通成本也与之骤增。目前需要业务 RD 参与的主要有以下几部分内容：

梳理需部署的服务集合与目标规模，交由 SRE 进行服务节点创建及运维设施搭建；
梳理依赖资源，例如 Mysql 库、KV 集群等，交由基础架构 SRE 进行资源统一创建或者 RD 通过平台手动创建；
根据新的资源描述进行代码改造或者平台配置调整；

因此当前在每次建站交付过程中都需要通过一个非常复杂的文档来收集上述信息，这些过程都非常依赖 RD 的经验，有的需要梳理全量代码才能完成，一方面非常低效，另一方面也容易出错，往往在联调过程中会发现各种资源漏建、代码漏改或改错的情况，导致交付进展缓慢，有的问题甚至还会流入生产环境，例如将欧洲机房某个服务的 redis 连接信息配置成美东集群导致的线上故障。除此之外，SRE 的交付动作目前也缺少统一的能力支持，基本是通过各类临时脚本实现，可维护性也存在一定风险。

因此，当前在每次建站交付过程中都需要通过一个非常复杂的文档来收集上述信息，该过程非常依赖 RD 的经验，有的需要梳理全量代码才能完成，一方面非常低效，另一方面也容易出错，同时，在联调过程中往往会发现各种资源漏建、代码漏改或改错的情况，从而导致交付进展缓慢；有的问题甚至还会流入生产环境，例如将欧洲机房某个服务的 redis 连接信息配置成美东集群导致的线上故障。

进一步剖析上述问题，我们可以发现它们源自以下几个根因：

烟囱式 PaaS 平台（梳理低效）：目前的基础平台各类能力均以独立的 PaaS 形式对外提供，业务服务在开发过程中的不同依赖需要分别去对应平台进行申请与管理，进而形成了烟囱，导致无法集中描述一个服务的全部依赖，只能依赖于 RD 的经验；
交付流程缺少沉淀（交付低效）：整个交付流程缺少能力支持与流程管理，导致出现各种一次性脚本与跨团队沟通，效率较低；
集群差异逻辑缺少管理（改造低效）：业务服务环境间的差异配置与业务代码耦合，基本是通过一个集群对应一份配置的形式进行管理，有的配置甚至散落在代码各处，导致在新环境部署时需要 RD 介入改造代码，效率低且容易引入风险。

解决思路

针对上述三个核心问题根因，结合长期的建站交付目标我们得出如下解决思路：

梳理提效：建设应用模型，标准化描述各业务模块与依赖资源、运维设施、平台配置的关联关系，并实现应用信息的全生命周期管理；
交付提效：基于标准化的应用描述，建设自动化的交付框架，实现一站式应用交付；
改造提效：收敛业务模块中与环境关联的配置与逻辑，并进行标准化管理，与交付能力打通后实现交付过程代码 0 改造；

一言以蔽之：建设以应用为中心的自动化交付框架。

技术方案

参照上述的整体解决思路，我们依次介绍三个核心问题的技术解决方案。

应用建模

在上面的现状分析中说到，我们目前缺少围绕一个应用或者一个服务的整体描述，因此无法直接在一个全新环境中将其交付出来，为了解决这个问题，主要从两个方向入手：1. 制定应用描述的模板；2. 围绕应用汇总本身及相关依赖的信息，组织成符合上述模板的应用描述。

首先是应用描述模板的制定，我们采用了目前业内比较规范的云原生开放应用模型——OAM(Open Application Model)。一方面是因为 OAM 对应用的模型定义比较清晰，另一方面也是为了契合滴滴云原生技术路线。

Focused on application rather than container or orchestrator, Open Application Model [OAM] brings modular, extensible, and portable design for modeling application deployment with higher level yet consistent API.

This is the key to enable simple yet robust application delivery across hybrid environments including Kubernetes, cloud, or even IoT devices.

在 OAM 中，应用是由以下几个核心概念组合构成：

Component (组件)：组件可以简单理解为一个业务服务的架构组成，组件既可以包括应用运行所依赖的资源：比如 MySQL 数据库，也包括应用服务本身：比如拥有多个副本的 Golang 服务；
Trait (运维特征)：运维特征描述了应用组件在具体部署环境中的运维特征，比如应用的部署策略、弹性伸缩策略、Ingress 规则等，在不同的部署环境里有不同的实现方式；
ApplicationConfiguration (应用配置)：应用配置是一个应用所有组件及运维特征详细信息的静态描述文件，该文件本身对应 OAM 规范中的声明式 API，用来使后续的交付框架根据 RD 及 SRE 提交的应用描述，实例化出对应的、真正运行起来的应用；

以某真实线上服务为例，其应用模型可以由如下组件描述：

Service 组件：包含弹性云集群 (Workload) 和三个 Trait (负责代码更新的部署模块、日志清理的 CutLog 日志切割以及观测策略)；
Mysql 组件：包含 Mysql 实例 (Workload)，包含实例信息、业务类型、套餐信息和连接信息 (VIP+Port、用户名、密码)；
S3 组件：和 Mysql 组件一样，S3桶 (Workload) 包含桶名称、桶权限类型和连接信息；
BizConfig 组件：包含一组 Yaml 配置和 Mysql 组件、S3 组件的连接信息，最终生成服务环境配置。

应用描述文件 ApplicationConfiguration 示例如下：

使用上述应用描述模板，我们可以将一个应用的所有信息描述出来，同时这样的描述是关注点分离的，开发者只需要明确服务的架构，定义依赖的 Component 及相关描述，而其他的运维属性信息 Traits 则由 SRE 负责填充，这样在交付过程中职责边界是清晰的。

有了这样的描述模板，我们进一步对准入系统进行升级，在新应用进行创建的过程中以此为入口由负责人进行相关信息的描述，同时对旧应用也可以进行准入重入，将相关信息汇总至此，并且会伴随应用的全生命周期存在，这样在后续的新环境交付的时候直接拉取应用的完整描述然后交由下面的交付框架进行批量交付即可。

交付框架

在具备了应用完整描述信息之后，接下来便是基于这个标准化描述文件进行自动化交付的框架设计。

基于上述的长期建站目标，我们最终采用了基于阿里云开源的 基于 OAM 模型的云原生应用交付平台——KubeVela 进行定制化的建设方案，核心原因如下：

声明式交付：KubeVela 是基于 K8S 实现的，因此在 KubeVela 中的应用交付是面向终态的，交付人员给出应用描述后，它可以保证交付至应用所需状态，这样可以降低用户的使用门槛以及底层 API 的复杂性。同时也方便后续与 GitOps 结合，以代码的方式对应用状态进行常态化管理。
基础设施无关：虽然 KubeVela 是基于 K8S 实现的，但是它只使用了 K8S 的控制平面，具体的交付目标环境是不做限制的，因此适用于滴滴目前的自建机房架构，也同样适用于公有云的云原生技术体系，迁移过程对于用户也是透明的。
高度可扩展：KubeVela 中各类依赖组件的交付支持都是通过 CUE 语言进行定义的，非常容易适配当前滴滴内的各个资源组件，且交付能力的拓展非常方便，同时也支持与 IAC 能力的结合，方便对多云环境的资源进行透明交付。

KubeVela 整体架构如下：

我们主要使用了 KubeVela 的核心引擎，上层的应用层与滴滴现有的 DevOps 平台结合，下层基础设施接入滴滴的基础架构栈，深度定制了滴滴内部的交付平台。对滴滴内各类核心资源组件与运维设施进行了交付能力适配接入，同时支持了基于 Terraform 对接公有云的资源组件交付能力，实现了从应用组件描述到应用声明式交付的完整流程，同时将该能力落地成了应用中心平台，实现了应用编排、资源交付、环境管理、应用克隆等能力，供建站交付过程使用。

同时在适配过程中我们发现，资源组件和运维设施的接入维护以及对外交付能力的露出都需要相关方不少的支持投入，同时在后续变更过程中的管理成本也很高，为此我们基于 KubeVela 的 x-Def 能力实现了组件市场解决该问题，如下图所示，组件市场支持接入方自定义交付模板，该模板会将相关参数透出至交付环节供用户输入，同时在 KubeVela 交付引擎中将用户输入的内容传递至相关组件的交付接口，实现组件方交付能力的自助接入。

在应用建模与交付框架完成后，建站交付的过程如下图所示：日常 RD & SRE 在应用准入、日常变更、运维过程中依赖应用中心维护应用的环境无关编排信息，该编排信息通过交付框架支持在任意新的多云环境中进行声明式交付。解决了上述建站过程中依赖人工进行应用依赖信息梳理以及人工交付的低效问题。

关于应用建模及交付框架的详细技术细节将在系列第三篇文章展开进行更深入的介绍。

环境信息管理

环境信息管理重点解决各业务模块代码中与集群耦合的配置与逻辑管理问题，如 Mysql 连接串、超时重试配置等。历史上由于缺少统一规范，而业务模块运行时环境有非常多，包括离线自测环境、线上联调环境、预发环境、小流量环境、多区域生产环境等，导致大家广泛将集群间差异的配置与逻辑硬编码在配置文件或代码中，甚至有的业务逻辑的实现也存在通过集群进行分支控制的，导致建站期间很难遍历需要变更的范围，出现上述低效以及高风险问题。

我们从本质出发思考该问题便容易发现：首先业务模块的逻辑中带有环境信息是完全不必要也不合理的，因为业务功能的实现与实际部署的环境不应有耦合，理论上一套逻辑集成后可被交付至任意环境，包括自建设施或公有云、离线测试或线上生产环境等；其次环境信息是和环境一一对应的，可以认为是环境的元信息而不是业务代码的运行时配置，业务代码应该做到能从环境元信息中获取相应字段后统一执行后续逻辑。上述两点也都在描述云原生应用最佳实践的十二要素配置管理原则中提及，详情可参考文末资料内容。

基于上述思考，我们形成了理想的环境信息管理方案：1. 标准化定义环境相关配置模板；2. 解耦业务代码与环境配置实现集中式管理；3. 打通应用交付框架实现新环境配置自动生成。

配置模板定义

配置模板定义的目的是将服务代码依赖的环境相关差异信息进行标准化定义，方便后续的集中式管理与自动化生成。

环境相关差异信息大致可分为三类：环境元信息（region、可用区、类型等）、组件信息（连接串、超时重试信息等）、其他自定义字段，针对环境元信息与组件信息，我们与相关设施提供方定义标准化模板，支持业务代码获取，针对这部分模板字段，支持与上述交付框架打通，关联交付规则，实现配置自动化交付能力；对于其他自定义字段，主要用于非标模板的管理，如需新增，需要用户定义标准交付规则，适配配置自动交付能力。模板详情如下图所示：

配置集中管理

在配置模板标准化定义完成后，需要将配置仓库从代码仓库中解耦出来进行集中管理以实现后续的自动化交付，配置集中管理是环境信息管理中最核心也是最复杂的部分。

要实现与配置与代码解耦集中管理的重点需要回答三个问题：1. 增删改查如何交互？2. 环境配置如何下发？3. 环境配置如何被业务代码获取？下面来依次探讨：

1. 增删改查入口

在环境配置集中管理后，需要有增删改查入口来取代原研发过程中直接操作代码的流程，这个问题相对简单，唯一需要思考的是为了保证环境配置仓库的标准化，是不允许用户直接进行通过 git 进行任意修改与提交的，因此需要封装一层配置仓库的操作入口。为了实现简单，我们在前期直接使用滴滴成熟的 WebIDE 能力，在其上添加了较为完整的配置校验插件之后交由用户进行编辑修改；在后期这种方式的配置校验偏后置，且无法支持更为复杂的校验能力，用户易用性也比较差的问题越发凸显，因此我们在此基础上提供了更友好的白屏化交互能力。

2. 环境配置下发通道

这里有多种选择，最直接的是考虑使用滴滴现成的配置热更新组件 Apollo，但是通过对国际化全量服务进行扫描和分析后我们发现，这里的环境配置和 Apollo 管理的配置存在较大差异，Apollo 中更适合管理动态配置，即在运行时调整的配置，无须进行服务重建，而这里的环境配置更多的是静态配置，例如 Mysql 连接串、下游依赖的 Token 等，这些配置基本只在服务启动时加载一次，同时，大部分配置场景还是会随着代码变更，整体的配置变更频率较低，对质量保障的要求更高，而 Apollo 目前配置变更的流程相对线上代码的变更质量保障要弱很多。

另一种选择是将配置下发放置在 CD 阶段，类似目前弹性云的环境变量管理，这样可以在每次服务变更时进行环境配置的 double check，但是这种方式依然存在着风险，例如配置变更在开发测试期间和变更时的环境变量配置不一致导致的异常。

因此最后权衡后我们决定把配置下发的流程前置到 CI 阶段，在代码仓库之外新增一个配置仓库，在代码变更流水线中的构建阶段进行配置仓库内容的拉取，这样可以保证配置的变更可以完整走过 CR、测试、自动化 case 等质量保障环节。当然放置在 CI 环节还有一系列相关问题需要解决，例如配置的拉取脚本，配置的协同开发流程，和代码流水线的合并等。下图为配置仓库与业务代码仓库的协同 CI 流程。

3. 环境配置获取机制

解决了配置下发通道问题之后，接着需要解决服务代码如何获取这部分解耦的配置，这里的设计需要考虑的关键问题是服务接入的成本，因为这里的改造基本涉及所有的服务，如果成本过高，推进难度会很大。最直接想到的方案是提供简单易用的 SDK，同时与公司的各种研发框架结合，我们在项目初期尝试了这种方案，但是在部分试点服务接入过程中我们发现，SDK 的接入成本还是很难接受，原服务配置中有环境差异配置也有很多环境无关配置，为了接入这部分配置管理，还需要对其进行拆分，导致很多额外成本。另一方面，SDK 的维护成本也很高，我们需要为不同语言开发不同的 SDK，后续的版本更新也需要所有服务配合。

因此我们采用了另一种模板替换的方案：配置在仓库中通过固定格式管理，然后服务在原配置中将需要从配置仓库中获取差异配置的部分改造为占位符，例如：^cac{{.mysql.user}}，我们在配置下发过程中自动识别这些占位符进行字符替换。这样业务代码的配置获取方式可以保持不变，只需对配置进行少量改造即可，改造量非常低，同时这种方案是语言无关的，维护成本也非常低。具体的细节也放在本系列第二篇文章中介绍。

配置自动交付

在配置模板标准化以及集中管理完成之后，我们便掌握了所有模块所依赖的环境差异信息，且是格式化的数据，因此交付框架可以获取并理解这些差异信息内容，自然可以实现在新环境下资源组件交付后进行模块依赖的差异信息注入，进一步实现建站交付的提效；为此，我们在交付框架中额外实现了 BizConfig 组件，负责收敛交付出的资源描述信息，然后按照集中管理的配置模板进行自动化注入，并自动完成镜像构建及部署交付。

解决上述三个配置管理的核心问题之后，还有两个需要重点考虑的问题，包括：稳定性保障及配置防腐。

稳定性保障：由于环境配置与业务代码仓库解耦后对原有的CI/CD流程有一定的侵入，作为业务服务变更过程中的基础依赖，对其稳定性要求很高，因此我们在事前事中进行了全面的稳定性保障能力建设：事前，对于配置模板的变更都要求通过完整的自测 case 集合回归，同时对配置替换过程与结果进行了完整透出，方便 RD 了解环境信息的注入内容；事中，我们在每一个环境信息替换或生效的关键阶段均进行了 Metric 上报，当出现任何预期外异常都可及时感知，同时提供了降级策略，即使在配置管理服务异常期间，也不会阻塞业务服务正常迭代。
配置防腐：由于配置接入标准会影响建站交付过程中的可用性，而业务功能在两次交付之间会伴随大量的迭代，有打破配置接入标准的风险，因此我们针对配置防腐进行了重点保障：1. 在环境信息增删改查的入口进行了完整的字段合法性检查；2. 在业务代码变更过程中引入了自动化 CR 能力，对变更代码进行静态分析，针对新引入的环境标识相关逻辑、未托管字段进行强拦截；3. 结合交付框架探测出来的应用依赖信息进行一致性检查。

在环境配置管理能力建设完成后，实现了建站交付无须代码改造，解决了上述建站过程中资源交付后需要大量人工改造与部署联调的低效问题。

关于环境信息管理的详细技术细节将在系列第二篇文章展开进行更深入的介绍。

整体架构

将上述三个核心方向的技术方案结合起来便可得到建站提效的整体技术架构：

如上图所示，整体架构由以下几部分组成：

交付平台 UI：交付平台 UI 主要提供前端用户交互的能力，将各类交付能力进行封装，提供多种交付方式例如单应用交付、批量应用交付、应用迁移交付、业务维度交付等，支持查看交付流程及状态等。此处需要和现有运维能力的结合，借用相关能力，例如服务树关联、权限管理继承等，方便 SRE 或 RD 的操作。
管理中心：管理中心主要负责交付平台使用过程中的管理功能，包括权限校验、角色划分、服务准入、交付状态、流程管理、配置渲染及存取。此外，管理中心需要作为中心节点，管理国际化不同机房及公有云的交付。权限校验主要是对操作人的权限进行管理，交付平台的操作会直接影响服务的运行时状态，因此权限需要做严格管理，同时需要保证各类操作符合安全合规规范；角色划分主要是对操作人的角色进行划分，主要包括 RD 和 SRE，整个交付过程中涉及的操作需要由不同角色共同完成，因此需要将由不同角色完成的操作进行划分并管理依赖关系；服务准入负责提供服务接入交付平台的能力，进行服务必要元数据的收集；流程管理和交付状态负责定义交付的流程，管理交付状态机的变化，方便操作方理解并感知交付状态；配置渲染负责将用户提交的交付配置渲染成交付框架可以识别的交付执行计划；配置存取负责管理用户提交的交付配置版本；
交付框架：交付平台的核心，负责 OAM 模型的实现，以及应用组件的注册，以及各组件对应 Controller 的实现（其中各类通用资源的管理，如 Mysql、S3 等通过引入 Terraform 能力实现，此处提供单独的 Controller 接入，其余公司内部依赖通过自定义 Controller 管理）
Adaptors：适配层，负责与具体交付组件交互逻辑的对接，其中资源类的交付通过 Terraform Provider 完成，其他组件对接通过自定义的 Adaptor 完成
环境管理：负责管理业务的环境差异配置，避免在新环境的服务交付过程中还需要进行代码的变更。由以下几个模块组成：差异配置管理，负责托管服务的差异配置，将配置与原业务代码分离；配置获取 SDK，负责提供模块获取配置的能力；另外通过改造当前CI/CD流程，将分离的配置在打包流程中重新注入业务代码，保证业务模块可以通过 SDK 获取到。
运维能力：负责提供相关运维能力的交付和迁移能力，例如：弹性云、部署系统、接入层等，这类能力在以往的交付过程一般由 SRE 手动创建，这里需要将这些能力的创建与迁移过程接入交付框架，通过交付配置指定所需能力以及相关参数。其中有几个核心问题需要考虑：首先是首次交付之后，如何保障配置与线上实时同步一致，如果不一致是否会导致下次交付出现异常；其次是如何应对各能力提供方的使用方式调整，如参数变更，环境变化，新增功能等。
资源依赖：负责提供服务依赖资源的申请和迁移能力，例如：Mysql、KV 等。这类资源一般需要 RD 手动申请，或者由 SRE 手动复制，且申请后需要在代码中进行配置并在 odin 上新增白名单，因此在将资源依赖的创建与迁移过程接入交付框架的过程中，需要额外考虑与后续流程的打通和相互依赖，实现代码变更以及白名单新增的自动化。这个过程需要各资源方提供资源复制的能力来支持新环境的快速交付，此外，公有云和自建机房的资源管理方式存在差异，云上的资源管理与应用绑定，且可以通过资源平台统一接入，因此在资源依赖的接入过程中需要额外考虑屏蔽多云之间的差异。
中间件：负责提供服务使用中间件的配置和迁移能力，中间件主要包括服务模块可能依赖的各类中间组件，例如 Disf、Apollo、彩虹桥等，这类组件在新环境交付时，一般需要 RD 手动配置或者复制，因此也需要将这类配置过程接入交付框架，通过交付配置指定所需依赖以及相关参数。具体实现以及注意事项与运维能力基本一致，差异在于两类配置的指定由不同角色同学完成。

实施路径

在完成上述建站提效的整体技术解决方案的设计之后，接下来进入到该方案的具体实施落地的阶段，而该项目的落地难度无疑是巨大的。

从方案的整体拆解过程中容易发现，我们的解决方案定位是建设较为通用的建站交付平台，该交付能力是对原有 DevOps 体系的完善，因此需要内部各基础架构与中间件团队的适配支持，同时环境配置管理的接入还需要全流程业务模块负责人的改造支持，涉及团队范围非常广，需要设计比较合理的实施路径并把控落地节奏。

我们判断其中有几个核心关键点需要把控：1. 阶段性里程碑：需要合理拆解项目技术话题，结合实际使用场景取得阶段性成果，激发参与成员的价值感；2. 平台产品化：需要有成熟稳定的落地产品，并与当前大家熟悉的 DevOps 流程深度融合，提升易用性的同时减少大家对体验迁移的不适；3. 长期防腐投入：避免低频率的交付场景对建站能力的腐蚀，将基础能力应用至更多高频场景为佳。

基于以上考虑，我们的实施路径大致分为三个阶段：

1. MVP快速建设+小型场景适应性验证（持续时间约 6 个月）

该阶段的主要目标是整体方案的可行性验证，因此我们精简了整体方案，在 KubeVela 框架基础上适配了滴滴内部较为常用的 1-2 个组件及 1-2 个运维设施交付能力，同时自行实现了简易的配置仓库管理流程，并在国际化出行的小型机房建设过程中应用，验证了交付流程的有效性。

2. 能力拓展覆盖+平台产品化（持续时间约 1 年）

该阶段的主要目标是对 MVP 版本支持能力的全面拓展，逐个适配接入各类常用资源组件与运维设施；同时与平台同学合作，将 MVP 版本中自行实现的交付能力与环境配置管理能力集成至已有的 DevOps 流程中，形成标准化平台产品。

3. 全链路推广接入+真实场景大规模应用（持续时间约 6 个月）

在平台能力相对成熟之后，我们启动了国际化出行业务全链路的推广接入，包括应用模型描述、交付能力收敛以及环境差异配置管理能力的推广，并在国际化出行真实的建站场景中进行了大规模的应用，验证了交付能力对建站效率的大幅提升。

在上述三个阶段完成后，建站能力在国际化出行业务得到验证并取得了不错的成果，我们接着将注意力转移至平台能力的进一步拓展，以及长期防腐能力的建设上：

平台能力拓展：进一步接入覆盖使用范围较小的资源组件，并收集集团其他业务线的交付需求，将交付能力推广至平台其他业务线；
长期防腐能力：在应用描述与环境差异配置能力基础上，逐步构建资源探测、配置一致性、接入拦截等能力，保证交付效果的可持续。

落地效果

最终整体建站提效能力落地为应用中心及环境信息管理两个平台，分别负责应用信息管理&交付以及环境差异信息管理。具体效果如下：

1. 应用中心

2. 应用模型：负责应用依赖的资源组件信息的增删改查。

3. 环境管理：负责管理应用模型在不同环境下的交付，支持环境间克隆。

4. 环境信息管理：负责环境差异信息的增删改查以及编译部署环节的注入获取能力

在上述平台产品落地成熟之后，再回过头来看上文中提到的某模块交付的CASE，交付流程从原来复杂的资源梳理+资源交付+代码改造过程，优化至只需要从交付平台中选择该模块任意环境进行应用描述的克隆，进行相关交付规格的配置调整后便可由交付平台实现自动化的交付过程，整个交付无须人工参与便可将模块依赖的弹性云集群、资源组件以及代码中依赖的新环境配置一并交付，开箱即用，直接进入联调测试环节。

同时，我们也在 2023 年国际化出行新机房真实建站过程中全面应用了上述建站交付能力，实现了一次完整建站过程的人力投入大幅减少80%，初步解决了困扰已久的建站低效问题。

未来规划

首先，需要对当前建站能力进行进一步的拓展以更全面地解决建站过程中的效率问题，包括支持的基础设施环境（自建 IDC、公有云等）、支持的资源组件范围（如大数据链路、内部中间件等）、支持的组件交付能力范围（如数据同步、配置同步等）、交付平台的交互优化等，同时可以进一步将建站能力推广至滴滴其他业务线以支持更多的建站需求。

其次，当前完成建站提效能力建设之后，在滴滴的 DevOps 流程中补充了两项核心能力：