# 操作模式 2 x 2 表示法
<a name="operating-model-2-by-2-representations"></a>

 這些操作模式 2 x 2 表示法屬於圖示，可協助您了解您環境中團隊間的關係。這些圖表著重於相應人員負責的相應工作和團隊間的關係，但我們也將討論在這些範例中的管控和決策制定。

 視支援的工作負載而定，您的團隊可能在數種模式中擔負數個部分的責任。您可能希望打破更專業的學科領域，而非描述的高階領域。隨著您劃分或彙整活動，或重疊團隊並提供更具體的詳細資訊，這些模式可能會有無限的變化。

 您可能會發現跨團隊間會有能夠提供其他優勢或發揮效率的重疊或尚未辨識的功能。您也可識別貴組織內尚未滿足，但自己打算解決的需求。

 評估組織變更時，請檢視模式間的權衡、您的個別團隊位於模式中的哪個階段 (目前和變更後)、您團隊的關係和責任將如何變更，以及效益是否能夠影響貴組織。

 您可以使用以下四種操作模式獲得成功。部分模式更適用於特定使用案例，或部署中的特定時間點。在您的環境中使用時，部分模式可能比其他模式更具優勢。

**Topics**
+ [完全獨立的操作模式](fully-separated-operating-model.md)
+ [DevOps 搭配雲端受管服務供應商](devops-with-cloud-managed-service-provider.md)
+ [雲端維運和平台啟用 (COPE)](cloud-operations-and-platform-enablement.md)
+ [分散式 DevOps](distributed-devops.md)
+ [分散式 DevOps](decentralized-devops.md)
+ [改進您的操作模式](evolving-your-ops-model.md)

# 完全獨立的操作模式
<a name="fully-separated-operating-model"></a>

 應用程式和平台位於下圖的垂直軸上。應用程式是指幫助實現業務成果的工作負載，可以是自訂開發或採購的軟體。平台是指實體和虛擬基礎設施，以及支援該工作負載的其他軟體。

 工程和操作位於水平軸上。工程是指開發、建置和測試應用程式和基礎設施。操作是指部署、更新及持續支援應用程式和基礎設施。

 

