Palantir 如何构建他们的 GitOps 内部开发者平台

Palantir 开发的独特软件实现了以数据为驱动的操作和决策，其客户多为国际政府和情报机构。尽管公司最初选择了 GitOps 作为对开发者友好的工作流程，但这一决策的实施远比预期要难。Palantir 的解决方案很明确：搭建一个更为优秀的内部开发者平台对 GitOps 进行扩展，不过要实现这个目的还有些工作要做。

从 2017 年开始，这五年来作为公司基础设施及阿波罗平台（Apollo）的生产平台负责人， Greg DeArment 一直享有 Palantir 在完善阿波罗平台以支持持续部署（CD）这一过程的第一手资料。不过，就如 Greg 在一次演讲中的所言，这次转型并不是一帆风顺的。本文中讲述了他与团队不得已多次重组才能完成目标的全部故事。

Palantir 的业务内容是为其客户提供包括 Foundry 和 Gotham 在内的多个系统，虽然这些产品具有各不相同的工作内容，但均是由 Palantir 的内部底层 DevOps 平台阿波罗所驱动。

阿波罗是于 2017 年左右推出，标志着公司首次涉足生产使用的 GitOps 领域，不过公司早在 2015 年就已经投资于平台工程和基础建设了。

时至今日，阿波罗平台服务于数百个环境和服务，超过一千名工程师在 4 至 12 人的团队中工作。根据 Greg 所说，阿波罗平台是支撑着 Palantir 在生产中软件构建、部署、运维的一切。

无论是超大规模云环境、政府的本地部署环境，还是逐渐增多的边缘环境，阿波罗都有应用。总的来说，Greg 说平台每天都有上千次部署和配置变更。那么他的团队是如何应对如此大量的 GitOps 工作量呢？

Greg 指出，在平台的起伏发展中所有权和组织都起到了作用。公司将阿波罗平台的员工分为两个主要团队：

• 生产基础设施团队中包括约 110 名软件工程师、DevOps 工程师，以及运维人员。这些利益相关者负责部署和运维公司内所有面向客户的产品，包括云基础设施及阿波罗平台本身。

• 内部基础设施团队由 20 名工程师组成，负责构建第一方软件，同时负责处理 GitHub、Circle CI、SalesForce 等第三方软件。也就是 Palantir 作为现代公司运营所需的一切。

在谈及如何将这些强大的能力应用于工作中时，Greg 说 Palantir 对 GitOps 主要有三个用例，他也提出了几个问题，或许能帮助他人在尝试推广更多 GitOps 友好的平台工程工作流时，更好地清楚任务背后的原因：

• 持续部署的服务管理：Palantir 是如何利用阿波罗平台部署并管理面向客户平台的服务？

• 用于基础设施的 GitOps：Palantir 是如何利用 GitOps 优化其云基础设施的管理？在使用第三方工具时，公司要如何将其转型为像是 Kubernetes 这类同软件运行一样真正使用的状态？

• 内部基础设施。Palantir 是如何利用 GitOps 管理器开发者工具与生态系统？

Greg 演讲的大部分内容都集中在第一个用例上，但也针对其他两个用例提出了有用的介绍，探讨了通往成功的道路是如何一波三折的。

自从 2017 年左右 Greg 就职于 Palantir 开始，阿波罗的采用率呈线性增长，在 2021 年甚至到达了每月超过一万次的拉取请求（PR）！虽然有明显的成功，但 Greg 的团队却还在不断抽时间为合并 PR 而奋斗。

尽管阿波罗平台起初为公司大大地提速，但最终其本身也成为了负担。Greg 认为，尽管该平台自动化了许多如为 Foundry 所运行的每个环境打开拉去请求在内的任务，但与人工打开请求相比平台所花费的时间也是非常多的。在某些情况下，解决这些请求甚至能花费 140 个小时！

必须要做些什么了。在 2019 年，团队为降低 PR 数量进行了协调性投资，例如重组仓库（repo）以方便管理。在一段时间内这种方式似乎可行，但问题不断重演，公司需要新的解决方案和修复手段。最后，公司意识到现有的零散方案并不划算。

虽然内部用户对阿波罗平台意见各异，但 Greg 发现用户不满往往会随着对平台的使用量而增加。一些值得关注的症结如下：

