檢閱和比較常見的雲端作業模型

作業模型是獨特的，且會根據其目前的需求和限制，專屬於其所支援的業務。 但作業模型不是 雪花。 客戶作業模型中有幾個常見的模式；本文概述四個最常見的模式。

作業模型比較

下圖根據複雜度的範圍繪製了常見的作業模型，包括最不複雜的分散式作業，乃至於最複雜的全域作業。 下表將根據其他幾個屬性的相對值，比較相同的作業模型。

優先事項或範圍

雲端作業模型主要由兩個因素所驅動：

• 策略優先順序或動機
• 要管理的公事包範圍

	分散式作業 (ops)	集中式作業 (ops)	企業作業 (ops)	分散式作業 (ops)
策略優先順序或動機	創新	控制	民主化	整合
組合範圍	工作負載	登陸區域	雲端平台	完整組合
工作負載環境	高複雜度	低複雜度	中複雜度	中或可變複雜度
登陸區域	N/A	高複雜度	中到低複雜度	低複雜度
基礎公用程式	N/A	N/A 或低支援	集中式支援，支援程度較高	最多支援
雲端基礎	N/A	N/A	混合式、提供者專有或區域基礎	分散式和同步

• 策略優先順序或 動機：每個作業模型都會提供 雲端採用的典型策略動機。 但某些作業模型可簡化特定動機。

• 公事包範圍：公事包範圍可識別特定作業模型設計所支援的最大範圍。 例如，集中式作業是針對某些登陸區域而設計的。 但作業模型決策可能會為組織建立營運風險。 嘗試管理大型複雜組合時，作業風險會產生。 這些組合在登陸區域設計中可能需要許多登陸區域或可變複雜度。

重要

採用雲端通常會觸發目前作業模型的反映，並可能導致從一個常見的作業模型轉移到另一個作業模型。 但雲端採用不是唯一的觸發程式。 業務優先事項和雲端採用的範圍可能會改變組合所需的支援方式。 此外，最配適的作業模型中可能也會有其他轉變。 當董事會或其他管理階層團隊制定 5 到 10 年的商務計劃時，這些計劃常會包含調整作業模型的需求 (明確或隱含)。 作業模型是引導決策的適當參考。 這些模型可能會變更或需要自訂，以符合您的需求和條件約束。

責任一致性

眾多的小組和個人負責支援不同的功能。 但每個常見的作業模型都會將決策結果的最終責任指派給一個小組或個人。 此方法將影響對作業模型的投資方式，以及為每項功能提供的支援層級。

	分散式作業	集中式作業	企業作業	分散式作業
業務配合	工作負載小組	集中式雲端策略	CCoE	可變 - 形成龐大的雲端策略小組？
雲端作業	工作負載小組	集中式 IT	CCoE	根據組合分析 - 請參閱業務配合和商務承諾
雲端治理	工作負載小組	集中式 IT	CCoE	多層控管
雲端安全性	工作負載小組	安全性作業中心 (SOC)	CCoE + SOC	混合 - 請參閱定義安全性策略
雲端自動化和 DevOps	工作負載小組	集中式 IT 或 N/A	CCoE	根據組合分析 - 請參閱業務配合和商務承諾

加速 Azure 中的作業模型實作

如同定義您的作業模型中所述，雲端採用架構的每個方法都會提供用來開發作業模型的結構化路徑。 這些方法可協助您克服因採用雲端作業模型而產生的阻礙。

下表概述加速作業模型實作的方式。

	分散式作業	集中式作業	企業作業	分散式作業
起點	Azure Well-Architected Framework (WAF)	Azure 登陸區域：從小規模開始選項	Azure 登陸區域：CAF 企業規模	業務配合
反覆運算次數	焦點放在工作負載上，可讓小組逐一查看 WAF。	「從小規模開始」選項需要對每個方法進行更多反覆運算，但可隨著雲端採用工作成熟而完成。	如參考實作所示，未來的反覆運算通常著重於少量新增設定。	請參閱 Azure 登陸區域的實作選項，開始使用最符合您的作業基準的選項。 請依照該選項的設計原則中定義的反覆運算路徑操作。

