平台工程的一个重要主张及其工作方法

在上一篇文章 《Platform Engineering 平台工程 15 问》中，已经强调过，平台工程建设中，应该包含IDP（内部开发者平台），但是，它不仅仅是工具链或内部开发人员平台。

平台工程继承了 DevOps 运动的目标，通过打通Dev与Ops之间的隔阂，加快软件的价值交付，同时还需要：

• 通过提高工程师的体验，来减少工作流程中各角色之间的工作摩擦阻力。这些摩擦来自于DevOps早期对其简单粗暴的解释。即：就是让开发工程师了解并掌握所有运维技能，并使用自己不熟悉的工具完成大量的运维琐事。

• 通过提升 DevOps 工程实践与工作流程的一致性，从而保持只需较少的人力，即可进行IDP的建设与维护。

很多企业都加入了平台工程的行列，并成立了平台团队。Puppet 的《2023 年平台工程状态报告》显示，51% 的公司在过去三年中成立了平台团队。这些团队一般有以下章程：

• 确定其他职能部门的共同要求，并开发/利用集中管理的解决方案来满足这些要求。

• 为集中管理的解决方案提供管理和主题专业知识。

• 使开发人员能够使用集中管理的解决方案，提供自动化的自助服务方法和基本的防护措施。这可能需要利用更高级别的界面，如开发人员门户网站。

有了平台工程，开发人员就可以从操作底层解决方案的复杂性中抽身出来。他们可以专注于编写由主题专家团队和自助服务界面支持的代码。

Netflix 和阿迪达斯等首批采用者从其平台工程计划中获得了巨大收益。这是因为这两家公司都清楚地知道自己想要实现什么目标，并逆向制定了解决方案：Netflix 的目标是统一工程体验，而阿迪达斯则希望缩短开发人员启动项目并将其集成到基础设施中的时间。

一位团队分布于多个国家的组织说：对他们来说，所有地区的基础设施部署、应用程序开发和安全措施保持一致是重中之重。他们的解决方案是一个内部云原生平台，可供分布在各地的团队使用。另一位客户希望将开发人员从管理基础设施等端到端责任中解脱出来，因此成立了一个基础平台团队，以便轻松 "插入 "其他系统或应用程序。

从上面的例子中，可以看到，无论是减少开发人员的责任，还是创建一致的软件开发环境，公司制定明确目标至关重要。这一点是与原有的 DevOps 运动所不同的重要的主张。

原有的DevOps 运动并没有提出这一明确观点。

在确定目标之后，就可以采取快速、简单的解决方案来实现这些目标。

采用 "大处着眼、小处着手、逐步发展"的方法。从能够改善开发人员指标或解决开发人员生产率等问题的 MVP 或最小可行平台开始。随着时间的推移，可以为这个 MVP 添加功能，也可以创建另一个 MVP。

对个性化需求保持警惕。有时候，个性化需求是代表光明未来，而有时候，它则代表混乱杂序。个性化需求可能会分散平台工程团队的注意力。随着平台使用的时间越长，这种个性化需求可能成为发展的阻力和障碍。此类需求可以让提出该需求的团队自行解决和维护。而产品团队在这类支持性工具上投入大成本，还不如去做产品特性需求功能。

不要过分依赖于工具。有关平台工程的文献往往强调使用 "专业工具和平台"。虽然这可能很重要，但公司应该评估自己的目标，并确定使用现有最简单工具实现目标的最快方法。

并不是每家公司都立即需要内部开发人员门户或自助服务功能。解决方案可以很简单，只需建立一个集中式的 wiki 页面，收集那些开发人员需要花费大量时间搜索的最常见技术信息也是不错的起点。