平台工程的模式与反模式

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source link and all formatting exactly as you specify.

平台工程概述

平台工程已经存在一段时间了。然而，最近由于它与 DevOps 的相关性，兴趣迅速增长。

对某些人而言，平台工程解决了一个常见的 DevOps 拓扑问题：将 IT 运维嵌入缺乏时间和经验的 DevOps 团队中。这是一种反模式，也称为 Anti‑Type F。

平台工程可以帮助您 扩展组织规模 并 降低开发人员的负担。

使用我们的平台工程决策流程 来判断它是否是您问题的合适解决方案。它还指导您提前建立关键衡量指标，以便跟踪内部开发者平台（IDP）的价值。

反模式与正向模式

我们在下文中描述平台工程的反模式和正向模式。如有建议，请告诉我们。

如果您熟悉 Team Topologies，则不太可能使用常见的平台工程反模式。当您遇到问题时，库仍然可以帮助您向同事描述问题。

Source: …

减少认知负荷

IDP 应该 降低复杂性 并 消除开发者的认知负荷。如果平台使用起来过于困难，就未能实现这一关键目标。平台可能增加开发者负担的方式包括：

• 使用开发者不熟悉的配置文件格式。
• API 的方法和参数没有统一的约定。
• 没有文档。
• 平台未能减轻开发者的痛点。

配置文件

如果平台包含配置文件，请对格式保持灵活。应当能够轻松地从以下任意一种格式解析相同的数据：

• JSON 文件（面向 Web 开发者）
• YAML 或 XML 文件（面向后端团队）

这让开发者可以使用他们熟悉的格式，而不是只能使用你方便的格式。

API 与 CLI

在创建 API 或命令行界面（CLI）时，要对以下内容保持细致且一致：

• 方法名称
• 参数名称
• 参数顺序

这会使接口更易于使用。

文档

你的 IDP 文档应当 简洁明了，重点包括：

• 可用的功能
• 如何使用这些功能

治理、风险与合规（GRC）

如果开发者未能满足 GRC 目标，而你又添加一个处理这些需求的平台，可能会 给开发团队增加更多负担。应先解决现有的开发者问题；随后再在不增加开发者负担的前提下满足外部要求。

整体成功标准

• IDP 必须 显著降低 开发者的认知负荷、复杂性和倦怠感。
• 它不能 把所有痛苦转嫁 给平台团队。

构建合适的平台

“如果你建造它，他们就会来。” – 《梦之田野》 (1989)

如果在构建内部开发者平台时采用同样的做法，你将难以获得内部市场份额。应从一开始就让开发者参与进来，构建能够解决他们特定问题的平台。

平台不匹配的常见症状

• 技术不匹配 – 例如，让管理 Kubernetes 更容易，却发现开发者已经转向无服务器函数。
• 技能假设 – 例如，创建简化的微服务模板，却发现开发者已经是微服务专家，不看重你的解决方案。
• 强制选择 – 例如，使用最新技术设计平台，而业务更倾向于稳定、成熟的方案。

仅凭信念无法设计你的 IDP。与多个团队的开发者交流，发现平台可以消除的共同痛点。孤立地创建平台必然导致采纳率低下。

团队动态与知识转移

当你组建平台工程团队时，通常会挑选在平台涉及领域拥有最多经验的人加入。这可能会导致以下问题：

• 平台团队认为自己比开发团队更懂。
• 开发团队失去运行软件所需的知识。
• 开发团队失去能够将他们迁移到平台上的人员。

Best practices:

1. 继任计划 – 如果将人员从开发团队调到平台团队，务必制定完善的继任计划，并注重协作，以提升剩余开发者的自助服务能力。
2. 避免认知过载 – 不要在没有计划的情况下移除有技能的团队成员，这可能导致倦怠。
3. 小步起步 – 从精简的平台团队开始，解决能够让其他团队更频繁发布的痛点。
4. 招聘协作能力 – 选择平台团队成员时，以沟通与协作能力为重点，而不仅仅是技术知识。

