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

作業模型是其所支持業務的唯一且專屬的，根據其目前的需求和限制。 但運營模式不會 雪花。 客戶作業模型有數種常見模式;本文概述四種最常見的模式。

作業模型比較

下圖會根據複雜度範圍，將通用作業模型從最不複雜（分散式）對應到最複雜（全域作業）。 下表根據其他幾個屬性的相對值，比較相同的作業模型。

優先順序或範圍

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

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

	分散式作業（作業）	集中式作業（Ops）	企業營運作業	分散式作業 （作業）
策略性優先順序或動機	創新	控制	民主化	集成（或整合）
公事包範圍	工作量	登陸區域	雲端平臺	完整投資組合
工作負載環境	高複雜度	複雜度低	中度複雜度	中度或變數複雜度
登陸區域	N/A	高複雜度	中至低複雜度	複雜度低
基礎框架公用程式	N/A	N/A 或低支援	集中式和更多支援	大部分支援
雲端基礎	N/A	N/A	混合式、提供者特定或區域基礎	分散式和同步處理

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

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

重要

採用雲端通常會觸發對目前作業模型的反映，並可能導致從一個常見的作業模型轉移到另一個作業模型。 但雲端採用並不是唯一的觸發因素。 商務優先順序和雲端採用的範圍可以變更組合需要支援的方式。 此外，最適合的作業模型可能會發生其他變化。 當董事會或其他執行團隊開發 5 到 10 年的業務計劃時，這些計劃通常包括調整運營模式的需求（明確或隱含）。 作業模型是引導決策的良好參考。 這些模型可能會變更或需要自定義，以符合您的需求和條件約束。

責任調整

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

	分散式作業	集中式作業	企業運營	分散式作業
業務協調	工作負載小組	中央雲端策略	CCoE	變數 - 組成廣泛的雲策略小組？
雲端作業	工作負載小組	中央資訊科技	CCoE	根據投資組合分析 - 請參閱 業務對齊 和 業務承諾
雲端治理	工作負載小組	中央 IT	CCoE	多層治理
雲端安全性	工作負載小組	安全性作業中心（SOC）/ DevSecOps 功能	CCoE + SOC	混合 - 參見定義安全策略
雲端自動化和DevOps	工作負載小組	中央資訊技術部門 或 不適用	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) 應用程式或發行步調緩慢的成熟自定義應用程式。 如果變更率是由一般更新和修補程式所驅動，則集中作業可能是管理組合的有效方式。

• 優先順序：優先順序是創新的中心控制，並評估現有的運營流程與向現代雲端作業的文化轉變。
• 不同的優勢：集中化引進了規模經濟、最佳品種的控制措施和標準化的作業，並最適合與雲端環境搭配使用。 這些環境需要特定的設定，才能將雲端作業整合到現有的作業和流程中。 集中化在擁有數百個工作負載組合且具有適度架構複雜度和合規需求的情況下最為有利。
• 明顯的劣勢：擴展以應對大量工作負載的需求，可能會對集中式團隊造成重大壓力，因為他們需要為生產工作負載做出操作決策。 如果預期技術資源在未來 18 到 24 個月內的調整規模會超過 1,000 個 VM、應用程式或數據來源，您可能需要考慮使用企業級模型。
• 風險：此方法會將集中化限製為較小的訂用帳戶數目（通常是一個生產訂用帳戶）。 在雲端應用過程中的稍後階段進行重構時，涉及重大風險，並可能會干擾您的部署計劃。 若要避免重新作業，請嘗試專注於分割、環境界限、身分識別工具和其他基礎元素。
• 指引：Azure 登陸區實作選項符合「由小開始，再擴展」的開發步伐，可建立穩健的起點。 您可以使用這些選項來加速採用工作。 但要成功，應建立明確的政策，以在可接受的風險容忍度內引導早期採用工作。 控管和管理方法可協助建立流程，以平行方式讓作業成熟。 遵循這些步驟作為必須完成的階段關卡，才能在作業成熟時允許增加風險。

集中式作業的優點

