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

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

流程和重点区域

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

服务操作目标

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

每个 Azure 服务的服务级别协议 (SLA) 因服务而异。 例如，Azure 保证特定的每月运行时间百分比。 有关详细信息，请参阅 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 服务事件和计划内维护。 这样，你就可以采取措施来减少停机时间了。 可以设置可自定义的云警报，并使用个性化仪表板来分析运行状况问题、监视对云资源的影响、获得指导和支持，并共享详细信息和更新。

最后，确保设置适当的通知，以便在事件发生时通知相应人员。 事件可能是主动发生的，例如当某个指标超过阈值时，也可能是被动发生的，例如组件或服务的故障。 有关详细信息，请参阅 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 解决方案。