基线 Microsoft Foundry 聊天参考架构的登陆区访问、治理与运维

数据科学家和智能体开发者访问

与基线架构一样，本架构禁用对 Foundry 门户和其他基于浏览器体验的公共入站访问。基线架构部署一台跳板机，为各种工作负载角色使用的浏览器提供来自虚拟网络的源 IP 地址。

当工作负载连接到 Azure 登陆区（Azure landing zone）时，你的团队获得更多访问选项。与平台团队协作，看看能否在不管理和治理虚拟机（virtual machine，VM）的情况下，获得对各种基于浏览器的 Foundry 门户的专用访问。这种访问可能通过来自现有 ExpressRoute 或 VPN Gateway 连接的传递路由实现。

基于本机工作站的访问需要跨本地路由和 DNS 解析，平台团队可以帮助提供。把此要求纳入你的订阅配给请求。

提供对这些门户的本机工作站访问，比管理 VM 跳板机更能提高生产力并简化维护。

跳板机的作用

本架构中的跳板机为运营支持提供价值，而不是用于运行时目的或 AI 与机器学习开发。跳板机可以排查 DNS 和网络路由问题，因为它提供对原本无法从外部访问的组件的内部网络访问。

在基线架构中，Azure Bastion 访问由你管理的跳板机。

在本架构中，Azure Bastion 作为平台团队管理的共享区域资源部署在连接订阅中。为在本架构中展示该用例，Azure Bastion 位于连接订阅中，你的团队不部署它。

充当跳板机的 VM 必须符合组织对 VM 的要求。这些要求可能包括 Microsoft Entra ID 中的企业身份、特定基础映像和修补制度。

监控资源

Azure 登陆区平台把共享可观测性资源作为管理订阅的一部分提供。但是，我们建议你预配自己的监控资源，以便承担工作负载的所有权职责。此做法与基线架构一致。

你预配下列监控资源：

• Application Insights 作为你的团队的应用性能管理（application performance management，APM）服务。你在聊天 UI、Agent Service 和模型中配置此服务。
• Azure Monitor Logs 工作区作为来自工作负载拥有的 Azure 资源的全部日志和指标的统一汇聚点。

与基线架构类似，所有资源必须把 Azure 诊断日志发送到你的团队预配的 Azure Monitor Logs 工作区。此配置是资源的基础设施即代码（infrastructure as code，IaC）部署的一部分。你可能还需要把日志发送到中央 Azure Monitor Logs 工作区。在 Azure 登陆区中，该工作区通常位于管理订阅中。

平台团队可能有更多影响工作负载登陆区中资源的流程。例如，他们可能使用 DINE 策略配置诊断，并把日志发送到集中管理订阅。他们也可能通过策略应用 Azure Monitor 基线警报。确保你的实现不阻断这些额外的日志和警报流。

Azure Policy

基线架构建议使用一般策略来帮助治理工作负载。当你把本架构部署到工作负载登陆区时，不需要添加或移除额外策略。为帮助强制治理并增强此工作负载的安全性，继续把策略应用到你的订阅、资源组或资源。

预期工作负载登陆区订阅在你部署工作负载之前就已有现有策略。一些策略通过审计或阻止部署中的特定配置来帮助组织治理。

下列示例策略可能导致工作负载部署复杂化：

• 策略：机密［在 Key Vault 中］应具有指定的最长有效期。

复杂化：Foundry 可以把与知识和工具连接相关的机密存储在已连接的 Key Vault 中。这些机密没有由服务设置的到期日期。基线架构不使用这些类型的连接，但你可以扩展架构以支持它们。

• 策略：AI Search 服务应使用客户管理的密钥对静态数据加密。

复杂化：本架构不要求客户管理的密钥。但你可以扩展架构以支持它们。

• 策略：Foundry 模型不应为预览版。

复杂化：在开发期间，你可能使用一个预览模型，并预期在生产工作负载中启用智能体能力时它已正式发布。

平台团队可能应用 DINE 策略，以处理向工作负载登陆区订阅的自动部署。预先把平台发起的限制和变更纳入你的 IaC 模板并加以测试。如果平台团队使用的 Azure 策略与应用要求冲突，你可以协商解决方案。

随时间管理变更

在本架构中，平台提供的服务和运营充当外部依赖项。平台团队持续应用变更、接入登陆区并施加成本控制。平台团队可能不会优先处理单个工作负载。对这些依赖项的变更，例如防火墙修改，可能影响多个工作负载。