![\[傳統模式圖\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/operational-excellence-pillar/images/full-seperate.png)


 從歷史上看，組織採用了 ITIL 等架構或 ISO 等標準，並圍繞這些架構或標準制定營運活動，這通常會導致完全分離的拓撲。在此模式中，各象限中的活動由個別團隊執行。工作透過工作請求、佇列、票證或使用 IT 服務管理 (ITSM) 系統等機制，在團隊之間轉交。

 任務轉給團隊或團隊間的任務轉交會讓事情變得更複雜，並形成瓶頸與延誤。除非是要優先處理的請求，否則請求可能延誤處理。如果晚發現缺陷，可能需要大量重新作業，也可能需要再次交由相同的團隊和職務處理。如果發生需由工程團隊採取行動的事件，其回應會因遞交活動而受到延誤。

 當業務、開發和營運團隊根據正在執行的活動或職務組織時，目標不一致的風險會升高。如此會導致讓團隊專注於其特定責任，而非專注於達成業務成果。團隊可能專精於狹隘的領域，或在實際或邏輯空間上遭到分離，因而阻礙溝通與合作。

# DevOps 搭配雲端受管服務供應商
<a name="devops-with-cloud-managed-service-provider"></a>

「DevOps 搭配雲端受管服務供應商」模式遵循應用程式團隊的*誰開發誰執行*方法。但是，貴組織現有的技能或團隊成員可能無法支援專門的平台工程和營運團隊，或您可能不適合投入時間和人力物力來進行此工作。

或者，您可能想要擁有一個專注於建立讓您的企業脫穎而出之功能的平台團隊，但希望將無差異化的日常作業外包。

[AWS Managed Services](https://aws.amazon.com/managed-services/) 等受管服務供應商或 [AWS Partner Network](https://aws.amazon.com/partners/find/results/?keyword=Managed+Service+Provider)中的供應商都會提供實作雲端環境的專業知識，並支援您的安全和合規要求及業務目標。

![\[DevOps 搭配雲端受管服務供應商\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/operational-excellence-pillar/images/devops-msp.en.png)


就此變化而言，我們將透過平台團隊進行集中管控和管理，使用 AWS Organizations 和 AWS Control Tower 建立帳戶並管理政策。

此模式需要您修改機制，以與您的服務供應商的機制合作。它不會處理因團隊間 (包括您的服務供應商) 轉交任務而導致的瓶頸和延誤，或因晚發現缺陷而導致的潛在重新作業。

您可以獲得供應商標準、最佳實務、流程和專業知識的優勢。您也可以從其服務產品持續開發中獲得效益。

將受管服務加入操作模式後，便可節省時間和資源，讓您的內部團隊精簡並專注於將使您的企業脫穎而出的策略性成果，而非開發新技能和功能。它還可以為您提供時間來建置和成熟自己的平台功能，而不會降低雲端遷移計畫的速度。

# 雲端維運和平台啟用 (COPE)
<a name="cloud-operations-and-platform-enablement"></a>

此雲端維運和平台啟用 (COPE) 模式旨在透過支援應用程式團隊採用 DevOps 文化為工作負載執行工程和營運活動，從而建立*誰開發誰執行*方法。

您的應用程式團隊可能負責遷移、採用雲端或現代化工作負載，但可能不具有充分支援雲端架構和營運的現有技能。應用程式團隊能力和熟悉度的缺乏可能會降低組織的敏捷性並影響業務成果。

為了解決此問題，請使用貴組織內現有的營運專業知識來支援應用程式團隊的雲端維運之旅。這可以是一個專門的專家團隊，也可以是一個虛擬團隊，參與者是從整個組織中選出的。但是，目標保持不變，即提供營運支援，以培養工作負載團隊的能力，使用雲端優先的自動化原則，消除無差別的繁重工作，提供標準化模式，並促進自主性。目標是跨雲端功能培養足夠的成熟度並降低營運責任的障礙，以便應用程式團隊不再需要額外的支援。

COPE 模式著重於工作負載層級。如果多個團隊同時需要此方法，如果您正在執行複雜、大規模的多年遷移專案，或者您要建置支援這些計畫的平台，請考慮使用雲端卓越中心 (CCoE)。許多人在尋求加速遷移到雲端並廣泛轉型組織時，發現這種機制很成功。

![\[雲端維運和平台啟用 (COPE) 圖\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/operational-excellence-pillar/images/cope.en.png)


您的平台工程團隊會建置一層薄型的核心共用平台功能，這些功能是以預先定義的標準為基礎，供應用程式團隊採用並由 COPE 團隊提供。平台工程團隊編制透過自助服務機制提供給應用程式團隊的企業參考架構和模式。使用 AWS Service Catalog 等服務，應用程式團隊可以部署已核准的參考架構、模式、服務和組態，預設情況下符合集中控管和安全標準。

平台工程團隊還為應用程式團隊提供一組標準化服務 (例如，開發工具、可觀測性工具、備份和復原工具及聯網)。

COPE 團隊管理和支援標準化服務，並為應用程式團隊根據參考架構和模式建立雲端服務提供協助。他們與應用程式團隊合作，協助他們建立基準作業。在此過程中，應用程式團隊隨著時間的推移逐步對系統和資源承擔更多責任。COPE 團隊與平台工程團隊一起推動持續改進，並擔任應用程式團隊的擁護者。

應用程式團隊在設定環境、CI/CD 管道、變更管理、可觀測性和監控以及建立事件和事件管理程序方面取得協助，並視需要整合 COPE 團隊。COPE 團隊與應用程式團隊一起參與進行這些操作活動，隨著應用程式團隊取得擁有權，COPE 團隊會隨著時間的推移逐步停止參與。

應用程式團隊受益於 COPE 團隊的技能和組織所學到的經驗。其受到透過集中控管建立的防護機制保護。應用程式團隊以公認的成功案例為基礎，並從他們採用的組織標準的持續發展中獲益。透過建立可觀測性和監控的程序，他們可以更深入地了解工作負載的操作，並且能夠更好地了解他們對工作負載所做的變更的影響。

COPE 團隊還可以保留支援操作活動所需的存取權，提供跨應用程式團隊的企業操作視圖，並提供關鍵事件管理支援。COPE 團隊保留對視為無差別繁重工作的活動的責任，他們透過可大規模支援的標準解決方案來滿足這些活動。他們還繼續為應用程式團隊管理易於理解的程式設計和自動化操作活動，以便他們能夠專注於差異化其應用程式。

您可以取得貴組織源自團隊成功案例的標準、最佳實務、程序和專業知識的優勢。可建立一種機制來複寫這些成功模式，以便新團隊在雲端中採用或實現現代化。此模式強調 COPE 團隊協助應用程式團隊建立及轉換知識和成品的能力。它減輕了應用程式團隊的操作負擔，但也帶來了應用程式團隊無法變得獨立的風險。它在平台工程、COPE 和應用程式團隊之間建立關係，建立回饋迴圈以支援進一步發展和創新。

建立平台工程和 COPE 團隊，同時定義組織範圍內的標準，可以促進雲端採用並支援現代化工作。透過提供 COPE 團隊作為應用程式團隊的顧問和合作夥伴的額外支援，您可以消除工作負載層級的障礙，這些障礙會減緩應用程式團隊採用有益的雲端功能的速度。

# 分散式 DevOps
<a name="distributed-devops"></a>

 分散式 DevOps 模式遵循 [COPE 方法](cloud-operations-and-platform-enablement.md)，在工程團隊中分隔 (或分配) 應用程式工程操作和基礎設施工程操作職責。

 您的應用程式工程師會執行其工作負載的工程和操作。相同地，您的基礎設施工程師會執行其用於支援應用程式團隊的平台工程和操作。

![\[分散式 DevOps 模式圖\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/operational-excellence-pillar/images/distributed-devops.en.png)


 在此範例中，我們將管控視為集中在組織內的其他地方。標準會分發、提供給應用程式和平台團隊，或與之共用。

 使用可協助您集中管控跨帳戶環境的工具或服務，例如 [AWS Organizations](https://aws.amazon.com/organizations/)。[AWS Control Tower](https://aws.amazon.com/controltower/features/) 等服務會擴大此管理功能，協助您定義帳戶設定的藍圖 (支援您的操作模式)、使用 AWS Organizations 套用持續管控，以及自動化新帳戶的佈建。

 *誰開發誰執行*並不表示應用程式團隊負責全堆疊、工具鏈和平台。

 平台工程團隊為應用程式團隊提供一組標準化服務 (例如，開發工具、監控工具、備份和復原工具及聯網)。平台團隊也可將核准之雲端供應商服務、相同的特定組態或兩者的存取權提供給應用程式團隊。

 提供部署核准之服務和組態的自助服務功能的機制 (例如 Service Catalog) 有助於限制在強制執行管控時與履行請求關聯的延遲。

 平台團隊可啟用全堆疊可見性，以便應用程式團隊可以區分其應用程式元件和服務，以及其應用程式耗用之基礎設施元件所發生的問題。平台團隊也可提供設定這些服務的協助，以及如何改善應用程式團隊營運的指引。

 如之前所述，機制存在的目的應為請求標準新增、變更及例外狀況，以支援活動及其應用程式的創新。

 分散式 DevOps 模式提供健全的意見回饋迴圈給應用程式團隊。工作負載的日常操作會透過直接互動，或間接透過支援和功能請求，而增加與客戶的接觸。如此提高的可見性有助於應用程式團隊更迅速處理問題。透過更深入參與和更密切的關係能深入了解客戶需求，並更迅速地實現創新。

 所有這一切對於支援應用程式團隊的平台團隊也是如此，因為平台團隊應將這些應用程式團隊視為客戶。

 採用的標準可能事先經過核准可以使用，進而減少進入生產所需的審查工作量。使用平台團隊提供的支援和經過測試的標準，可能會減少這些服務發生問題的頻率。採用標準可協助應用程式團隊專注於差異化工作負載。

# 分散式 DevOps
<a name="decentralized-devops"></a>

分散式 DevOps 模式是*誰開發誰執行*方法的變體，其中操作主要由工作負載團隊負責。

您的應用程式工程師會執行工作負載的工程和操作。相同地，您的基礎設施工程師會執行其用於支援應用程式團隊的平台工程和操作。

![\[分散式 DevOps 圖\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/operational-excellence-pillar/images/decentralized-devops.en.png)


在此範例中，我們進行分散管控。標準仍會由平台團隊分發、提供給應用程式團隊，或與之共用，但應用程式團隊可自由設計和操作新的平台功能，以支援其工作負載。

在此模式中，應用程式團隊受到的限制較少，但伴隨而來的卻是責任大幅增加。必須擁有其他技能 (和潛在的團隊成員)，以支援其他平台功能。如果技能組合不足，且無法及早辨識缺陷，則大量重新作業的風險會提高。

強制執行並非專門委派給應用程式團隊的政策。使用可協助您集中管控跨帳戶環境的工具或服務，例如 [AWS Organizations](https://aws.amazon.com/organizations/)。[AWS Control Tower](https://aws.amazon.com/controltower/features/) 等服務會擴大此管理功能，協助您定義帳戶設定的藍圖 (支援您的操作模式)、使用 AWS Organizations 套用持續管控，以及自動化新帳戶的佈建。

讓應用程式團隊設有請求標準新增和變更的機制，將會帶來好處。他們可以貢獻可使其他應用程式團隊受益的新標準。平台團隊可能會認為，為這些其他功能直接提供支援，能有效幫助實現業務成果。

此模式透過重要技能和團隊成員要求，減少對於創新的限制。它解決了團隊間轉交任務所導致的許多瓶頸和延誤，同時仍促進團隊與客戶之間建立有效的關係。

# 改進您的操作模式
<a name="evolving-your-ops-model"></a>

 提供的模式在工作負載層級逐步邁向更多自主性，符合「雙比薩團隊」原則。重要的是要了解，從傳統方法到分散式 DevOps (作為持續發展到「雙比薩團隊」模式的基礎) 的旅程可能需要時間，並且需要在許多功能方面建置成熟度。因此，我們提供了一個範例，說明當您的團隊和組織在企業轉型之旅中如何在模式之間轉換。在每個變更或模式中，您都在朝著一個更自主，但仍然與組織保持一致的團隊發展。

![\[從內部部署至自動化價值串流和程序的雲端操作模式發展圖\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/operational-excellence-pillar/images/evolving-ops.en.png)


 在評估您的團隊如何支援貴組織發展時，請檢查模式之間的權衡、您的個別團隊位於模式中的哪個階段 (在轉型和發展時)、您團隊的關係和責任可能如何變更，以及效益是否能夠影響貴組織。請記住，變化從來都不是線性的。某些模式更適合旅程中的特定使用案例或時間點，而其中一些模式可能比您環境中的模式具有優勢。