DevOps 缺少定义，平台工程需要指导性路线图
在 PlatformCon 2022 大会上，Puppet 现场首席技术官 Nigel Kersten 谈了平台工程指导性路线图的需求。他分享道，在之前的文化转型中，如敏捷和 DevOps，行业在方法和定义方面开始出现分歧。关于如何进行组织和文化变革才是拥抱新范式的最佳方法，人们感到很困惑。
Kersten 认为，缺少方向不仅会导致实现很糟糕，而且还会产生不良后果。缺乏对 DevOps 的理解会产生一个副作用，就是 DevOps 工具和软件生态系统会自称是实现 DevOps 的手段，导致许多人错误地认为，DevOps 的目的仅仅是实施恰当的工具。
然而，正如 Showpad 工程副总裁 Patrick Debois 在 2010 年所指出的那样，DevOps 不仅仅是软件：
DevOps 运动是围绕着一群人开展起来的，他们相信，将适当的技术和态度相结合可以彻底改变软件开发和交付的世界。
在大规模迁移过程中，对文化和流程的关注往往不够。在企业层面，现有团队、流程和沟通渠道的数量使得这项运动很容易失去目标。正如 Kersten 所指出的那样，大量供应商和软件公司向该领域发布工具，加剧了这种情况：
有太多供应商看到了这个巨大的、充满活力的社区，这些人非常热衷于改变现状，并且说，“那个软件，是的，完全是 DevOps 的”。所有这些都开始扭曲和异化整个运动，以至于人们的期望和理解变得有点难以实现。
Kersten 认为，有必要制定一个指导性路线图，以确保这段历史不会在平台工程运动中重演。创建一个合适的团队结构只是为成为一个成功的组织奠定基础的开始。团队之间的互动同样重要。正是在这一点上，组织往往会陷入困境。
对平台工程来说，这并不新鲜，而对 DevOps 来说，这也一直是项挑战。SoundHound 高级工程主管 Adam mclurin 指出：
关于 DevOps 到底是什么，现在有太多无用的争论。我认为，我们应该退一步看，DevOps 只是价值流优化的一个子集和一个切实的指导。
如果没有一个清晰的前进路径，如果对希望通过平台工程推动什么价值缺少共同的理解，那么就有可能产生不确定性和误解。然而，正是在将这些理念应用于活跃的组织时，许多人开始陷入挣扎。
组织，特别是大型企业公司，已经有了许多模式和流程，这使得进行任何变革都成为一项挑战。虽然团队拓扑和价值流优化等理念帮我们提供了一个变革的入口，但它们可能不足以确保变革执行过程完全正确。
InfoQ 采访了 Kersten，详细讨论了这个路线图理念和平台工程的未来。
Nigel Kersten：我几乎是从一开始就深入参与了 DevOps 运动。我看到，这个领域的活力和生产力令人难以置信，而且对中小型科技公司产生了巨大的影响，但我也观察到，通常，大型企业在尝试采用这些实践时没有得到同样的好处。
正是 DevOps 宽泛的定义造就了这个充满活力的社区，然而，同样是因为缺少明确的定义，当大多数企业开始尝试“做 DevOps”时，他们以 DevOps 的名义做了各种不同的事，其中大多数都失败了。我一直在和企业里设法实践 DevOps 的人交流，这可能是发布工程师、（重命名的）系统管理员和（按开发人员要求行事的）运维人员所做的任何事，在我看来，这都不是真正的“DevOps”，因为他们缺乏高效协作这个基本特征。
我担心，我们会在平台工程中看到同样的事情。如果满腔热忱的早期实践者社区不聚在一起，进一步明确通往成功的路径，那么我们终将重复之前的遭遇，这会非常遗憾。
请注意，我不认为像 SAFe 这样的模型是正确的方法，因为在这种模型中，角色和流程都高度具体，让人感觉非常僵硬，与敏捷截然相反。我认为，我们需要的是一个如何逐步采用平台工程方法的地图，而不是一个高度具体的最终目标。
Kersten：团队拓扑是目前为止最好的模型，Matt 和 Manuel 的出色工作让我感到敬畏，虽然正在使用 TT 模型的人大多数都声称已经读完了这本书，但我是不大相信的。那不仅仅是关于实现我们一开始介绍的各种团队，还涉及确保这些团队之间有恰当的交互模式与实践。
我看到，人们最常犯的两个错误是：一、不关注团队之间的互动；二、没有严肃地对平台产品负责人这样的角色进行投资。
坦率地说，如果整个企业领域都能接受团队拓扑关于“平台即产品”的相关工作，认真地遵循它，并相互学习如何推动那种变革，那么我们将处于一个非常有利的位置。
Kersten：最根本的问题是，所有这些转型都涉及大量的人员互动，组织规模越大、存在时间越长，要改变人员互动方式就越难，你必须从链条的上游推送组织变革。
我曾“Web 规模”的大型科技公司工作过，然后是中小型科技公司，再然后是在过去十年里，与许多非常传统的企业共事。令人惊讶的是，与科技公司相比，大多数企业的内部沟通都很糟糕。我已经记不清参加过多少次会议和小组讨论了，很明显，与我一起工作的团队以前从未真正地一起工作过。
最终的成功需要通过非常谨慎地设计实现团队之间的高效交互，尽可能减少中介，并重点关注系统生产者和消费者之间的反馈循环。我看到人们经常犯的一个错误是，在团队之间设定一个开放式的“协作”目标，导致了没完没了的会议和小组讨论，事实证明，当消费者数量超过生产者时（几乎在任何情况下都是如此），这会非常低效。
作为供其他人使用的系统的生产者，你绝对应该在设计阶段专注于有意义的协作，对于用户使用系统的体验，要确保自己可以直接从他们那里获得及时的反馈，但在规模比较大时，要想真正的高效，你就会希望专注于构建自助服务系统，让用户可以按自己的速度和节奏进行操作。
我坚信，大多数企业失败的原因是，他们试图通过项目管理而不是产品管理来实施这些计划。将内部用户群视为用户市场，将自己构建的解决方案视为面向这些用户的产品。这意味着你需要以适合他们的方式为他们解决问题，而不仅仅是提供“能力”，这意味着你需要随着时间的推移、问题的变化不断地解决它们，而问题总是会变化的！
Kersten：我发现，当你为拥有大型公有云组件的开发者构建平台时，有两种常见的失败模式。第一种是构建全新的接口，将底层的公有云服务完全抽象，这里的问题是，用户对这些服务几乎总是有一些了解，他们会因为你将它们隐藏起来而感到沮丧，而且没有你的帮助就无法自己解决新问题。
第二种则完全走另一个方向，简单地向所有用户公开所有的公有云服务，并简单地将身份管理和成本控制的所有权交给“平台团队”。开发团队都将针对相同的问题提出不同的解决方案，而安全性和合规性等领域的处理成本将越来越高。
要在这两种模式之间切换，你必须尽早找人担任产品经理，一个对平台有远见的人，就像其他产品一样。在产品管理中有句话是这样说的：“真相在大楼外”，这一点至关重要，从一开始就要记住。如果你的平台团队是由公司其他部门的基础设施运营人员组成的，而且没有和真正使用平台的人建立沟通渠道，那么你就不知道用户真正想要的是什么，你就无法为他们构建可以真正解决他们问题的解决方案。
最理想的情况是，团队成员既有具备基础设施运营经验的人，也有可以代表平台用户的人，而产品经理负责确定功能优先级及平衡竞争性需求，并致力于确保你可以从平台用户那里获得可靠的反馈。
如果这些你都有，就可以在我提到的两个失败点之间不断地进行路线修正。
Kersten：我们仍在整理最终报告，但数据中出现了一些非常有趣的观点。一般来说，现在的从业者对平台工程的看法比对 DevOps 要积极得多，而且更多的人看到了可度量的积极结果。看起来，平台工程有巨大的潜力，有望成为一种更容易采用的模型，让企业可以获得 DevOps 的好处。
但这可不是闹着玩的，绝大多数受访者都担心，他们的平台团队无法跟上产品团队消费平台的需求，抵制变化和沟通问题妨碍了许多人的工作。
我们还看到，产品经理的角色至关重要，几乎可以肯定，整个行业都人手不足，团队希望招聘具有更好沟通技能的人，并希望有人帮他们在整个组织内传播和设定切合实际的预期。
原文链接：
https://www.infoq.com/articles/platform-engineering-roadmap/
相关阅读：
声明：本文为 InfoQ 翻译，未经许可禁止转载。
点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！
从大前端“穿越”到终端，开发者应该必备什么技能？| 解读终端的 2022