共用方式為


Synapse 實作成功方法:執行作業整備程度檢閱

注意

本文是根據設計成功實作 Azure Synapse系列文章的一部分。 如需系列概觀,請參閱根據設計成功實作 Azure 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 Identity Protection 以自動偵測及補救身分識別型風險。
  • 存取控制:確認適當的存取控制已就緒,並符合最低權限原則。 使用 Azure 服務所提供的安全性功能,強化解決方案的安全性。 例如,Azure Synapse 提供細微的安全性功能,包括資料列層級安全性 (RLS)、資料行層級安全性和動態資料遮罩。 如需詳細資訊,請參閱 Azure Synapse Analytics 安全性技術白皮書:存取控制
  • 威脅防護:確認適當的威脅偵測機制已就緒,以預防、偵測及回應威脅。 Azure Synapse 提供 SQL 稽核、SQL 威脅偵測和弱點評量,以進行資料庫的稽核、保護和監視。 如需詳細資訊,請參閱 Azure Synapse Analytics 安全性技術白皮書:威脅偵測

如需詳細資訊,請參閱 Azure Synapse Analytics 安全性技術白皮書

監視

設定並記下相關期望,以便監控企業整備程度。 這些期望應該描述:

  • 如何監視完整的使用者體驗,以及是否包含對單一使用者體驗的監視。
  • 要監視的每個服務的特定計量。
  • 發現使用者體驗不佳時該如何通知及向誰通知。
  • 主動式健康狀態檢查的詳細資料。
  • 任何已就緒的機制,其可自動執行動作以回應事件,例如自動引發票證。

請考慮使用 Azure 監視器來收集、分析及處理來自 Azure 和內部部署環境的遙測資料。 Azure 監視器可在幾秒內主動找出問題,協助您將應用程式的效能和可用性最大化。

列出解決方案中要針對每個服務監視的所有重要計量,以及其可接受閾值。 例如,您可以檢視計量來監視專用 SQL 集區。

請考慮使用 Azure 服務健康狀態,以獲得 Azure 服務事件和計劃性維護的通知。 如此一來,您可以採取行動來緩解停機時間問題。 您可以設定可自訂的雲端警示,並使用個人化儀表板來分析健康狀態問題、監視對雲端資源的影響、取得指引和支援,以及共用詳細資料和更新。

最後,請務必設定好適當的通知,以在事件發生時通知適當的人員。 事件可能是主動式事件 (例如特定計量超過閾值) 或回應式事件 (例如元件或服務失敗)。 如需詳細資訊,請參閱 Microsoft Azure 警示概觀

高可用性

定義並記下解決方案的「復原時間目標 (RTO)」和「復原點目標 (RPO)」。 RTO 是指服務可在多快時間內供使用者使用,而 RPO 則是指在容錯移轉時會發生多少資料遺失量。

每個 Azure 服務都會針對服務預期的高可用性 (HA) 發佈一組指導方針和計量。 請確認這些 HA 計量符合您的商務期望。 若有不一致,可能需要加以自訂才能符合您的 HA 需求。 例如,Azure Synapse 專用 SQL 集區支援八小時 RPO 與自動還原點。 如果該 RPO 不足,您可以使用適當頻率來設定使用者定義的還原點,以符合您的 RPO 需求。 如需詳細資訊,請參閱 Azure Synapse 專用 SQL 集區中的備份與還原

災害復原

定義並記下災害復原 (DR) 案例的詳細程序。 DR 案例可能包括容錯移轉程序、通訊機制、呈報流程、戰情中心設定及其他項目。 另請記下判斷中斷原因的程序,以及從災害中復原所採取的步驟。

使用 Azure 服務提供的內建 DR 機制來建置 DR 程序。 例如,Azure Synapse 會每天執行一次 SQL 專用集區的標準異地備份,並存放至配對的資料中心。 您可以使用異地備份從主要位置的災害中復原。 您也可以設定 Azure Data Lake Storage (ADLS),將資料複製到數百英哩以外的另一個 Azure 區域。 如果主要位置發生災害,您可以起始容錯移轉,將次要儲存位置轉換成主要儲存位置。 如需詳細資訊,請參閱災害復原與儲存體帳戶容錯移轉

下一步

在<根據設計成功實作 Azure Synapse>系列的下一篇文章中,了解如何監視您的 Azure Synapse Analytics 解決方案。