改进组织平台工程实践的一个重要部分是评估应用程序平台。 应用程序平台包括用于支持组织中开发、部署和应用程序管理的所有工具和服务。
简化和标准化
基础结构即代码（IaC）和自动化工具可以与模板相结合，以标准化基础结构和应用程序部署。 若要减轻最终用户对平台细节的负担，可以通过将选项分解为相关的命名约定来抽象平台详细信息，例如：
- 资源类型类别（高计算、高内存）
- 资源大小类别（例如，小型、中型和大型 T 恤大小）
模板应表示已使用预设配置进行测试的一般要求，因此开发团队可以立即开始使用提供最少的参数，而无需查看选项。 然而，有时候团队需要更改已发布模板上的更多选项，这些选项超出了通常的可用或理想。 例如，批准的设计可能需要在受支持的模板默认值之外的特定配置。 在此实例中，运营或平台工程团队可以创建一次性配置，然后决定模板是否需要将这些更改合并为默认值。
可以使用具有偏移检测功能的 IaC 工具跟踪更改，这些功能可以自动修正偏移（GitOps）。 这些工具的示例包括 Terraform 和云原生 IaC 工具（例如 群集 API、 Crossplane、 Azure 服务操作员 v2）。 在 IaC 工具偏移检测之外，有一些云配置工具可以查询资源配置，例如 Azure Resource Graph。 这些可以带来两个好处：监视基础结构代码之外的更改，并查看已更改的预设配置。 为了避免过于僵化，也可以在部署中实现具有预定义限制的容差。 例如，可以使用 Azure Policy 来限制部署可以拥有的 Kubernetes 节点数。
自我管理还是托管？
在公有云中，可以选择使用软件即服务（Saas）、平台即服务（PaaS）或基础结构即服务（IaaS）。 若要了解有关 SaaS、PaaS 和 IaaS 的详细信息，请参阅培训模块 描述云服务类型。 PaaS 服务提供简化的开发体验，但其应用模型更具规范性。 归根结底，你需要在易用性和控制之间进行权衡并做出评估。
在平台设计期间，评估和确定组织的服务需求优先级。 例如，无论是直接在 Azure Kubernetes 服务 （AKS）上构建应用，还是通过 Azure 容器应用 构建应用取决于服务的要求以及内部容量和技能集。 对于 Azure Functions 或 Azure 应用服务等函数样式服务也是如此。 容器应用、Functions 和应用服务可降低复杂性，而 AKS 提供更大的灵活性和控制。 实验性的应用程序模型，如Radius OSS 孵化项目，尝试在两者之间取得平衡，但相比于那些拥有完全支持并在既定IaC格式中存在的云服务，这些项目通常处于较低的成熟度阶段。
规划期间发现的问题应有助于判断你在哪个刻度范围的端点更适合。 在做出决策时，请务必考虑自己的内部现有技能集。
共享资源与专用资源
组织中的资源可由多个应用程序共享，以提高利用率和成本效益。 每个共享资源都有自己的一组注意事项。 例如，这些是共享 Kubernetes 群集时的注意事项，但有些适用于其他类型的资源。
- 组织： 在组织边界内（而不是跨）共享群集等资源可以改进它们如何与组织方向、要求和优先级保持一致。
- 应用程序租户： 应用程序可以有不同的租户隔离要求;如果单个应用程序可以与其他应用程序共存，则需要查看单个应用程序安全性和法规合规性。 例如，在 Kubernetes 中，应用程序可以使用命名空间隔离。 但你还应考虑针对不同环境类型的应用程序租赁。 例如，最好避免将测试应用程序与同一群集上的生产应用程序混合，以避免由于配置错误或安全问题而产生意外影响。 或者，可以选择先测试和优化专用 Kubernetes 群集，以在共享群集上部署之前跟踪这些问题。 无论如何，方法中的一致性是避免混淆和错误的关键。
- 资源消耗： 了解每个应用程序的资源使用情况和备用容量，并执行预测来估计共享是否可行。 还应注意消耗的资源限制（数据中心容量或订阅限制）。 目标是避免由于共享环境中的资源约束而移动应用程序和依赖项，或者在容量耗尽时发生实时站点事件。使用资源限制、代表性测试、监视警报和报告来识别资源消耗，并防范消耗过多资源的应用程序。
- 优化共享配置： 共享资源（如共享群集）需要额外考虑和配置。 这些注意事项包括交叉收费、资源分配、权限管理、工作负荷所有权、数据共享、升级协调、工作负荷放置、建立、管理和迭代基线配置、容量管理和工作负荷放置。 共享资源有好处，但如果标准配置过于严格且不会演变，则它们会过时。
实施治理策略
治理是使用防护措施实现自助服务的关键部分，但以不影响应用程序业务价值的时间的方式应用合规性规则是一个共同的挑战。 治理有两个部分：
- 初始部署符合性（右开始）： 这可以通过通过目录提供的标准化 IaC 模板来实现，该模板具有权限管理和策略，以确保只能部署允许的资源和配置。
- 保持合规性（保持正确）： 基于策略的工具可以在发生资源更改时阻止或发出警报。 除了核心基础设施之外，还应考虑工具在 Kubernetes 等资源以及容器或虚拟机中使用的操作系统内支持合规性。 例如，你可能想要强制实施锁定的 OS 配置或安装安全软件工具，例如 Windows 组策略、SELinux、 AppArmor、 Azure Policy 或 Kyverno。 如果开发人员仅有权访问 IaC 存储库，则可以添加审批工作流来查看建议的更改，并阻止直接访问资源控制平面（如 Azure）。
维护合规性需要工具来访问、报告和处理问题。 例如， Azure Policy 可与许多 Azure 服务一起使用，用于审核、报告和修正。 它还具有不同的模式，例如 Audit、 Deny 和 DeployIfNotExists ，具体取决于你的需求。
虽然策略可以强制实施符合性，但它们也可能意外中断应用程序。 因此，请考虑在大规模操作时，采用策略即代码（PaC）实践。 PaC 是您的开好头并保持正确方法的关键组成部分，它提供：
- 集中管理的标准
- 策略的版本控制
- 自动测试和验证
- 缩短推出时间
- 持续部署
PaC 可以通过如下功能来帮助最小化不良策略的影响范围：
- 作为代码存储在已审核和批准的存储库中的策略定义
- 用于提供测试和验证的自动化
- 基于环的策略逐步推出和对现有资源的纠正措施有助于最大程度地减少潜在不良策略的影响范围
- 修复任务中内置了安全控制，例如：如果超过 90% 的部署失败，则会停止修复任务。
实现特定于角色的可观测性和日志记录
若要支持应用程序和基础结构，需要在整个堆栈中实现可观测性和日志记录。
每个角色的要求不同。 例如，平台工程和运营团队需要仪表板来查看具有适当警报的基础结构的运行状况和容量。 开发人员需要应用程序指标、日志和跟踪，以便对显示应用程序和基础结构运行状况的仪表板进行故障排除和自定义。 这两个角色可能遇到的一个问题是：要么由于信息过多而导致认知过载，要么由于缺少有用信息而存在知识差距。
若要解决这些挑战，请考虑以下事项：
- 标准： 应用日志记录标准，以便更轻松地创建和重用标准化仪表板，并通过 OpenTelemetry 可观测性框架等内容简化引入处理。
- 权限： 提供团队或应用程序级仪表板，使用 Grafana 之类的内容为任何感兴趣的人提供汇总数据，以及应用程序团队的受信任成员在需要时安全地访问日志的工具。
- 保留： 保留日志和指标可能很昂贵，并且可能会造成意外的风险或合规性违规。 建立保留默认值，并将其作为正确启动指南的一部分发布。
- 监视资源限制： 运营团队应能够识别和跟踪给定类型的资源的任何限制。 应使用 Azure Policy 等工具将这些限制纳入 IaC 模板或策略。 然后，操作应主动使用 Grafana 之类的监控面板进行监控，并扩展那些无法实现或启用自动扩展的共享资源。 例如，随着时间的推移和应用的上线与修改，监视 Kubernetes 集群节点的数量以评估容量。 需要警报，并且这些定义应存储为代码，以便以编程方式将其添加到资源。
- 确定关键容量和运行状况指标： 监视和警报操作系统和共享资源（例如 CPU、内存和存储）以防止资源匮乏，使用诸如 Prometheus 或 Azure Monitor 中的 Kubernetes 监控来进行指标收集。 可以监视正在使用的套接字/端口、聊天应用的网络带宽消耗以及群集上托管的有状态应用程序数。
使用最低特权、统一安全管理和威胁检测原则构建安全
代码、容器、群集和云/基础结构的每个层都需要安全性。 下面是建议的最低安全步骤：
- 遵循 最低特权原则。
- 跨多个管道统一 DevOps 安全管理。
- 确保上下文洞察力清晰可见，以识别和缓解最关键的风险。
- 支持在运行时检测和响应云工作负载中的新式威胁。
为了帮助解决此领域的问题，你需要工具来评估跨云和混合（例如 ，Microsoft Defender for Cloud）处理工程和应用程序系统、资源和服务的工具。 除了应用程序安全性之外，评估：
- 使用类似于 Microsoft Defender External Attack Surface Management（Defender EASM）的外部攻击面管理工具。
- 网络安全服务 - 使用 Azure 网络安全等方式保护应用程序和云工作负载免受基于网络的网络攻击。
- 使用安全信息和事件管理（SIEM）解决方案（如 Microsoft Sentinel）进行智能安全分析。
- 像 Microsoft Purview 一样，安全地治理、保护、可视化和管理您的数据资产方法。
- 扫描代码是否存在潜在的安全漏洞、检测机密、查看 GitHub 高级安全性和Azure DevOps 的 GitHub 高级安全性等依赖项的方法。
- 对您的软件供应链进行管理，尤其是容器的管理。 例如，应用 容器安全供应链框架。
权限要求可能因环境而异。 例如，在某些组织中，不允许单个团队访问生产资源，新应用程序在评审完成之前无法自动部署。 但是，开发和测试环境中可能允许自动资源和应用部署和对群集的访问进行故障排除。
管理对服务、应用程序、基础设施的身份访问在大规模情况下可能充满挑战。 标识提供者创建、维护和管理标识信息。 计划应包括应用程序和服务的身份验证服务，这些服务应与大规模基于角色的访问控制（RBAC）授权系统集成。 例如，可以使用 Microsoft Entra ID 大规模为 Azure 服务（例如 Azure Kubernetes 服务）提供身份验证和授权，而无需直接在每个单个群集上设置权限。
应用程序可能需要访问标识才能访问云资源（如存储）。 你需要查看要求并评估标识提供者如何以最安全的方式支持这一点。 例如，在 Azure Kubernetes 服务中，云本机应用可以利用与 Microsoft Entra ID 联合的工作负荷标识，以允许容器化工作负载进行身份验证。 此方法允许应用程序访问云资源，而无需在应用程序代码中进行机密交换。
通过识别工作负荷所有者和跟踪资源来降低成本
管理成本是平台工程的另一部分。 若要正确管理应用程序平台，需要一种方法来标识工作负荷所有者。 需要一种能够根据特定元数据集列出资源所有者的清单的方法。 例如，在 Azure 中，可以使用 AKS 标签、 Azure 资源管理器标记以及 Azure 部署环境中的 项目等概念将资源分组到不同的级别。 为实现这一点，所选的元数据在部署工作负载和资源时必须包含强制属性，例如使用 Azure Policy。 这有助于进行成本分配、解决方案资源映射和所有者。 请考虑运行常规报告来跟踪孤立资源。
除了跟踪之外，你可能还需要通过使用相同的元数据，借助成本管理系统（例如 Microsoft Cost Management），将成本分配给各个应用程序团队，以管理其资源使用情况。 虽然此方法跟踪应用程序团队预配的资源，但不包括共享资源（例如标识提供者、日志记录和指标存储以及网络带宽消耗）的成本。 对于共享资源，可以按单个团队平均分配运营成本，或者在存在非均匀消耗的情况下提供专用系统（例如日志存储）。 某些共享资源类型可能能够提供有关资源消耗的见解。 例如，Kubernetes 具有 OpenCost 或 Kubecost 等工具，可提供帮助。
还应查找成本分析工具，可在其中查看当前支出。 例如，在 Azure 门户中，存在成本警报和预算警报，可在达到预设阈值时跟踪组中资源的消耗情况并发送通知。
确定何时和何处投资
如果你有多个应用程序平台，则决定何时和何处投资改进来解决高成本或可观测性差等问题可能很棘手。 如果您是初次使用，Azure 体系结构中心有几种潜在的模式供您评估。 但除此之外，在开始规划要执行的作时，需要考虑以下几个问题：
| 问题 | 提示 |
|---|---|
| 是否要调整现有应用程序平台、开始全新或使用这些方法的组合？ | 即使你对现在拥有的东西感到满意或重新开始，你也想考虑如何随着时间的推移进行调整。 即时更改很少起作用。 您的应用平台是一个不断变化的目标。 理想系统随着时间的流逝而变化。 你希望将此想法和任何相关的迁移计划纳入你的前向设计。 |
| 如果你想改变你今天正在做的事情，你对哪些产品、服务或投资感到满意？ | 俗话说，“如果它没有损坏，不要修复它。不要在没有理由的情况下改变事情。 但是，如果你有任何本土解决方案，请考虑是否是时候转向现有产品，以节省长期维护。 例如，如果要运行自己的监视解决方案，是否要从运营团队中删除该负担并迁移到新的托管产品？ |
| 你会看到随时间而发生的最大变化在哪里？ 在你们组织的应用类型中，这些是否存在于所有（或大多数）通用的领域中？ | 对你或你的内部客户不满意且不太可能经常变更的领域，是一个很好的起点。 从长远来看，这些投资收益最大。 这也可以帮助你理清如何促进迁移到新解决方案。 例如，应用模型往往流畅，但日志分析工具往往具有更长的保质期。 您还可以在确认方向变更带来了预期回报的同时，专注于启动新项目和应用程序。 |
| 你是否在增值最高的领域投资自定义解决方案？ 你觉得独特的应用基础结构平台功能是竞争优势的一部分吗？ | 在进行任何自定义操作之前，如果你发现了差距，请考虑供应商最有可能投资的领域，然后将你的自定义思维专注于其他方面。 首先将自己视为集成商，而不是自定义应用基础结构或应用模型提供程序。 构建的任何内容都需要维护，从长远来看，这使前期投入相形见绌。 如果你感到迫切需要在一个领域定制开发解决方案，而你怀疑这些领域最终将由供应商长期支持或涵盖，请规划解决方案的逐步淘汰或长期支持。 内部客户通常对现成产品感到高兴，甚至有可能比定制产品更满意。 |
调整现有应用程序平台投资以进行优化可能是一种有效的启动方法。 进行更新时，请考虑从新应用程序开始，以简化试点想法，然后再进行任何类型的推出。通过 IaC 和应用程序模板化来考虑此更改。 投资自定义解决方案，以满足在高影响、高价值领域的独特需求。 否则，请尝试使用现成的解决方案。 与工程系统一样，专注于自动化预配、跟踪和部署，而不是假设有一条刚性路径来帮助管理随时间推移的更改。