共用方式為


更新多租使用者解決方案的考慮

雲端技術的優點之一是持續改善和演進。 身為服務提供者,您必須將更新套用至解決方案:您可能需要變更應用程式程式代碼、Azure 基礎結構、資料庫架構或任何其他元件。 請務必規劃如何更新環境。 在多租用戶解決方案中,請務必特別清楚您的更新原則,因為某些租使用者可能不願意允許變更其環境,或者他們可能有限制您可以更新其服務條件的需求。

規劃更新解決方案的策略時,您需要:

  • 識別租使用者的需求。
  • 釐清您自己的服務運作需求。
  • 尋找您和租使用者都可以接受的餘額。
  • 將策略清楚傳達給租使用者和其他項目關係人。

在本文中,我們會提供技術決策者的指引,說明您可以考慮更新租用戶軟體的方法,以及相關的取捨。

您的客戶需求

客戶通常會有明確或隱含的需求,可能會影響系統更新的方式。 請考慮下列層面,以建立客戶可能引發之任何關注點的圖片:

  • 期望和需求: 找出客戶在解決方案更新時可能擁有的任何期望或需求。 這些合約或服務等級協定可能會正式傳達給貴使用者,或者這些合約可能是非正式的。
  • 維護時段: 瞭解您的客戶是否預期服務定義,甚至是自我定義的維護時段。 他們可能需要與用戶溝通任何潛在的中斷,或者可能需要在更新完成之後測試服務的重要層面。
  • 法規: 釐清客戶是否有任何需要額外核准才能套用更新的法規考慮。 例如,如果您提供包含IoT元件的健康解決方案,您可能需要在套用更新之前,先從美國食品和藥物管理局(FDA)取得核准。
  • 敏感度: 瞭解您的任何客戶是否特別敏感或抗拒套用更新。 如果是,請嘗試瞭解原因。 例如,如果他們執行實體商店或零售網站,他們可能會想要避免在黑色星期五前後更新,因為風險高於潛在利益。
  • 歷程記錄: 檢閱您自己成功完成更新的追蹤記錄,而不會對您的客戶造成任何影響。 您應該遵循良好的 DevOps、測試、部署和監視做法,以減少中斷的可能性,並確保您快速找出更新導入的任何問題。 如果您的客戶知道您能夠順暢地更新其環境,則不太可能進行物件。
  • 復原: 考慮客戶是否想要在發生重大變更時回復更新,以及誰會觸發這類回復要求。

您的需求

您也需要從自己的觀點考慮下列問題:

  • 控制您願意提供: 客戶是否合理控制套用更新的時間? 如果您要建置大型企業客戶所使用的解決方案,答案可能是是的。 不過,如果您要建置以取用者為主的解決方案,您不太可能控制升級或操作解決方案的方式。
  • 版本: 您一次可以合理維護多少個解決方案版本? 請記住,如果您發現 Bug 並需要加以 Hotfix,您可能需要將 Hotfix 套用至使用中的所有版本。
  • 舊版的後果: 讓客戶落後於目前版本的影響為何? 如果您定期發行新功能,舊版會很快過時嗎? 此外,視您的升級策略和變更類型而定,您可能需要為解決方案的每個版本維護個別的基礎結構。 因此,當您維護舊版的支援時,可能會有營運和財務成本。
  • 復原: 您的部署策略可支持復原至舊版嗎? 這是您想要啟用的嗎?

注意

請考慮您是否需要讓解決方案離線進行更新或維護。 一般而言,中斷時段被視為過時的做法,而新式 DevOps 做法和雲端技術可讓您避免在更新和維護期間停機。 不過,您需要針對零停機時間部署進行設計,因此當您規劃解決方案架構時,請務必考慮您的更新程式。

即使您未在更新程式期間規劃中斷,您仍可能會考慮定義一般維護期間。 視窗可協助與客戶溝通特定時間發生的變更。

如需達成零停機部署的詳細資訊,請參閱 透過版本化服務更新消除停機時間。

尋找餘額

如果您將服務更新的步調完全保留給租使用者的自由裁量,他們可能會選擇永遠不會更新。 請務必自行更新解決方案,同時考慮客戶可能擁有的任何合理考慮或限制。 例如,如果客戶對星期五的更新特別敏感,因為這是一周中最繁忙的一天,那麼您可以輕鬆地將更新延遲到星期一,而不會影響您的解決方案嗎?

一個可以正常運作的方法,是使用 下列其中一種方法,逐一在租用戶的基礎上推出更新。 提供客戶已規劃更新的通知。 允許客戶暫時退出,但不能永遠退出;當您需要套用更新時,請設定合理的限制。

