译自 How to Host Your Own Platform as a Product Workshop 。
您是否在为采用平台工程而苦苦挣扎？像产品工厂一样去尝试平台，协调利益相关者并改变思维方式。
通常，当组织开始谈论平台工程时，这不一定意味着要从零开始。毕竟，大多数公司已经拥有某种形式的平台。可能因为它是一个由上至下的举措，运营部门通过部门竖井扔出的东西，所以采用率较低。
当组织采用平台即产品策略时，这种情况应该会改变。这种做法涵盖了平台工程的社会技术方面，它考虑了人员、流程和技术的交集——而不仅仅是后者。这种思维方式的转变首先不是专注于构建内部功能，而是专注于为内部开发人员客户提供服务和互动。也许最重要的是，在科技行业裁员盛行的时期，这种做法侧重于学习使用平台技术解决复杂问题——所以不要先考虑技术，而是先考虑问题。
Anna Ciula 和 Cansu Kavili Örnek 与红帽的客户合作，帮助他们构建采用这种平台工程思维的适用型平台。红帽的开放创新实验室团队开发并开源了一项半天的平台即产品工坊。在 WTF is SRE 的活动中，该团队联络负责人 Ciula 和架构师 Cavil Örnek 回顾了他们过去两年利用这项研讨会帮助团队最大限度地利用其平台的经验。
你可能已经读过 DevOps 已死。虽然是一个吸引人的标题，但平台工程最终被视为 DevOps 的交付机制。
“我看到的是，平台工程是 DevOps 实施的自然延伸或自然的下一步 - 就像 DevOps 的成熟版本一样。因为技术变得非常复杂，而且有这种开销，开发人员每天都需要新的东西出现，“ Kavali Örnek 说。“平台工程为他们提供一些通用的、可重用的功能，以减轻他们的认知负担，这样他们就可以真正专注于他们喜欢做的事情——业务应用程序、开发软件。
她担心，随着 DevOps 已死的观念，职位会改变，但工作方式将保持不变。为了解决 Puppet 的平台工程状态报告中强调的挑战 - 包括周期时间太慢，平台团队采用的阻力以及缺乏沟通 - 这些团队必须采用平台即产品的思维方式，这是团队拓扑创造的一个术语。
“将这种现代的产品管理思维应用于平台的构建，”她定义平台即产品，承认这是“从关注平台的底层技术转向关注实际用户和开发者需求，并在此基础上构建平台，这是一个巨大而困难的转变。”
Ciula 解释说，平台即产品工坊的设计是为了响应红帽客户共同面临的挑战。“我们看到开发人员因运维部门在他们脚下摆放各种障碍而感到完全沮丧。然后，运维人员因开发人员称他们愚蠢，不知如何使用平台而感到完全沮丧。”这些反应都导致运维部门通过命令和控制的措施要求使用平台，以及她所说的“影子 IT 反叛者在信用卡上创建自己的集群”。
与所有平台工程一样，这个工坊希望创建一种通用语言，让每个人都在同一页面上，所有利益相关者都接受平台即产品思维方式的好处。
只有所有相关者都参与其中，您的平台即产品工坊才有用。这不仅包括用户和客户，还包括 Ciula 称为影响者的合规与安全团队。正如我们之前写的，平台工程抽象出 Syntasso 的 Abigail Bangser 所说的“非差异化但并非不重要的工作”，以便应用团队能够更快地产生业务价值。
在简要介绍之后，这个工坊让所有这些利益相关者优先考虑您在平台工程成功方面面临的挑战，包括：
- 开发人员认知负担高
- 开发人员不信任也不采用该平台
- 糟糕的开发人员体验
- 客户正在遭受糟糕的服务
- 平台太贵了
- 平台太慢，无法更改
与它的名字相反，DevOps 主要关注运营，而这个工坊则更多地强调了开发人员体验和最终客户体验，并将整个平台计划与业务联系起来。
“这通常是一个非常非常有帮助的讨论，” Ciula 保证，但是，特别是在受监管的环境中，她警告说，“它往往会变得激烈，因为人们对更重要的东西有不同的看法。
这就是为什么你应该留出足够的时间让每个人都专注于最大的问题，而不是让谈话脱轨。
接下来，您分解虚拟的或非常粘性的便利贴，并作为一个组进行澄清：
- 什么是平台？（这是一个统一的管理控制台。）
- 什么不是平台？（不仅仅是 Kubernetes。）
- 平台有什么作用？
- 平台不应该做什么？（它不是支持所有边缘情况的包罗万象。）
Kavali Örnek 说，所有利益相关者都在房间里，这一点至关重要，这样你就不会只有运维视图或开发视图——任何从该平台中受益的人都应该感到被代表。
“这有助于我们围绕这个平台的外观以及这个平台将负责的内容划定界限，”她说。“对于每个人来说，了解这个平台是什么以及我们试图解决什么样的问题非常重要。
“通常，这里的每个人都知道产品是什么，它正在解决问题或是对需求的回应，” Ciula 说。但重要的是要重申“它必须是可行的。它必须在技术上可行。它必须是可取的。
这依赖于每个人都理解功能团队和授权产品团队之间的区别——平台工程师将解决问题，但不一定实施解决方案。
“授权产品团队被交给了要解决的问题，而不是要实施的解决方案，”她说。
这使团队能够将此产品镜头应用于具有明显业务倾斜的平台。大多数情况下，目标包括减少：上市时间、运营负担和/或开发人员认知负担。
“它应该为开发人员构建，与开发人员一起响应他们的基本需求，” Ciula 说，“显然它需要在技术上可行。
她将此视为一个“啊哈”时刻，她说:“我们的许多客户都在说‘天哪!实际上没有人在这样做。我们实际上没有一个平台产品经理，其工作就是确保我们为业务做点什么。”
此外，她收到的反馈是，平台团队并没有真正考虑开发人员和他们需要的服务，只是教育他们如何使用平台。
将平台视为产品的第一步，而不仅仅是另一个自上而下的瀑布计划，就是拥有产品 backlog 。
“在 backlog 中，你不只是把关于构建和维护平台的事情放在一起，” Ciula 说。内部营销同样重要：“你必须考虑一些事情，比如传播你的产品，让人们更想要它。
这不仅有助于为开发人员创造透明度，而且一旦他们得到平台的消息，请求就会涌入。 backlog 有助于管理内部用户的期望。
“我们希望开发者使用我们的平台。我们不想让开发者的生活变得苦恼。这种传道般的热情和对开发者真实需求的理解是至关重要的。” Kavali Örnek 说。她指出 DevOps 的三大支柱之一，并强调“与开发者进行这种对话和反馈循环真的很重要。”
接下来，工坊将团队拓扑的产品四个特征应用于平台：
- 可选使用
- 根据用户需求精心设计和策划
- 为用户简化某些内容
- 与科技一起发展
对于这些要点中的每一点，问问自己，这能说是你目前的平台吗？
当然，尤其在受监管的环境中， Kavali Örnek 也听到一些对选择权的反对意见。如果法规和安全性不可选，那么这些意见也许合理。但是，这个练习的真正目的是向所有利益相关者展示：“你应该以开发者想要使用的方式构建你的平台，”她解释说。“它应该是如此吸引人，以致于开发者不想寻找任何其他替代方案。他们想使用你的平台。”
否则，您将面临她所谓的空集群问题，其中有一些应用程序位于其之上，但您的大多数应用程序团队都不支持您的平台。
“这个平台是可选的。我们必须把它做得非常好，我们将倾听开发者的心声，他们会来使用它，并希望在内部为我们进行推广,” Kavali Örnek 说，为平台团队设定了理想的目标。
这个平台产品研讨会的第三个模块围绕衡量成功进行。通常，在进行这次工坊时， Red Hat 团队发现人们只是简单地衡量速度、故事点和缺陷数量， Ciula 认为这有点令人失望。
虽然 DORA 指标——部署频率、变更前置时间、平均恢复时间和变更失败率——被视为行业标准，但她的客户很少应用这些指标。这意味着 1 5分钟模块的大部分内容都只是一个愿望。
“我们想向他们重申，平台应该为业务做点什么，” Ciula 说。“该平台不仅适用于技术。它应该提供一些可以对业务产生可衡量结果的东西。
除 DORA 指标外，这个工坊还鼓励考虑平台采用率、开发者上手时间、开发者净表现评分等指标。“我们希望给他们留下一些思考的食物，这样一旦他们认真对待这个平台，他们就会接受这种平台即产品的方法，他们就会正确地做到这一点。
虽然本次研讨会还有其他模块，但也许最重要的是在后续步骤中结束，以便参与者准备好采取行动。
Red Hat 围绕迭代交付周期帮助创建了一个开放式实践库，具有更紧密的反馈循环，就像横向八字形或无穷大符号一样。这个莫比乌斯环从DevOps，敏捷，设计思维，影响映射和以人为本的设计等中提取，因此团队可以为每种情况选择相关实践：
- 你为什么要解决问题？
- 你在为谁解决它？
- 正在解决哪些问题？
- 如何解决这些问题？
然后，他们可以设计并实施他们认为可以解决结果的实验。这是一个持续的发现和交付之旅。Ciula 解释说，在某种程度上，这是为了确保平台团队不会只停留在交付功能而没有花时间重新审视发现阶段。
最后， Kavali Örnek 认为，成功的平台即产品战略取决于组织的心理安全，这就是为什么莫比乌斯循环包含平台工程的社会技术实践的技术和文化实践。