摘要：文章探讨了内部平台建设中开发者体验问题，指出当前平台常常增加摩擦而非赋能，强调平台应以产品思维打造，关注用户需求，减少认知负荷，并融入开发者工作流程，最终实现真正的赋能。

文章探讨了内部平台建设中开发者体验问题，指出当前平台常常增加摩擦而非赋能，强调平台应以产品思维打造，关注用户需求，减少认知负荷，并融入开发者工作流程，最终实现真正的赋能。

译自：If I Need Slack to Use It, It’s Not a Platform as Product

作者：Shweta Vohra

我还记得第一次有人告诉我：直接使用内部平台，现在都是自助服务了。

所以我尝试了。我打开了文档。滚动。继续滚动。注意力分散了。在 Slack 频道里发消息。等我终于设法启动了我需要的东西时，我已经读了三个 wiki 页面，凭猜测填写了一些 Terraform 变量，并且逆向工程了一个命名约定，感觉像是另一个团队 backlog 里的谜题。

我不是在入门，而是在解码。

那时我意识到有些不对劲。如果我需要一个 Slack 讨论串才能弄清楚你所谓的平台，那它还是个平台吗？或者它只是一个假装是平台的不成熟产品？

让我们稍微退后一步。在整个行业范围内，内部平台正风靡一时。但我只能回忆起我经历过的一个真正让人感到轻松愉快的平台。具有讽刺意味的是，它不是内部构建的，我们将繁重的工作外包给了第三方。这带来了一定的成本，而且并非每个组织都有意愿或预算进行这种投资。

今年四月在伦敦举行的 KubeCon + CloudNativeCon 欧洲大会上，同样的开发者担忧在走廊谈话、闪电演讲和非正式聚会中回荡。

糟糕的文档仍然是一个主要的障碍。分布式系统让人感到不知所措。反馈循环缓慢而痛苦。工具蔓延使工作流程支离破碎。开发者们被不明确的平台所有权和脆弱的 CI/CD 设置所困扰。

可观测性是零散的。本地设置很少与生产环境匹配。而且大多数团队仍在争论谁拥有什么。

如果这让你觉得熟悉，你并不孤单。平台工程承诺解决这些挑战。但实际上，它通常会引入新的复杂性，并为开发者及其工作流程带来更多的摩擦。

作为一名开发者，每次我听到“平台即产品”这个词时，我都会停下来。它到底意味着什么，它对像我这样的角色重要吗？

“平台”已经变成了一个万能的标签。

一个用 UI 包装的脚本？平台。

一个带有下拉菜单的 Jenkins 管道？平台。

一个共享的自动化模板仓库？也是。

但作为开发者，我们更清楚。一个真正的平台不是一个工具。它是一种体验，一种帮助我们更快地行动、更好地构建并减少摩擦的体验，而不是增加摩擦。

问题是每个团队对它的定义都不同。我已经在我的关于平台和相关主题的书中深入探讨了这一点。在我们的行业中，有些人将其称为门户，另一些人将其称为产品，而对于开发者来说，它通常会变成完全不同的东西。这导致了持续的混乱和多次跳转才能完成预期的工作，使团队陷入困境、感到沮丧并且无法有效地前进。

在我跨团队、跨领域和跨交付环境的工作经验中，我看到了一种持续存在的开发者摩擦模式，尤其是在当今快节奏的云原生世界中。这并不新鲜，但由于处理基础设施、运维和介于两者之间的一切的负担而加速了。我们让开发者负责所有这些。

很容易将开发者受挫归咎于不断发展的技术，但仅仅是工具并不能说明全部情况。无论堆栈或规模如何，许多相同的问题都会在团队和组织中不断出现。

根据我的经验，以下是超越技术层面的四个反复出现的挑战。这些并非详尽无遗，因此请随时在评论中分享你自己的看法。让我们仔细看看：

开发者面临的最常见的挑战之一是管理时间和注意力，抛开生活中所有的数字干扰，使其变得简单。在编写代码、审查 pull request、修复错误和参加会议之间，大多数开发者都疲惫不堪。

深度工作变得罕见。上下文切换成为常态。 生产力受到打击。

然后是技术变革的步伐。生态系统发展迅速。新的框架、工具、最佳实践几乎每周都会出现。即使是最有经验的开发者也难以跟上潮流，而不在工作时间之外付出巨大的努力。