• 成本管理：將共用服務集中到許多工作負載，會產生規模經濟，並消除重複的工作。 中央團隊可以透過企業範圍的規模和效能優化，快速實施成本降低。
• 責任：集中式專家化和標準化可能會導致更高的穩定性、更好的作業效能，以及最少的變更相關中斷。 這種方法可降低專注於工作負載的團隊面對的廣泛技能要求。
• 標準化：一般而言，集中式模型作業的標準化和成本最低，因為重複的系統或工作較少。
• 作業支援：減少複雜度和集中式作業，可讓較小的 IT 小組更輕鬆地支持作業。
• 專長： 集中式支援小組可讓安全性、風險、治理和作業方面的專家推動業務關鍵性決策。
• 登陸區域設計：中央 IT 可藉由將登陸區域和訂用帳戶數目降至最低，以減少複雜性。 登陸區域設計通常會模擬先前的數據中心設計，以減少轉換時間。 隨著採用的進行，共用資源可能會移至個別的訂用帳戶或平台基礎。
• 基礎公用程式：您可以將現有的數據中心設計帶入雲端，以產生模擬內部部署工具和作業的基礎共用服務。 當內部部署作業是您的主要作業模型時，這可能是一個優點，但請注意一些缺點。 內部部署作業可減少轉換時間、利用規模經濟，並支持內部部署與雲端裝載工作負載之間的一致作業程式。 這種方法可以降低短期的複雜度和精力，讓較小的小組透過減少學習曲線來支援雲端作業。
• 職責分離：在中央作業中，職責分離是清晰的。 中央 IT 部門維持對生產環境的控制，並減少其他小組需要提升許可權的情況。 這種方法可藉由限制具有高級權限的帳戶數量來減少安全漏洞。

集中式作業的缺點

• 成本管理：中央團隊不總是了解工作負載架構，無法在工作負載層級達成有效的優化。 缺乏理解會限制由於運行工作負載的精細調整而產生的成本節省量。 不完全瞭解工作負載架構可能會影響集中式成本優化，這會影響妥善架構工作負載的效能、規模和其他要素。 在將全企業成本變更套用至高優先工作負載之前，您的中央資訊技術團隊應該先瞭解並完成 Microsoft Azure Well-Architected 檢閱。
• 責任：集中生產支援和准入給少數人帶來高操作負擔，對每個人施加更大的壓力。 對這些個人施加的壓力會導致需要對已部署工作負載執行更深入的檢閱，以驗證遵守詳細的安全性治理和合規性需求。
• 標準化：中央IT策略使標準化難以擴展，而不需要中央IT人員的人數隨之線性增加。
• 作業支援：此方法的最大缺點在於其與測量創新的重大規模和變化相關聯。
• 專長： 開發人員和DevOps專家在這類環境中面臨價值過低或太受限的風險。
• 登陸區域設計：數據中心設計是以上述方法的限制為基礎，這些方法不一定與雲端相關。 遵循這種方法會減少重新思考環境分割的機會，並削弱促進創新的可能。 缺乏落地區域劃分會增加安全漏洞的潛在影響、治理和遵循合規性的複雜性，並可能會阻礙雲端採用之旅。 請參閱上述風險一節。
• 基礎公用程式：在數位轉型期間，雲端可能會成為主要作業模型。 專為內部部署作業所建置的中央工具，可減少將作業現代化並提升營運效率的機會。 選擇不在採用過程的早期將作業現代化也是一種選擇。 在雲端採用旅程中建立平臺基礎訂用帳戶，即可實現現代化。 如果不進行進階規劃，這項工作可能很複雜、昂貴且耗時。
• 職責分離：中央行動通常遵循兩個途徑之一，兩者都可能會阻礙創新。
  • 選項 1：中央 IT 的外部團隊獲得模擬生產環境的有限存取權。 此選項會阻礙實驗。
  • 選項 2：Teams 在不支援的環境中進行開發和測試。 此選項會阻礙部署程式，並降低部署後整合測試的速度。

企業作業

企業作業是所有雲端作業的建議目標狀態。 企業營運藉由簡化決策和責任，平衡控制與創新的需求。 中央資訊技術部門被更具協助性的雲端卓越中心或 CCoE 小組所取代，這些小組支援工作負載團隊。 CCoE 小組要求工作負載小組對決策負責，而不是控制或限制其行為。 工作團隊被賦予更多權力和責任，能在明確的框架內推動創新。

