方案 2 解决方案 - 任务关键型应用程序
在上一单元中，你完成了涉及 911 调度系统的高可用性的方案。 在本单元中，你将查看一种可能的解决方案以及其他一些需要考虑的事项。
查看时，应将所提供的解决方案与在上一单元中制定的解决方案进行比较。 通常情况下，任何问题都存在不止一种正确的解决方案，但总会有一些权衡取舍。 你的解决方案中的哪些事项与建议的事项不同？ 你的解决方案中是否存在需要重新考虑的内容？ 所提供的解决方案中是否有在你的解决方案中可得到更彻底的解决的内容？
部署选项和配置
对于处理方案，所进行的第一个选择通常是确定哪种 Azure SQL 部署选项可能最为适合。 如果仅考虑服务级别协议 (SLA)，则要求 SLA 为 99.995%，这只有 Azure SQL 数据库可以提供。 若要获取此 SLA，必须部署业务关键服务层并启用可用性区域。
另一组决策与如何在灾难中启用异地冗余并保持高可用性有关。 尽管异地复制和自动故障转移组在此处都可作为选项，但自动故障转移组将使客户能够在需要时进行故障转移，而无需更改任何连接字符串。 此设置可能有助于减少更新应用程序连接字符串的故障时间，因为这是不需要的。 你还可以配置监视查询来检查状态。 这样，如果出现问题，你甚至可以强制执行故障转移。
在此配置中，考虑主机托管所扮演的角色也很重要。 为保持高可用性，应用程序需尽可能接近数据库，毫无疑问也需要位于同一区域中。 你需要确保应用程序已部署在自动故障转移组的两个区域中，因此存在应用程序的冗余副本（如 Web 应用）。 如果发生故障转移，则可以使用 Azure 流量管理器将流量重新路由到次要区域中的应用程序。
DBA 和敏感数据
911 调度系统协调员对有关如何在保护敏感数据（如健康状况历史记录及其他个人信息）的同时允许 DBA 执行其作业表达了关注。
若要确保 DBA 无法看到存储在特定列中的敏感数据，且对包含敏感数据的表的所有访问受到监视，你可以使用一些 Azure SQL 技术。 使用 SQL 审核是监视访问的最佳做法，但 DBA 仍将能够看到数据。 使用数据分类对敏感数据进行分类将会有所帮助，因为敏感数据将被标记，且你可以使用 SQL 审核来对其进行跟踪。 但是，实现这些操作后，DBA 仍将能够看到敏感数据。 可以使用动态数据掩码来帮助屏蔽敏感数据，但仅使用权限阻止 db_owner 查看用户数据是不可能的。
如果数据库中存在高度敏感的数据，则可以使用 Always Encrypted 来安全地阻止 db_owners 来查看它。 你还可以使用角色分隔来管理 Always Encrypted 密钥，以使安全管理员无法访问数据库，且 DBA 不会以纯文本形式访问物理密钥。 通过将此策略与使用 SQL 审核进行监视结合使用，你甚至可以监视、屏蔽和跟踪具有 db_owner 权限的 DBA 对敏感数据的访问。
DBA 需要对敏感数据进行遮盖，但仍需要能够使用 Azure 门户和 SQL Server Management Studio 或 Azure Data Studio 对性能进行故障排除。 他们需要能够创建新的包含数据库用户，这些用户必须映射到 Microsoft Entra 主体。
一种解决方案是在每个实例上为 DBA 创建一个名为 SQL DBA 的 Microsoft Entra 组。 然后，将该组分配给 SQL Server 参与者的 Azure 基于角色的访问控制 (RBAC) 角色。 最后，可以将组设置为逻辑服务器上的 Microsoft Entra 管理员。