分散式作業

作業一向是複雜的。 如果您將作業的範圍限制為一個工作負載或一小部分的工作負載，您可以控制複雜度。 分散式作業是最不複雜的一般作業模型。 在此形式的作業中，所有工作負載都會由專用工作負載小組獨立運作。

• 優先順序：您的小組會測量跨多個工作負載集中控制或標準化的創新。
• 明顯的優點：讓工作負載和業務小組全權掌控設計、組建和作業，藉以盡可能加快創新速度。
• 明顯的缺點：跨工作負載的標準化效能下降、透過共用服務的規模效益縮小，集中治理的合規性工作一致性降低。
• 風險：在管理工作負載組合時，此方法會帶來風險。 工作負載小組可能有專門負責集中式 IT 職能的特殊小組。 某些組織會將此作業模型視為高風險選項，特別是必須符合第三方合規性需求的公司。
• 指引：分散式作業僅限於工作負載層級決策。 Microsoft Azure Well-Architected Framework 支援在該範圍內所做的決策。 雲端採用架構中的程序和指引可能會增加分散式作業不需要的額外負荷。

分散式作業的優點

• 成本管理：作業成本很容易對應至單一業務單位。 工作負載特定作業支援更大的工作負載優化。
• 責任：一般而言，這種形式的作業高度依賴自動化以盡可能降低額外負荷。 責任通常著重於 DevOps 和發行管理的管線。 這種類型的作業在開發期間支援更快速的部署和較短的意見反應週期。
• 標準化：使用原始程式碼和部署管線，將環境從發行標準化到發行。
• 作業支援：影響作業的決策僅考量該工作負載的需求，並簡化作業決策。 DevOps 社群的成員指出作業支援是最單純的作業形式，因為其作業範圍較窄。
• 專業知識：DevOps 和開發小組在此方法下受惠最深，且在推動市場變化方面遇到的阻力最小。
• 登陸區域設計：沒有具體的作業優勢。
• 基礎公用程式：沒有具體的作業優勢。
• 職責區分：沒有具體的作業優勢。

分散式作業的缺點

• 成本管理：企業成本較難計算。 沒有集中式治理小組時，會更難實作統一成本控制或最佳化。 若規模較大，此模型的成本可能會很高，因為每個工作負載在部署的資產和人員指派方面可能會有重複。
• 責任：缺少集中式支援時，表示會由工作負載小組全權負責治理、安全性、作業和變更管理。 當這些工作尚未在程式碼檢閱和發行管線中自動化時，缺少支援就會有問題。
• 標準化：跨工作負載組合的標準化是可變且不一致的。
• 作業支援：跨多個工作負載建立最佳做法時，常會失去規模效益。
• 專業知識：小組成員須承擔更大的責任，在應用程式設計和設定中針對治理、安全性、作業和變更管理做出明智且合乎道德的決策。 請經常參閱 Microsoft Azure Well-Architected檢閱和 Azure Well-Architected Framework，以改善所需的專業知識。
• 登陸區域設計：登陸區域不會隨工作負載而不同，在此方法中不予考量。
• 基礎公用程式：少數基礎服務 (若有的話) 會在工作負載之間共用，而降低規模效益。
• 職責區隔：DevOps 和開發小組的需求較高，可提高這些小組的許可權使用量。 如果您需要職責區隔，您可能需要大量投資 DevOps 成熟度，才能使用這種方法運作。

集中式作業

在狀態穩定的環境中，可能無須注重個別工作負載的架構或不同的作業需求。 對於主要由狀態穩定的工作負載組成的技術環境，通常會以集中式作業作為標準。 舉例來說，狀態穩定的作業包括商業現成軟體 (COTS) 應用程式，或是發行頻率較低的完善自訂應用程式等等。 如果變化率由定期的更新和修補檔所驅動，則集中作業可能是管理組合的有效方式。

