平台工程给整个企业带来的价值是不容置疑的。Gartner 不仅将平台工程列为2023年十大技术趋势之一，还将其纳入其技术成熟度曲线，这为公司如何通过构建内部开发者平台(IDP)来改善开发者体验提供了强有力的指引。

更重要的是，平台工程社区正在迅速发展。从这也可以看出，这不仅仅是某个公司做出的决定。使用内部开发人员平台的开发人员获得了无可争议的优势，比如开发人员生产力的提升、更好的产品成果、更好的开发体验和更低的成本。

现在，人人都在云上开展工作，员工们也十分期望使用这样的工具平台，IDP已经成为一种保持竞争力的必需品，这极大地提高了开发者的生活质量。

不过，这也意味着人们的期望值变的极高。除非发明一款新的 Heroku(当然没有它的任何限制)，否则任何其它事情都可能被视为失败。

我认为至关重要的是，要加倍努力提高开发人员的生产力。但在开始之前，应该了解什么是不该做的：了解陷阱的所在，可以更容易地避开它们。我目睹了无数努力付之东流，也见证了平台工程的发展，以下是我在为 Salesforce 和其他公司创建 IDP 过程中得到的一些收获。

失败的平台工程模式

导致平台工程项目失败的情况有很多种，有一些会使项目还没成熟就陷入瘫痪。在创建 IDP 时，请注意下面这些错误的模式：

先把平台建好，他们一定会用的

这是一个很大的逻辑错误。你知道你在做什么吗？人们会因为你建了平台就一定使用它？你这是在给自己挖坑。

当然，新平台可能比问题百出的旧系统更好，但这并不意味着新系统是完美的，比如它可能浪费更多时间或者根本没法满足开发人员的某些需求。

在这种情况下，结果只会助长不满情绪。用户会抱怨你给他们带来的新问题，而不是抱怨旧问题。这不是一个好的预期效果。

更糟糕的是，这会造成一个“恶意遵从”的环境。人们会使用平台，因为他们被告知要这么做。但每当平台产出不了他们预期的结果时，他们便会责怪平台以及平台团队。平台成了很好的甩锅对象 。

这不仅会损害你的职业发展，还会让团队以后不愿接受新要求，也会给企业文化带来负面影响。

不过也不用过分担心，这有一个简单的解决方案：做一个好的、专业的产品经理，与客户拉近距离。不过，最好你在开始做这件事情之前就这样做。

在产品需求上，我们把精力放在我们认为的，而不是询问用户真正需要的功能上，将使我们陷入无法挽回的困境中。换句话说，提前了解各类典型用户的需求将使我们摆脱窘境。

记住，改善开发人员的体验是一个至关重要的目标。定期征求反馈意见，以便了解真实需求变化及改进建议。我们通过采用以用户为中心的产品管理方法，解决重要问题，进而提高产品使用率。

这是唯一正确的路径

构建 IDP 意味着为开发者构建黄金路径。但问题在于，一些潜在的黄金之路并不太经得起推敲。开发软件不存在“唯一正确的路径”， 如果你的 IDP 迫使人们接受不可行的做法，它就不会成功。

在某种程度上，对于“过度自信”的工具，开发人员都会拿一些你没有预料到的情况进行证伪——作为优秀的开发者，他们会非常认真的寻找解决方案，然后告诉你：“看吧，这个工具支撑不了我的工作。”

你的黄金路径需要考虑到人们偏离正轨的倾向——并有足够的适应性来匹配。例如，在不使用像 Kafka 这样的队列技术或像 Hadoop 这样开箱即用的分布式计算框架的情况下，IDP 仍然可以支撑。IDP 的架构应该允许多种集成方式，这样也方便以后进行扩展。平台的架构必须考虑到，开发人员会想自助加入你甚至没有听说过的未来技术。

讨人喜欢的平台

虽然“唯一正确路径”反模式会导致一定的失败，但反过来做，也可能导致失败——构建一个“讨人喜欢”的平台。毕竟，你永远不可能让每个人都满意，尝试这么做可能会让事情变得更糟。

并非每个功能需求都具有相同的权重。比如，你的一个团队想要使用一些尖端的实验技术。集成上述工具可能会让他们满意，但也可能导致平台的不稳定——这不是一个理想的平台特性。

在一些其他情况下，你过度吹嘘自己的能力，结果只能不可避免地让人失望。例如，你可能有许多使用不同技术栈的团队。如果你说“放心吧，你们所有的需求我都能够满足，不会有问题的。”这样你便把自己拖进了无限的痛苦折磨中。

记住，你的能力是有限的。更重要的是，要明白，你的团队精力越分散，产出的工作质量就会越受到影响。即使你有大量的资金和资源，你也无法支持所有可能的技术组合，更不用说做得让所有人都满意了！

与其试图取悦整个组织，不如从 MVP 开始，与愿意接受早期不成熟产品并持续提供反馈的灯塔团队紧密合作。通过帮助你指导改进和提高生产效率，你的灯塔项目能够在需求出现时及时完成开发。当然，你仍然需要在迭代过程中合理地划分优先级，在没有大量需求积压的情况下，这是很容易做到的。一旦产品稳定性达到一定程度，你便可以考虑向更多团队推广，最终推广到整个组织。

搭积木式的架构方式

你希望通过创建一个平台，帮助公司达到新的高度，但一定不能通过搭积木的方式，让平台充满不稳定技术。当你试图能为给公司带来蓬勃发展的产品和服务打下基础时，这样创建平台的方式是非常糟糕的。