• 優先順序：優先順序是技術決策的民主化。 技術決策的民主化會將先前由中央IT所擔任的責任轉移到工作負載小組。 為了實現這一優先順序的轉變，決策會變得較不依賴人工操作的審核流程。 此方法支援使用雲端原生工具自動檢閱、治理和強制執行。
• 不同的優勢：環境分割和職責分離允許控制與創新之間的平衡。 集中式作業維持需要加強合規性和穩定狀態運營的工作負載，或具有較大的安全風險。 相反地，此方法支持減少需要更大創新之工作負載和環境的集中式控制。 較大的投資組合可能會與控制與創新之間的平衡作鬥爭。 這種彈性可讓您更輕鬆地調整數千個工作負載，減少作業痛點。
• 明顯的劣勢：內部部署的方案在企業雲端運營中可能效果不佳。 此作業方法需要許多前端的變更。 控制與責任的文化轉變往往是最大的挑戰。 文化轉變之後，運營轉變需要時間以及付出努力來實施、成熟和穩定。 在穩定的工作負載中可能需要進行架構轉變，而需要工具上的調整來支援文化、操作和架構的轉變。 這些變動可能需要承諾使用主要的雲端服務提供者。 在進行這些變更之前所做的採用工作可能需要大量重新作業，而不只是一般重構工作。
• 風險：這種方法需要高層對變更策略的承諾與支持。 它也需要技術小組的承諾與投入，以克服學習曲線的挑戰並實現所需的變更。 企業、CCoE、中央 IT 以及工作負載團隊之間需要長期合作，才能看到長期效益。
• 指引：Azure 登陸區域選項定義為企業級。 這些選項提供參考實作，以示範技術變更如何在 Azure 中使用雲端原生工具傳遞。 企業級方法會引導小組完成充分利用這些實作所需的營運和文化轉變。 這種方法可能會根據您的採用策略和合規約束，量身打造參考架構，來配置環境。 當您實作企業級時，治理和管理方法可協助定義程式。 這些程式可以擴充您的合規性和作業功能，以符合您的作業需求。

企業作業的優點

• 成本管理：中央小組會處理跨組合優化，並讓個別工作負載小組負責更深入的工作負載優化。 以工作負載為中心的小組被授予了決策權，並在這些決策導致成本產生負面影響時提供明確指導。 中央和工作負載小組共同承擔在適當層級做出成本決策的責任。
• 責任：中央小組會使用雲端原生工具來定義、強制執行和自動化護欄。 工作團隊的努力透過 CCoE 自動化和實踐得以加速。 工作團隊被賦予推動創新和在這些準則內做出決策的權力。
• 標準化：集中式護欄和基礎服務，在所有環境中建立一致性。
• 作業支援：需要集中式作業支援的工作負載會分配到具有穩定環境管控的環境。 分割和區分職責可讓工作負載小組在自己的專用環境中對作業支持負責。 自動化雲端原生工具可確保具有集中式作業支援的所有環境的最低作業基準。
• 專業知識：將安全性、風險、治理和作業等核心服務集中，可確保適當的集中專業知識。 清楚的流程和指引引導工作負載小組，並賦予他們權力做出更詳盡的決策。 這些決策會擴大集中式專家的影響，而不需要以技術規模線性方式調整員工規模。
• 登陸區域設計：登陸區域設計會複製投資組合的需求，建立清晰的安全性、治理和責任界限。 在雲端中操作工作負載需要這些界限。 分割做法不太可能類似於先前數據中心設計所建立的條件約束。 在企業營運中，登陸區域設計較不複雜，可加快規模並降低自助需求的障礙。
• 基礎公用程式：基礎公用程式裝載於個別的集中控制訂用帳戶中，稱為平台基礎。 然後，中心工具會作為實用服務導管傳送到每個著陸區。 將基礎公用程式與登陸區域分開，將一致性和規模經濟最大化。 這些公用程式也會在集中管理的責任和工作負載層級責任之間建立明確的區別。
• 職責分離：基本公用事業和登陸區域之間的職責明確分離是作業方法中最大的優勢之一。 雲端原生工具和程序支援集中式小組與工作負載小組之間的存取權和適當的控制權平衡。 此方法是以個別登陸區域的需求和裝載於登陸區域區段的工作負載為基礎。

企業作業的缺點

