译自 9 Steps to Platform Engineering Hell 。这就是平台工程反模式。

平台工程若做得当，可大幅提升开发效率和工程速度;若做得不当，则可能让你陷入困境。

如果你从事DevOps和云原生工作，你可能已经听说平台工程是一门新学科，承诺能弥补DevOps在企业云原生环境下的不足。你可能也知道它专注于构建内部开发者平台(IDP)，实现开发者自助服务，减轻运维团队压力。你的DevOps朋友告诉你这是最热的新事物，如果你把职称改为平台工程师，薪水可能会增加20%。

然而，平台工程若做得当，可极大提升开发效率和工程速度;但若做得不当，也可能让你陷入新的困境。令人惊讶的是，许多工程团队正在盲目全速冲向这种新的困境。以下就是踏进平台工程地狱的九个步骤。

第一步：团队改名为平台团队，但仍在按照工单工作

市场营销终于说动了你的组织。管理层看到平台工程出现在Gartner的热门技术周期中，决定建立平台工程团队和IDP。热情还在，但不幸的是，团队组成没有太大变化，仍被大量任务和Slack信息淹没。他们没有时间构建精心设计的平台，而是仍然仅仅试图求生存。

第二步：没有从“平台即产品”的角度转变思维

平台团队仍保持DevOps思维，继续为各产品团队编写流水线和自动化。他们收到太多开发者请求，没有时间或资源退而制定长期策略，构建可扩展的IDP并将其交付给整个工程组织。

第三步：你的平台团队为运维构建平台，而非开发者所需

更多平台工程师终于加入团队，个个运维经验丰富，从业多年。他们聚在一起，认真思考职业生涯中遇到的最大运维难题。于是启动设计一个平台，来解决多年来困扰他们的种种烦人问题。但开发者永远不会使用这个平台，因为它没有解决开发者痛点，仅仅解决了运维问题。此时，平台工程项目已烧掉400万美元，采用率仍为零。

第四步：你无缘无故用新技术替换旧技术

更多平台工程师加入团队，个个渴望利用CNCF新景观中的最新技术。他们想用GitHub Actions替换Jenkins，用Kubernetes替换所有虚拟机，引入Terraform，后来又用Crossplane取而代之。与此同时，成本持续上涨，生产力继续下滑。

第五步：你认为自己的设置与众不同

因为每个团队和组织都有独特需求，自定义工作流无处不在。这反过来需要更多自定义集成。也就是说，一分钟前你还在为一家普通线上运动鞋店运行简单设置，下一分钟就部署到高度定制的自管理混合Kubernetes环境。

第六步：你构建开发者从未要求的门户

平台团队有人听说开发者自助服务和门户是最热门话题，所以决定在现有基础设施混乱上加搭一个门户网站，却从未询问过开发者。平台团队对“建立就会被使用”的老派思维已不再奏效感到惊讶。此时，已烧掉800万美元，采用率仍为零，生产力直线下降。

第七步：各处出现新的平台工程孤岛

因为你是大型低效沟通的企业，中层管理启动多个平台工程项目但互不协调。高层不介入，工作量加倍，沟通变得更糟。结果，你为五个团队构建了五个平台，大多一个也不work。采用率？没错，仍为零。而且，现在已烧掉1500万美元。恭喜!

第八步：你试图掩盖沉没成本

副总裁、业务领导和部门主管对大量沉没成本和无处可逃感到紧张。没有人敢说出真相：此时大部分平台需重新构建。它不可扩展，也不work。

公司落后竞争对手，但报表上一切看似仍好。这得益于管理者编造自己的指标来美化平台表现。此时，少数称职的平台工程师已离开公司。

第九步：你被解雇

那么最终将如何收场呢？不会好看，我们可以肯定。也许你被解雇，或者公司慢性衰亡直至死亡。或许会被竞争对手收购。谁知道呢？我们确知这些选项都不是好的结局。

听起来够糟糕了吗？

遗憾的是，我们已经看到太多企业走上这条路。你甚至可能认出自己的团队正在危险地向哪一步迈进。好消息是，事情不必如此发展。永远从一个地狱跌入另一个地狱，不必是你的命运。

那么，如何避免这种情况呢？很简单。加入平台工程社区，从超过16000名从业者的错误和最佳实践中学习。将你的平台打造成产品，倾听开发者心声。遵循 Humanitec 的参考架构，在 AWS、GCP 或 Azure 上构建企业级 IDP。