你必须以高效、及时的方式与平台团队沟通，以管理全部外部依赖项。事先测试变更很重要，以免它们对工作负载产生负面影响。

影响工作负载的平台变更

在本架构中，平台团队管理下列资源。对这些资源的变更可能影响工作负载的可靠性、安全性、运营和性能目标。在平台团队实施这些变更之前评估它们，以确定它们如何影响工作负载。

• Azure 策略：对 Azure 策略的变更可能影响工作负载资源及其依赖项。这些变更可能包括直接的策略更新，或把登陆区移动到新的管理组层次结构中。这些变更可能直到新部署发生时才被注意到，因此你必须彻底测试它们。

示例：某策略不再允许部署需要客户管理密钥加密的 Azure Cosmos DB 实例，而你的架构使用 Microsoft 管理的密钥加密。

• 防火墙规则：对防火墙规则的修改可能影响工作负载的虚拟网络，或影响广泛适用于全部流量的规则。这些修改可能导致流量被阻断，甚至静默的流程失败。这些潜在问题既适用于出站防火墙，也适用于由 Azure Virtual Network Manager 应用的 NSG 规则。

示例：到 Bing API 的流量被阻断，导致用于互联网依据数据的智能体工具调用失败。

• 中心网络中的路由：中心中路由的传递性质发生变化，如果工作负载依赖到其他虚拟网络的路由，可能影响工作负载功能。

示例：路由变更使 Foundry 智能体无法访问由另一个团队运营的向量存储，或使数据科学团队无法从工作站访问 Foundry 门户。

• Azure Bastion 主机：Azure Bastion 主机可用性或配置的变更。

示例：配置变更阻止对跳板机和构建代理 VM 的访问。

影响平台的工作负载变更

下列示例描述你应传达给平台团队的工作负载变更。在新变更生效之前，平台团队必须对照你的新变更验证平台服务的可靠性、安全性、运营和性能目标。

• 网络出站：监控网络出站的任何显著增加，以防止工作负载成为网络设备上的吵闹邻居。此问题可能影响其他工作负载的性能或可靠性目标。本架构大体上是自包含的，不太可能出现出站流量模式的显著变化。
• 公共访问：对工作负载组件公共访问的变更可能需要额外测试。平台团队可能把工作负载重新安置到不同的管理组。

示例：在本架构中，如果你从 Application Gateway 移除公共 IP 地址并使此应用仅限内部，工作负载对互联网的暴露就会改变。另一个示例是把基于浏览器的 AI 门户暴露到互联网，我们不建议这样做。

• 业务关键性评级：对工作负载服务级别协议（service-level agreements，SLAs）的变更可能需要平台团队和工作负载团队之间新的协作方式。

示例：由于采用增加和成功，你的工作负载可能从低业务关键性转变为高业务关键性。

• 数据主权：围绕数据主权的要求变更，可能需要平台团队改变其日志收集计划、对你的工作负载 Purview 集成的支持，或对组织安全信息和事件管理（security information and event management，SIEM）解决方案的支持。

示例：你的工作负载现在可能要求全部智能体线程数据留在地理边界内。如果 Foundry 连接到 Purview 或 SIEM，你需要确保用户数据不会被复制到违反监管要求的区域。

企业架构团队

一些组织有企业架构团队，可能影响你的工作负载及其架构的设计。该团队理解企业的 AI 采用战略，以及《Azure 上的 AI 工作负载设计》（AI workloads on Azure）中的原则和建议。与该团队协作，确保此聊天工作负载满足特定场景目标，并与组织战略和建议对齐。

考虑事项

这些考虑事项实施 Azure 良好架构框架（Azure Well-Architected Framework）的支柱。该框架是一组指导原则，可用于提高工作负载质量。更多信息请参阅《良好架构框架》（Well-Architected Framework）。

可靠性

可靠性帮助确保你的应用能够履行你对客户做出的承诺。更多信息请参阅《可靠性设计评审清单》（Design review checklist for Reliability）。

本架构维持基线架构中的可靠性保证。它不为核心工作负载组件引入新的可靠性考虑。

#### 关键依赖项

把工作负载在平台登陆区和工作负载登陆区中执行的全部功能视为依赖项。维护包含每个依赖项联系方式和升级路径的事件响应计划。把这些依赖项纳入工作负载的失效模式分析（failure mode analysis，FMA）。

