文｜朵晓东（诨名：奕杉)
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 支撑运用研制者完结针对运用的模型规划。KCLschema[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 还处于刚刚开源的十分早期的阶段，在未来还有许多的作业要做。最重要的是咱们期望把咱们渠道工程的理念和实践共享给更多企业和团队，一同推进并见证一些有意思的改变产生。
更多详情请参阅： [kusionstack.io/zh-CN/blog/…]
相关链接
[1]KusionStack: [kusionstack.io/docs/user_d…]
[2]DevOps Anti-Types : [web.devopstopologies.com/#anti-types]
[3]Platform Engineering : [platformengineering.org/blog/what-i…]
[4]内部工程渠道: [internaldeveloperplatform.org/what-is-an-…]
[5] KCL : [github.com/KusionStack…]
[6]Konfig : [github.com/KusionStack…]
[7] PaaS 模型笼统： [kusionstack.io/docs/refere…]
[8]功用函数： [kusionstack.io/docs/refere…]
[9]束缚规矩： [kusionstack.io/docs/refere…]
[10]工程结构规划： [kusionstack.io/docs/user_d…]
[11]主动兼并技能： [kusionstack.io/docs/refere…]
[12]静态类型体系: [kusionstack.io/docs/refere…]
[13] Kusion : [github.com/KusionStack…]
[14] mixin: [kusionstack.io/docs/refere…]
[15] 生成技能： [kusionstack.io/docs/refere…]
[16]组合编译技能: [kusionstack.io/docs/refere…]
[17]in-schema束缚: [kusionstack.io/docs/refere…]
[18]deprecated装修器: [kusionstack.io/docs/refere…]
[19] 高性能 ： [kusionstack.io/blog/2022-d…]
[20]Citc/Piper ： [cacm.acm.org/magazines/2…]
本周引荐阅览
KusionStack 在蚂蚁集团的探究实践 (上)
Kusion 模型库和东西链的探究实践
Go 内存走漏，pprof 够用了么？
Go 代码城市上云——KusionStack 实践