共计 8025 个字符，预计需要花费 21 分钟才能阅读完成。
文|朵晓东（花名：奕杉 )
KusionStack 负责人、蚂蚁团体资深技术专家
在基础设施技术畛域深耕，专一云原生网络、运维及编程语言等技术工作
一、摘要
本文尝试从平台工程、专用语言、分治、建模、自动化和协同文化等几个角度论述规模化平台工程实际中的挑战和最佳实际。心愿通过把咱们平台工程的理念和实际分享给更多企业和团队，一起让一些有意思的变动产生。
本文基于 KusionStack[1] 技术栈在蚂蚁平台工程及自动化中的实际总结而成。
二、平台工程：让企业级 DevOps 产生
DevOps 理念在 10 多年前被提出，从 KVM 到容器再到云原生时代，大量企业投入 DevOps 静止以冀望解决外部规模化运维效率和平台建设效率的窘境。其中大部分陷入过某种基于对 DevOps 奢侈认知的 Anti-Pattern，同时也有局部公司摸索出本人的门路。我经验过如下图简示的 Anti-Patterns，Dev 与 Ops 团队各行其是，或者简略的强制 Dev 团队独立实现 Ops 工作。在 DevOps Anti-Types[2] 中能够找到更多更典型分类。
企业内规模化 DevOps 难以推广的起因多种多样，特地是在 企业内自持基础设施 、 同时采纳云上技术平台 的公司阻力最大。其中以这几种状况尤为常见：
– 研发团队和运维团队因为部门墙、领导者短少洞察等等起因各自为政，难以达成一致意见；
– 研发团队低估了基础设施技术、运维、稳定性工作的专业性、复杂性和疾速变动，以奢侈的 DevOps 了解强制利用研发者成为专家；
– 领导者建设了专职的 DevOps 团队，但沦为两头的执行者，没能让 Dev 和 Ops 团队各自向前一步，严密协同；
– 平台研发团队对规模化带来的业务复杂性以及技术演进带来的技术复杂性应答有余，无奈对利用研发者提供无效的技术撑持；
不同于面向云上托管基础设施服务和 DevOps-as-a-Service 产品工作的小型团队，中大型企业往往须要依据本身团队架构和文化建设适当的 DevOps 体系。从胜利案例看，无论是 Meta 公司由 Dev 齐全承当 Ops 职能，还是 Google 公司引入 SRE 团队作为中间层，平台工程 （ Platform Engineering [3]） 都表演了十分重要的角色。
平台工程旨在帮忙企业构建面向利用研发者的自服务运维体系，尝试通过工程化的技术手段和工作流程解决以下关键问题：
– 设计正当的抽象层次，帮忙利用研发者升高对 Infra、platform 等技术以及运维、稳定性工作的认知累赘；
– 为利用研发者提供对立的工作界面和空间，防止用户陷入割裂的平台产品界面、简单的工作流中；
– 帮忙研发者通过无效的工作流程和举荐门路基于 外部工程平台[4] 疾速发展工作；
– 帮忙研发者通过配套的 CI、CD、CDRA 等产品自服务治理利用生命周期；
– 帮忙平台产品研发团队简略、高效、统一的凋谢其平台根底能力；
– 通过培训、布道、经营等伎俩营造协同工作和分享的文化。
事实上，不是所有人都应该或者可能成为这个畛域的专家，这十分艰难！
实际上平台技术团队的专家通常也仅善于本人的业余畛域而已，特地是在云原生理念和技术广泛应用的明天，面向大量高度凋谢、可配置的平台技术带来的成千盈百的利用配置，PaaS 畛域的业务复杂性，以及高稳定性和对立治理的要求，而平台工程的目标正是为了让利用研发者尽可能简略无痛的参加到这样规模化的 DevOps 工作中。
在蚂蚁的实际中，咱们更趋向于以下这种单干状态，在团队架构和工作模式上更凑近 Google 的最佳实际。平台研发者及 SRE 成为“Enabler”反对利用研发者自服务的实现研发及交付运维，同时利用研发者使其利用可交付运维的工作后果也成为运维人员能够接手利用运维工作的根底。最终 SRE、利用研发及运维人员把工作过程中的问题和痛点反馈给平台研发者造成正向循环。
三、专用语言：工程化形式的一极
有什么比一种专用语言更适宜凋谢的、自服务的、面向畛域业务的问题定义，同时须要满足自动化、低平安危险、低噪音、易治理的企业外部要求吗？正如记录音乐有五线谱，存储工夫序列数据有时序数据库一样，在平台工程的特定问题域内，一批配置和策略语言用于编写和治理规模化简单配置及策略。
不同于混合编写范式、混合工程能力的高级通用语言，这类专用语言的外围逻辑是以收敛的无限的语法、语义汇合解决畛域问题近乎有限的变动和复杂性，将规模化简单配置和策略编写思路和形式积淀到语言个性中。
在蚂蚁的平台工程实际中，咱们强化了客户端的工作形式，将围绕利用运维生命周期的模型、编排、束缚和策略稳固、可扩大的通过专用语言 KCL[5] 编写保护在共享仓库 Konfig[6] 中。
KCL 是一种面向有编程能力的利用研发者的 动态强类型语言，提供古代高级语言的编写体验和围绕畛域目标无限性能。在平台工程实际中 KCL 不是一种仅用于编写 K-V 对的语言，而是一种面向平台工程畛域的专用语言。利用研发者、SRE、平台研发者面向 Konfig 协同研发，通过 KCL 原生性能编写利用配置，以及在 PaaS 畛域更为高频和简单的 模型形象[7]、性能函数[8] 和 束缚规定[9]，即编写稳固、可扩大的业务模型、业务逻辑、防错束缚和环境规定。
Konfig 仓库则成为对立的编程界面，工作空间和业务层载体，而基于 KCL 的平安、低噪音、低副作用、统一的编写范式更有利于长期治理和治理。
四、分治：解构规模化问题
分治思路是解决规模化问题的钥匙，从 MapReduce 到 Kubernetes 无不体现其效用。在规模化交付运维畛域，经典运维平台试图在对立的黑盒平台产品中，以内置的对立模型、编排、provision 技术来应答全量业务场景。这样的实际能够 疾速启动 ， 在小范畴内见效，但随着不同业务主体采用率晋升引入差异化需要，同时随着继续变动的平台技术逐步进入疲态。
在蚂蚁的实际中，Konfig monorepo 是外部工程平台向研发者凋谢的编程界面和工作空间，帮忙利用研发者以对立的编程界面编写围绕利用运维生命周期的配置和策略，从而编排和应用存量和新增的平台基础设施，按需创立治理云原生环境以及基于 RBAC 的权限，并通过 GitOps 形式治理交付过程。
Konfig monorepo 为不同场景、我的项目、利用提供了独立的白盒的编程空间，其内生的扩展性来源于：
– 灵便、可扩大、独立的客户端的 工程结构设计[10]；
– 独立配置块主动合并技术[11] 反对任意分块、可扩大的配置块组织；
– 动态类型零碎[12] 技术提供古代编程语言可复用、可扩大的类型化建模和束缚性能；
– 我的项目粒度的 GitOps CI 工作流程定义反对；
– 基于 Kusion[13] 引擎的 provision 技术抉择。
Konfig monorepo 提供了分治的、可组合的工程结构设计、代码组织、建模形式、工作流程定义和 provision 技术抉择反对，同时又以统一的研发模式和工作流承载了可扩大的业务需要。这样客户端的工作形式在保障灵活性、可扩展性、可移植性的同时也升高了对服务端 扩大机制，如 Kubernetes API Machinery，持续增长的压力。
下图示意了一种 Konfig monorepo 中 GitOps 形式的典型的自动化工作流程，从面向利用的代码变更开始，通过可配置的 CI、CD 过程触达运行时，这样的机制相比中心化的黑盒产品形式更加凋谢、可定制、可扩大，也免去了针对不同业务场景、不同我的项目、利用设计蠢笨的配置文件治理 portal 的必要。
五、建模：边际收益和长尾问题
有了分治的白盒化的工程结构设计、代码组织形式、建模形式、工作流程定义和 provision 技术抉择，以怎么的策略面向平台 API 工作是另一个须要思考的问题。在企业内典型的争议在于直面平台细节还是设计一种形象，或者回升到显式 （explicit） 和隐式 （implict） 的理念的争议。
形象的隐式的形式是运维平台工程师们面向非专家型终端用户的广泛抉择，他们心愿能设计出易于了解、便于应用的利用模型或 Spec 形象，与具体的平台技术细节隔离，升高用户认知累赘，并通过升高细节感知防错。但大部分运维平台的研发者偏向于设计一种弱小的、对立的利用模型或 Spec 形象，在实践中往往会遇到这些妨碍：
– 随着企业内不同业务主体采用率的晋升，对立建模难以落地。在蚂蚁外部最典型的案例是 Infra 根底技术类组件和 SaaS 利用间的微小差异性，SaaS 利用便于对立，Infra 利用往往须要独自设计。
– 面向企业内大量的平台技术，对立模型本身难以稳固，特地是应答继续变动的业务需要和平台技术驱动的需要增长。在蚂蚁的实际中，交付运维受多种因素影响有较强的不稳定性，同时围绕利用的 deliverable、runtime、security、instrumentation 的业务需要也在增长。以 instrumentation 为例，近两年对利用运行时可察看性、SLO 定义的需要快速增长间接驱动了终端用户应用的变动。
– 形象模型的共性问题是须要面向用户设计出正当的模型，面向平台 API 细节放弃同步。
在蚂蚁的实际中，面向终端用户即利用研发者咱们采纳了形象模型的形式，通过如下思路解决几个关键问题：
– 面向典型利用场景 （如蚂蚁的 SOFA 利用） 建模，这些模型由平台研发者、平台 SRE 主导开发，与利用研发者独特保护，达到用户体验、老本和规范兼容的均衡，在蚂蚁的实际中形象模型的信息熵收敛比约为 1：5，通过宽泛的高频应用保障建模投入的边际收益。
– 对于非典型用户场景或利用，由平台研发者、平台 SRE 反对利用研发者实现针对利用的模型设计。KCL schema[7] 和 mixin[14] 等机制帮忙用户建模、形象、继承、组合、复用，缩小反复代码，事实上这样的建模设计工作也是利用 PaaS 畛域的重点之一，但对于这样的场景咱们须要更正当的分工。最终大量“非标”平台技术在蚂蚁外部首次以统一的形式被纳管，无效解决了长尾问题。在典型协同模式下，平台研发者、平台 SRE 编写平台能力根底组件成为“Enabler”，帮忙利用研发者应用平台能力根底组件疾速“搭积木”，实现其利用模型的研发工作。
– 面向平台技术，咱们提供了平台 API Spec 到 KCL 类型代码的 生成技术[15]，并通过 组合编译技术[16] 原生反对对不同 Kubernetes API 版本的编译时抉择，在外部实际中解决了利用形象模型面向不同版本 Kubernetes 集群工作的灵便需要。同时，KCL 反对 in-schema 束缚[17] 和 独立环境规定[9] 的编写。此外，KCL 还提供了 deprecated 装璜器[18] 反对对已下线模型或模型属性的标注。通过在客户端强壮的、齐备的模型和束缚机制，在编译时裸露如配置谬误、类型漂移等常见问题。绝对于运行时左移的发现问题，防止推动到集群时产生运行时谬误或故障，这也是企业内，特地是高风险等级企业，对生产环境稳定性的必须要求。
对于根底平台技术的专家型用户，他们通常十分相熟特定的技术畛域，更心愿以 直面平台细节 的显式的形式工作，语言提供必要的动态性和模块化反对，通过类型和束缚机制保障稳定性。但这种显式的形式无奈解决专家用户不相熟跨畛域平台技术应用细节的问题，也不能解决面向平台技术的扩展性和复杂性叠加的问题。在蚂蚁外部小范畴基于 YAML 的显式的工程实际中，面向大量高度凋谢、可配置的平台技术，复杂性随着平台技术使用率继续叠加，最终陷入难以浏览、编写、束缚、测试及保护的僵化状态。
六、自动化：新的挑战
运维自动化是基础设施运维畛域的经典技术领域，随着云原生理念及技术的火上浇油，能够被自动化集成成为企业运维实际的根本要求，开源凋谢、高度可配置的 CI、CD 技术逐渐被企业驳回，黑盒的、无奈被集成的“产品”形式逐渐被灵便的可编排形式弱化并代替。这种实际的次要劣势在于其弱小的自定义编排和链接能力，高度的可扩展性和良好的可移植性。
特地是在 Kubernetes 生态，GitOps 形式有更高的采用率，与可配置的 CI、CD 技术有人造的亲和性。这样的变动也在推动以工单和运维产品为核心的工作流逐渐转变为以工程效率平台为核心的自服务工作流，而生产环境的运维能力则成为了工作流中面向生产主动运维的一个重要环节。在开源社区，面向不同研发效率平台的形象层技术创新也在沉闷进行中，平台侧研发者心愿通过最短的认知和实际门路买通利用到云环境的 CI、CD 过程。
在蚂蚁的工程实际中，工程效率平台深度参加了 Konfig monorepo 的凋谢自动化实际，咱们的实际方向也与工程效率平台技术演进方向高度一致。
在从几人到几十人再到几百人的协同工作中，面向运维场景的工作流设计，高频的代码提交和 pipelines 执行，实时自动化测试和部署过程，这些对服务于单库的工程效率平台造成了很多的挑战。
特地是 monorepo 中多样化的业务须要独立且弱小的工作流自定义和操作反对，也须要高实时性、强 SLO 保障的并行的工作流执行能力，这些需要与单库模式的需要有微小的差别，也给咱们制作了很多麻烦。
大部分配置语言是解释型语言，而 KCL 被设计为一种编译型语言，由 Rust、C、LLVM 优化器实现，以达到对规模化 KCL 文件提供 高性能[19] 编译和运行时执行的指标，同时反对编译到本地码和 Wasm 以满足不同运行时的执行要求。另外 Git 的存储及架构设计不同于 Citc/Piper[12] 架构，不适用于规模化代码的 monorepo，所幸明天咱们的代码量还没有遇到很大的问题。咱们正在一起工作解决这些问题，心愿随着实际的深刻逐渐解决他们。
七、协同和文化：更重要的事
以上的技术、工具、机制都十分重要，但我必须要说，对于工程化、DevOps 更重要的是 个人与团队的协同 、 单干和分享的文化，因为这是一种由人组成的工作，人和文化是其中的要害。
在企业内，如果部门墙、团队壁垒丛生，风行关闭蹩脚的工程文化，咱们通常会看到大量公有的代码库和公有文档，小群体的判断和工作形式，本该严密单干的团队以各自指标为导向各行其是，在这样的文化下我认为所有规模化工作都会十分艰难。所以如果你所在的公司或团队想驳回规模化 DevOps，我认为最重要的是做好宽泛的沟通并开始文化的建设，因为这相对不只是几个人的事，并且这很有难度且不可控。
在蚂蚁的实际中，初期总有各种各样的艰难，大家对自服务机制和协同文化的放心尤为突出，例如“我竟然要写代码？”，“我的代码竟然跟其余团队在一个仓库里？”，“我负责的工作可不简略，这种形式行不通”都是很典型的担心。
所幸咱们最终建设了一个面向独特指标的虚构组织，合作方和领导者给予了充沛的反对，咱们在理念和工作形式上达成统一并协同工作。在实际过程中，大多数工程师并不是阻碍，当然他们会吐槽技术、流程和机制还不够欠缺，心愿取得更好的体验，这无可非议。
真正的阻碍首先来自于运维平台研发团队本身，我看到一些公司的 DevOps 现实最终回归到运维平台团队代替利用研发者做掉所有工作，甚至不让用户接触到代码和工具链这些生产工具，急于暗藏于已有的 GUI 产品界面，我认为这跑偏了，也低估了用户本身的能力和创造力。
另外阻碍也来自于局部平台技术团队的技术负责人，他们很难放下继续多年的已有工作，难以承受转向到新的用户服务模式。可行的方法是让他们明确这项工作的意义和近景，逐渐的分阶段的影响他们。
八、小结
通过一年多的实际，有 400+ 研发者间接研发参加了 Konfig monorepo 的代码奉献，治理了超过 1500 个 projects，其中平台研发者及平台 SRE 与利用研发者比例不到 1：9，这些利用研发者有些是利用 owner 自己，有些是利用研发团队的代表，这由利用团队本人决定。
通过继续的自动化能力搭建，基于 Konfig monorepo 每天产生 200-300 次 commits，其中大部分是自动化的代码批改，以及大概 1K pipeline 工作执行和近 10K KCL 编译执行。
在明天如果将 Konfig 中全量代码编译一次并输入会产生 300W+ 行 YAML 文本，事实上一次公布运维过程中须要屡次不同参数组合的编译过程。通过轻量化，便于移植的代码库和工具链，咱们实现了一次意义重大的内部专有云交付，免去了革新、移植输入一系列老旧运维平台的苦楚。在蚂蚁外部咱们服务了几种不同的运维场景，正在扩充利用规模并摸索更多的可能性。
最初我想说一说下一步的打算，咱们的技术和工具在易用性和体验上还有很大的晋升空间，须要更多的用户反馈和继续的改良，体验工作没有疾速门路。在测试方面，咱们提供了简略的集成测试伎俩，起到了冒烟测试的作用，但这还不够，咱们正在尝试基于束缚、规定而非测试的形式保障正确性。
在工作界面方面，咱们心愿构建基于 IDE 的线下工作空间，继续规约、优化外部线上产品体验和工作流程。同时咱们心愿继续晋升覆盖范围和技术能力。
另外咱们也心愿将实际形式更宽泛的利用在 CI 构建，自动化运维等场景，缩短终端用户的信息感知和端到端工作流程。目前 KusionStack 还处于刚刚开源的十分晚期的阶段，在将来还有大量的工作要做。最重要的是咱们心愿把咱们平台工程的理念和实际分享给更多企业和团队，一起推动并见证一些有意思的变动产生。
更多详情请参考： [https://kusionstack.io/zh-CN/…]
相干链接
[1]KusionStack:
[https://kusionstack.io/docs/u…]
[2] DevOps Anti-Types :
[https://web.devopstopologies….]
[3] Platform Engineering :
[https://platformengineering.o…]
[4]外部工程平台:
[https://internaldeveloperplat…]
[5] KCL :
[https://github.com/KusionStac…]
[6] Konfig :
[https://github.com/KusionStac…]
[7] PaaS 模型形象：
[https://kusionstack.io/docs/r…]
[8]性能函数：
[https://kusionstack.io/docs/r…]
[9]束缚规定：
[https://kusionstack.io/docs/r…]
[10]工程结构设计：
[https://kusionstack.io/docs/u…]
[11]主动合并技术：
[https://kusionstack.io/docs/r…]
[12]动态类型零碎:
[https://kusionstack.io/docs/r…]
[13] Kusion :
[https://github.com/KusionStac…]
[14] mixin :
[https://kusionstack.io/docs/r…]
[15] 生成技术：
[https://kusionstack.io/docs/r…]
[16]组合编译技术:
[https://kusionstack.io/docs/r…]
[17] in-schema 束缚:
[https://kusionstack.io/docs/r…]
[18] deprecated 装璜器:
[https://kusionstack.io/docs/r…]
[19] 高性能：
[https://kusionstack.io/blog/2…]
[20] Citc/Piper：
[https://cacm.acm.org/magazine…]
本周举荐浏览
KusionStack 在蚂蚁团体的摸索实际 (上)
Kusion 模型库和工具链的摸索实际
Go 内存透露，pprof 够用了么？
Go 代码城市上云——KusionStack 实际