例如：Kubernetes 提供了极大的灵活性，但也带来了陡峭的学习曲线。YAML 蔓延、复杂的集群配置和不一致的环境成为障碍而不是推动因素。

团队正在使用各种从未打算一起工作的服务，将管道和平台拼接在一起。出现了脆弱的系统。调试变得更加困难。每个人都在等待别人的平台错误修复才能继续前进。

安全和合规性要求持续增长，但工具很少能满足开发者的需求。安全变成了一个被动的检查清单，而不是一个集成的防护栏。而开发者则被夹在中间。

这些不是孤立的抱怨。它们是反复出现的主题，影响着士气、速度和质量，跨团队、跨工具和跨时区。

以 Terraform 为例。从理论上讲，它实现了基础设施自动化。但在实践中，当每个服务都需要自己的模板，当不存在抽象层，并且当加密和标记等标准留给部落知识时，它很快就会变成另一个负担。

内部门户网站，被宣传为自助服务，通常只是位于脆弱、不透明流程之上的表单。你填写它们并等待。如果出现问题？你又回到了 Slack。

API 呢？有些人声称他们的平台是 API 优先的，但当你尝试使用其中一个 API 时，最终需要四个单独的 Slack 消息才能理解它。

这不是开发者赋能。这是包裹在友好界面中的熵。

我们不是要求完美的产品或平台。我们要求的是流畅。

一个好的平台应该在开发者已经工作的地方与他们会合：CLI、代码库或 API 层。它应该通过开关而不是模板来提供配置灵活性。安全默认设置（如加密和日志记录）应该是内置的，而不是可选的。

如果你的平台团队从不与用户交谈，那么你不是在构建产品，而是在运送一场猜谜游戏。

配置一个完整的环境不应该需要部落知识或多个 Jira 工单。理想情况下，平台应该问一些智能问题并处理其余的事情，就像一个代理一样。它应该在后台运行合规性和漏洞检查。预加载所需的库。悄悄地保持它们的最新状态。

让开发者构建，而不是照看基础设施。

“平台即产品”在幻灯片和章程中听起来很有吸引力。但在实践中，大多数内部工作流程、自助服务、门户网站，除非有意和用户输入构建，否则都达不到要求。

这是许多人忽略的部分：如果你的平台团队从不与用户交谈，那么你不是在构建产品，而是在运送一场猜谜游戏。

想让开发者采用你的平台？让他们参与进来。与他们共同设计。衡量入门摩擦。像对待错误一样对待反馈。像跟踪正常运行时间一样跟踪采用情况和影响。最重要的是，不要再认为“左移”与“倾听左侧”相同。

每个变通方法都是你的平台无法正常工作的症状。

一个真正的平台会消失在开发者（或用户）的流程中。一个糟糕的平台会每天中断它。

像产品一样思考会引发一个重要的问题：对于你组织中的开发者来说，多少标准化才足够？定义的受众在哪里？产品路线图呢？将平台采用与业务影响联系起来的指标呢？支持模式呢？反馈循环呢？

如果你的内部平台没有这些，那么它就不是一个产品。它甚至可能不是一个平台。

作为一名开发者，我不需要另一个带有花哨名称的工具。我需要一个可以悄悄地消除障碍的系统。一个不需要工单队列、Slack 消息或多标签调查才能开始的系统。

如果你称你的内部平台为产品，那就证明它，无论是在它的设计、支持还是体验方面。如果你还没有准备好这样做，也许就不要再这样称呼它了。

因为下次我在你所谓的平台上遇到障碍时，我不会提交工单。我会编写一个变通方法。每个变通方法都是你的平台无法正常工作的症状。

但是变通方法无法扩展。具有产品文化的平台，如果构建得当，则可以。

我们只是在这里触及了皮毛。在接下来的几周里，我们将更深入地探讨真正需要什么才能超越破碎的工作流程和被动工程，不仅提供批评，还提供解决方案模式、现场笔记以及从成功（和失败）的平台之旅中获得的来之不易的经验教训。

一个真正的平台会消失在开发者（或用户）的流程中。一个糟糕的平台会每天中断它。

我们将探讨如何减少认知负荷、加速反馈并将产品思维带入内部开发者体验。

我们还将挑战平台工程仅仅是粘合工作的概念。因为真正的粘合剂（那种将团队、工具和信任结合在一起的粘合剂）不是存在于文档中。它存在于周到的设计、明确的所有权和帮助开发者建立势头的日常仪式中。

让我们构建名副其实的平台。

来源：Marker科技