考虑下列工作负载依赖项以及可能发生的示例场景：

• 出站防火墙：集中式出站防火墙经历与工作负载无关的变更。多个工作负载共享该防火墙。
• DNS 解析：本架构对大多数资源使用平台团队提供的 DNS，并结合 Azure DNS 和链接的 DNS Private Resolver 规则集用于 Agent Service。因此，工作负载依赖对专用终结点 DNS 记录的及时更新以及 DNS 服务的可用性。
• DINE 策略：针对 Azure 专用 DNS 区域或任何其他平台提供的依赖项的 DINE 策略以尽力而为方式运行，并且不包含 SLA。例如，本架构专用终结点的 DNS 配置延迟，可能阻止聊天 UI 达到可接收流量的状态，或阻止智能体完成 Agent Service 查询。
• 管理组策略：各环境之间一致的策略支持可靠性。确保预生产环境与生产环境匹配，以提供准确测试，并防止可能阻断部署或缩放的、特定于环境的偏差。更多信息请参阅《在 Azure 登陆区中管理应用开发环境》（Manage application development environments in Azure landing zones）。

这些考虑中有许多在没有 Azure 登陆区时也可能存在。你需要与平台团队协作处理这些问题，并确保满足全部要求。更多信息请参阅《识别依赖项》（Identify dependencies）。

安全性

安全性为抵御蓄意攻击以及防止宝贵数据和系统被滥用提供保证。更多信息请参阅《安全性设计评审清单》（Design review checklist for Security）。

#### 入站流量控制

为把你的工作负载与组织内的其他工作负载分支隔离，在子网上应用 NSG，并利用区域中心的非传递性质或控制。构建全面的 NSG，只允许你的应用及其基础设施所需的入站网络要求。不要仅依赖中心网络的非传递性质来保障安全。

平台团队实施用于安全的 Azure 策略。例如，某策略可能确保 Application Gateway 具有设置为拒绝模式的 Web 应用防火墙，从而限制你的订阅可用的公共 IP 地址数量。除这些策略外，部署更多以工作负载为中心的策略，以加强入站安全态势。

下表显示本架构中入站控制的示例。

#### 出站流量控制

应用表达解决方案所需出站连接要求的 NSG 规则，并拒绝其他一切。不要只依赖中心网络控制。作为工作负载操作员，你必须尽可能靠近来源阻止不需要的出站流量。

你拥有虚拟网络内工作负载的子网，但平台团队很可能在订阅配给过程中创建了专门表示你所采集要求的防火墙规则。确保架构生命周期内子网和资源放置的变更仍与你的原始请求兼容。与网络团队协作，确保持续的最小访问出站控制。

下表显示本架构中出站控制的示例。

对于离开工作负载虚拟网络的流量，本架构在工作负载级别通过 NSG 施加控制，在平台级别通过中心网络防火墙施加控制。NSG 提供初始的、宽泛的网络流量规则。在平台的中心，防火墙应用更具体的规则以增加安全性。

本架构不要求内部组件之间的东西向流量，例如 Agent Service 与其依赖的 AI Search 实例之间的流量，路由经过中心网络。

#### DDoS Protection

确定谁应应用覆盖你的解决方案公共 IP 地址的 DDoS Protection 计划。平台团队可能使用 IP 地址保护计划，或使用 Azure Policy 强制虚拟网络保护计划。本架构需要 DDoS Protection 覆盖，因为它有一个用于从互联网入站的公共 IP 地址。更多信息请参阅《网络与连接建议》（Recommendations for networking and connectivity）。

#### 身份和访问管理

除非平台团队的治理自动化要求额外控制，本架构不因平台团队的参与而引入新的授权要求。Azure 基于角色的访问控制（Azure role-based access control，Azure RBAC）应继续履行最小权限原则，只向需要的人、且只在需要时授予有限访问。更多信息请参阅《身份和访问管理建议》（Recommendations for identity and access management）。

#### 证书和加密

你的团队通常为 Application Gateway 上的公共 IP 地址采购 TLS 证书。与平台团队协作，理解证书采购和管理流程应如何与组织期望对齐。

本架构中的全部数据存储服务都支持 Microsoft 管理的或客户管理的加密密钥。如果工作负载设计或组织要求更多控制，使用客户管理的加密密钥。Azure 登陆区本身不强制特定方法。

#### Microsoft Defender for Cloud