“Magpie”平台反模式

对闪亮事物感兴趣的人常被称为喜鹊（乌鸦科的一种，喜欢收集闪亮的物品）。喜鹊平台专注于最新技术，而不是解决开发者在现有系统中面临的真实问题。

• 为全新项目构建平台很有吸引力，但帮助团队处理他们的现有生产软件会产生更大的影响。
• 识别开发者的痛点所在，然后为新软件构建更好的平台。

当开发团队采用新技术时，他们可能看起来需要所有方面的帮助。先让他们建立起知识；实际的痛点会显现，随着他们适应新技术，许多早期的痛苦会消失。

证明影响

你需要证明平台的影响力，因此需要一个稳定的起点，以便让其他人认真对待你的测量结果。如果利益相关者认为改进仅仅是因为团队对技术和业务领域变得熟悉，他们可能会忽视你的改进。

Platforms must prove their i (text truncated in source)

欢迎随时对本指南提出编辑或补充建议。

对现有团队和技术栈的影响

将会有许多机会在团队以不同方式解决问题时合并技术。
有时引入用于部署或监控的新工具可以一次性为许多团队消除痛点。关键是要展示平台的好处。

Source: …

长期投资

一旦你在组织中引入了平台，就需要进行长期投资以保持其可用性。

• 如果平台团队在交付产品后解散，平台可能会成为拖累所有依赖它的人的负担。
• 导致 IDP 中决策的背景可能会发生变化，导致团队被迫使用已经不再适用的旧方案。
• 平台可能变得如此难以使用，以至于团队必须迁移出去才能完成工作。

**关键要点：**平台需要持续改进——添加新的黄金路径并逐步淘汰过时的路径，以持续提供业务价值。

将雄心与投资相匹配

您应该限制平台的雄心，以匹配长期投资水平。

如果贵组织的技术生态碎片化，可能会想用 IDP 解决过多问题。支持所有现有的工具和技术将会：

• 让平台被拉得过于薄弱，以至于失去实用性。
• 使平台团队的负担比开发人员更沉重。

避免“拉伸”平台

一个常见导致平台被拉伸的原因是以 内部市场份额 来衡量平台团队。

• 增加更多的黄金路径可以提升市场份额，但这会违背鼓励围绕良好技术选择进行整合的目标。
• MONK metrics 可以帮助在市场份额、开发者满意度和成果之间取得平衡，防止平台被过度扩展。

成本控制与自助服务

当你提供自助服务选项时，必须围绕 成本跟踪和控制 构建 有力的叙事。

• 如果每个开发者都启动类似生产环境的实例，成本可能会失控。
• 任何让支出变得容易的按钮都应包含 自动限制（例如，短期测试环境、并发环境的上限）。
• 这为平台团队提供了与财务部门在 成本治理 方面合作的机会。

一体化 DevOps 工具陷阱

当平台决策脱离技术知识时，人们往往会倾向于采用 一体化 DevOps 平台。

• 这 并不符合平台工程或 DevOps 的理念。
• 单一的通用工具会限制平台的能力和持续改进的可能性；工具的功能会约束所有问题的解决方案。

更好的做法：

• 将平台设计为解决特定痛点的 内部产品。
• 在需要时选择 最佳实践工具，并创建可复用的库（例如统一日志和遥测）。
• 请记住：黄金路径并不是工具；它是一种经过策划、可重复的做事方式，通常基于专用的构建、部署和监控工具构建。

处理边缘情况

• 虽然平台团队旨在统一整体，但边缘情况始终会存在。
• 僵硬的平台 会迫使团队退出并寻找替代方案。
• 与团队互动并倾听边缘情况，使平台团队能够 对抗 这些情况并保留内部市场份额。

平衡：

