組合階層
若要瞭解工作負載、資產和支援服務 的組合 如何一起運作，您需要建立組合階層。 本文提供組合階層層級的清楚定義，以及小組針對每個層級的預期提供指引。 在本文中，階層的每個層級也稱為範圍。
工作負載
提供已定義商務價值的技術集合稱為工作負載。 集合可能包含應用程式、伺服器或虛擬機器、資料、裝置和其他類似群組的資產。 大部分企業都依賴於多個工作負載來提供重要的商務功能。
一般來說，商務專案關係人和技術領導人會針對每個工作負載的持續支援而共用承擔當責。 在工作負載生命週期的某些階段中，這些角色會明確定義。 在工作負載生命週期的更多作業階段中，這些角色可能會轉換成共用的作業管理小組或雲端作業小組。 隨著工作負載數目的增加，角色 (明示或暗示) 變得更複雜且矩陣化。
工作負載及其支援的資產是任何組合的核心。 範圍或層級會定義這些工作負載的檢視方式，以及它們受到潛在支援小組矩陣影響的程度。
雖然字詞可能不同，但所有 IT 解決方案都包含資產和工作負載：
- 資產：支援工作負載或解決方案的技術功能最小單位。
- 工作負載：IT 對商務支援的最小單位。 工作負載是基礎結構、應用程式和資料資產的集合，可支援一般商務目標或執行一般商務程式。
當您部署第一個工作負載時，工作負載和其資產可能是唯一定義的範圍。 其他層可能會隨著部署的工作負載增加而確定義。
IT 組合
當公司透過矩陣化方法或集中式方法來支援工作負載時，可能會有更廣泛的階層可援這些工作負載：
- 登陸區域： 登陸區域會提供支援一或多個工作負載所需的必要基礎公用程式或共用管道的工作負載。 登陸區域在雲端中非常重要，雲端採用架構的整個就緒方法著重于登陸區域。 如需更詳細的定義，請參閱什麼是登陸區域？
- 基礎公用程式：需要這些共用的 IT 服務，工作負載才能在技術和商務組合內運作。
- 平台基礎：此組織建構會將基礎解決方案集中化，並協助確保會對所有登陸區域強制執行這些控制項。
- 雲端平臺： 視支援完整組合的整體策略而定，客戶可能需要具有不同平臺基礎部署的多個雲端平臺，以控管多個區域、混合式解決方案，甚至是多重雲端解決方案。
- 組合：透過技術功能濾鏡，組合是橫跨所有雲端平台的工作負載、資產和支援資源的集合。 透過商務功能濾鏡，組合是專案、人員、程序和投資的集合，可支援及管理技術組合以推動商務成果。 這兩個功能濾鏡會共同擷取組合。
階層當責與指導方針
當責小組會管理組合階層的每一層。 下圖顯示當責小組與指導方針之間的對應，以支援其商務決策、技術決策和技術實作。
注意
下列清單所述的小組可能是虛擬小組或個人。 針對此階層的某些變化，可以摺疊部分當責小組，如稍後的當責變化中所述。
- 投資 組合： 雲端策略小組和卓越雲端中心 (CCoE) 使用 策略 和 計畫 方法來引導影響整體組合的決策。 雲端策略小組負責雲端組合階層的企業層級。 雲端策略小組也應該獲悉環境、登陸區域和高優先順序工作負載的相關決策。
- 雲端平臺： 雲端治理小組負責專業領域，以確保每個環境的一致性與 治理 方法一致。 雲端治理小組負責管理所有環境中的所有資源。 雲端治理小組應接受針對可能需要例外或變更控管原則的相關變更進行諮詢。 雲端治理小組應該也要獲悉工作負載和資產採用進度的通知。
- 登陸區域和雲端基礎：雲端平台小組負責開發支援採用的登陸區域和平台公用程式。 雲端自動化小組負責將這些登陸區域和平台公用程式的開發和持續支援自動化。 這兩個小組都使用 就緒 方法來引導實作。 這兩個小組都應該在工作負載採用進度和對企業或環境有任何變更時收到通知。
- 工作負載：採用會在工作負載層級進行。 雲端採用小組會使用 移 轉與 創新 方法來建立可調整的程式，以加速採用。 採用完成之後，工作負載的擁有權可能會轉移至雲端作業小組，該小組會使用 管理 方法來引導作業管理。 這兩個小組都應該對於使用 Microsoft Azure Well-Architected Framework，以進行會影響其支援工作負載的詳細架構決策感到安心。 這兩個小組都應該收到對登陸區域和環境變更的通知。 這兩個小組可能偶爾會參與登陸區域功能。
- 資產：資產通常是雲端作業小組的責任。 該小組會使用 管理 方法中的管理基準來引導作業管理決策。 此外也應該使用 Azure Advisor 和 Azure Well-Architected Framework 來進行提供作業需求所需的詳細資源和架構變更。
當責變化
- 單一環境：當企業只需要一個環境時，通常不需要 CCoE。
- 單一登陸區域：如果環境只有一個登陸區域，則治理和平台功能可能會合併為一個小組。
- 單一工作負載： 有些企業只需要單一登陸區域和單一環境中的一個工作負載或一些工作負載。 在這些情況下，不太需要治理、平台和作業小組之間的職責區分。
常見的工作負載和當責範例
下列範例說明公事包階層。
COTS 工作負載
傳統上，企業會有商業現成軟體 (COTS) 軟體解決方案，以增強商務程序。 這些解決方案會經過安裝、設定，然後運作。 在設定之後，解決方案架構不會有任何變更。
在這些案例中，COTS 解決方案的任何雲端採用，都會隨著轉換到雲端作業小組而結束。 然後，雲端作業小組會成為該軟體的技術擁有者，並承擔管理設定、成本、修補週期和其他作業需求的當責。
這些工作負載包括帳務處理套件、物流軟體或產業特定解決方案。 在 Microsoft 術語中，這些套件的廠商稱為獨立軟體廠商 (ISV)。 許多 ISV 都提供一項服務，可在您的訂用帳戶中部署及維護其軟體套件的執行個體。 他們也可能提供在其自己的雲端裝載環境中執行的軟體套件版本，為工作負載提供平台即服務 (PaaS) 替代方案。
除了 PaaS 供應專案之外，雲端作業小組負責確保這些工作負載的基本作業合規性需求。 雲端作業小組應與雲端治理小組合作，以配合成本、效能和其他架構要素。
開發中搭配作用中修訂
當 COTS 解決方案或 PaaS 供應項目未配合商務需求，或沒有解決方案存在時，企業會建置自訂開發的工作負載。 一般而言，只有一小部分的 IT 組合會使用此工作負載方法。 但是，這些工作負載往往會運用不成比例的高百分比 IT 貢獻來獲得業務成果，尤其是與新收益錢潮相關的成果。 這些工作負載往往可與新創意構想良好對應。
從敏捷方法和 DevOps 做法發展而來的各種不同的移動，這些工作負載支持商務/DevOps 一致性優先於傳統的 IT 管理。 針對這些工作負載，可能會有數年不會對雲端作業小組進行遞交。 在這些情況下，開發小組會擔任工作負載的技術擁有者。
由於大量時間和資本限制，自訂開發選項通常受限於高價值的機會。 一般的範例包括應用程式創新、深度資料分析或任務關鍵性商務功能。
中斷/修正或終止開發
在自訂開發的工作負載達到尖峰成熟度之後，開發小組可能會重新指派給其他專案。 在這些情況下，技術擁有權通常會轉換為雲端作業小組。 需要小型修正時，作業小組會登錄開發人員以解決該錯誤。
在某些情況下，開發小組會移至最終會取代目前工作負載的專案。 或者，小組可能會繼續進行，因為工作負載支援的商機已分階段。在這些終止案例中，雲端作業小組會作為技術擁有者，直到不再需要工作負載為止。
在這兩個案例中，雲端作業小組通常會擔任長期的技術擁有者和決策制訂者。 當作業變更需要大量架構變更時，該小組可能會登記應用程式開發人員。
任務關鍵性工作負載
在每家公司中，有一些工作負載對於讓企業失敗而言太重要。 有了這些任務關鍵性的工作負載，通常會有具備各種責任等級的作業和開發擁有者。 這些小組應配合作業變更與架構變更，以將對生產解決方案的中斷降到最低。
這些案例需要高度聚焦於職責區分。 營運小組通常會負責生產環境中的日常作業變更。 當這些作業變更需要架構變更時，這些變更會由非生產環境中的開發或採用小組完成，之後作業小組才將變更套用至生產環境。
具有必要職責區分的任務關鍵性工作負載的範例包括 SAP、Oracle 或其他企業資源規劃 (ERP) 解決方案之類的工作負載，橫跨公司中的多個業務單位。
策略組合一致性
務必了解雲端採用工作的策略性目標，並配合組合以支援該轉換。 一些常見類型的策略性組合一致性有助於塑造組合階層的結構。 下列各節提供組合對齊方式和對公事包階層的影響範例。
創新或開發導向的組合
某些公司，特別是快速成長的啟始公司，具有高於自訂開發專案的平均百分比。 在大量開發組合中，環境、登陸區域和工作負載通常會壓縮，因此特定工作負載可能會有特定環境。 結果是環境、登陸區域和工作負載之間的 1：1 比率。
因為環境會裝載自訂解決方案，DevOps 管線和應用程式層級的報告可能會取代作業和治理功能的需求。 這些客戶可能會減少對作業、控管或其他支援角色的焦點。 更重視雲端採用和雲端自動化小組的責任也很常見。
組合一致性：IT 組合可能會聚焦於工作負載和工作負載擁有者，以促進重要的架構決策。 在採用和作業活動期間，這些小組可能會在 Azure Well-Architected Framework 指導中找到更多價值。
界限定義：邏輯界限，即使是企業層級，也可能聚焦於生產環境和非生產環境區分。 公司軟體組合中的產品之間可能也有清楚的分割。 有時候，開發和主控的客戶執行個體之間可能也會有分割。
作業導向的組合
具有更多 IT 作業小組的跨國企業組織，通常會更高度聚焦於治理和作業，而非開發。 在這些組織中，較高百分比的工作負載通常會與雲端營運小組內的技術擁有者維護的一或多個中斷/修正類別一致。
組合一致性：IT 組合將會配合工作負載，但是這些工作負載接著會配合作業單位或業務單位。 此外，組織可能也會有關於投資模型、產業或其他商務分割需求。
界限定義：登陸區域可能會將應用程式群組為應用程式原型，以在類似的分割中保持類似的作業。 環境很可能指的是資料中心、全國、雲端提供者區域或其他作業組織標準等實體建構。
移轉導向的組合
類似於作業導向的組合，主要透過移轉建立的組合，將以會導致現有資產移轉的特定商業動因為基礎。 一般來說，資料中心是這些動因的最大因素。
組合一致性：IT 組合可能會配合工作負載，但更可能會配合資產。 如果公司過去發生轉換到 IT 作業，許多使用中的資產可能無法輕易地對應至已投資的工作負載。 在這些情況下，許多資產可能沒有已定義的工作負載明確的工作負載擁有者，直到之後在移轉程序中為止。
界限定義：登陸區域可能會將應用程式群組為界限，以反映內部部署分割。 雖然不是最佳做法，但環境通常會比對代表網路分割做法的內部部署資料中心名稱和登陸區域。 更好的做法是遵循更緊密配合營運導向組合的分割。
治理導向的組合
應盡早與治理小組配合。 透過治理做法和雲端治理工具，組合和環境界限可充分平衡創新、作業和移轉工作的需求。
組合一致性：治理導向的組合傾向於包含資料點，其會擷取創新和作業的詳細資料，例如工作負載、作業擁有者、資料分類和作業重要性。 這些資料點會建立組合的廣泛觀點。
界限定義：治理導向的組合中的界限傾向於支持作業優先於創新，同時使用管理群組導向的階層，以與業務單位和開發環境的準則對應。 在階層的每個層級中，雲端治理界限可以有不同程度的原則強制執行，以允許開發和創意的彈性。 同時，生產等級的需求也可以套用至生產訂用帳戶，以確保職責區分和作業一致。