• 優先事項：優先事項集中控制創新性，並在文化轉移至新式雲端作業的過程中，衡量現有的作業程序。
• 明顯的優點：集中化導入了規模效益、絕佳的控制和標準化作業，且十分適合雲端環境。 這些環境需要特定的設定，以將雲端作業整合至現有的作業和程序中。 集中化對於有數百個工作負載、且架構複雜性與合規性需求適度的組合，最為有利。
• 明顯的缺點：調整為符合大型工作負載組合的需求，可能會對進行生產工作負載作業決策的集中式小組造成沉重的壓力。 如果技術資產預期調整超過 1，000 個 VM、應用程式或資料來源，您可能會在 18-24 個月內考慮企業模型。
• 風險：此方法會將集中化限定於較少的訂用帳戶 (通常是一個生產訂用帳戶)。 後續在您的雲端旅程中重構時將涉及重大風險，且可能會干擾您的採用計劃。 若要避免重新作業，請嘗試專注於分割、環境界限、身分識別工具和其他基礎元素。
• 指引：與「從小規模著手並擴充」開發速度一致的 Azure 登陸區域實作選項，是良好的起點。 您可以使用這些選項來加速採用工作。 但若要成功，請建立清楚的原則，以引導可接受的風險承受度內的早期採用工作。 控管和管理方法有助於建立以平行方式讓作業趨於完善的程序。 請執行這些步驟，您必須先完成這些階段性任務，才能隨著作業的完善容許更高的風險。

集中式作業的優點

• 成本管理：將跨許多工作負載的共用服務集中化，可建立規模效益並消除重複的工作。 集中式小組可透過全企業的大小調整和規模最佳化，使成本快速降低。
• 責任：集中的專業化和標準化可提高穩定性和作業效能，並盡可能減少因變化而產生的中斷。 這種方法可降低工作負載焦點小組的廣泛技能壓力。
• 標準化：一般而言，使用集中式模型時，標準化和營運成本最低，因為複製的系統或工作較少。
• 作業支援：減少複雜度和集中式作業，可讓較小的 IT 小組更輕鬆地支援作業。
• 專業知識： 集中式支援小組可讓安全性、風險、治理和作業專家推動業務關鍵決策。
• 登陸區域設計：集中式 IT 可將登陸區域和訂用帳戶的數目降至最低，以降低複雜度。 登陸區域設計常會仿照先前的資料中心設計，以縮短轉換時間。 在採用的過程中，共用資源可能會移至個別的訂用帳戶或平台基礎。
• 基礎公用程式：您將現有的資料中心設計帶入雲端，導致模擬內部部署工具和作業的基礎、共用服務。 若內部部署作業是您的主要作業模型，這可能是一個優點，但請留意一些缺點。 內部部署作業可減少轉換時間、以規模經濟為基礎，並支援內部部署和雲端託管工作負載之間的一致作業程式。 這種方法可以降低短期的複雜度和精力，讓較小的小組使用降低的學習曲線來支援雲端作業。
• 職責區分：集中式作業中有明確的職責區分。 中央 IT 可維持生產環境的控制權，並減少其他小組任何提高許可權的需求。 此方法可藉由限制具有提高許可權的帳戶數目來減少缺口。

集中式作業的缺點

