Synapse 实现成功方法：执行操作就绪情况评审

生成 Azure Synapse Analytics 解决方案并准备好部署后，请务必确保该解决方案的操作就绪情况。 执行操作就绪情况评审对解决方案是否准备好为用户提供最佳服务进行评估。 在发布前投入时间和资源来评估操作就绪情况的组织的成功率要高得多。 同样重要的是，在部署后定期（可能每年）进行一次操作就绪情况评审，以确保不会偏移操作预期。

进程和重点区域

进程和重点区域包括服务操作目标、解决方案就绪情况、安全性、监视、高可用性 (HA) 和灾难恢复 (DR)。

服务操作目标

从客户的角度记录服务期望，并获取企业对这些服务期望的认同。 进行任何必要的修改，以满足服务的业务目标。

每个 Azure 服务的服务级别协议 (SLA) 因服务而异。 例如，Microsoft 保证每月有具体的正常运行时间百分比。 有关详细信息，请参阅 Azure Synapse Analytics 的 SLA。 确保这些 SLA 与你自己的业务 SLA 保持一致，并记录它们之间的任何差距。 同样重要的是，定义不同团队之间的任何操作级别协议 (OLA) 并确保它们与 SLA 保持一致。

解决方案就绪情况

请务必使用以下几点来评审解决方案就绪情况。

• 介绍整个解决方案体系结构，其中标注了不同组件的关键功能，以及它们如何相互交互。
• 记录解决方案的可伸缩性方面。 包括有关缩放所涉及的工作量以及它对业务的影响的特定详细信息。 考虑它是否可以响应用户活动的突然激增。 请记住，Azure Synapse 提供了以最少停机时间进行缩放的功能。
• 记录解决方案中的任何单一故障点，以及如何在发生此类故障时进行恢复。 包括此类故障对依赖服务的影响，以尽量减少影响。
• 记录解决方案的所有依赖服务及其影响。

安全性

数据安全和隐私不容协商。 Azure Synapse 实施多层安全体系结构，为数据提供端到端的保护。 使用以下几点评审安全就绪情况。

• 身份验证：确保尽可能使用 Microsoft Entra 身份验证。 如果使用非 Microsoft Entra 身份验证，请确保已建立强密码机制，并定期轮换密码。 有关详细信息，请参阅密码指南。 确保监视已到位，以检测与用户身份验证相关的可疑操作。 考虑使用 Azure 标识保护自动检测和修正基于标识的风险。
• 访问控制：确保按照最低特权原则实施适当的访问控制。 使用 Azure 服务提供的安全功能来增强解决方案的安全性。 例如，Azure Synapse 提供精细安全功能，包括行级安全性 (RLS)、列级安全性和动态数据掩码。 有关详细信息，请参阅 Azure Synapse Analytics 安全白皮书：访问控制。
• 威胁防护：确保设置适当的威胁检测机制，以阻止、检测和响应威胁。 Azure Synapse 提供 SQL 审核、SQL 威胁检测和漏洞评估，以审核、保护和监视数据库。 有关详细信息，请参阅 Azure Synapse Analytics 安全白皮书：威胁检测。

有关详细信息，请参阅 Azure Synapse Analytics 安全白皮书。

监视

设置并记录有关监视业务就绪情况的期望。 这些期望应描述：

• 如何监视整个用户体验，以及它是否包括对单用户体验的监视。
• 要监视的每个服务的特定指标。
• 如何以及谁通知用户体验不佳。
• 主动运行状况检查的详细信息。
• 任何自动执行操作以响应事件的机制，例如自动提交票证。

考虑使用 Azure Monitor 从 Azure 和本地环境中收集、分析遥测数据并对其采取操作。 Azure Monitor 通过在几秒钟内主动识别问题，帮助你最大程度地提高应用程序的性能和可用性。

列出解决方案中每个服务要监视的所有重要指标及其可接受的阈值。 例如，可以查看指标来监视专用 SQL 池。

请考虑使用 Azure 服务运行状况通知 Azure 服务事件和计划内维护。 这样，就可以采取操作来减少停机时间。 可以设置可自定义的云警报，并使用个性化仪表板分析运行状况问题、监视对云资源的影响、获取指导和支持，以及共享详细信息和更新。

最后，确保设置适当的通知，以在事件发生时通知合适的人员。 事件可能是主动的（例如当某个指标超过阈值时），也可能是被动的（例如某个组件或服务出现故障）。 有关详细信息，请参阅 Microsoft Azure 中的警报概述。

高可用性

为解决方案定义并记录恢复时间目标 (RTO) 和恢复点目标 (RPO)。 RTO 是用户可以在多长时间内使用该服务，而 RPO 是在发生故障转移时会出现多少数据丢失。

每个 Azure 服务都发布了一组关于服务的预期高可用性 (HA) 的准则和指标。 确保这些 HA 指标符合业务预期。 当它们不一致时，可能需要进行自定义以满足 HA 要求。 例如，Azure Synapse 专用 SQL 池支持具有自动还原点的 8 小时 RPO。 如果 RPO 不够，则可以使用适当的频率设置用户定义的还原点以满足 RPO 需求。 有关详细信息，请参阅在 Azure Synapse 专用 SQL 池中备份和还原。

灾难恢复

定义并记录灾难恢复 (DR) 方案的详细进程。 DR 方案可以包括故障转移进程、通信机制、升级进程、作战室设置等。 还要记录确定中断原因的进程以及从灾难中恢复所要采取的步骤。

使用 Azure 服务提供的内置 DR 机制来生成 DR 进程。 例如，Azure Synapse 每天对配对的数据中心执行一次 SQL 专用池的标准异地备份。 可以使用异地备份从主位置的灾难中恢复。 还可以设置 Azure Data Lake Storage (ADLS) 以将数据复制到相距数百英里的另一个 Azure 区域。 如果主位置发生灾难，则可以启动故障转移以将辅助存储位置转换为主存储位置。 有关详细信息，请参阅灾难恢复和存储帐户故障转移。

后续步骤

在“Azure Synapse 成功（设计）”系列的下一篇文章中，了解如何监视 Azure Synapse 解决方案。