使用与基线架构中讨论的相同的 Microsoft Defender for Cloud 配置。如果订阅配给流程没有自动启用这些 Defender 计划，确保你作为工作负载团队承担此职责。

#### Microsoft Purview

部署 Foundry 时，预期你将被要求使用 Microsoft Purview 的原生集成。部署期间，确保在 Microsoft Foundry 控制平面中启用 Microsoft Purview Data Security。请参阅《使用 Microsoft Purview 管理 Microsoft Foundry 的数据安全与合规》（Use Microsoft Purview to manage data security & compliance for Microsoft Foundry）。

成本优化

成本优化关注减少不必要开支并提高运营效率的方法。更多信息请参阅《成本优化设计评审清单》（Design review checklist for Cost Optimization）。

基线架构中的全部成本优化策略适用于本架构中的工作负载资源。使用 Azure 定价计算器中的此预配置估算来理解工作负载资源的成本。调整数值以匹配你的使用模式和区域定价。

本架构从 Azure 登陆区平台资源中获益很大。例如，Azure Firewall 和 DDoS Protection 等资源从工作负载资源转变为平台资源。即使你通过分摊计费模型使用这些资源，所增加的安全和跨本地连接也比自行管理这些资源更具成本效益。利用平台团队的其他集中产品，把这些好处扩展到你的工作负载，同时不损害其服务级别目标、恢复时间目标或恢复点目标。

注意

预配置的定价估算不包括共享平台基础设施，例如 Azure Firewall、Azure Bastion、DDoS Protection 或中心网络资源。平台团队在平台订阅中管理这些资源，成本在工作负载之间分摊。

重要

不要试图通过把 Foundry 依赖项合并为平台资源来优化成本。这些服务必须保持为工作负载资源。

卓越运营

卓越运营涵盖部署应用并使其在生产中持续运行的运营流程。更多信息请参阅《卓越运营设计评审清单》（Design review checklist for Operational Excellence）。

你仍然负责基线架构中的全部卓越运营考虑。这些职责包括监控、GenAIOps、质量保证和安全部署实践。

#### 关联来自多个汇聚点的数据

工作负载的 Azure Monitor Logs 工作区存储工作负载的日志和指标及其基础设施组件。但是，中央 Azure Monitor Logs 工作区常常存储来自集中服务的日志和指标，例如 Azure Firewall、DNS Private Resolver 和 Azure Bastion。关联来自多个汇聚点的数据可能是一项复杂任务。

关联数据有助于支持事件响应。本架构的分诊运行手册（runbook）应处理这种情况，并在问题超出工作负载资源时包含组织联系信息。工作负载管理员可能需要平台管理员的协助，以关联来自企业网络、安全或其他平台服务的日志条目。

重要

给平台团队：在可能时，授予 Azure RBAC 权限以查询和读取相关平台资源的日志汇聚点。为网络和应用规则评估以及 DNS 代理启用防火墙日志。应用团队可以使用此信息排查任务。更多信息请参阅《监控和威胁检测建议》（Recommendations for monitoring and threat detection）。

#### 构建代理

本架构中的许多服务使用专用终结点。与基线架构类似，此设计可能需要构建代理。你的团队安全、可靠地部署构建代理。平台团队不参与此过程。

确保构建代理管理符合组织标准。这些标准可能包括使用平台批准的操作系统映像、修补计划、合规报告和用户身份验证方法。

性能效率

性能效率指你的工作负载高效扩展以满足用户需求的能力。更多信息请参阅《性能效率设计评审清单》（Design review checklist for Performance Efficiency）。

基线架构中的性能效率考虑也适用于本架构。你的团队保留对应用流中资源的控制，而不是平台团队。根据工作负载和成本约束缩放聊天 UI 宿主、语言模型和其他组件。根据架构的最终实现，在对照性能目标衡量性能时考虑下列因素：

• 出站和跨本地延迟
• 来自成本控制治理的 SKU 限制

贡献者

Microsoft 维护本文。下列贡献者撰写了本文。

主要作者：

• Bilal Amjad | Microsoft Cloud Solution Architect
• Freddy Ayala | Microsoft Cloud Solution Architect
• Chad Kittel | Principal Software Engineer - Azure Patterns & Practices

PRIMARY_SOURCE: https://learn.microsoft.com/en-us/azure/architecture/ai-ml/architecture/baseline-microsoft-foundry-landing-zone