# 關係和擁有權
您的操作模式定義團隊之間的關係，並支援可識別的擁有權和責任。
**Topics**
+ [OPS02-BP01 資源已識別擁有者](ops_ops_model_def_resource_owners.md)
+ [OPS02-BP02 流程和程序已識別擁有者](ops_ops_model_def_proc_owners.md)
+ [OPS02-BP03 已為營運活動識別負責其效能的擁有者](ops_ops_model_def_activity_owners.md)
+ [OPS02-BP04 存在管理責任和擁有權的機制](ops_ops_model_def_responsibilities_ownership.md)
+ [OPS02-BP05 存在用於要求新增、變更和例外狀況的機制](ops_ops_model_req_add_chg_exception.md)
+ [OPS02-BP06 團隊之間的責任是預先定義或經過協商的](ops_ops_model_def_neg_team_agreements.md)
# OPS02-BP01 資源已識別擁有者
工作負載的資源必須已識別變更控制、疑難排解和其他功能的擁有者。系統會為工作負載、帳戶、基礎設施、平台和應用程式指派擁有者。擁有權會使用集中註冊或連接至資源的中繼資料等工具來記錄。元件的商業價值會透露其適用的流程和程序。
**預期成果：**
+ 資源已使用中繼資料或中央寄存器識別擁有者。
+ 團隊成員可以識別誰擁有資源。
+ 帳戶在可能的情況下擁有單一擁有者。
**常見的反模式：**
+ 您 的替代聯絡人 AWS 帳戶 不會填入。
+ 資源缺少可識別其屬於哪個團隊的標籤。
+ 您有一個沒有電子郵件映射的ITSM佇列。
+ 兩個團隊對基礎設施的關鍵部分的擁有權重疊。
**建立此最佳實務的優勢：**
+ 透過指派擁有權，資源的變更控制很簡單。
+ 疑難排解問題時，可以讓合適的擁有者參與。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
定義擁有權對環境中的資源使用案例的意義。擁有權可能意味著誰監督資源的變更、在疑難排解期間支援資源或者是負有財務責任的人員。指定並記錄資源的擁有者，包括名稱、聯絡資訊、組織和團隊。
**客戶範例**
AnyCompany 零售將所有權定義為擁有變更和資源支援之團隊或個人。他們利用 AWS Organizations 來管理其 AWS 帳戶。備選帳戶連絡人正在使用群組收件匣進行設定。每個ITSM佇列都會對應至電子郵件別名。標籤會識別誰擁有 AWS 資源。對於其他平台和基礎設施，他們有 Wiki 頁面會指出擁有權和聯絡資訊。
### 實作步驟
1. 首先為您的組織定義擁有權。擁有權可能表示誰擁有資源的風險、誰擁有資源的變更，或誰在疑難排解時支援資源。擁有權也可能意味著資源的財務或管理擁有權。
1. 使用 [AWS Organizations](https://aws.amazon.com/organizations/) 管理帳戶。您可以集中管理帳戶的替代聯絡人。
1. 只要使用公司擁有的電子郵件地址和電話號碼作為聯絡資訊，即使聯絡資訊所屬的個人已離職，您仍可存取這些資訊。例如，為帳單、營運和安全建立各別的電子郵件分發清單，在每個作用中 AWS 帳戶中將這些設定為帳戶、安全和營運聯絡人。即使有人正在休假、變更角色或離開公司，多人也會收到 AWS 通知並能夠回應。
1. 如果帳戶不是由 [AWS Organizations](https://aws.amazon.com/organizations/) 管理，備選帳戶聯絡人便會協助 AWS 適時與相關人員取得聯繫。設定帳戶的備選聯絡人以將其指向團體而非個人。
1. 使用標籤來識別 AWS 資源的擁有者。您可以在不同的標籤中指定擁有者及其聯絡資訊。
1. 可以使用 [AWS Config](https://aws.amazon.com/config/) 規則來強制資源具有所需的擁有權標籤。
1. 如需有關如何為組織建立標記策略的深入指引，請參閱 [AWS Tagging Best Practices whitepaper](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)。
1. 使用 [Amazon Q Business](https://aws.amazon.com/q/business/)，這是一個使用生成式 AI 的對話式助理，可提高員工生產力、回答問題並根據企業系統中的資訊完成任務。
1. 將 Amazon Q Business 連接到您公司的資料來源。Amazon Q Business 為超過 40 個支援的資料來源提供預先建置的連接器，包括 Amazon Simple Storage Service （Amazon S3）、Microsoft SharePoint、Salesforce 和 Atlassian Confluence。如需詳細資訊，請參閱[企業版 Amazon Q 連接器](https://aws.amazon.com/q/business/connectors/)。
1. 對於其他資源、平台和基礎設施，請建立識別擁有權的文件。所有團隊成員都應可以存取。
**實作計劃的工作量：**低。利用帳戶聯絡資訊和標籤來指派 AWS 資源的所有權。對於其他資源，您可以使用 Wiki 中的資料表來記錄擁有權和聯絡資訊，或使用ITSM工具映射擁有權。
## 資源
**相關的最佳實務：**
+ [OPS02-BP02 程序已識別擁有者](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS02-BP04 存在機制來管理責任和所有權](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
**相關文件：**
+ [AWS 帳戶管理 - 更新聯絡資訊](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html)
+ [AWS Organizations - 更新組織中的替代聯絡人](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_contacts.html)
+ [《AWS 標記最佳實務》白皮書](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [使用 Amazon Q Business and Identity Center 建置私有且 AWS IAM安全的企業生成 AI 應用程式](https://aws.amazon.com/blogs/machine-learning/build-private-and-secure-enterprise-generative-ai-apps-with-amazon-q-business-and-aws-iam-identity-center/)
+ [Amazon Q Business 現已正式推出，可透過生成式 AI 提升員工生產力](https://aws.amazon.com/blogs/aws/amazon-q-business-now-generally-available-helps-boost-workforce-productivity-with-generative-ai/)
+ [AWS 雲端 Operations & Migrations 部落格 - 使用 和 實作自動化 AWS Config 和集中式標記控制項 AWS Organizations](https://aws.amazon.com/blogs/mt/implementing-automated-and-centralized-tagging-controls-with-aws-config-and-aws-organizations/)
+ [AWS 安全部落格 - 使用 擴展您的預先遞交掛鉤 AWS CloudFormation Guard](https://aws.amazon.com/blogs/security/extend-your-pre-commit-hooks-with-aws-cloudformation-guard/)
+ [AWS DevOps 部落格 - AWS CloudFormation Guard 整合至 CI/CD 管道](https://aws.amazon.com/blogs/devops/integrating-aws-cloudformation-guard/)
**相關研討會：**
+ [AWS 研討會 - 標記](https://catalog.workshops.aws/tagging/)
**相關範例：**
+ [AWS Config 規則 - EC2具有必要標籤和有效值的 Amazon](https://github.com/awslabs/aws-config-rules/blob/master/python/ec2_require_tags_with_valid_values.py)
**相關服務：**
+ [AWS Config 規則 - 必要標籤](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)
+ [AWS Organizations](https://aws.amazon.com/organizations/)
# OPS02-BP02 流程和程序已識別擁有者
了解誰具有個別流程和程序的擁有權、為何使用特定流程和程序，以及為何該擁有權存在。了解使用特定流程和程序的原因，能夠幫助發現改進機會。
**預期成果：**您的組織擁有一套明確定義且維護良好的操作任何流程和程序。流程和程序儲存在中心位置，並可供您的團隊成員使用。透過明確指定的擁有權經常更新流程和程序。如果可能，指令碼、範本和自動化文件會以程式碼的形式實作。
**常見的反模式：**
+ 未記錄處理程序。隔離的操作員工作站上可能存在碎片化指令碼。
+ 有關如何使用指令碼的知識由少數個人掌握，或非正式地作為團隊知識。
+ 舊版流程由於更新而到期，但更新的擁有權不清楚，原始著作人不再是組織的一部分。
+ 流程和指令碼不容易發現，因此在需要時 (例如，回應事故) 無法立即使用。
**建立此最佳實務的優勢：**
+ 流程和程序可大幅提升您操作工作負載的效率。
+ 新的團隊成員更快速地變得高效。
+ 減少事故緩解的時間。
+ 不同的團隊成員 (和團隊) 可以以一致的方式使用相同的流程和程序。
+ 團隊可以透過可重複的流程擴展其流程。
+ 標準化流程和程序有助於減輕團隊之間轉移工作負載責任的影響。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
+ 流程和程序已經確定負責其定義的擁有者。
+ 識別為支援工作負載所執行的營運活動。將這些活動記錄在可探索的位置中。
+ 唯一識別負責活動規格的個人或團隊。他們負責確認具備適當技能的團隊成員能夠成功執行該活動，且該團隊成員具備正確許可、存取權和工具。如果執行該活動時發生問題，執行該活動的團隊成員需負責提供改善活動所需的詳細回饋。
+ 透過 AWS Systems Manager 等服務，使用文件和 AWS Lambda 來擷取活動成品中繼資料中的擁有權。使用標籤或資源群組擷取資源擁有權，並指定擁有權和聯絡資訊。使用 AWS Organizations 建立標記政策，並擷取擁有權和聯絡資訊。
+ 隨著時間的推移，這些程序應逐步發展為可以作為程式碼執行，從而減少人為干預的需求。
+ 例如，請考慮 AWS Lambda 函數、CloudFormation 範本或 AWS Systems Manager 自動化文件。
+ 在適當的儲存庫中執行版本控制。
+ 包括合適的資源標記，以便可以很容易地識別擁有者和文件。
**客戶範例**
AnyCompany Retail 將擁有權定義為擁有應用程式或應用程式群組 (共享共同的架構實務和技術) 流程的團隊或個人。最初，流程和程序作為分步指南記錄在文件管理系統中，可使用託管應用程式的 AWS 帳戶中的標籤以及帳戶內特定資源群組中的標籤進行探索。他們利用 AWS Organizations 來管理他們的 AWS 帳戶。隨著時間的推移，這些流程會轉換為程式碼，並使用基礎設施即程式碼 (例如 CloudFormation 或 AWS Cloud Development Kit (AWS CDK) 範本) 來定義資源。操作流程會變成 AWS Systems Manager 或 AWS Lambda 函數中的自動化文件，這些自動化文件可以作為排程任務啟動，以回應諸如 AWS CloudWatch 警示或 AWS EventBridge 事件之類的事件，或由 IT 服務管理 (ITSM) 平台內的請求啟動。所有流程都有標籤來識別擁有權。在流程的程式碼儲存庫所產生的 wiki 頁面中維護自動化和流程的文件。
### 實作步驟
1. 記錄現有的流程和程序。
1. 審核並將其維持在最新狀態。
1. 識別每個流程或程序的擁有者。
1. 將其置於版本控制之下。
1. 在可能的情況下，在共用架構設計的工作負載和環境之間共用流程和程序。
1. 建立回饋和改進機制。
1. 定義審核流程頻率的政策。
1. 定義審核者與核准者的流程。
1. 實作問題或票證隊列，以提供和追蹤意見回饋。
1. 在可能的情況下，流程和程序應得到變更核准委員會 (CAB) 的預先批准和風險分類。
1. 驗證流程和程序是否可供需要執行流程和程序的人員來存取和探索。
1. 使用標籤來指示可以針對工作負載存取流程和程序的位置。
1. 使用有意義的錯誤和事件訊息來指出可解決問題的適當流程或程序。
1. 使用 Wiki 和文件管理，讓整個組織可一致搜尋流程和程序。
1. 使用 [Amazon Q Business](https://aws.amazon.com/q/business/)，這是一個使用生成式 AI 的對話式助理，可提高員工生產力、回答問題並根據企業系統中的資訊完成任務。
1. 將 Amazon Q Business 連接到您公司的資料來源。Amazon Q Business 為 40 多個受支援的資料來源提供預先建置的連接器，其中包括 Amazon S3、Microsoft SharePoint、Salesforce 和 Atlassian Confluence。如需詳細資訊，請參閱 [Amazon Q 連接器](https://aws.amazon.com/q/business/connectors/)。
1. 適時進行自動化。
1. 當服務和技術提供 API 時，應該開發自動化。
1. 對流程進行充分的教育。制定使用者故事和要求以自動化這些流程。
1. 成功衡量流程和程序的使用情況，並建立問題或票證以支援反覆改進。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS02-BP01 已為資源識別擁有者](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP04 存在管理責任和擁有權的機制](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
+ [OPS11-BP04 執行知識管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**相關文件：**
+ [AWS 白皮書 - DevOps on AWS 簡介](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [AWS 白皮書 - 標記 AWS 資源的最佳實務](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [AWS 白皮書 - 使用多個帳戶組織您的 AWS 環境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [AWS 雲端 操作和遷移部落格 - 使用 Amazon Q Business 簡化您的操作](https://aws.amazon.com/blogs/mt/streamline-operations-using-amazon-q-for-business/)
+ [AWS 雲端 操作和遷移部落格 - 建立雲端自動化實務以實現卓越營運：AWS Managed Services 的最佳實務](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [AWS 雲端 操作和遷移部落格 - 使用 AWS Config 和 AWS Organizations 實作自動化和集中式標記控制](https://aws.amazon.com/blogs/mt/implementing-automated-and-centralized-tagging-controls-with-aws-config-and-aws-organizations/)
+ [AWS 安全部落格 - 使用 AWS CloudFormation Guard 擴展您的預先提交勾點](https://aws.amazon.com/blogs/security/extend-your-pre-commit-hooks-with-aws-cloudformation-guard/)
+ [AWS DevOps 部落格 - 將 AWS CloudFormation Guard 整合到 CI/CD 管道中](https://aws.amazon.com/blogs/devops/integrating-aws-cloudformation-guard/)
**相關研討會：**
+ [AWS Well-Architected 卓越營運研討會](https://catalog.workshops.aws/well-architected-operational-excellence/en-US/)
+ [AWS 研討會 - 標記](https://catalog.workshops.aws/tagging/)
**相關影片：**
+ [如何在 AWS 上自動執行 IT 操作](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [AWS re:Invent 2020 - 使用 AWS Systems Manager 自動執行任何操作](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [AWS re:Inforce 2022 - 使用 AWS 自動化修補程式管理和合規性 (NIS306)](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [支援 支援您 - 深入了解 AWS Systems Manager](https://www.youtube.com/watch?v=xHNLNTa2xGU)
**相關服務：**
+ [AWS Systems Manager - 自動化](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Service Management Connector](https://aws.amazon.com/service-management-connector/)
# OPS02-BP03 已為營運活動識別負責其效能的擁有者
了解誰負責在已定義的工作負載上執行特定活動，以及為什麼該責任存在。透過了解誰負責執行活動，可得知誰將會進行活動、驗證結果，以及提供回饋給活動擁有者。
**預期成果：**
您的組織清楚地規定了對已定義的工作負載執行特定活動並回應工作負載所產生事件的責任。該組織記錄了流程和履行的擁有權，並使此資訊可被發現。您可以在組織變更發生時審核並更新責任，而團隊會追蹤並衡量缺陷和低效率識別活動的效能。可以實作回饋機制來追蹤缺陷和改進並支援迭代改進。
**常見的反模式：**
+ 您不記錄責任。
+ 隔離的操作員工作站上存在碎片化指令碼。只有少數人知道如何進行使用，或非正式地將其稱為*團隊知識*。
+ 舊版流程由於更新而到期，但沒有人知道誰擁有該流程，並且原始著作人不再是組織的一部分。
+ 流程和指令碼無法被發現，在需要時 (例如，回應事故) 無法立即使用。
**建立此最佳實務的優勢：**
+ 了解誰負責執行活動，在需要採取動作時通知誰，以及誰會執行動作、驗證結果並為活動擁有者提供意見回饋。
+ 流程和程序可大幅提升您操作工作負載的效率。
+ 新的團隊成員更快速地變得高效。
+ 可以減少緩解事故所需的時間。
+ 不同的團隊可採取一致的方式來使用相同的流程和程序。
+ 團隊可以透過可重複的流程擴展其流程。
+ 標準化流程和程序有助於減輕團隊之間轉移工作負載責任的影響。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
若要開始定義職責，請先從現有文件開始，例如責任矩陣、流程與程序、角色與責任，以及工具與自動化。審查並主持有關文件化流程責任的討論。與團隊一起審查，以識別文件責任和流程之間的不一致。與該團隊的內部客戶討論提供的服務，以確定團隊之間的期望差距。
分析並解決差異。找出改進的機會，並尋找經常請求的資源密集型活動，這些活動通常需要改進。探索最佳實務、模式和規範性指引，以簡化和標準化改進。記錄改善機會，並追蹤改進完成情況。
隨著時間的推移，這些程序應逐步發展為可以作為程式碼執行，從而減少人為干預的需求。例如，程序可以啟動為 AWS Lambda 函數、CloudFormation 範本或 AWS Systems Manager 自動化文件。驗證這些程序是否在適當的儲存庫中受版本控制，並包含適當的資源標記，以便團隊能夠輕鬆識別擁有者和文件。記錄執行活動的責任，然後監控用於成功啟動和操作的自動化，以及期望成果的績效。
**客戶範例**
AnyCompany Retail 將擁有權定義為擁有應用程式或應用程式群組 (共享共同的架構實務和技術) 流程的團隊或個人。最初，公司將流程和程序記錄為文件管理系統中的分步指南。其會使用託管應用程式的 AWS 帳戶中的標籤以及帳戶內特定資源群組中的標籤來探索程序，並使用 AWS Organizations 來管理其 AWS 帳戶。隨著時間的推移，AnyCompany Retail 會將這些流程轉換為程式碼，並使用基礎設施即程式碼 (例如 CloudFormation 或 AWS Cloud Development Kit (AWS CDK) 範本) 來定義資源。操作流程會變成 AWS Systems Manager 或 AWS Lambda 函數中的自動化文件，它們可以作為排程任務啟動，以回應諸如 Amazon CloudWatch 警示或 Amazon EventBridge 事件之類的事件，或由 IT 服務管理 (ITSM) 平台內的請求啟動。所有流程都有標籤，可用來識別其擁有者。團隊會在流程的程式碼儲存庫所產生的 wiki 頁面中管理自動化和流程的文件。
### 實作步驟
1. 記錄現有的流程和程序。
1. 審核並確認其是否為最新狀態。
1. 確認每個流程或程序都有擁有者。
1. 將程序置於版本控制之下。
1. 在可能的情況下，在共用架構設計的工作負載和環境之間共用流程和程序。
1. 建立回饋和改進機制。
1. 定義審核流程頻率的政策。
1. 定義審核者與核准者的流程。
1. 實作問題或票證隊列，以提供並追蹤意見回饋。
1. 在可能的情況下，為流程和程序提供變更核准委員會 (CAB) 的預先批准和風險分類。
1. 讓流程和程序可供需要執行它們的人員進行存取和探索。
1. 使用標籤來指示可以針對工作負載存取流程和程序的位置。
1. 使用有意義的錯誤和事件訊息來指出可解決問題的適當流程或程序。
1. 使用 Wiki 或文件管理，讓整個組織可一致搜尋流程和程序。
1. 在適當的時候實現自動化。
1. 當服務和技術提供 API 時，開發自動化。
1. 驗證是否充分理解流程，制定使用者故事和要求以自動化這些流程。
1. 衡量流程和程序的成功使用情況，並追蹤問題以支援反覆改進。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS02-BP01 已為資源識別擁有者](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP02 流程和程序已識別擁有者](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP04 存在管理責任和擁有權的機制](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
+ [OPS02-BP05 存在識別責任和擁有權的機制](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_find_owner.html)
+ [OPS11-BP04 執行知識管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**相關文件：**
+ [AWS 白皮書 \$1 DevOps on AWS 簡介](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [AWS 白皮書 \$1 標記 AWS 資源的最佳實務](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [AWS 白皮書 \$1 使用多個帳戶組織您的 AWS 環境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [AWS 雲端 操作和遷移部落格 \$1 建立雲端自動化實務以實現卓越營運：AWS Managed Services 的最佳實務](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [AWS 研討會 - 標記](https://catalog.workshops.aws/tagging/)
+ [AWS Service Management Connector](https://aws.amazon.com/service-management-connector/)
**相關影片：**
+ [AWS 知識中心直播 \$1 標記 AWS 資源](https://www.youtube.com/watch?v=MX9DaAQS15I)
+ [AWS re:Invent 2020 \$1 使用 AWS Systems Manager 自動執行任何操作](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [AWS re:Inforce 2022 \$1 使用 AWS 自動化修補程式管理和合規性 (NIS306)](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [支援 支援您 \$1 深入了解 AWS Systems Manager](https://www.youtube.com/watch?v=xHNLNTa2xGU)
# OPS02-BP04 存在管理責任和擁有權的機制
了解您角色的責任以及您為業務成果做出貢獻的方式，因為這種了解可明確任務的優先順序以及您的角色為何重要。這有助於團隊成員辨識需求並適當地回應。當團隊成員知道自己的角色時，他們可以建立擁有、找出改進機會，以及了解如何影響或進行適當的變更。
有時候，責任可能沒有明確的擁有者。在這些情況下，設計一種機制來解決此差距。為有權指派擁有權或計劃解決需求的人員建立明確定義的上報路徑。
**預期成果：**組織內的團隊擁有明確定義的職責，其中包括他們與資源、要執行的動作、流程及程序的關係。這些職責符合團隊的責任和目標，以及其他團隊的責任。您可以用一致且可探索的方式記錄上報路徑，並將這些決策輸入到文件成品中，例如責任矩陣、團隊定義或 Wiki 頁面。
**常見的反模式：**
+ 團隊的責任含糊不清或定義不佳。
+ 團隊沒有將角色與責任保持一致。
+ 該團隊沒有調整其總體目標和具體目標以及其責任，這使得它難以衡量成功。
+ 團隊成員的責任與團隊和更廣泛的組織不一致。
+ 您的團隊不會更新職責，這導致其與團隊執行的任務不一致。
+ 確定職責的上報路徑尚未定義或不清楚。
+ 上報路徑沒有單一執行緒擁有者，以確保及時回應。
+ 角色、責任和上報路徑不容易發現，在需要時 (例如，回應事故) 無法立即使用。
**建立此最佳實務的優勢：**
+ 了解誰擁有責任或擁有權時，可讓您聯絡適當的團隊或團隊成員，以提出請求或轉換任務。
+ 為了降低不作為和未解決需求的風險，您已經確定了有權指派責任或擁有權的人員。
+ 當您明確定義責任範圍時，團隊成員將獲得自主權和擁有權。
+ 您的責任決定了您所做的決定、您採取的動作，以及如何將活動交給其適當的擁有者。
+ 很容易識別被放棄的責任，因為您清楚地了解哪些責任不在團隊責任範圍內，這有助於您上報以進行澄清。
+ 團隊可以避免混亂和緊張，並且可以更充分地管理工作負載和資源。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
確定團隊成員的角色和責任，並確保他們了解其角色的期望。讓此資訊可供探索，如此組織的成員便能夠確定他們針對特定需求需要聯絡的人員 (團隊或個人)。隨著組織尋求利用機會在 AWS 上進行遷移和現代化，角色和職責也可能會改變。讓您的團隊及其成員了解他們的責任，並對其進行適當的培訓，以便在此次變更期間執行其任務。
確定應接收上報的角色或團隊，以確認責任和擁有權。此團隊可以與各種利益相關者互動以做出決定。但是，他們應該擁有決策制定流程的管理權。
為您的組織成員提供可存取的機制，以探索和識別擁有權和責任。這些機制教導他們應該聯絡誰以滿足特定需求。
**客戶範例**
AnyCompany Retail 最近使用平移方法，完成了在 AWS 中將工作負載從內部部署環境遷移到其登陸區域。他們執行了操作審查以反映他們如何完成一般操作任務，並驗證其現有的責任矩陣是否反映了新環境中的操作。當他們從內部部署遷移到 AWS 時，他們減少了與硬體和實體基礎結構相關的基礎架構團隊的責任。此舉還揭示了為其工作負載發展營運模式的新機會。
他們在確定、處理並記錄大部分職責的同時，還定義了任何遺漏或隨著營運實務演變而可能需要變更的任何責任的上報路徑。若要探索標準化和改善工作負載效率的新機會，請提供 AWS Systems Manager 等操作工具以及 AWS Security Hub CSPM 和 Amazon GuardDuty 等安全工具的存取權。AnyCompany Retail 根據他們希望首先解決的改進來審查責任和策略。由於公司採用新的工作方式和技術模式，他們會更新其責任矩陣以進行匹配。
### 實作步驟
1. 從現有文件開始。一些典型的來源文件可能包括：
1. 責任或負責者、當責者、事先諮詢者和事後告知者 (RACI) 矩陣
1. 團隊定義或 Wiki 頁面
1. 服務定義和產品
1. 角色或職位描述
1. 審查並主持有關文件化責任的討論：
1. 與團隊進行審查，以確定文件化責任與團隊通常執行的責任之間的不一致。
1. 討論內部客戶提供的潛在服務，以確定團隊之間的期望差距。
1. 分析並解決差異。
1. 找出改進機會。
1. 找出頻繁發出的資源密集型請求，這類請求通常表示需要改進。
1. 尋找最佳實務、了解模式、遵循規範性指引，並簡化和標準化改進。
1. 記錄改進機會，並追蹤完成情況。
1. 如果團隊尚未負責管理和追蹤職責指派，請指定團隊中負責此職責的人員。
1. 為團隊定義一個流程以請求澄清責任。
1. 審核流程，並確認其清晰且易用。
1. 確保有人擁有並追蹤他們結論的上報。
1. 建立運營指標以衡量有效性。
1. 建立意見回饋機制，以確認團隊是否能突顯改進機會。
1. 實作定期審查機制。
1. 文件存放在可發現且可存取的位置。
1. Wiki 或文件入口網站是常見選擇。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS01-BP06 評估權衡](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)
+ [OPS03-BP02 授權團隊成員在成果有風險時採取動作](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_emp_take_action.html)
+ [OPS03-BP03 鼓勵向上呈報](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_enc_escalation.html)
+ [OPS03-BP07 適當地為團隊提供資源](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_res_appro.html)
+ [OPS09-BP01 使用指標衡量營運目標與 KPI](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_measure_ops_goals_kpis.html)
+ [OPS09-BP03 審核營運指標並優先改進](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_review_ops_metrics_prioritize_improvement.html)
+ [OPS11-BP01 建立持續改進程序](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_process_cont_imp.html)
**相關文件：**
+ [AWS 白皮書 - DevOps on AWS 簡介](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [AWS 白皮書 - AWS 雲端 採用架構：營運觀點](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/aws-caf-operations-perspective.html)
+ [AWS Well-Architected Framework 卓越營運 - 工作負載層級操作模型拓撲](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model-2-by-2-representations.html)
+ [AWS 方案指引 - 建置雲端操作模式](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/welcome.html)
+ [AWS 方案指引 - 為雲端操作模式建立 RACI 或 RASCI 矩陣](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/create-a-raci-or-rasci-matrix-for-a-cloud-operating-model.html)
+ [AWS 雲端 操作和遷移部落格 - 透過雲端平台團隊提供商業價值](https://aws.amazon.com/blogs/mt/delivering-business-value-with-cloud-platform-teams/)
+ [AWS 雲端 操作和遷移部落格 - 為何選擇雲端操作模式？](https://aws.amazon.com/blogs/mt/why-a-cloud-operating-model/)
+ [AWS DevOps 部落格 - 組織如何實現雲端操作的現代化](https://aws.amazon.com/blogs/devops/how-organizations-are-modernizing-for-cloud-operations/)
**相關影片：**
+ [AWS Summit Online - 加速轉型的雲端操作模式](https://www.youtube.com/watch?v=ksJ5_UdYIag)
+ [AWS re:Invent 2023 - 面向未來的雲端安全性：一種新的操作模式](https://www.youtube.com/watch?v=GFcKCz1VO2I)
# OPS02-BP05 存在用於要求新增、變更和例外狀況的機制
您可以向流程、程序和資源的擁有者提出請求。請求包含新增、變更和例外狀況。這些請求會經歷變更管理程序。評估收益和風險後，若可行並經判斷是合適的行為，則應制定明智的決策以核准請求。
**預期成果：**
+ 可以根據分配的擁有權請求變更流程、程序和資源。
+ 變更是經過深思熟慮的，權衡了利益和風險。
**常見的反模式：**
+ 必須更新部署應用程式的方式，但無法向操作團隊請求變更部署程序。
+ 必須更新災難復原計畫，但沒有確定的擁有者可以請求變更。
**建立此最佳實務的優勢：**
+ 流程、程序和資源可隨需求的變化而發展。
+ 擁有者可以在進行變更時做出明智決策。
+ 變更是經過深思熟慮的。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
若要實作此最佳實務，必須能夠要求變更流程、程序和資源。變更管理流程可以很簡單。記錄變更管理流程。
**客戶範例**
AnyCompany Retail 使用責任指派 (RACI) 矩陣來確定誰擁有流程、程序和資源的變更。他們擁有記錄在案的變更管理流程，簡單且易於遵循。使用 RACI 矩陣和流程，任何人都可以提交變更請求。
**實作步驟**
1. 確定工作負載的流程、程序和資源，以及各自的擁有者。將其記錄在您的知識管理系統中。
1. 如果尚未實作 [OPS02-BP01 資源已識別擁有者](ops_ops_model_def_resource_owners.md)、[OPS02-BP02 流程和程序已識別擁有者](ops_ops_model_def_proc_owners.md) 或 [OPS02-BP03 已為營運活動識別負責其效能的擁有者](ops_ops_model_def_activity_owners.md)，請先從這些項目開始。
1. 與組織中的利益相關者合作，制定變更管理流程。此流程應涵蓋資源、流程及程序的新增、變更及例外狀況。
1. 可以使用 [AWS Systems Manager Change Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html) 做為工作負載資源的變更管理平台。
1. 在您的知識管理系統中記錄變更管理流程。
**實作計劃的工作量：**中。制定變更管理流程需要與組織中的多個利益相關者保持一致。
## 資源
**相關的最佳實務：**
+ [OPS02-BP01 資源已識別擁有者](ops_ops_model_def_resource_owners.md) - 在建立變更管理流程之前，資源需要確定的擁有者。
+ [OPS02-BP02 流程和程序已識別擁有者](ops_ops_model_def_proc_owners.md) - 在建立變更管理流程之前，流程需要確定的擁有者。
+ [OPS02-BP03 已為營運活動識別負責其效能的擁有者](ops_ops_model_def_activity_owners.md) - 在建立變更管理流程之前，操作活動需要確定的擁有者。
**相關文件：**
+ [AWS 方案指引 - AWS 大型移轉的基礎說明手冊：建立 RACI 矩陣](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html#raci)
+ [雲端白皮書中的變更管理](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**相關服務：**
+ [AWS Systems Manager Change Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html)
# OPS02-BP06 團隊之間的責任是預先定義或經過協商的
團隊間已定義或協商說明如何相互配合及支援的協議 (例如，回應時間、服務水準目標或服務水準協議)。團隊間的溝通管道記錄於文件中。透過了解團隊工作對於商業成果和其他團隊及組織成果的影響，可得知其任務的優先順序，並協助他們適當地回應。
如果責任和擁有權未定義或未知，則您會面臨風險，不僅無法及時處理必要的活動，在解決這些需求時還會出現冗餘和可能相互衝突的工作。
**預期成果：**
+ 團隊間的工作或支援協議已達成一致並記錄在案。
+ 彼此支援或合作的團隊已定義了溝通渠道和回應期望。
**常見的反模式：**
+ 生產環境中發生問題，而且兩個不同的團隊開始彼此獨立地進行疑難排解。他們各自為政的工作延長了中斷時間。
+ 運營團隊需要開發團隊的幫助，但沒有商定回應時間。請求卡在待辦事項中。
**建立此最佳實務的優勢：**
+ 團隊知道如何互動和互相支援。
+ 對回應的期望是眾所周知的。
+ 溝通渠道已明確定義。
**未建立此最佳實務時的曝險等級：**低
## 實作指引
實作此最佳實務意味著團隊之間的合作方式沒有歧義。正式協議規定了團隊如何一起工作或相互支援。團隊間的溝通渠道記錄於文件中。
**客戶範例**
AnyCompany Retail 的 SRE 團隊與其開發團隊簽訂了服務水準協議。每當開發團隊在其票證系統中提出請求時，他們可以期望在十五分鐘內得到回應。如果發生站點中斷，SRE 團隊在開發團隊的支援下牽頭進行調查。
**實作步驟**
1. 與組織中的利益相關者合作，根據流程和程序來制定團隊之間的協議。
1. 如果在兩個團隊之間共享一個流程或程序，則制定有關團隊將如何一起工作的執行手冊。
1. 如果團隊之間存在依賴關係，請同意請求的回應 SLA。
1. 在知識管理系統中記錄責任。
**實作計劃的工作量：**中。如果團隊之間沒有現有協議，則可能需要努力與組織中的利益相關者達成協議。
## 資源
**相關的最佳實務：**
+ [OPS02-BP02 流程和程序已識別擁有者](ops_ops_model_def_proc_owners.md) - 在團隊之間達成協議之前，必須確定流程所有權。
+ [OPS02-BP03 已為營運活動識別負責其效能的擁有者](ops_ops_model_def_activity_owners.md) - 在團隊之間達成協議之前，必須確定運營活動所有權。
**相關文件：**
+ [AWS Executive Insights - 透過雙披薩團隊賦予創新力量](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/)
+ [DevOps on AWS 簡介 - 雙披薩團隊](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html)