为什么会有这样的事情发生？毕竟，没有哪个平台团队想制造混乱。但我确实已经无数次见到过这种情况了。

问题关键点往往在于，团队是如何构建平台的。许多团队试图将一系列尚处于生命周期早期的不成熟技术焊接在一起。即便你能跟上其中部分组件的迭代更新速度，但众多这样的组件聚合在一起的维护成本将呈指数级增长，最终让你无能为力。

尽早调整自己的策略，避免出现“搭积木”式的反模式。不要去做华而不实的事情，要勇于处理那些艰难的、基础的架构问题——从基本要素开始，才能提高你成功的几率。

我们在建造房子时，需要按照特定的顺序做事。首先，你要浇筑地基，然后建造框架和墙，最后添加门、窗和装饰。我在以前写的文章中也提到过，我们在考虑构建漂亮的 UI 或服务之前，首先要设计 IDP 的架构。

当然，我承认，这种策略可能不是最能打动人的，但按正确的顺序打好基础，未来会获得巨大回报。除了提高 IDP 的稳定性之外，构建一个坚实的基础还可以进一步满足其它任务需求，比如集成那些酷炫的技术。

“瑞士奶酪”平台

瑞士奶酪有很多优点。例如，它非常符合空气动力学，重量轻，而且非常美味。然而，就像积木架构一样，我们也要避免 IDP 中的“瑞士奶酪”问题。（译者注：瑞士奶酪理论提到，如果把很多片奶酪重叠放置在一起，在自然光线下，因为每片奶酪的孔洞位置不一，光线无法透过奶酪；而在极端情况下，孔洞刚好连成一条线，光便会透过去。此处作者想表达的是，平台每个层面都可能有漏洞，不安全因素就是光源，可能穿透平台。）

主要的原因在于，你并不总能找到漏洞的位置，有些漏洞比其他漏洞更致命。虽然你可能能够解决可用性等方面的缺陷，但安全性是完全不同的情况。

记住，只需要一个漏洞就能造成严重破坏。如果你的平台漏洞百出，就会大大增加泄露数据、暴露敏感客户信息的可能性，并将你的公司从行业领导者的位置拉下。

打造人人都满意的平台是一项崇高的追求。然而，如果你以牺牲安全为代价，那么一旦事情搞砸了，你最大的粉丝就会变成你最恶毒的诋毁者。

这里的解决方案很简单：从项目的第一天起，甚至在你开始第一天的编码之前，就把安全性作为优先事项考虑。

“瑞士奶酪”在系统工程中唯一有效的作用是，当你谈论风险分析和事故原因时，你需要在所有阶段都把安全放在首位。

致命的成本旋涡

这是一个大问题。许多团队创建的平台缺乏内在的成本控制机制，比如 AWS 配置配额。这种“全速前进，不用关心预算”的观念是行不通的。

这种反模式的缺点应该是显而易见的，但是很容易忽略它们的范围。每个平台工程师都知道超出他们的项目预算是不好的。但很少有人意识到成本超支可能对公司单位经济指标产生更广泛的影响。许多计算密集型公司在云计算上的花费比他们在办公室和工资上的花费加起来还要多。对于一家科技公司来说，糟糕的单位经济状况实际上会决定其是否能达到盈利预期。

不幸的是，这种思想上的忽视似乎是根深蒂固的。我曾在一些公司工作，在没有 CFO 批准的情况下，你不能为开发团队订购披萨，但任何一个员工都可以调用一个每天会启动数十万个实例的 API 节点!

让组织中的每个人都参与到有成本意识的 DevOps 中可能是一件不大可能的事。然而，作为一名平台架构师，你需要引导这项工作。

咨询你的 FinOps 联络人，让你的 DevOps 工作与公司的财务架构紧密结合。如果你不能控制底线，你的平台就注定要失败——不管你在早期获得了多少投资!

智能平台工程的关键要点

那么，成功的平台工程行为与失败的行为区别有哪些呢？回顾一下，你需要：

• 从产品经理的角度审视平台。

• 推销你的平台，但不要过度吹嘘。

• 将你的平台视为产品，并确定你的主要客户和利益相关方。

• 接受你不能重新创造 Heroku 或 AWS 的事实，除非你有数亿美元可以花。

• 了解并迭代 MVP，它将帮助您赢得下一轮投资。

当然，到目前为止列出的失败模式只是常见的一些情况。其他还有一些也会导致失败，如设计 IDP 时为了满足团队中声音最大的那部分需求而牺牲了一些边缘需求，以及仅仅为了抽象而牺牲了对底层技术的关键支撑，等等。然而，无论这些风险中哪一种被证明与你的情况最相关，在早期计划阶段获得对风险更广泛的认识都是朝着正确方向迈出的一步。

知道要避免什么，但也要知道要专注于什么。专注于那些让你的平台工程团队更有效率的事情。这样做将使成功和构建能够带来持久价值的东西变得更加容易。

作者介绍：

Aaron Erickson 是 Orgspace 的联合创始人兼首席执行官。在 Orgspace 之前，他在领导岗位上工作了 30 年，最近一次是在 New Relic 担任工程副总裁。在整个职业生涯中，他一直倡导构建更好的软件。他在 ThoughtWorks 工作了十年，在那里他通过快速和持续地交付应用推动了数字化转型。Aaron 现在旧金山生活和工作。

原文链接：

https://www.infoq.com/articles/platform-engineering-lessons-learned/

相关阅读：

平台工程应知应会

平台工程的 2023：助力云原生重构研发组织文化与组织架构

Puppet 2023 DevOps 现状报告：平台工程有助于提升开发效率