Azure 上 SaaS 工作負載的 DevOps 做法
DevOps 做法對於管理 Azure 上的工作負載而言是不可或缺的，尤其是 SaaS 應用程式。 主要層面包括上線、下線和修改客戶實例。 這些做法不僅能簡化作業，還能增強延展性和可靠性，將中斷的機會降到最低。
本文說明有效率的客戶生命週期管理和安全部署做法的設計考慮。
管理客戶生命週期
管理 客戶生命週期事件 對於任何 SaaS 應用程式都至關重要。 這些事件通常包括：
- 上架：客戶註冊時。
- 改變：修改客戶的實例，例如變更其定價層。
- 下架：當客戶取消其帳戶時。
您可能會遇到其他生命週期事件。 例如，您可能會允許客戶暫停其訂閱，同時保留其數據一段設定期間，並在稍後繼續訂閱。 每個事件對於您的應用程式都有唯一的影響。
在某些解決方案中，客戶生命週期管理可能只需要在資料庫數據表中建立或管理數據。 對於其他解決方案，它可能牽涉到協調 Azure 基礎結構、應用程式程式代碼和更複雜的設定部署。
生命週期管理是 SaaS 解決方案控制平面的重要責任。 一開始，您的小組可能會手動處理這些活動，但經過一段時間后，請嘗試將更多功能轉換成正規化控制平面解決方案或應用程式。
設計考量
一致性。 規劃生命週期管理策略時，請考慮每個客戶生命週期事件所需的動作複雜度。 這包括您的解決方案大小、客戶群和組織額外負荷。 請確定您已清楚瞭解每個事件的必要步驟，並投資控件來維持一致性。 定期檢閱和更新您的程式，以協助確保您的解決方案隨著解決方案的發展而保持有效。
租用模型。 處理客戶生命週期事件的方法取決於您的租用模型。
- 具有基礎結構資源的完整多租用戶解決方案。 上線或下線客戶通常牽涉到更新客戶清單和應用程式數據存放區中的相關聯數據。
- 每位客戶的專用資源。 這些工作通常牽涉到起始部署至 Azure、監視進度，以及處理部署失敗，可能是人為介入。
- 客戶部署的資源。 您可能需要直接與客戶的工程小組互動，才能上線或下線。
階層。 請考慮您的定價模式和每個層級的不同基礎結構需求，特別是當您允許客戶隨時自由變更其SKU時。
- 例如，如果您的 SaaS 解決方案包含核心應用程式和多個付費附加元件模組，請確定核心應用程式的資源已在上線期間部署。 此外，允許動態新增和移除附加元件模組。 拿掉模組時，決定是否要刪除相關聯的數據，或將其儲存為可能重新啟用。
設計建議
| 建議 | 優點 |
|---|---|
| 記錄每種類型的客戶生命週期事件。 請確定您擷取每個事件的處理程式逐步詳細數據。 |
藉由瞭解事件，您可以規劃如何回應解決方案設計中的每個事件。 清楚的指示可協助人類操作員維持一致性，並做為未來自動化的基礎。 |
| 針對每個生命週期事件，傳達您與客戶之間的共同責任。 清楚及早地傳達您預期客戶要執行的動作，以完成生命周期階段。 | 您可以減少因錯誤溝通所造成的潛在錯誤和客戶挫折感。 |
| 針對每個生命週期事件進行容量規劃。 例如，在上線新客戶時，如果現有的實例沒有足夠的容量來處理額外負載，請規劃部署應用程式的新實例。 如需詳細資訊，請參閱 Azure 上 SaaS 工作負載的計費和成本管理。 |
您可以支援您更輕鬆地調整規模，並避免部署失敗。 |
| 實際時，將生命週期事件自動化。 對於低量或早期解決方案，手動部署和設定可能就已足夠，但仍應該使用腳本，即使工程師每次發生生命週期事件時都會執行這些腳本也一樣。 隨著解決方案的成熟，將這些責任整合到完整的控制平面中，以減少人為錯誤並支援更高的規模。 |
您可以降低人為錯誤的重大風險，並支援更高的規模。 |
規劃基礎結構管理策略
儘早開發部署、維護和管理 Azure 基礎結構的策略。 當您調整 SaaS 時，資源數目就會增加。 從一開始就遵循管理策略比稍後在基礎結構變得太複雜而無法手動處理時，更容易協調基礎結構。
設計考量
客戶資源管理。 您的租用模型會影響 SaaS 解決方案中的資源部署。 您可以為每個客戶部署專用的 Azure 資源，或在一組客戶之間共用資源。 或者，您可以使用一組共享資源，在將新客戶上線時重新設定它們。 管理資源生命週期的常見方法：
- 將您的客戶清單視為要部署的資源組態。 使用集中式部署管線來部署和設定這些資源。
- 將您的客戶清單視為數據。 使用控制平面應用程式來布建和設定基礎結構。
基礎結構自動化。 許多組織一開始會透過 Azure 入口網站 手動部署雲端基礎結構，這一點一開始很容易，但無法妥善調整。 規劃使用基礎結構即程序代碼 （IaC） 工具來自動化基礎結構設定，例如 Bicep 或 Terraform。 如需更複雜的需求，請建立直接使用 Azure Resource Manager API 的控制平面。
基礎結構屬性。 追蹤哪些客戶部署在哪一個基礎結構上。 追蹤對於精確的容量規劃和成本屬性很重要。 您可以在客戶資料庫中集中追蹤客戶基礎結構，或針對專用基礎結構，搭配客戶特定的資源群組和資源標籤使用 Azure 資源元數據。 如需詳細資訊，請參閱 SaaS 工作負載的資源組織。
設計建議
| 建議 | 優點 |
|---|---|
| 使用部署管線、腳本或範本搭配小組熟悉的工具來建置基礎結構自動化。 | 使用已知工具可降低錯誤的風險，因為如果無法了解這些工具，基礎結構自動化可能會造成干擾。 |
| 盡可能使用 IaC 部署基礎結構。 | 隨著基礎結構數量的增長，手動維護基礎結構會變得更有風險且更負擔。 |
| 將核心基礎結構與客戶層級基礎結構分開。 | 不同類型的基礎結構具有不同的生命週期和管理活動。 藉由將它們分開，您可以獨立地根據自己的排程管理每個集合。 |
| 使用 Azure 受控應用程式來部署和管理客戶部署的資源。 | Azure 受控應用程式提供一系列功能，可讓您在客戶的 Azure 訂用帳戶內部署和管理資源。 |
規劃應用程式部署
定期更新應用程式程式代碼和組態，以增強功能。 客戶預期在更新和安全推出期間保持一致的運行時間，以將中斷的風險降到最低。
設計考量
標準化工具和程式。 經過業界證明的 DevOps 工具可確保在管理應用程式部署的程式中，函式和成熟度之間的一致性。 在大部分情況下，開發您自己的工具會被視為反模式。
取捨：複雜度和成本。 在金錢和技能方面，使用熟悉的DevOps工具可以符合成本效益。 不過，它增加了個別管理每個工具的操作負擔。 請務必繼續開放新的技術創新，以利於您的工作負載。漸進式部署更新。 一次推出客戶子集的更新，將使用者分成邏輯群組。 將相同的嚴謹套用至組態變更，因為它們可以改變程式代碼行為並造成中斷。 請遵循這些變更的部署程式。
採用版本控制策略。 允許客戶選擇其應用程式版本會增加彈性，但會使您的作業複雜化。 設定淘汰舊版的明確期望，並概述不再支援時會發生什麼事。
自動化。 由於人為錯誤和缺乏一致性，手動部署容易發生風險。 即使您的部署是以手動方式觸發，您的部署程式也應該盡可能自動化，而且應該需要最少的人為介入。 請考慮部署程式的步驟，以及如何將其自動化。
測試。 執行下列命令，將測試整合到您的部署程式中：
- 程式代碼建置期間的單元測試
- 部署後整合測試
- 一般效能測試
- 一般安全性和滲透測試
決定在任何階段是否有任何測試失敗時要採取的動作。
部署失敗。 考慮必要的動作和準備復原策略，以規劃部署失敗。
存取客戶環境。 如果您將資源部署到客戶環境，請瞭解如何在這些環境中套用更新。 請考慮 Azure 受控應用程式所提供的功能，例如 將更新部署至應用程式。
設計建議
| 建議 | 優點 |
|---|---|
| 使用已建立且經過業界證實的 DevOps 工具和程式來管理您的應用程式部署。 在大部分情況下，開發您自己的工具會被視為反模式。 如需詳細資訊，請參閱 OE：03 軟體開發實務 |
您可以確定您的工程小組不需要學習自定義建置工具，就能有效地部署。 |
| 主動通知客戶任何即將或已完成的部署。 | 您可以確定客戶已設定適當的預期，以瞭解您應用程式的變更。 |
| 採用安全部署做法，使用漸進式曝光、健康情況模型等策略，將更新部署至客戶群組。 從較不敏感或早期採用者客戶開始，再移至更重要的客戶。 如需詳細資訊，請參閱 安全部署實務的建議。 |
這種方法有助於找出問題，再影響所有客戶。 |
| 將設定視為程式碼。 | 您可以降低停機時間的可能性，並針對生產變更採用一致的程式。 這可啟用集中式作業責任，例如測試變更，並逐步推出組態和程式代碼的更新。 |
| 定義變更管理程式並傳達版本更新原則，以確保客戶知道誰觸發更新、其頻率和條件。 如果允許客戶選擇其應用程式版本，請設定淘汰舊版的明確指導方針。 將生產環境中執行的應用程式版本數目降至最低。 |
維護舊版會導致作業效率低下。 藉由設定明確的期望和原則，為您的客戶提供必要的控制，同時避免過度負擔您的小組。 |
| 避免為單一客戶自定義應用程式。 若要支援不同的客戶需求，您可以建立解決方案的各種層級，或使用功能旗標來針對特定使用者啟用特定功能。 |
避免將哪些功能部署到哪個版本時模棱兩可，並降低維護負擔。 |
| 有失敗部署的復原計劃，包括觸發和必要核准的準則。 | 復原方案有助於確保即使在未預期的情況下，您也能從部署錯誤中復原。 |
| 在軟體開發程式中定期和多個階段測試您的應用程式。 採用「左移」思維，並在生命週期早期攔截 Bug 和偏差。 | 協助防止重大錯誤影響您的客戶。 |
其他資源
多租用戶是設計 SaaS 工作負載的核心商務方法。 這些文章提供有關採用 DevOps 做法的詳細資訊：
後續步驟
瞭解在 Azure 上實作支援 SaaS 解決方案的程式和工具的事件管理考慮。