优化应用程序平台

了解要在平台工程 旅程中首先解决的问题后，你可能会发现需要解决应用程序平台的一些挑战。 本文提供了一些有关如何执行此操作的提示。 你将详细了解创建架构良好的应用程序平台时经常遗漏或被遗忘的方面。 具体而言，基础结构管理、安全性、成本管理、治理和可观测性。

决定投资时间和地点

如果目前有一个或多个应用程序平台，则决定何时何地投资解决已发现问题的改进可能比较棘手。 如果刚开始， Azure 体系结构中心 有几个潜在的模式可供你评估。 但除此之外，在开始计划要执行的操作时，需要考虑以下几个问题：

问题	技巧
是要调整现有应用程序平台、重新开始，还是结合使用这些方法？	即使你对现在拥有的东西感到满意或正在重新开始，你也需要考虑如何随着时间推移而适应变化。 闪光切割很少起作用。 无论如何，与工程系统一样，应用程序平台都是一个移动的目标。 你今天登陆的东西会随着时间的流逝而改变。 你需要将这种想法和任何相关的迁移计划纳入你的未来设计。 在 应用软件工程系统中 详细了解已涵盖的基础结构即代码 (IaC) 和模板化方法，以帮助管理新应用程序的一些此变体。
如果你想改变你现在正在做的事情，你喜欢哪些产品、服务或投资？	俗话说，“如果它没有坏，就不要修复它。不要在没有理由的情况下更改内容。 但是，如果你有任何本地解决方案，请考虑是否是时候转向现有产品，以节省长期维护。 例如，如果你正在操作自己的监视解决方案，是否要从运营团队中消除该负担并迁移到新的托管产品？
你认为随时间推移发生的变化最大在哪里？ 其中是否有所有 (或大多数) 组织应用类型共有的区域？	你或你的内部客户不满意且不太可能频繁更改的领域是很好的起点。 从长远来看，这些具有最大的投资回报。 这也可以帮助你解决如何帮助迁移到新解决方案。 例如，应用模型往往是动态的，但日志分析工具的保质期往往较长。 还可以专注于要启动的新项目/应用程序，同时确认方向更改具有所需的回报。
你是否在增值最高的领域投资自定义解决方案？ 你是否强烈认为独特的应用基础结构平台功能是你的竞争优势的一部分？	如果你已经确定了差距，在执行自定义操作之前，请考虑供应商最有可能投资的领域，并将你的自定义思维集中在别处。 首先，将自己视为集成商，而不是自定义应用基础结构或应用模型提供程序。 构建的任何内容都必须得到维护，从长远来看，这些成本与前期成本相形见绌。 如果你觉得迫切需要在某一领域自定义构建解决方案，你怀疑供应商将得到长期、计划日落或长期支持。 如果不是更) ，内部客户通常会像自定义产品一样满意地 (。

调整现有应用程序平台投资是一种很好的方法。 进行更新时，请考虑从新应用程序开始，以在任何类型的推出之前简化试点想法。通过 IaC 和应用程序模板化来考虑此更改。 为高影响力、高价值领域的独特需求投资自定义解决方案。 否则，请尝试使用现成的解决方案。 与工程系统一样，专注于自动预配、跟踪和部署，而不是采用一种刚性路径来帮助管理随时间推移的更改。

设计和体系结构注意事项

虽然可以使用多种潜在的应用程序平台模式，但下面是一些在设计过程中经常遗漏的一些常见问题。

基础结构管理

如 应用软件工程系统中所述，IaC 和自动化工具可与模板结合使用，以标准化基础结构和应用程序部署。 为了减轻最终用户对平台细节的负担，应通过将选项分解为相关的命名约定来抽象平台详细信息，例如：

• 资源类型类别 (高计算、高内存)
• 资源大小类别 (T 恤大小调整、小型中型和大型。)

目标应该是拥有表示已使用预设配置测试的一般要求的模板，以便开发团队可以立即开始提供最少的参数，而无需查看选项。 但是，在某些情况下，团队需要更改已发布模板上比可用或所需的更多选项。 例如，批准的设计可能需要支持模板默认值之外的特定配置。 在这种情况下，运营或平台工程团队可以创建一次性配置，然后决定模板是否需要将这些更改合并为默认值。

可以使用具有偏移检测功能的 IaC 工具跟踪更改，这些功能可以自动修正 gitOps) (偏移。 这些工具的示例包括 Terraform 和云原生 IaC 工具 (示例、 群集 API、 跨平面、 Azure 服务操作员 v2) 。 在 IaC 工具偏移之外，检测有云配置工具可以查询资源配置，例如 Azure Resource Graph。 这可以带来两个好处：监视基础结构代码之外的更改，并查看更改的预设配置。 为了避免过于僵化，还可以在部署中实现预定义限制的容差。 例如，可以使用 Azure Policy 来限制部署可以具有的 Kubernetes 节点数。

自我管理还是托管？

在公有云中，可以选择使用 SaaS、PaaS 或 IaaS。 若要详细了解 SaaS、PaaS 和 IaaS，请参阅培训模块 描述云概念。 PaaS 服务提供简化的开发体验，但其应用模型更规范。 最终，需要在易用性和控制之间进行权衡，你需要评估。

在平台设计期间，评估要提供或移动到的服务并确定其优先级。 例如，是直接在 Azure Kubernetes 服务 (AKS) 上生成应用，还是通过 Azure 容器应用 (ACA) 取决于对服务的要求以及内部容量和技能集。 函数样式的服务（如 Azure Functions 或 Azure 应用服务）也是如此。 ACA、Azure Functions和App 服务降低了复杂性，而 AKS 提供了更高的灵活性和控制力。 更多实验性应用模型（如 OSS Radius 孵化项目）试图在两者之间实现平衡，但通常处于成熟阶段，而不是提供完全支持且采用既定 IaC 格式的云服务。

计划时发现 的问题应有助于 评估此缩放的哪个端适合你。 在做出决定时，请务必考虑自己的内部现有技能集。

共享资源与专用资源

在资产中，有多个资源可以由多个应用程序共享，以提高利用率和成本效益。 每个可共享的资源都有其自己的一组注意事项。 例如，以下是共享 K8s 群集的注意事项，但有些注意事项适用于其他类型的资源：

• 组织： 在组织边界内（而不是跨组织边界）共享群集等资源可以改进它们与组织方向、要求、优先级等保持一致的方式。
• 应用程序租赁： 应用程序可以有不同的租户隔离要求;如果单个应用程序可以与其他应用程序共存，则需要查看其安全性和法规合规性。 例如，在 Kubernetes 中，应用程序可以使用命名空间隔离。 但你还应考虑不同环境类型的应用程序租户。 例如，通常最好避免将测试应用程序与同一群集上的生产应用程序混合使用，以避免由于配置错误或安全问题而导致的意外影响。 或者，可以选择先在专用 Kubernetes 群集上进行测试和优化，以在共享群集上进行部署之前跟踪这些问题。 无论如何，方法中的一致性是避免混淆和错误的关键。
• 资源消耗： 了解每个应用程序资源使用情况和备用容量，并执行预测来估计共享是否可行。 还应了解 (数据中心容量消耗的资源限制或订阅限制) 。 目标是避免由于共享环境中的资源限制而移动应用程序和依赖项，或者避免由于容量耗尽而发生实时站点事件。 使用资源限制，具有代表性的测试、监视警报和报告可以帮助识别资源消耗情况，并防止应用程序消耗过多的资源，从而可能影响其他应用程序。
• 优化共享配置： 共享资源（如共享群集）需要额外的考虑和配置。 这些注意事项包括交叉充电、资源分配、权限管理、工作负载所有权、数据共享、升级协调、工作负载放置、建立、管理和迭代基线配置、容量管理和工作负载放置。 共享资源有好处，但如果标准配置过于严格且不发展，则它们将过时。

其中一些问题由 PaaS 解决方案简化，但其中许多要点甚至适用于共享数据库之类的内容。 共享有上升和下边，因此你应该仔细考虑权衡。

有关本文的 Kubernetes 群集方面的详细信息，请参阅 Azure Kubernetes 服务 (AKS) 多租户文档。

治理

治理是启用具有防护栏的自助服务的关键部分，但以不影响应用程序实现业务价值的方式应用合规性规则是一个常见的挑战。 治理是一个广泛的主题，但如果这是你遇到的问题，请记住此空间的两个方面：

• 初始部署符合性 (从) 开始： 这可以通过通过目录提供的标准化 IaC 模板来实现，这些模板具有权限管理和策略，以确保仅可以部署允许的资源和配置。
• 保持合规性 (保持正确) ： 基于策略的工具可以在发生资源更改时阻止或发出警报。 除了核心基础结构之外，请考虑工具还支持资源（如 K8）以及容器或 VM 中使用的 OS 的合规性。 例如，你可能想要强制实施锁定的 OS 配置或安装安全软件工具，例如 Windows 组策略、SELinux、AppArmor、Azure Policy 或 Kyverno。 如果开发人员仅有权访问 IaC 存储库，则可以添加审批工作流来查看建议的更改，并阻止直接访问资源控制平面 (示例 Azure) 。

保持合规性需要工具来访问、报告和处理问题。 例如，Azure Policy可以与许多 Azure 服务一起使用，以便进行审核、报告和修正。 它还具有不同的模式，例如审核、拒绝和 DeployIfNotExists，具体取决于你的需求。

虽然策略可以强制实施合规性，但它们也可能意外中断应用程序。 因此，在大规模操作时，请考虑将策略演变为代码 (PaC) 做法。 作为正确 开始和保持正确 方法的关键部分，PaC 提供：

• 集中管理的标准
• 策略的版本控制
• 自动测试 & 验证
• 缩短推出时间
• 持续部署

PaC 有助于将潜在错误策略的爆炸半径降到最低，其功能如下：

• 作为代码存储在经过审查和批准的存储库中的策略定义。
• 用于提供测试和验证的自动化。
• 基于环的逐步推出策略 & 对现有资源进行修正，有助于最大程度地减少潜在错误策略的冲击半径。
• 修正任务内置了安全性，并具有控制措施，例如，如果超过 90% 的部署失败，则停止修正任务。

可观

若要支持应用程序和基础结构，需要跨整个堆栈的可观测性和日志记录，平台工程、运营和开发人员团队可以使用这些可观测性和日志记录来查看所发生的情况。

但是，要求因角色而异。 例如，平台工程和运营团队需要使用仪表板来查看具有适当警报的基础结构的运行状况和容量。 开发人员需要应用程序指标、日志和跟踪来对显示应用程序和基础结构运行状况的自定义仪表板进行故障排除和自定义。 其中任一角色可能遇到的一个问题是，由于信息过多或知识差距，认知过载，因为缺少有用的信息。

若要解决这些难题，请考虑以下事项：

• 标准： 应用日志记录标准，以便更轻松地创建和重用标准化仪表板，并通过 OpenTelemetry 可观测性框架等简化引入处理。
• 权限： 请考虑使用 Grafana 之类的内容来提供团队或应用程序级仪表板，以便为感兴趣的任何人提供汇总数据，并为应用程序团队的受信任成员提供一个工具，以便在需要时安全地访问日志。
• 保留： 保留日志和指标的成本可能很高，并且可能会产生意外的风险或违反合规性。 建立保留默认值，并将其作为入门指南的一部分发布。
• 监视资源限制： 运营团队应该能够识别和跟踪给定类型资源的任何限制。 如果可能，应将这些限制纳入使用 Azure Policy 等工具的 IaC 模板或策略中。 然后，操作应使用 Grafana 之类的仪表板主动监视，并扩展无法或无法启用自动缩放的共享资源。 例如，在应用随时间推移载入和修改时，监视 K8s 群集节点的容量数。 需要警报，这些定义应存储为代码，以便以编程方式将其添加到资源。
• 确定关键容量和运行状况指标： 监视 OS 和共享资源并发出警报 (示例：CPU、内存、存储) 使用 Prometheus 或 Azure Container Insights 等指标收集指标时出现不足。 可以监视正在使用的套接字/端口、聊天应用的网络带宽消耗，以及群集上托管的有状态应用程序的数量。

安全性

每个层（从代码、容器、群集和云/基础结构）都需要安全性。 每个组织都有自己的安全要求，但从较高层面讲，以下是平台需要考虑的一些事项：

• 遵循 最小特权原则。
• 跨多个管道统一 DevOps 安全管理。
• 确保可识别和修正最关键风险的上下文见解可见。
• 在运行时跨云工作负载启用对新式威胁的检测和响应。

为了帮助解决此领域的问题，你将需要工具来评估跨云和混合 (跨工程和应用程序系统、资源和服务工作的工具，例如，Microsoft Defender for Cloud) 。 除了应用程序安全性之外，还需要评估：

• 使用类似于 Microsoft Defender 外部攻击面管理 (Defender EASM) 进行外部攻击面管理。
• 网络安全服务 - 应用程序和云工作负载保护，通过 Azure 网络安全等功能防范基于网络的网络攻击。
• 智能安全分析 - (SIEM) 解决方案（如 Microsoft Sentinel）使用安全信息和事件管理
• 像 Microsoft Purview 一样安全地治理、保护、可视化和管理数据资产的方法
• 扫描代码中是否存在潜在安全漏洞、检测机密、查看依赖项（如 azure DevOpsGitHub Advanced Security和GitHub Advanced Security）的方法。
• 软件供应链的管理，尤其是容器 (管理，例如，应用 容器安全供应链框架) 。

权限要求可能因环境而异。 例如，在某些组织中，不允许单个团队访问生产资源，在评审完成之前，无法自动部署新应用程序。 但是，在开发和测试环境中，可能允许自动资源和应用部署，以及访问群集进行故障排除。

大规模管理对服务、应用程序和基础结构的标识访问可能具有挑战性。 你需要标识提供者创建、维护和管理标识信息，同时向应用程序和服务提供身份验证服务，并且这些服务可以与基于角色的访问控制授权系统集成，以便大规模身份验证和授权管理 (RBAC) 。 例如，可以使用 Azure RBAC 和 Microsoft Entra ID 为 Azure 服务（如 Azure Kubernetes 服务）大规模提供身份验证和授权，而无需直接在每个群集上设置权限。

应用程序可能需要访问标识才能访问存储等云资源。 你需要查看要求并评估标识提供者如何以最安全的方式支持此功能。 例如，在 AKS 中，云原生应用可以利用与 Microsoft Entra ID 联合的工作负载标识来允许容器化工作负载进行身份验证。 此方法允许应用程序访问云资源，而无需在应用程序代码中进行机密交换。

元数据 & 成本管理

成本是另一个问题，它可能会浮出水面，使平台工程工作浮出水面。 若要正确管理应用程序平台，需要一种方法来标识工作负载所有者。 你需要一种方法来获取映射到特定元数据集所有者的资源清单。 例如，在 Azure 中，可以使用 AKS 标签、Azure 资源管理器标记以及 Azure 部署环境中的项目等概念将资源分组到不同的级别。 为此，所选元数据必须包含必需属性， (部署工作负载和资源时使用Azure Policy) 之类的属性。 这有助于成本分摊、解决方案资源映射、所有者等。请考虑运行定期报告来跟踪孤立的资源。

除了跟踪之外，你可能需要将此相同的元数据与 Microsoft 成本管理等成本管理系统配合使用，将成本分配给单个应用程序团队的资源使用。 虽然此方法跟踪应用程序团队预配的资源，但它不涵盖共享资源（例如标识提供者、日志记录 & 指标存储以及网络带宽消耗）的成本。 对于共享资源，可以按单个团队平均划分运营成本，或者提供专用系统 (示例，记录存储) 消耗不一致的情况。 某些共享资源类型也许能够提供有关资源消耗情况的见解，例如 Kubernetes 具有 OpenCost 或 Kubecost 等工具，可以提供帮助。

还应查找成本分析工具，可在其中查看当前支出。 例如，在Azure 门户存在成本警报和预算警报，这些警报可以跟踪组中资源的消耗情况，并在达到预设阈值时发送通知。

设计开发人员自助服务基础