• 成本管理：集中式小組不一定會了解工作負載架構，因此未必能在工作負載層級進行具影響力的最佳化。 缺乏瞭解會限制來自微調工作負載作業的成本節省量。 對工作負載架構缺乏全面了解，可能會影響集中式成本最佳化，進而對架構良好的工作負載造成效能、規模和其他要素的影響。 在您將全企業成本變更套用至高設定檔工作負載之前，您的中央 IT 小組應該先瞭解並完成 Microsoft Azure Well-Architected檢閱。
• 責任：將生產支援和存取集中化會對一些人帶來較大的作業負擔，且每個人都會承受更大的壓力。 對這些人施加的壓力，就會需要對已部署的工作負載進行更深入的檢閱，以驗證是否符合詳細的安全性治理和合規性需求。
• 標準化：使用集中式 IT 方法時，若未對集中式 IT 人員進行線性調整，就難以調整標準化。
• 作業支援：此方法最大的缺點與衡量創新性的重大調整與轉變有關。
• 專業知識：在此類型的環境中，開發人員和 DevOps 專家承受了遭到低估或過於受限的風險。
• 登陸區域設計：資料中心設計是根據前述方法的限制 (不一定與雲端相關)。 遵循這種方法可減少重新思考環境分割的機會，增加創新的機會。 缺少登陸區域分割會增加缺口的潛在影響、治理和合規性遵循的複雜性，並可能會造成阻礙，以在雲端旅程中採用。 請參閱上述的風險一節。
• 基礎公用程式：在數位轉型期間，雲端可能會成為主要作業模型。 集中式工具是針對內部部署作業而建置的，可降低將作業現代化的機會，並提高作業效率。 選擇不提早在採用程序中將作業現代化，也是一個選項。 在雲端採用旅程中建立平臺基礎訂用帳戶，即可達成現代化。 該工作可能很複雜、昂貴且耗時，而不需要進階規劃。
• 職責區隔：中央作業通常會遵循兩個路徑的其中一個，而且兩者都可能會阻礙創新。
  • 選項 1：授權給集中式 IT 以外的小組存取模擬生產環境的開發環境。 此選項會阻礙實驗。
  • 選項 2：小組在不支援的環境中進行開發和測試。 此選項會阻礙部署程序，並且使部署後的整合測試的速度變慢。

企業作業

企業作業是所有雲端作業的建議目標狀態。 企業作業可簡化決策和責任，在控制與創新的需求之間取得平衡。 集中式 IT 會取代為更便利的雲端卓越中心 (可支援工作負載小組)。 CCoE 小組會讓工作負載小組負責決策，而不是控制或限制其行動。 在妥善定義的護欄內，工作負載小組會獲得更多權力並承擔更大的責任，以推動創新。

• 優先事項：優先事項是技術決策的民主化。 經由技術決策的民主化，先前由集中式 IT 承擔的責任會轉移給工作負載小組。 為了在優先順序上實現此一轉變，決策變得較不依賴人工執行的檢閱程序。 此方法支援使用雲端原生工具自動檢閱、治理和強制執行。
• 明顯的優點：區隔環境和區分職責可讓您在控制與創新之間取得平衡。 集中式作業可維護需要較高合規性和穩定狀態作業的工作負載，或意味著較高的安全性風險。 相反地，此方法支援減少需要更大創新之工作負載和環境的集中控制。 較大的組合可能會難以在控制與創新之間取得平衡。 此彈性可讓您更輕鬆地擴充上千個工作負載，並減輕作業負擔。
• 相異缺點：在企業雲端作業中，內部部署工作可能無法正常運作。 此作業方法需要許多方面的變更。 控制和責任的文化轉移常是最大的挑戰。 文化轉移之後的作業轉移需要花費時間和不懈的努力來實作、完善和趨於穩定。 在穩定的工作負載中可能需要進行架構轉移，而文化、營運和架構轉移又需要工具轉移來提供力量與支援。 這些轉移可能需要對主要雲端提供者做出承諾。 在進行這些變更之前所做的採用工作可能需要大量重新作業，而超出一般重構工作。
• 風險：此方法需要管理階層對變更策略做出承諾。 此外也需要技術小組的承諾，以克服學習曲線並提供所需的變更。 需要企業、CCoE 和中央 IT 與工作負載小組之間的長期合作，才能看到長期優點。
• 指引：Azure 登陸區域選項會定義為 企業級。 這些選項提供參考實作，以示範技術變更如何在 Azure 中使用雲端原生工具傳遞。 企業規模方法可引導小組完成必要的營運和文化轉移，以充分利用這些實作。 您也可以採用相同的方法調整參考架構，以根據您的採用策略和合規性限制適當設定環境。 當您實作企業級時，治理和管理方法可協助定義程式。 這些程式可以擴充您的合規性和作業功能，以符合您的作業需求。

企業作業的優點

