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