尽可能地组织和标准化平台的各个方面，以确保从第一天到第 2000 天乃至更长时间的易用性和维护性。
译自 5 Lessons For Building a Platform as a Product，作者 Colin Humphreys。
在 20 年的平台工程经验和 10 年的 平台即产品 建设经验中，以下五个关键经验教训可以帮助您打造成功的平台即产品。
作为一名在平台工程领域工作了二十年的专业人士，我专门从事平台即产品的构建，为全球一些最知名的品牌构建平台，并创办了一些最终被更大组织收购的公司。在此过程中，我犯过很多错误，也取得了一些成功。
我最近在 PlatformCon 演讲中分享了我最重要的学习成果，“20 年平台工程，10 年平台即产品，5 个经验教训。” 我想在本文中进一步阐述几个主题。
让我们深入探讨我从平台即产品经验中获得的五个经验教训，这些教训是我 来之不易的（因为事情可能会出错，而且确实会出错！）：
- 采用“产品思维”。
- 为您的组织找到合适的抽象。
- 使您的平台民主化。
- 无处不是棕地，一切都很复杂。
- 第一天很容易；第二千天很难。
在构建平台时，“产品思维” 意味着什么？在 我与 Joe Fitzgerald 共同撰写的一篇关于平台即产品的白皮书 中，我们定义了关于平台“产品化”的思考方式，它可以重塑我们对平台构建的看法：
“您的平台不是现成的软件；它是一组不断发展的可重用服务，与您的现有系统集成，为您的业务创造有价值的结果。平台的功能应该根据其用户的需求而改变——您的应用程序开发人员——在他们中，它是一个可识别的内部品牌。换句话说，您的平台应该被视为一种产品。”
如果您没有从产品思维出发进行构建，平台将变得以项目为导向。它很可能局限于特定的开始和结束日期，并具有发布和某些功能，其运作方式与大多数短期项目非常相似。与大多数现成的软件发布一样，它进入世界，我们希望一切顺利。然后，我们重复这个以项目为中心的流程。这种增量式平台构建方法与上述定义不符，并且会错过一些重要的机会，因为合理的平台工程 不仅仅是工程。
用户是构建优秀平台的核心。用户想要什么，他们会使用什么？平台根据这种使用和我们积极从用户群中寻求的反馈而发展。与大多数事物一样，它应该响应不断变化的开发或业务需求以及使用模式，以提供价值。
从工程角度来看的可行性、从产品管理角度来看的可行性以及从设计和可用性角度来看的吸引力，共同构成了我们所说的“成功产品”。这意味着，虽然平台工程是必要的，但它本身并不足以，因为成功的平台产品需要产品管理和设计技能。
为平台即产品带来真正且持续的价值，首先需要了解其用户，并牢记以下几点：
- 平台工程只是其中的一部分——产品和设计也很重要。
- 与用户合作，并亲身体验他们如何使用平台；使用 X 作为服务来确保可扩展性。
- 捕获用户指标并响应反馈，以不断适应用户需求并注入持续创新。
与任何 CTO 交谈，他们都会告诉你，他们的应用程序团队在非开发任务上花费了太多时间。2019 年 《新堆栈》上发表的一项调查报告称，开发人员在编写或改进代码上花费的时间不到三分之一。我自己与 CTO 的非正式聊天表明，估计有 80% 以上的应用程序团队时间花在了不创造价值的繁琐工作上。也就是说，开发人员正在构建自己的内部平台，专注于运营工作负载，并执行许多其他非创意任务。
CTO 和开发人员都希望减轻这种负担。平台工程可以提供帮助——如果组织投资寻找适合其业务的抽象。这是一个很大的 如果，因为没有一个放之四海而皆准的平台，这也是一个潜在的障碍。
一种常见的方法是经典的糟糕的 DevOps“你写它，你运行它”的心态，在这种心态中，各个团队决定构建自己的平台，结果发现其他多个内部团队也投资创建了他们的平台。撇开导致这种情况发生的组织沟通孤岛不谈，这样做是浪费的、低效的，并且没有利用平台工程的力量。
什么是“正确的抽象”？一个很好的起点是询问我们从平台中需要哪些关键属性才能使其有价值。它将如何为组织提供最大的效率、安全性和生产力？实现这一点需要查看组织中对团队的 期望，但 对业务来说是独一无二的。如果某件事对行业来说并不独特，那么购买现成的产品可能更有意义，或者获得现有的云服务来满足需求，而不是试图自己构建它。
决定正确抽象的一种方法是了解错误的抽象。强迫每个人走上一条规定性的“黄金路径”，旨在展示事情应该如何完成，这会造成摩擦和阻力。这种“独裁式方法”是一种常见的冲突，因为不同的意见和经验与“这就是一切运作方式”的方法发生冲突。无论是 CI/CD、使用的确切框架、暂存和生产，还是其他工具，创建（可）分解的抽象以确保人们更有效率并具有一定的灵活性 非常重要。以高级抽象形式提供选项有助于提供一些不会变成电网的指路牌。
正确的抽象将对组织及其需求是独一无二的，这意味着：
- 找到对您的团队的期望，但对您的业务来说是独一无二的
- 没有灵活性的承诺的“黄金路径”会降低生产力并造成摩擦
- 不要对应用程序团队发号施令；他们会对事情如何运作有自己的看法。您应该尝试让他们的生活更轻松，但要以合作的方式，不要推翻他们的经验。
在企业中交付有意义、高效且有价值的软件通常涉及许多利益相关者。尽早让这些人“参与进来”，否则您将在将价值投入生产和为组织的客户提供价值方面遇到困难。
整个过程中有许多人有权对您试图做的事情说“不”——出于各种原因。从一开始就民主化平台有助于将这些利益相关者纳入其中，并尽早将他们的价值带入平台。对于企业来说，价值实现时间是一个重要的考虑因素，在某些组织中，复杂性、合规性和治理（以及其他因素）会严重减缓价值交付。
民主化平台力量的一个例子：一家保险公司将六个月到两年的部署周期缩短到将所有将代码部署到生产的活动整合到一个平台并将其自动化，从而将他们的部署周期缩短，并能够每天部署多次。
让合适的利益相关者参与进来，并将他们及其价值带到谈判桌上来，这对您最终得到的平台有很大影响。民主化过程的一些关键点：
- 为您的平台创建一个自助式 API，并提供不同的接口来访问它
- 帮助其他团队（身份、CI/CD、数据库）将他们的价值贡献到该平台
- 使安全、网络和其他赋能团队能够提供他们提供的服务，例如，子系统团队从赋能团队获得价值，等等。
世界不是一个原始的绿色空间，这适用于拥有大量遗留内容的组织。是的，一切都是棕地 并且很复杂，即使是最有价值的解决方案也不能取代所有内容或在所有地方使用。
作为一个现实世界的例子，我和一家全球顶级银行的首席技术官谈过，他解释说他很喜欢 Cloud Foundry 的功能，但想知道他负责的其他 99% 的工作负载应该用什么。本质上，思考需要完成什么以及可以用现有资源完成什么至关重要，有时甚至至关重要。如果你规模很小或拥有基础应用程序，使用 Heroku、Netlify 或其他平台即服务将非常合理。但是，对于面临可扩展性、合规性和治理问题以及无数不符合新平台和服务的长期遗留应用程序的组织来说，复杂性是不可避免的。
大多数企业都是棕地，复杂程度难以想象，而且难以处理。这种现实告诉我们必须以诚实的方式思考我们的平台以及它们如何以及是否能够适应这种环境，而不是试图对其进行支配。
在大多数组织中，底层只有一个基础设施层。不可能说，“所有东西都在 Kubernetes 上”。相反，更有可能看到 Terraform、Pulumi、云 API 以及 Chef、Puppet 等基础设施即代码工具，以及大量脚本，一些是声明性的，一些是命令式的，等等。如果平台要为组织提供真正的价值，它必须与所有这些内容协同工作。在构建平台时，让用户能够以 X 作为服务的理念带来他们的价值至关重要。你需要一个简单一致的 API，作为人们长期以来一直在提供的价值的接口。如果平台要在组织内部提供实际价值，这个 API 必须同时适用于旧资源和新资源。
做好应对复杂性和遗留问题的准备。解决这一现实的一些关键考虑因素包括：
- 适应，不要支配。
- 理解和规划平台将需要处理大量棕地内容。
- 为旧资源和新资源提供简单一致的 API
第一天，从头开始创建一些东西很容易。在第 2000 天，维护第一天构建的东西要困难得多。即使经过精心计划，随着时间的推移，组织中也会发生很多事情——人们离开并带走了大量的机构知识；层层叠叠，第 2000 天存在的东西与第一天截然不同。
如何应对这种情况？正如所指出的，一些挑战是无法预见的，但组织和标准化为可管理的结构是第一步。通过 X 作为服务的理念，将我们需要管理的内容纳入结构化设置，以便了解它们在哪里、它们是什么版本以及在那里安装了什么软件，可以做到这一点。考虑将你提供的服务标准化，而不是共享代码库（一颗定时炸弹），这有助于确保用户参与进来，而不是承担他们的维护噩梦。
第 2000 天可能比看起来更容易。考虑从第一天到第 2000 天，确保你的平台为用户提供服务的方法：
- 组织和标准化
- 考虑构建应用程序很容易，但维护起来更具挑战性
- 共享代码是一个维护噩梦；将事物作为服务提供（管理舰队，让每个人都参与进来，保持更新和安全）
无论组织处于平台工程旅程的哪个阶段，这五个教训都可以在评估和设计未来平台时派上用场：
- 产品思维：将你的平台打造成产品
- 找到合适的抽象：将你的平台打造成适合你的产品
- 民主化你的平台：通过尽早从利益相关者那里获取尽可能多的价值，并在此过程中更容易获得认可，使你的平台更加健壮。
- 处处都是棕地，处处都是复杂：使你的平台能够适应遗留企业及其基础设施和系统的现有复杂性。
- 第一天很容易；第二千天很难：尽可能组织和标准化平台的各个方面，以确保从第一天到第 2000 天及以后的易用性和可维护性。