• 在没有整合的情况下容纳每一种情形会让平台团队因复杂性和认知负荷而不堪重负。
• 最佳的软件产品拥有 明确的聚焦，并且不尝试做所有事情。

设计提示： 允许团队添加边缘情况 而不一定将其纳入支持范围。边缘情况不应迫使用户离开平台或扩大平台的攻击面。

市场份额报告

当您报告平台市场份额时，突出三个数字：

1. 总市场规模 – 所有开发者。
2. 受支持的市场规模 – 使用金路线支持的技术栈的开发者。
3. 市场份额 – 实际使用平台的开发者。

市场份额图表

• 显示内部开发者的总体市场。
• 指示该市场中有多少可以使用 IDP。
• 显示实际选择使用的数量。

使用该图表 指导决策，用于新的金路线，并跟踪平台对其目标受众的吸引力。

团队设计与交互模式

创建团队很容易；构建使其成功的交互则要付出更多工作。

• Team Topologies 使用团队和交互模式的组合来描述这一点。
• 如果在没有关注交互设计的情况下创建平台团队，它将会失败。

文化

软件交付需要一种 高信任、低指责的文化 才能成功。平台工程也不例外——文化是绩效的最大预测因素之一。（更多关于 DevOps 文化的信息请参见。）

平台作为长期产品

• 构建平台不是一个项目；它必须是长期战略。
• 当平台被搁置时，会限制所有用户的性能——甚至比根本不创建平台更糟。

你需要：

• 稳固的团队设计。
• 明确的交互模式。
• 对平台的产品思维。

成功的标志

现在您已经了解了平台工程可能失败的多种方式，让我们看看成功的样子。

• 在 Puppet State of Platform Engineering Report 中，94 % 的受访者 认为该概念帮助组织实现了 DevOps 的收益。
• 在 DORA 指标 上表现强劲是平台工程成功的良好预测因素。

良好平台工程最关键的标志是…… (continue with your success criteria here).

Source:

平台工程即产品

开发者是客户，内部平台必须解决他们的问题才能赢得市场份额。

1. 平台团队的产品思维

• 定期与开发者接触 – 与使用平台的团队保持反馈循环。
• 可衡量的成功标准 – 定义并跟踪平台 KPI（例如采纳率、价值实现时间）。
• 产品经理的职责
  • 不仅仅是维护待办事项列表。
  • 在组织内部提升平台的认知度。
  • 与其他部门建立网络，纳入他们的需求。
  • 帮助开发者满足 安全、治理、风险和合规（SGRC）要求。

2. 愿景、决策与文档

愿景

一个强大且鼓舞人心的愿景能够指引正确的决策，防止平台仅为获取内部市场份额而支持错误的选择。

决策登记册

• 记录每一个重要的架构或产品决策。
• 保存决策背后的理由，防止决策被遗忘或日后被逆转。

文档

高质量的文档对产品采纳 至关重要。

• 保持文档的时效性。
• 让文档易于查找和使用（例如可搜索的文档、快速入门指南）。

3. 提升平台价值的 DevOps 能力

“DevOps 通过以下方式提升软件交付绩效。”

这些能力还能提高构建 有价值平台 的可能性。

4. 小步快跑，快速迭代

• 不要一开始就追求“黄金路径”。
• 解决 一个影响广泛的问题，然后迭代实现成功。

常见的“易获胜”模式：

1. 部署通用且已批准的技术栈。
2. 按需供应基础设施并创建环境。
3. 收集遥测数据、错误日志，监控生产系统。

其核心原则：抽象出复杂领域，让开发者不至于陷入细节泥潭。

• 当现成工具合适时直接使用。
• 否则，构建一个 façade（外观层）来简化该复杂领域。

5. 最精简的可行平台

• 从 最小功能集 开始，确保产生最大影响。
• 缓慢扩展，优先考虑高影响区域，而不是一次性解决所有问题。

示例：Unified

（原始来源中内容已截断；如有需要可继续补充。）