有一定年龄和背景的读者会记得 CFEngine，早期流行的配置管理系统之一（至今仍在使用！）。它为管理员提供了一种强大的方法，可以在异构机器集群中管理系统配置，并开启了自动化配置管理的时代大门，这是现代技术生态系统中的关键一环。我曾经和负责 CFEngine 基础设施的团队合作，并管理过这些团队，亲眼见证了管理这些系统的价值和挑战。但我也看到了这种心态在平台工程技术上的局限性。

配置管理和基础设施供应及其编排对组织来说是一个棘手的问题。该领域已经注入了大量的创新，从诸如 Terraform 这样的“基础设施即代码”提供的进展，到像 Kubernetes 这样的编排平台的发展。维护异构环境的问题，尤其是随着这些环境在复杂性方面的增长（例如，为了使用多种云服务将应用程序部署到云上，所有需要存在的组件），是无止境的。虽然我们可能已经超越了 cfengine，但许多现代平台工程团队仍然专注于这一部分的堆栈，使得应用程序团队能够轻松选择适当的架构或蓝图以供应其应用程序所需运行的云资源。

我也觉得这种做法，尤其是当你平台团队主要关注这一点时，是有问题的。这源于一条看似合理的路径。

1. Terraform 真是糟糕透了。特别是当你所在的公司在从旧的数据中心模式迁移到云的过程中，你的初始做法是让每个应用团队自己编写 Terraform 来部署资源，你很快会发现每个团队都在花费大量时间解决相同的问题。所以为什么不为他们节省时间，集中编写 Terraform，创建一些模式供所有人使用呢？这说得通吧？这样可以快速完成“第0天”（初始部署）的目标。
2. 接着你开始想，还有很多其他的事情我们可以配置，比如配置可观测性，确保他们设置适当的日志和警报。我们可以让他们指定所需的服务级别，并将他们配置到多个区域或地区。所有这些都很好且有用，使应用程序团队有更好的部署体验。所以为什么不继续在这条道路上走下去呢？
3. （有时候）尽管我们觉得 Terraform 很糟糕，应该集中管理它，但我们也不希望完全隐瞒它，因为那样会变得过于限制。因此我们没有完全隐藏它：我们生成的代码会干净地提交到一个仓库，应用团队可以访问并根据需要进行修改。我们希望 帮助 而不是 限制 他们。

你可以花很长的时间用这种方式来构建东西；事实上，跟上云服务的变化和应用团队的需求意味着你可以一直这样做下去。那么，为什么不试试这种方法呢？这样做并不是不明智，实际上，很多团队已经通过这种方式取得了不错的成果。但也有一些假设，有时会被明确地说出来，有时则是默认的。

• 假设#1：虽然在提供所需基础设施方面存在足够的相似性，我们可以创建这些“蓝图”并使其适用于许多应用程序，但我们无法为这些相似的应用程序组创建更好的抽象概念。我们不希望在部署阶段之外，有太多或任何我们（平台团队）运营的生产软件，因为这会使我们在关键路径上，而我们不确定自己能否胜任。
• 假设#2：云供应商以这种方式操作所有底层系统，以至于他们很少干扰到应用程序团队的日常工作。应用程序团队可以依靠自己或他们的SRE来处理相关事务。当出现问题时，我们能够提供调试支持，但无需成为关键生产支持的一部分。
• 假设#3：我们能为应用程序团队解决的最大瓶颈问题是在云中配置并运行他们应用程序所需的堆栈。这在云计算旅程的初期似乎是显而易见的，当时整个公司都在试图弄清楚如何完成这些事情，而且很少有团队在云中运行有意义的应用程序。

现在我已将这些假设推断出，你可能已经猜到我接下来要说什么了。如果你同意所有这些假设，祝你好运，希望你是对的；对你所在的工作环境来说，这种做法对你们来说可能是最合适的！但这些假设也带来了一些主要局限。

避免运营工作通常对平台团队来说是个坏主意。平台团队的价值往往与其能够为应用团队减轻多少运营负担成正比，而回避运营工作会削弱你们的价值。在预算吃紧时，提供支持的团队通常比那些负责关键系统运行的团队更早被削减；前者常被视为非必需，而后者则是不可或缺的。

可以理解的是，有时候应用程序团队并不希望你参与到他们的操作中去，特别是如果你本身不是很擅长这些操作。但是，当你是所有配置和基础设施部署方面的专家时，你很难做到完全置身事外；从操作的角度，不了解底层基础设施的话，很难知道如何做到这一点，这意味着在出现问题时，你可能会被要求帮忙调试；或者，应用程序团队足够了解情况，不需要你了……那么，他们真正需要你的蓝图来做什么呢？也许一开始帮助他们启动是有用的，但现在可能只是给他们的专家带来了一些麻烦，并才能更好地掌控局面。