此外,請考慮讓您自己能夠部署安全性修補程式或其他重要 Hotfix,但最少或沒有事先通知。 請確定租用戶瞭解這種做法及其保護其數據的重要性。

另一種方法是允許租使用者在其選擇時起始自己的更新。 同樣地,您應該提供期限,此時您代表他們套用更新。

警告

請小心讓租使用者起始自己的更新。 實作很複雜,而且需要大量開發和測試工作才能提供和維護。

無論您做什麼,請確定您有監視租使用者健康情況的程式,特別是在套用更新之前和之後。 重大生產事件(也稱為 即時網站事件)通常會在程式代碼或設定的更新之後發生。 因此,請務必主動監視並回應任何問題,以保留客戶信心。 如需監視的詳細資訊,請參閱 設計及建立監視系統的建議。

與客戶通訊

清楚溝通是建置客戶信心的關鍵。 請務必說明定期更新的優點,包括新功能、Bug 修正、解決安全性弱點和效能改善。 新式雲端裝載解決方案的優點之一是持續傳遞功能和更新。

請考量下列問題:

  • 您是否會通知客戶即將推出的更新?
  • 如果您這麼做,您會提供退出程式來隱含要求許可權,以及退出退出的限制為何?
  • 您是否有套用更新時所使用的排程維護期間?
  • 如果您有緊急更新,例如重大安全性修補程式,會發生什麼事? 您可以在這些情況下強制更新嗎?
  • 如果您無法主動通知客戶即將推出的更新,是否可以提供回顧通知? 例如,您可以使用您已套用的更新清單來更新網站上的頁面嗎?
  • 您要在生產環境中維護多少個不同的系統版本?

與客戶支援小組通訊

重要的是,您自己的支援小組能夠完整瞭解已套用至每個租用戶基礎結構的更新。 客戶支援代表應該能夠輕鬆地回答下列問題:

  • 最近是否已將更新套用至租用戶的基礎結構或共享元件?
  • 這些更新的性質為何?
  • 舊版是什麼?
  • 更新套用至此租用戶的頻率為何?

如果其中一個客戶因為更新而發生問題,您必須確保客戶支援小組具備瞭解變更內容所需的資訊。

支援更新的部署策略

請考慮您將如何將更新部署至基礎結構。 這會受到您使用的 租用模型 影響很大。 部署更新的三種常見方法包括部署戳記、功能旗標和部署步調。 您可以單獨使用這些方法,也可以將它們結合在一起,以符合更複雜的需求。

在所有情況下,請確定您有足夠的報告和可見度,讓您知道每個租使用者的基礎結構、軟體或功能版本、他們有資格移轉至哪些專案,以及與這些狀態相關聯的任何時間相關數據。

部署戳記模式

許多多租使用者應用程式非常適合 部署戳記模式,您可以在其中部署應用程式的多個復本和其他元件。 視隔離需求而定,您可以為每個租使用者部署戳記,或執行多個租使用者工作負載的共用戳記。

戳記是提供租用戶之間隔離的絕佳方式。 它們也可讓您彈性地進行更新程序,因為您可以逐步跨戳記推出更新,而不會影響其他人。

功能旗幟

功能旗標 可讓您將功能新增至解決方案,同時只將該功能公開給客戶的子集或租使用者。

如果上述任一情況適用於您,請考慮使用功能旗標:

  • 您可以定期部署更新,但想要避免顯示新功能,直到完全實作為止。
  • 您想要避免套用行為變更,直到客戶選擇加入為止。

您可以自行撰寫程式代碼,或使用像是 Azure 應用程式組態 之類的服務,將功能旗標支援內嵌至應用程式。

部署環

部署通道 可讓您逐步跨一組租使用者或部署戳記推出更新。 您可以將租使用者子集指派給每個通道。

您可以決定要建立的通道數量,以及每個通道對您自己的解決方案的意義。 通常,組織會使用下列通道:

  • Canary: Canary 通道包含您自己的測試租使用者和想要在有更新的客戶可供使用時,了解他們可能會收到更頻繁的更新,而且更新可能尚未像其他項目一樣全面地通過驗證程式。
  • 早期採用者: 早期採用者通道包含稍有風險反感的租使用者,但仍準備接收定期更新的租使用者。
  • 使用者: 大部分的租用戶都屬於 使用者 通道,其接收頻率較低且測試程度更高的更新。

API 版本

如果您的服務公開外部 API,請考慮您套用的任何更新可能會影響客戶或合作夥伴與平臺整合的方式。 特別是,您必須注意 API 的重大變更。 請考慮使用 API 版本控制策略 來降低 API 更新的風險。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主體作者:

其他投稿人:

若要查看非公開的 LinkedIn 設定檔,請登入 LinkedIn。

後續步驟

在多租用戶解決方案中,考慮何時將要求對應至租使用者。