• 成本管理：中央小組更依賴工作負載小組在登陸區域內進行生產變更。 此轉變會產生潛在的預算超支風險以及實際支出合理化速度較慢的風險。 成本控制程式、清楚的預算、自動化控件和定期檢閱必須早到位，以避免成本意外。
• 責任：企業營運需要更大的文化和作業需求。 這些需求可確保中央和工作負載小組之間的責任和責任清楚明瞭。
• 傳統的變更管理流程，或變更諮詢委員會（CABs），可能無法維持此作業模型中所需的步調和平衡。 這些過程反映在自動化過程與程序中，這些過程和程序可安全地擴大雲端採用的規模。
• 缺乏對改變的承諾首先體現在談判和責任的協調上。 無法在責任轉移上達成一致，這表示在短期雲端採用工作期間可能需要中央 IT 運行模型。
• 標準化：缺乏集中護欄投資或自動化，對標準化造成風險，較難以通過手動審核程式克服。 登陸區域和共用服務中的工作負載之間的作業相依性會產生更大的風險。 這些風險延伸至升級週期中的標準化過程，或未來版本的基礎公用程式。 在進行平臺基礎的修訂時，所有支援的著陸區和其承載的工作負載都需要進行改進或自動化的測試。
• 作業支援：透過自動化和集中式作業提供的作業基準可能足以滿足低影響或低關鍵性的工作負載。 但是，處理複雜或高關鍵性的工作負載可能需要負載團隊或其他形式的專用作業。 如果是這樣，這可能會引起營運預算的變動，要求業務單位將營運費用分配給這些形式的進階作業。 如果需要集中 IT 來維持對營運成本的唯一責任，則企業作業可能難以實作。
• 專業知識：中央 IT 小組成員可能需要開發在自動化先前透過手動程序傳遞的集中控件上的專長。 此外，這些團隊可能會開發基礎設施即程式碼的方法的技術能力，以定義環境，並理解分支、合併和部署管線。 至少，平臺自動化小組可能需要決策技能，才能瞭解卓越雲端中心或中央作業小組所做的決策。 工作負載小組可能需要開發更多與控制其決策的控件和程式相關的知識。
• 登陸區域設計：登陸區域設計取決於基礎公用程式。 工作負載小組應該了解設計中已包含和禁止包含的內容。 這項瞭解可能有助於避免重複工作、錯誤或衝突。 若要建立彈性，您可以將例外狀況程式納入登陸區域設計。
• 基礎公用程式：集中式基礎公用程式需要時間。 這些公用程式最終會考慮選項，並開發可調整以符合各種採用計劃的解決方案。 早期採用工作的延遲是可能的。 延遲可能會由於過程中後續的加速和阻礙的避免而在長期內被抵消。
• 職責分離：確保職責的明確分離需要成熟的身分識別管理程式。 可能需要更多的維護，以確保使用者和群組的協調，以及開展員工入職和離職活動。 您可能需要採用新的流程，以配合透過提升的許可權進行即時存取。

分散式作業

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

雖然非常不鼓勵，但某些組織可能需要此作業方法。 此方法主要與組織有鬆散的不同業務單位集合、不同客戶區隔或區域營運基礎的組織有關。

• 優先順序：整合多個現有的作業模型。
• 過渡狀態，著重於將整個組織移至先前提及的其中一個作業模型。
• 當組織因規模或複雜性無法適應單一作業模型時，可採取長期的運營策略。
• 不同優勢：整合每個業務單位的一般作業模型元素。 此方法創建一種系統，將運營單位分組為一個有層級的架構，以協助它們使用一致且可重複的流程來成熟其運作。
• 相異缺點：跨多個作業模型的一致性和標準化難以長期維護。 此作業方法需要深入了解組合，以及技術組合的各個區段的運作方式。
• 風險：缺乏對主要作業模型的承諾可能會導致整個小組混淆。 當無法對齊單一作業模型時，請使用此作業模型。
• 指引：從徹底檢閱投資組合開始，該投資組合會使用 商業協調 文章中所述的方法。 嘗試依狀態作業模型將組合分組（分散式、集中式或企業）。
• 開發反映作業模型群組的管理群組階層。 此安排包括按區域、業務單位或其他準則劃分的其他組織結構，這些準則將工作負載分組從最不常見到最常見的類別進行對應。
• 評估工作負載與作業模型的對齊方式，以尋找最相關的作業模型叢集。 請遵循對應至節點與管理群組階層下所有工作負載的作業模式指引。
• 使用治理和管理方法來尋找常見的公司原則，包括階層各個點所需的作業管理做法。 套用常見的 Azure 原則，以自動化共用的公司原則。
• 當您使用各種部署來測試 Azure 原則時，請嘗試在管理群組階層中將其移至較高層級。 這些原則可以套用至許多工作負載，這些工作負載可能會發現共同點和不同的作業需求。
• 一段時間后，此方法可協助您定義可跨各種作業模型進行調整的模型。 這種方法也可能透過一組常見的原則和程式來統一小組。

此方法的優點和缺點是刻意留白。 完成組合的業務對齊之後，請參閱上面的主要作業模型一節，以清楚瞭解優點和缺點。

後續步驟

瞭解與作業模型相關聯的術語。 術語可協助您了解作業模型如何融入企業規劃的更大主題。

作業模型術語

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

什麼是登陸區域？