• 成本管理：集中式小組會處理跨組合的最佳化，並且讓個別工作負載小組負責更深入的工作負載最佳化。 工作負載焦點小組能夠做出決策，並在這些決策具有負面成本影響時提供清楚明瞭。 集中式和工作負載小組會在適當層級共同承擔成本決策的責任。
• 責任：集中式小組會使用雲端原生工具來定義、強制執行和自動化護欄。 工作負載小組的工作可透過 CCoE 自動化與實務準則加速完成。 工作負載小組可推動創新並在這些護欄內做出決策。
• 標準化：集中式護欄和基本服務可在所有環境間建立一致性。
• 作業支援：需要集中式作業支援的工作負載，會劃分到具有穩定狀態控制的環境中。 職責的區隔和劃分可讓工作負載小組在其專屬的環境中對作業支援負起責任。 自動化的雲端原生工具可確保所有具有集中式作業支援的環境都符合最低作業基準。
• 專業知識：集中核心服務，例如安全性、風險、治理和作業，可確保適當的中央專業知識。 清晰的程序和護欄可讓工作負載小組獲得必要的知識和權限，以做出更詳細的決策。 這些決策可擴大集中式專業知識的影響，而無須隨著技術規模以線性方式調整員工規模。
• 登陸區域設計：登陸區域設計會複寫組合的需求，並建立明確的安全性、治理和責任界限。 需要這些界限才能操作雲端中的工作負載。 分割實務不太可能與先前的資料中心設計所建立的限制類似。 在企業作業中，登陸區域設計較不複雜，可讓您更快速地調整規模，並減少自助需求的阻礙。
• 基礎公用程式：基礎公用程式裝載於集中控制的個別訂用帳戶中，名為平台基礎。 中央工具接著會以管道傳送到每個登陸區域作為公用程式服務。 將基礎公用程式與登陸區域分開，可讓一致性和規模效益達到最大。 這些公用程式也可清楚區分集中管理的責任與工作負載層級的責任。
• 職責區分：明確區分基礎公用程式與登陸區域之間的職責，是作業方法中最大的優點之一。 雲端原生工具和程式支援集中小組與工作負載小組之間的存取權和適當平衡控制。 此方法以個別登陸區域的需求和登陸區域區段中裝載之工作負載的需求為基礎。

企業作業的缺點

• 成本管理：集中式小組相依於工作負載小組，以在登陸區域內進行生產變更。 此轉移會產生潛在的預算超支風險，並且使適當調整實際支出的速度變慢。 成本控制程序、明確的預算、自動化的控制和定期檢閱必須及早進行，以避免成本超出預期。
• 責任：企業作業需要更高的文化和營運需求。 這些需求可確保集中式和工作負載小組之間有清楚的權責劃分。
• 傳統的變更管理程序或變更諮詢委員會 (CAB) 可能無法維持此作業模型所需的步調和平衡。 這些程式會反映在自動化流程和程式，以安全地調整雲端採用。
• 缺乏變更的承諾會先具體化交涉和責任的一致性。 無法隨著責任的轉移進行調整，意味著在短期雲端採用工作期間可能需要集中式 IT 作業模型。
• 標準化：若未投資於集中式護欄或自動化，將會產生標準化的風險，而這更難以透過手動檢閱程序來克服。 登陸區域中的工作負載和共用服務之間的作業相依性會產生更高的風險。 這些風險源自基礎公用程式升級週期或未來版本的標準化。 在平台基礎修訂期間，所有支援的登陸區域及其裝載的工作負載都需要進行改善甚或自動化測試。
• 作業支援：透過自動化和集中式作業提供的作業基準可能足以降低影響或低重要性工作負載。 但工作負載小組或其他形式的專用作業，對於複雜或高關鍵性工作負載可能需要。 如果是，它可能會建立營運預算的轉移，要求業務單位為這些形式的進階作業提供營運費用。 如果需要中央 IT 來維護營運成本的唯一責任，則企業作業可能難以實作。
• 專業知識：可能需要中央 IT 小組成員，才能開發先前透過手動程式傳遞的中央控制項專業知識。 此外，這些小組可能需要熟練運用來定義環境的基礎結構即程式碼方法，並了解分支、合併和部署管線。 至少，平臺自動化小組可能需要決策制定技能，以瞭解雲端卓越中心或中央營運小組所做的決策。 工作負載小組可能需要開發更多與控管其決策的控制和程序相關的知識。
• 登陸區域設計：登陸區域設計相依於基礎公用程式。 工作負載小組應該瞭解設計的內容，以及禁止包含的內容。 此一理解可能有助於避免重複的工作、錯誤或衝突。 若要建立彈性，您可以將例外狀況程式納入登陸區域設計。
• 基礎公用程式：集中式基礎公用程式需要時間。 這些公用程式最後會考量各種選項，並開發可調整以符合各種採用計劃的解決方案。 早期採用工作可能會延遲。 就長期而言，延遲是可抵消的，因為可在後續的程序中加快速度並規避一些障礙。
• 職責區分：要確保明確的職責區分，需端賴成熟的身分識別管理程序。 可能會有更多維護與使用者、群組和上線和上線活動的適當對齊方式相關聯。 您可能需要採用新的程式，以透過提高的許可權來容納 Just-In-Time 存取。