想要自己掌控所有内容的应用团队可以这样做；真正需要这样做的团队会做得更好，那些做得不好的团队会更加明白自己单独做所有事情的利弊。

对其他人来说，如果你能找到相似的蓝图，你应该考虑是否可以构建一个他们可以在其上部署应用程序的平台，而不仅仅是为他们维护配置。说清楚一点，这还挺棘手的。很容易就想到了类似Heroku的方案，而我们很多人都见过这种情况失败。同时，如果有很多工作要做，将各种组件结合在一起，使一组共同的应用程序可以部署到云端，我认为很可能你能够操作一些东西，例如，使用带有公司特有的控制器和与公司特有的权限和财务运营支持集成的托管Kubernetes这样的平台，允许你的应用程序团队指定一个更简单的配置参数子集，并将他们的应用程序部署到该平台。问问自己，你能自己构建和运营什么，可以帮助应用程序团队不再需要理解和维护那么多的底层基础设施的复杂性？

值得注意的是，这里需要注意的是，对于一些小型公司来说，直接使用几个选定的云服务平台（比如 Heroku、Vercel、AppEngine 等）来满足需求可能是适用的。但实际上，如果现成的供应商解决方案可以满足需求，我不会建议花费大量开发时间来构建自己的平台。但对于大型公司或者面对某些复杂情况，编写一些自定义软件（但不要太多）来实现公司所需的功能，同时简化底层的云复杂性，让应用团队更容易使用，对于应用团队来说是有价值的。

我们的定制 Kubernetes 平台是一个由平台工程团队构建和运营的真实平台示例。它之所以有效是因为 Kubernetes 让你可以写自己的代码；虽然这种棘手的工作你可能不想经常做，但它非常有用，可以让你把一个强大的通用系统聚焦在特定用例上，并作为服务提供出去。

你可能在想，这东西要是真的有用，肯定有人会做出来，或者云服务提供商会提供，但其实真的不需要我自己动手写代码。但是，从创建一个如此通用且有用的平台（可以卖给各种类型的公司，这非常非常难）与在特定环境里构建一些有用的东西，两者之间有很大的区别。特别是，将通用组件与公司的特定细节（通常与身份/权限、公司层级/账单部门代码等相关）进行集成，是一个值得探索的地方，用来平衡编写足够的代码以创建一个有价值的平台。

蓝图理念的吸引力在于它提供了一个后路；理论上，任何在terraform中能做到的事情都是可行的，应用团队可以尝试让更多的云功能变得可行，而你并没有真正设置任何实际限制，只是铺平了让某些模式更容易实现的道路。我非常理解为团队提供一个摆脱你选择的出路的重要性，以避免你的平台能力限制公司的创新。

不幸的是，保持广泛的可能选择也会保留所有与广泛选择相关的缺点。一开始选择总是很吸引人，但时间一长，选择往往会变得限制性，因为每一个量身定制的选择都需要持续的支持。如果你允许每个团队随时选择他们想要的东西，你就会陷入我们所说的“过度泛化的沼泽”。每个不同的选择都需要自己的胶水（一次性代码用于集成、自动化、配置等），虽然胶水快速创建，但修改起来却相当麻烦。

以产品的方式来构建平台，并不意味着要让所有人时刻都满意，并且完全按照他们的要求去构建。这意味着要花时间去理解究竟是什么导致了你的应用团队效率低下，然后自己去做这些艰苦的工作，让他们不必亲自去做。有时候，这意味着要做一些艰难的选择，比如决定支持什么或不支持什么，这可能会让某些特定小组感到失望。正如任何产品经理都会说的那样，设定策略并承担那些未必总是成功的决定所带来的压力是很大的。

要总结一下，做得好的平台工程不仅仅是配置管理和基础设施供应。它还包括努力识别、构建和运营抽象层概念，让应用团队可以花更少时间在底层技术上，把更多精力集中在解决业务问题上。与其思考如何支持无穷的变种脚本和自动化，不如考虑你可以构建哪些产品来覆盖最常见的架构模式，并且不只停留在供应和部署的层面。

这是系列文章的第一篇，我将尝试探讨和思考如何区分平台工程团队，以及通过平台工程创造有意义的价值。从这个意义上说，我写这些笔记是为了寻求读者的共鸣，我很想听听你们的问题和反馈！感谢詹姆斯·特恩布尔和皮特·米伦的早期反馈。

喜欢这篇帖子吗？你可能会喜欢我的书：《职业成长之路》，可以在亚马逊和Safari在线图书上找到，以及《技术人员、产品经理和团队领导的指南》，预计2024年秋季出版，并且可以在奥莱利学习平台上提前阅读！