平台实现的核心方面
平台工程是一种多学科方法，它结合了软件工程、系统设计和卓越运营，目的是创建一个可靠且可缩放的基础结构，用于生成和部署应用程序。 其核心在于不仅要构建可靠的平台，还要创建一个自助服务环境，为开发团队提供支持，同时确保与业务目标保持一致。 要想平台工程计划成功，一开始就需要组建合适的团队并清楚地了解问题空间。 有了这个基础，就能开发那些简化运营、减少摩擦并使开发人员能够专注于生成应用程序而不是管理基础结构的系统。
一旦团队组建到位，就可以将重点转移到高劳动强度领域的自动化，确定可以自动化的手动重复性任务，以节省时间并减少错误。 在此之后，对现有资源进行盘存至关重要，这样团队就可以将工具和服务集中起来，使其更易于管理和缩放。 下一步称为“开辟铺好的路”，涉及创建标准工作流和环境，以确保项目间的一致性。 之后，将环境部署为服务有助于进一步简化流程，使团队能够根据需要快速启动环境。 此时，主要目标变成优化自助服务开发人员体验，使开发人员能够独立管理其工作流，同时确保其有成功所需的工具和支持。 此方法改变了开发团队与基础结构交互的方式，为生成和交付应用程序创建了一个敏捷、高性能的环境。
除了制定明确定义的实现计划外，不要将平台工程作为单一的、广义的概念来对待，不妨将其分解为四个主要领域以促进实现过程：
- 工程系统：包括支持开发的工具和服务，例如 CI/CD、包管理、基于云的编码环境、代码扫描程序和 Linter，以及人工智能 (AI) 助手，例如 GitHub Copilot。
- 应用程序平台：由用作常用应用堆栈的构建基块的特选服务（例如 Azure Policy、Azure Key Vault、Azure 容器应用或 Cosmos DB）组成。
- 应用程序模板：提供明确定义的、特定于组织的模板，目的是促进工作负荷预配并遵循最佳做法。
- 开发人员自助服务功能：使开发人员能够自主管理其工作流，同时确保治理和遵守组织标准。
将这些领域纳入实现策略可减少开发人员的辛劳，促进创新，产生无缝的开发体验。
构建团队
在平台工程组织中，培养正确的文化对于长期成功至关重要。 从被动文化转变为主动文化是关键，在此转变过程中，平台团队负责生成和维护工具来支持组织。 这种转变对于减少知识孤岛和运营中断至关重要。 平台工程工作的成功与平台工程功能模型中概述的投资功能相一致，该模型强调如何进入组织成熟度的各个阶段 — 从临时到优化。 在临时阶段，公司认识到平台工程的必要性，但在领导层和开发团队之间可能缺少密切协调。 随着组织的成熟，高管的支持和文化转变促生了一种更具协作性和创新性的环境，在这种环境中，平台团队有权推动有意义的变革，使组织能够有效地进行缩放。
平台工程团队需要多样化的专业技能和以产品为中心的思维来生成和缩放可靠、高效且安全的内部开发人员平台。 平台工程师需要精通几个关键领域，包括容器业务流程（例如 Kubernetes）、CI/CD 管道（例如 GitHub Actions、Azure Pipelines）和监视工具（例如 Azure Monitor、Prometheus、Grafana）。 掌握 Terraform 和 Bicep 等基础结构即代码 (IaC) 工具的专业知识对于实现基础结构预配自动化至关重要。 此外，平台工程师应该能够熟练使用 Python、PowerShell 或 Bash 之类的脚本语言来编写代码，以实现跨系统的自动化和集成。 虽然平台工程师的人才库很难挖掘，但一个成功的团队应该组合利用不同背景（例如软件开发、站点可靠性工程 (SRE) 和 IT 运营）的专业知识。
实现高劳动强度领域的自动化
实现高劳动强度领域的自动化通常代表着在实现开发人员自助服务功能的道路上铺好的第一条路。 若要实现它，首先要确定那些频繁执行的、容易出错的或属于劳动密集型的流程，特别是那些与手动操作或服务台操作相关的流程。 接下来，评估流程执行频率、复杂性和可审核性等因素，以确定自动化目标的优先顺序。 在持续交付 (CD) 管道中实现基础结构即代码 (IaC) 不仅可以简化应用程序部署，而且可以实现共享基础结构和工具的动态预配。 使用灵活的 CI/CD 平台（如 GitHub Actions 和 Azure DevOps）或 GitOps 解决方案（如 Flux 和 Argo CD）来减少瓶颈并增强团队能力。
随着时间的推移，采用“一切即代码”(EaC) 模式可以创建一个安全且可重复的自动化框架，使用集中式 Git 存储库来存储 IaC 模板和配置（包括 Bicep 和 Azure 资源管理器模板、Terraform 清单文件、Helm chart，等等）。 这些存储库由运营团队管理，使开发人员能够提交拉取请求，这些请求在合并之前会经过安全的评审和审核。 然后，相同的 CI/CD 工具可以预配和配置任何基础结构、工具或服务 — 不管是特定于应用程序的还是共享的。 此方法支持可伸缩性、开发人员自助服务以及与治理流程的无缝集成，确保平台工程与组织目标保持一致，同时提高运营敏捷性。
“一切皆代码”方法的中心要旨是将几乎任何资源或流程表示为安全 Git 存储库中的文件。 Git 的可靠安全功能（例如提交历史记录、访问控制、拉取请求和分支保护）可确保透明度、支持协作式评审并在集成所做的更改之前强制执行自动检查。 与 CI/CD 系统组合在一起使用时，这将创建一个用于管理基础结构、工具和流程的多功能的、可审核的、安全的框架。
库存和集中
随着组织的发展，其技术资产的数量和复杂性也随之增大，这常常导致重复工作、孤立项目和资源浪费。 进行库存集中和资产跟踪是平台工程应对这些挑战的关键一步。 库存系统允许团队跟踪和管理代码、API、容器、虚拟机 (VM)、权限等资产。 此流程不仅改善了治理，还促进了重用并增强了可发现性，使团队能够更高效地运作。
集中的库存通过标记和组织资产在改善治理方面发挥着至关重要的作用。 适当的标记可确保资源与各自的所有者或团队相关联，从而使用户更容易管理生命周期并了解所做更改的潜在影响。 增强的可发现性是另一个主要好处，因为它通过帮助团队查找和重用现有资源来减少技术性蔓延，避免不必要的重复工作。 此外，进行库存集中有助于组织识别和清理过时的或不必要的资产，从而优化资源，减少浪费并进一步节省成本。
各种工具支持库存和资产跟踪，每个工具都迎合了技术生态系统的不同方面。 例如，Azure 部署环境 (ADE) 提供了一种跟踪通过基础结构即代码 (IaC) 创建的复杂基础结构的方法。 同样，Azure API 中心使开发人员能够有效地发现和管理 API。 GitHub Packages 或 Azure Artifacts 之类的包注册表通过改善供应链安全性和管理已批准的包和 SDK 提供了额外的价值。
为了进一步增强库存系统的优势，组织可以建立资产之间的关系链接，以创建其生态系统的更全面的视图。 例如，映射 API 定义、其代码存储库、关联的环境和治理策略之间的关系可以使团队更精确地管理资源。
开辟铺好的路
在平台工程中，“铺好的路”比喻传达了在促进创新与提供标准化指导之间达成平衡的意思。 最初，团队可能会采取多种非正式的途径来实现其目标，尝试不同的工具和工作流。 随着时间的推移，平台团队会观察到最有效且最广泛采用的方法，并将其转化为“铺好的路”，即高效的、用户友好的且引人注目的优化工作流，以吸引团队采用。
此过程通常被描述为“开辟铺好的路”，涉及识别团队工作流中的常见模式并将其转换为标准化的可缩放解决方案。 这些路无缝集成安全性、体系结构最佳做法和合规性要求，提供流畅且可靠的体验。 开发人员受益于降低的认知负荷、用于集成的一致 API、可以根据需要进行组合的模块化功能以及符合运营目标的可预测性能。
平台工程功能模型在此过程中发挥着关键作用，帮助组织确定何时从非正式道路过渡到铺好的路。 它确定了需要标准化的领域，并提供了有关如何有效地将这些做法规模化的见解。 这种结构化方法可确保创新不会受到压制，同时还能重点关注质量、合规性和性能。
“开辟铺好的路”方法鼓励良好的做法，但不会规范过头。 它支持社区参与，使团队能够协作，能够塑造平台，同时保留独特用例所需的灵活性。 通过平衡创新和标准化，该方法营造了一种能够让团队脱颖而出的环境，同时确保始终满足组织要求。
将环境部署为服务
将环境部署为服务旨在实现安全的、标准化的和自动化的基础结构预配。 这种方法的一个关键原则是以一种阻止开发人员直接访问的方式持久保存预配标识和机密。 这可以强制实施治理，同时确保基础结构更新始终安全。 例如，Azure 部署环境 (ADE) 通过支持角色分离和集中管理 IaC 模板对此模型进行了举例说明。
使用 ADE，平台工程师和运营团队可以协作生成和维护针对特定环境类型的模板的目录。 这些模板使用预配置的设置进行了扩充，集成了托管标识，并可根据角色控制访问权限。 然后，开发人员可以使用 CI/CD 管道通过 Azure CLI 或 Azure Developer CLI 之类的工具预配基础结构，而无需直接访问敏感凭据或基础订阅。 这种分离确保了合规性和安全性，同时保持了开发人员的工作效率。
即使不使用 ADE，相同的原则也可更广泛地应用，基础结构即代码 (IaC) 内容源自安全的、不可变的位置，机密管理实现自动化和隔离。 通过启用这些做法，平台工程使团队能够部署一致的环境，同时保持组织治理和运营效率。
优化自助服务开发人员体验
无缝的自助服务开发人员体验对于平台工程的成功至关重要，但实现它通常需要在用户所在的地方与其会面。 每个角色（开发人员、运营人员和其他人员）都倾向于使用定义其工作流的特定工具和环境。 为了让新的体验获得采用，必须与这些现有的“重心”保持一致。 务实的方法涉及的操作包括：规划适合已使用的工具的多个用户界面，允许团队从简单的增强功能着手，证明其价值，再视需求将其发展到更复杂的解决方案。
不要创造全新的体验，而应考虑增强和集成现有工具。 编辑器、集成开发环境 (IDE)、DevOps 套件、CLI 工具和低代码环境等平台通常有扩展性模型，这些模型允许以最小的开销进行自定义和扩展。 这种方法减少了维护，应用了熟悉的用户体验，加快了采用速度。 例如，基于 Web 的 IDE 扩展（例如为 VS Code 或 vscode.dev 生成的扩展）提供了一个灵活的、与 Web 兼容的起点，该起点可以扩展到本地开发环境。 类似地，Microsoft Teams 或 Slack 之类的工具中的 ChatOps 界面提供了直观的方式来触发自动化工作流并与 CI/CD 平台集成。
对于需要集中式界面的组织，投资自定义开发人员门户可以带来长期利益，但需要仔细的规划，并且需要资源。 诸如 Backstage.io（Spotify 最初开发的工具包）之类的解决方案提供高度可自定义的门户，这些门户可以集成插件和第三方工具，从而创建一个以开发人员为中心的动态中心。 无论你是从 Power Pages 之类的轻量级解决方案着手，还是构建综合门户，目标都是提供可缩放的、用户友好的体验，这些体验为开发人员提供支持，同时满足组织需求。