分散式作業

現有的作業模型可能過於根深蒂固，而無法讓整個組織轉移至新的作業模型。 此外，全域作業和各種合規性需求可能會使特定業務單位無法進行變更。 在此情況下，可能需要分散式作業方法。 這種方法到目前為止最複雜，因為它需要整合一或多個先前提及的作業模型。

雖然不建議這麼做，但某些組織可能需要此作業方法。 此方法主要與組織有鬆散的不同業務單位集合、不同客戶群或區域營運。

• 優先順序：整合多個現有的作業模型。
• 在過渡狀態，重點是將整個組織移至先前所述的作業模型之一。
• 當組織太大或太複雜而無法配合單一作業模型時，應採用長期作業方法。
• 相異的優點：整合來自每個業務單位的一般作業模型元素。 這種方法會建立一個車輛，將作業單位分組到階層中，以協助他們使用一致的可重複程式進行成熟作業。
• 明顯的缺點：跨多個作業模型的一致性和標準化很難長時間維護。 此作業方法需要深入瞭解組合，以及各種技術組合區段的運作方式。
• 風險：缺少對主要作業模型的承諾，可能會導致小組間的混淆。 當沒有任何方法可對齊單一作業模型時，請使用此作業模型。
• 指引：首先請使用業務配合一文中所述的方法，對組合進行完整的檢閱。 嘗試依狀態作業模型將組合分組 (分散式、集中式或企業)。
• 開發可反映作業模型群組的管理群組階層。 這項安排包括區域、業務單位或其他準則的其他組織模式，這些準則會將工作負載叢集從最不常見到最常見的貯體對應。
• 評估工作負載與作業模型的一致性，以找出最相關的作業模型叢集，並開始使用。 對於節點和管理群組階層下的所有工作負載，依照作業模型的對應指引操作。
• 使用控管和管理方法來尋找常見的公司原則，包括階層各種點的必要作業管理做法。 套用常用的 Azure 原則，將共用的公司原則自動化。
• 當您使用各種部署來測試 Azure 原則時，請嘗試在管理群組階層中將其移至較高層級。 原則可以套用至許多工作負載，而可能會出現共通性和不同的作業需求。
• 經過一段時間後，此方法可協助您定義可在各種作業模型之間調整的模型。 此方法也可能會透過一組常見的原則和程序來統合各個小組。

我們刻意未說明此方法的優缺點。 當您完成組合的業務協調後，請參閱上面的主要作業模型一節，以了解相關優缺點。

後續步驟

了解與作業模型相關聯的術語。 透過這些術語，您可以了解作業模型如何融入更大的公司規劃主題中。

作業模型術語

了解登陸區域如何提供任何雲端採用環境的基本建置區塊。

什麼是登陸區域？