• 阿波罗对 Git 及 GitHub 的使用致使其很难提升用户体验

• 新业务服务需要上百次 PR 提交

• 跨仓库编辑 YAML 致使学习曲线非常陡峭

• 基于文件的权限管理过于复杂，致使工作流程效率低下

解决 Git 与生产之间的差异并不容易。因为要与拥有 GitOps 系统的团队协作，负责调试这些问题的团队总会遇到各种困难：

• 由于阿波罗平台的诸多异步系统未能协同工作或刻意截断推送（push），致使合并到 Git 上的变更未能被阿波罗抓取，这一情况导致的中间状态很难被理解

• 用户体验和工作流程不尽如人意，Git 并不是决定代码变更是否被应用的唯一决定性因素，团队特定的维护方式或限制手段导致开发人员不得不查看多个信息流才能确定变更失败的原因

• 阿波罗的工程团队常常要面对组织性瓶颈，包括其他原因导致问询或客服支持条目

Greg 的最大收获之一是使用 Dev 工具支持生产用 GitOps。只有系统可用且可靠时，Palantir 才能对事件响应：

• 虽然出于对工具的熟悉，这些以开发者工具为中心的策略确实让团队开始了行动，但每到定期维护时间或其他中断发生时，这些策略又会成为恐慌的根源

• Palantir 有意在安全与身份层面将其内部的基础设施与面向客户的环境相分割，但正如人们所料，面向客户的环境对内部系统的依赖性让这一目标难以达成

• 阿波罗的内部基础设施团队有一套系统，生产基础设施团队在用另一套系统，这两个团队分处组织的不同部分，拥有不同的文化、优先级和期望，这导致了多次难以处理的摩擦

这一系列挑战中很多都与阿波罗运作 GitOps 的方式有关，但即使是不用开发者工具驱动平台，这些问题也是值得考虑的，尤其是涉及不同利益相关者之间冲突对平台成功率的影响方面更是重要。

在大概三年的时间内，Greg 与团队一直在不断努力改善 GitOps 工作流的用户体验。到了 2020 年，他们决定通过重新思考实现 GitOps 的方式，并将重点放在了四个宽泛的目标上：

一个可声明且具备审计历史和变更管理控制的单一事实来源绝对是一个优势，团队也能明白旧工具的不可持续性。新的实施方案不再将阿波罗平台与已有源码控制系统或工具相绑定，而是针对相同的功能性特征。

阿波罗平台的工程师认为用户不应该在没必要时与 YAML 文件交互，他们意图构建一个基于意图、以结果为导向的工作流程，让人们不再以代码仓库为单位，而是在团队层面处理变更，允许跨组织的变更并减少人工干预。

团队根据角色和责任对变更文件进行管理，而非是靠权限与审批。同理，决定的批准也会根据变更内容决定。

团队认为用户应当能清楚变更被暂缓的原因和时机，领导层也希望用户能够以单一视角观测变更，而非是在数百个不同仓库间搜索或是被迫成为 Palantir 在 GitHub 方面的专家。

通过重新设计已有的阿波罗平台功能，团队达成了以上的部分目标。举例来说，当前版本的平台功能包含一个用户看板和表格，让用户可以用更高层次的目标自行对仓库进行修改，再也不用深挖技术细节或修改 YAML 文件了。

最后，Greg 讨论了 Palantir 在追求 GitOps 的成功道路上，他所收获的其他更为广泛的第一手经验。首先，他认为相较于小型团队，服务于多种类型用户的平台常常会拥有完全不同的 GitOps 体验，而随着产品的复杂度与团队数量的增加，以 GitHub 驱动的 GitOps 运营开销也会随之增加。

Greg 同样提醒道，这些增长可能不会如大家所想的那样整洁且可预测，最初促使大家使用 GitOps 的工具不一定在扩展时也能提供很好的服务。

对平台所有权和团队结构的处理也是如此，如果不够谨慎，拥有 GitOps 基础设施的那个 DevOps 团队最终可能也会成为瓶颈本身。

Greg 的演讲对大型组织利用 GitOps 及其他智能平台工程实践提供了很好的洞察力，更多关于 GitOps 之旅及 Greg 对听众提问的详细回答，可参见大会视频。