开发平台工程中的有效接口涉及从自定义、手动流程过渡到简化预配和服务请求的标准化和一致解决方案。 本文探讨接口开发的各个阶段，重点介绍设置开发环境和诊断应用程序行为。
自定义进程
存在不同进程的集合来预配不同的功能和服务，但不会考虑接口的一致性。 自定义定制流程可满足个人或团队的即时需求，并且依赖于手动干预，即使提供商使用一些自动化实现脚本也是如此。
了解如何请求这些解决方案的人与人共享。 请求服务的过程缺乏标准化和一致性。 预配和使用平台服务可能需要功能提供程序的深度支持。
当公司尚未确定并记录预期时，缺乏中心要求和标准会使这一级别变得合适。 对于早期公司或平台工作的团队来说，它特别有效。 在这些环境中，团队可以自由地根据自己的需求发展流程和功能，以便他们更快地交付并支付标准化价格，前提是稍后需要。
设置开发环境：各个工程师通过向同事询问、查找文档以及遵循自己的已知做法来组合设置环境所需的步骤。
诊断应用程序行为：工程师选择自己的工具和过程来诊断行为。 他们负责采取措施访问应用程序和日志。
本地标准
工程师和工程团队主动但非正式地定义不同功能和服务的标准，以提高组织内可进行的知识共享量。 非正式支持社区围绕这些标准而涌现，但这依赖于个人和个人团队的资源和承诺。
设置开发环境：各个团队定义自己的工具和流程，并尝试确保团队内的工程师坚持这些流程。 可能通过文档或容器，但如何选择文档工具和流程由团队驱动。
诊断应用程序行为：各个团队定义自己的诊断行为做法和流程。 Teams 依赖于 devops/IT 团队来访问已部署的资源。
预配和观察平台和功能的一致标准接口存在并满足广泛的需求。 用户能够识别哪些功能可用，并启用这些功能来请求所需的功能。
提供了铺路或黄金路径，以文档和模板的形式提供。 这些资源定义如何使用合规和测试的模式预配和管理典型功能。 虽然某些用户能够自行使用这些解决方案，但这些解决方案通常仍需要深入的域专业知识，因此维护人员的支持仍然至关重要。
中心团队需要大量管理才能维护模板/文档，尤其是应对团队不断变化的需求。
设置开发环境：通过文档或模板在组织中定义所需工具和流程的常见路径进行一些投资。 团队可以在修改模板时偏离标准，但不能/不能合并回集中式团队。
诊断应用程序行为：为访问和诊断已部署的资源定义的标准做法。
自助服务解决方案
解决方案以向用户提供自治的方式提供，需要维护人员很少支持。 组织鼓励和启用解决方案提供一致的界面，使用户体验的可发现性和可移植性从一种功能到另一种功能。 虽然自助服务，但解决方案确实需要团队意识和实现。 为了改进此体验，可能有一种引导和简化的内部语言，使用户能够更快地采用和集成平台功能。 这会生成以用户为中心的、可自助且一致的功能集合。
设置开发环境：工程团队依赖于平台来设置开发环境。 存在可发现可用资源。 工程团队专门采用平台进行所有交互。 该平台通过发现和修改新模板和现有模板来帮助知识共享，不断增加平台提供的价值。
诊断应用程序行为：用于观察通过平台按需提供的资源/功能的工具和服务。 平台提供诊断和观察资源/功能的功能。
集成服务
平台功能以透明方式集成到团队用于完成其工作的工具和流程中。 自动预配某些功能，例如已部署服务的可观测性或标识管理。 当用户触碰所提供的服务的边缘时，有机会移动自动化解决方案并根据需要进行自定义，而无需离开内部产品/服务，因为平台功能被视为构建基块。 这些构建基块用于生成透明和自动组合，以满足更高级别的用例，同时在必要时启用更深入的自定义。
内部平台团队可以确定哪些功能适用于组织，并可以使用此知识来确定要投资哪些领域来进一步改进平台。
可以通过多种方式扩展和打包功能，从而提供预配、管理和观察资源和功能的最大灵活性。
设置开发环境：平台功能集成到团队已用于完成其工作的工具和流程中。 可以通过 CLI、IDE 等使用。
诊断应用程序行为：平台为每个已部署的应用程序自动设置可观测性功能。 平台提供与诊断数据和已部署应用程序交互的负担。