雲端技術的優點之一是持續改善和演進。 身為服務提供者，您必須將更新套用至您的解決方案。 您可能需要變更應用程式程式代碼、Azure 基礎結構、資料庫架構或任何其他元件。 請務必規劃如何更新環境。 在多租用戶解決方案中，請務必明確您的更新原則，因為您的部分租使用者可能不願意允許變更其環境，或者他們可能有限制您可以更新其服務之條件的需求。
規劃更新解決方案的策略時，您需要：
- 確認租戶的需求。
- 釐清您自己的服務運作需求。
- 尋找您和租使用者都可以接受的餘額。
- 將策略清楚傳達給租使用者和其他項目關係人。
本文提供技術決策者的指導，說明更新租戶軟體的方法以及涉及的取捨問題。
您的客戶需求
客戶通常會有明確或隱含的需求，可能會影響系統更新的方式。 請考慮下列層面，以便清楚了解客戶可能提出的疑慮：
期望和需求： 找出客戶何時可以更新其解決方案時可能擁有的任何期望或需求。 這些期望或需求可能會在合約或服務等級協定中正式傳達給貴使用者，或可能是非正式的。
維護期間： 瞭解您的客戶是否預期服務定義或自我定義的維護期間。 他們可能需要與使用者溝通潛在的中斷情況。 更新完成後，他們也可能預期會測試服務的重要層面。
法規： 釐清客戶是否有任何需要額外核准才能套用更新的法規考慮。 例如，如果您提供包含IoT元件的健康解決方案，您可能需要取得美國食品和藥物管理局 （FDA） 的核准，才能套用更新。
敏感性： 了解您的任何客戶是否特別敏感或抗拒套用更新。 如果是，請嘗試瞭解原因。 例如，如果他們執行實體商店或零售網站，他們可能會想要避免在黑色星期五前後更新，因為風險高於潛在利益。
歷史： 檢閱您的追蹤記錄，確認您在順利完成更新的同時，未對客戶造成任何影響。 您應該遵循良好的 DevOps、測試、部署和監視做法，以減少中斷的可能性，並確保您快速找出更新引進的任何問題。 如果您的客戶知道您能夠順利地更新他們的環境，那麼他們就不太可能會反對。
回退： 如果發生重大變更，請考慮客戶是否希望回退更新，以及由誰觸發這項回退請求。
您的需求
您也需要從自己的觀點考慮下列問題：
控制您願意提供： 客戶是否合理地擁有控制權，以決定何時套用更新？ 如果您要建置大型企業客戶所使用的解決方案，答案可能是是的。 不過，如果您要建置以消費者為主的解決方案，您不太可能給予控制權，以決定升級或操作解決方案的方式。
版本： 您一次可以合理維護多少個解決方案版本？ 如果您發現 Bug 或安全性弱點，且需要套用 Hotfix，您可能需要將它套用至目前使用的所有版本。
舊版的後果： 讓客戶落後於目前版本的影響為何？ 如果您定期發行新功能，舊版會很快過時嗎？ 此外，視您的升級策略和變更類型而定，您可能需要為解決方案的每個版本維護個別的基礎結構。 因此，當您維護舊版的支援時，可能會有營運和財務成本。
回滾： 您的部署策略可以支持回滾至舊版嗎？ 您要啟用這項功能嗎？
備註
請考慮您是否需要讓解決方案離線進行更新或維護。 中斷時段通常被視為是一種過時的做法，尤其是對於軟體即服務（SaaS）而言。 新式DevOps做法和雲端技術可讓您避免在更新和維護期間停機。 不過，您必須針對零停機時間部署進行設計。 規劃解決方案架構時，請務必考慮您的更新程序。
即使您未在更新過程期間規劃中斷，您仍可能會定義定期維護時段。 這種方法可協助與客戶溝通特定時間發生的變更。
如需如何實現零停機部署的詳細資訊，請參閱 透過版本化服務更新消除停機時間。
尋找餘額
如果您將服務更新的步調完全保留給租使用者的自由裁量，他們可能會選擇永遠不會更新。 重要的是要允許自己更新解決方案，同時考量客戶可能擁有的任何合理考量或限制。 例如，如果客戶對星期五的更新特別敏感，因為這是一周中最繁忙的一天，請考慮您是否可以同樣輕鬆地延遲週一的更新，而不會影響您的解決方案。
一個可行的方法是使用其中一種 部署策略，逐個租用戶推出更新。 通知您的客戶已規劃的更新。 允許客戶暫時選擇退出，但不可永久退出。在要求套用更新時，請設定合理的時間限制。
允許自己有能力在最少或沒有事先通知的情況下部署安全性修補程式或其他重要的hotfix。 請確定租用戶瞭解這種做法及其保護其數據的重要性。
另一種方法是允許租戶在他們選擇的時間啟動自己的更新。 再次，您應該提供一個截止日期，屆時您代表他們套用更新。
警告
請小心讓租戶自行執行更新。 此過程很複雜，需要大量的開發和測試的努力才能實現並維護。
無論您做什麼，請確定您有監視租使用者健康情況的程式，特別是在套用更新之前和之後。 重大生產事件也稱為 即時網站事件，通常會在變更程式代碼或設定之後發生。 因此，請務必主動監視並回應任何問題，以保留客戶信心。 如需詳細資訊，請參閱 Azure 上 SaaS 工作負載的事件管理。
與客戶通訊
清楚溝通是建置客戶信心的關鍵。 請務必說明定期更新的優點，包括新功能、Bug 修正、解決安全性弱點和效能改善。 新式雲端託管解決方案的優點之一是持續提供功能和更新。
請考慮下列問題：
您是否會通知客戶即將推出的更新？
如果您這麼做，會否透過提供選擇退出的程序來隱含地要求許可，並且退出的限制是什麼？
您是否有用來套用更新的例行維護窗口？
如果您有緊急更新，例如重大安全性修補程式，會發生什麼事？ 您可以在這些情況下強制更新嗎？
如果您無法主動通知客戶即將推出的更新，是否可以提供回顧通知？ 例如，您可以使用您已套用的更新清單來更新網站上的頁面嗎？
您要在生產環境中維護多少個不同的系統版本？
與客戶支援小組通訊
重要的是，您的支援小組需要對已經套用到每個租用戶基礎設施的更新擁有全面的了解。 客戶支援代表應該能夠輕鬆地回答下列問題：
最近是否已將更新套用至租用戶的基礎結構或共享元件？
這些更新的性質為何？
舊版是什麼？
更新套用至此租用戶的頻率為何？
如果其中一個客戶因為更新而發生問題，您必須確保客戶支援小組具備瞭解變更內容所需的資訊。
支援更新的部署策略
請考慮如何將更新部署至基礎結構。 您的更新策略在很大程度上取決於您所使用的 租用模型 。 部署更新的三種常見方法包括部署戳記、功能開關和部署環。 您可以單獨使用這些方法，也可以將它們結合在一起，以符合更複雜的需求。
在所有情況下，請確保您有足夠的報告和透明度。 您必須知道每個租使用者所使用的基礎結構、軟體或功能版本、他們有資格移轉至哪些專案，以及任何與這些狀態系結的時間相關數據。 追蹤這項資訊通常是 控制平面的責任之一。
部署標識模式
許多多租戶應用程式非常適用於 部署戳記模式。 在此模式中，您會部署應用程式的多個復本和其他元件。 根據您的隔離需求，您可以為每個租用戶或執行多個租使用者工作負載的共用戳記部署戳記。
戳記是提供租用戶之間隔離的絕佳方式。 它們也會為您提供更新程序的彈性，因為您可以逐步跨戳記推出更新，而不會影響其他人。
功能標幟
功能旗標 可讓您將功能新增至解決方案，同時只將該功能公開給客戶的子集或租使用者。
如果下列任一案例適用於您，請考慮使用功能旗標：
您定期更新，但想要避免顯示新功能，直到完全實現為止。
您想要避免套用行為變更，直到客戶選擇加入為止。
您可以自行撰寫程式代碼或使用 Azure 應用程式組態等服務，將功能旗標支援內嵌至應用程式。
部署環段
部署通道 可讓您逐步跨一組租戶或部署標記逐步推出更新。 您可以將租戶的一部分指派給發行序列中的每個階段。
您可以決定要建立的通道數量，以及每個通道對您自己的解決方案的意義。 通常，組織會使用下列環：
金絲雀：Canary 環包括您自己的測試租戶以及想要在更新可用時立即接收更新的客戶。 Canary 通道上的任何人都應該了解，他們可能會更頻繁地收到更新。 這些更新可能未經過如其他更新環節中的更新一樣嚴格的驗證流程。
早期採用者： 早期採用者通道包含租用戶，這些租用戶對風險稍微不安，但仍準備接收定期更新。
使用者： 大部分的使用者都屬於 使用者 環，其接收頻率較低且測試程度更高的更新。
API 版本
如果您的服務公開外部 API，請考慮您套用的任何更新可能會影響客戶或合作夥伴與平臺整合的方式。 特別是，您必須注意 API 的重大變更。 請考慮使用 API 版本控制策略 來降低 API 更新的風險。
貢獻者們
本文由 Microsoft 維護。 下列參與者撰寫本文。
主要作者：
- John Downs |Azure 模式和實務的主要軟體工程師
其他參與者：
- 查德·基特爾 |Azure 模式和實務的主要軟體工程師
- Daniel Scott-Raynsford | 合作夥伴技術策略師
- Arsen Vladimirskiy | 主任客戶工程師，FastTrack for Azure
若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。