伦敦——Syntasso 的首席工程师 Abigail Bangser 在本周的 State of Open Con 上说，“应用程序开发人员希望快速行动，而运维工程师希望安全行动”，这就是 DevOps 模型的崛起之地。 DevOps 将发布所需的所有技能带入了一个团队，这减轻了开发人员的一些认知负担，他们不再需要——过多地——担心代码之上的安全性、支持和成本，因为他们团队中的运维工程师已经涵盖了。不可否认，DevOps 还提高了团队自主权和发布速度。
但是，Bangser 继续说道，这也导致了大型组织的大量重复工作，在这些组织中，DevOps 团队并没有 100% 专注于为最终用户创造价值，因为他们仍然关心基础架构、扩展和安全性。她强调，这没有太多不同，但并非不重要。这就是内部开发平台团队的用武之地，以减少云端繁重的认知负担，以便开发人员可以专注于开发，而运维人员可以专注于运营。而平台工程师专注于跨组织团队所需的非差异但重要的代码。
“所以你有一个团队来生产和操作工具来帮助其他团队为他们的最终用户生产和操作他们的软件应用程序，”Bangser 说，提供了平台工程的最新定义。
现在我们知道了平台工程团队应该做什么，让我们深入探讨如何培养良好的内部开发人员平台体验——这样您的客户同事才会真正想要使用它。
应用团队，也许应用团队是关于闪亮的，但平台团队是关于旧的可靠的。 “我发现人们专注于新的创新技术，但他们忘记了他们正在为哪些人开发它。” Nicki Watt 是 OpenCredo 分布式系统咨询公司的首席执行官和首席技术官，她帮助多家组织建立了内部开发人员平台，使她能够发现一些模式和反模式，她在 State of Open Con 群体中分享了这些模式和反模式。
她说，很多客户认为 Kubernetes 是一个平台，但“如果你想构建一个伟大的平台，它必须不仅仅是 Kubernetes 和围绕它的开源生态系统。”内部开发人员平台是人员、流程和技术的混合体——它不是简单的配方——也不是 Venn 图。这需要对您的内部开发人员社区产生同理心。
首先，Watt 提醒与会者，“你的听众比你想象的更加多样化。”尤其是随着组织的发展，平台工程师——他们自己大多是基础设施专家——往往不知道面前的技术栈是由多少不同水平的技能和经验构建。她警告说，这会导致低级别的 YAML 抽象，并且“有些社区要考虑的更多”。
主要是应用程序开发人员，但也不要忘记可能需要硬件或其他不同功能的数据科学家和机器学习工程师。她还观察到，在平台设计中需要考虑领导和治理社区——包括监管和金融。毕竟，他们希望通过报告了解他们是否以及如何从这项投资中获得回报。她说，平台工程之旅的一部分是让高管们了解它的价值。
然后，“根据特定的社区需求调整平台本身是好的，但还不够，” Watt 说，因为你不能单独解决技术问题，而且只解决一次。平台不是一劳永逸的——团队一直在变化和适应，她指出，治理和流程不可能一刀切。而且总会有不同类型的团队。
“一些人需要更多的创新自由，而另一些人则需要更多的指导，”她说。 “如果你想建立一个真正伟大的平台工程开发者体验，这需要你将其视为一个整体的社会技术挑战。”她对平台工程的定义归结为构建、维护和提供“为所有使用它的社区精心策划的平台体验”，这会影响所有不断发展的技术、社会和团队结构。
我们已经谈到了内部开发人员平台如何位于不同组织的不同级别——甚至在组织内的不同级别。Watt 说，良好的平台工程经验会建立明确的界限和责任，并回答这两个问题：平台能做什么？工程师需要做多少？否则你最终会陷入责备游戏，她解释道。
这些边界可能因利益相关者而异，但请记住记录这些差异，包括：
- 平台是做什么的？
- 平台团队负责什么？
- 应用程序团队负责什么？
当然，与任何开发人员的经验一样，文档是鼓励自助服务和自动化的重要组成部分，Watt 说，这是平台用户最想要的。 “这种自助服务使团队能够根据需要走得快或慢。”她强调说，目标是让团队独立于你而不是依赖于你——“我们的目标是在这里获得授权”，而不是平台工程师被内部工单弄得焦头烂额。
平台团队是黄金途径的建设者，她解释说，这条途径灵活且可发展，但主要是确保有秩序。她建议，在边界内促进自由，提前制定基本规则。这可以是单一云与多云设置，或者仅提供对标准堆栈的支持，而平台团队不提供对平台轨道之外的最新闪亮实验的支持。
Watt 说：“通过这样做，你可以让人们自由选择，但你不会让所有人自由竞争，这可能会在以后导致挑战。”选择仅限于生态系统。
API 不断成为开发人员以他们想要的方式使用内部平台的最简单方法。部分原因是，正如 Postman 的首席传播者 Kin Lane 所说，API 是一份合同，甚至可以作为您与 API 客户的服务水平协议。他在 2019 年首次写道：“API 合约是对数字接口功能的共同理解，允许应用程序在其上进行编程。”API 减轻并传达了人机界面的变化。可读的方式，并且应该提供一些可靠性和稳定性的保证，他继续说。
以 API 优先的方式构建您的内部平台，使其更易于自助服务。 Bangser 说，通过将该服务合同扩展到内部平台，API 变成：
- 可发现的产品目录
- 一个或多个用户界面选项
- 按需提供（虽然不一定是即时交付）
- “什么都不做”脚本简介
这就是为什么她建议以有限的时间和投资来开始您的平台工程之旅，发布一个 API，开发人员可以使用该 API 访问将成为平台的内容。然后查看已经在运行的工具——Slack、Jira、Trello——并开始跟踪临时请求。什么是最频繁、最困难、最耗时的？您的应用程序团队的辛劳在哪里？ Bangser 建议，寻找任何手动、非价值驱动且难以扩展的东西。并希望通过 API 优先开发来减少它。
“API 允许清晰的通信边界，”她说，“创建 API 提供了迭代的能力。”
Watt 进一步建议定义一个实际的内部平台合同，一个 la Amazon Web Services 的共享责任模型。澄清这些界限，比如如果组织希望平台团队处理所有安全检查，或者如果您的平台工程师只提供工具并且每个团队负责在自己的容器上运行扫描。她建议，只要有可能，就支持自动化和 API 驱动的交互，尤其是在入职和基础设施配置方面。
当然，文档是必不可少的，包括创建模板和参考实现，这进一步支持自助服务。
“你想让你的团队更接近平台，与平台互动。做到这一点的一个好方法是提供他们需要的文档和参考实施，”Watt 说。
不要忘记提供平台工程体验的专业服务方面。 Watt 说这可以包括研讨会、结对编程、嵌入 DevOps 团队，或者，正如我们从 CyberArk 了解到的那样，您可以为您的平台团队借用应用程序开发人员。随着您的平台团队规模的扩大，您可能需要自己的平台传播者来吸引您的同事客户。
不要忘记，如果您的内部平台是与您的应用程序团队签订的合同，那么可靠性很重要，并且必须从一开始就将持续测试纳入您的平台策略。Watt 说，获得内在弹性和可靠性的可靠方法是吃自己的狗粮并使用平台——“将对他人的限制强加给自己”，尤其是“启动基础设施的工具”。只要你这样做，你就会发现问题很快就会得到解决，”她说。如果那不可能，至少要将您的参考实现作为示例租户进行测试。
最后，平台工程要求你“调整你的想法——目标不仅仅是提供服务，而是成为一种服务并为你的社区服务，”Watt 说。 “我们不仅需要像开源一样开放，还需要开放我们与人互动的方式，并与团队开放我们需要什么才能取得成功。”