# 組織
您的團隊必須對您的整個工作負載以及團隊成員在其中的作用達成共識，並且擁有共同的業務目標，以便設定能實現業務成功的優先事項。明確定義的優先事項將實現工作的最大收益。評估內部與外部客戶需求，並讓關鍵利益相關者 (包括業務、開發和營運團隊) 參與進來，以確定工作的重點領域。評估客戶需求將驗證您對實現業務成果所需的支援有透徹的了解。確保您了解由貴組織管控所定義的、可能要求或強調特定重點的準則或義務以及外部因素，例如法規合規要求和產業標準。確認您是否設有識別內部管控和外部合規要求變更的機制。如果未識別要求，請確保您已對此決定進行盡職調查。定期審查您的優先事項，以便在需求變更時更新優先事項。
評估對業務的威脅 (例如，業務風險和負債以及資訊安全威脅)，並將此資訊保存在風險登記表內。評估風險的影響，以及利益衝突或替代方法之間的權衡。例如，新功能加速上市可能是成本最佳化所強調的重點，或您可為非關聯式資料選擇關聯式資料庫，以簡化系統遷移工作而無須重構。管理收益和風險，以便在確定工作重點時做出明智的決定。某些風險或選擇可能在一段時間內是可以接受的，相關風險可能得以減輕，也可能出現無法接受風險存在的事實，在此情況下，您將需要採取動作來解決風險。
您的團隊必須了解其在達成業務成果中所扮演的角色。團隊必須了解自己在促成其他團隊成功的過程中所扮演的角色、其他團隊在促進其成功的過程中所扮演的角色，以及擁有共同目標。了解責任、擁有權、決策方式，以及誰有權制定決策，將有助於找到工作重點，並充分發揮團隊的優勢。團隊的需求將由其所支援的客戶、組織、團隊組成，以及工作負載的特性形塑而成。合理來說，無法要求單一操作模式支援貴組織中的所有團隊及其工作負載。
驗證每個應用程式、工作負載、平台和基礎設施元件都有已識別擁有者，而且每個流程和程序都有負責其定義的已識別擁有者，以及負責其執行的擁有者。
透過了解每個元件、流程和程序的商業價值、為何部署這些資源或為何執行活動，以及該擁有權為何存在，有助於團隊成員採取適當動作。明確界定團隊成員的責任，以便他們可以採取適當行動，並具有識別責任和擁有權的機制。擁有請求增加、變更和例外狀況的機制，這樣您就不會限制創新。定義團隊之間的協議，說明他們如何協同合作以互相支援並實現業務成果。
為您的團隊成員提供支援，讓他們能夠更有效地採取動作以及支援業務成果。參與的高階領導層應設定期望並衡量成功。資深領導階層應是採用最佳實務和組織演進的發起者、倡導者和推動者。當成果出現風險時，讓團隊成員採取行動，將影響降到最低，同時鼓勵他們在遇到風險時，向決策者和利益相關者呈報，以便處理問題並避免事故。針對已知風險和計劃事件進行及時、明確且可採取動作的溝通，讓團隊成員能夠及時採取適當的動作。
鼓勵試驗以加速學習，讓團隊成員保持興趣並積極參與。團隊必須發展自己的技能集，以採用新技術，並支援需求和責任的變更。提供專門的結構化時間用於學習，以支援並鼓勵這一舉措。驗證團隊成員擁有可取得成功並進行擴展的資源 (包括工具和團隊成員)，以協助達成您的業務成果。利用跨組織的多樣性，尋求多種獨特的觀點。使用此觀點來增加創新、挑戰假設，並降低確認偏差的風險。在團隊中增加包容性、多樣性和可及性，以獲得有益的觀點。
若有適用於貴組織的外部法規或合規要求，則您應使用 [AWS 雲端合規](https://aws.amazon.com/compliance/?ref=wellarchitected-wp)提供的資源來協助教育您的團隊，以便他們可以判斷對您的優先事項的影響。Well-Architected 架構強調學習、衡量和改善。它為您提供可評估架構並實作將隨時間擴展之設計的一致方法。AWS 提供 AWS Well-Architected Tool 以協助您在開發前審核您的方法、生產前的工作負載狀態以及生產中工作負載的狀態。您可以將工作負載與最新的 AWS 架構最佳實務做比較、監控工作負載的整體狀態，以及深入了解潛在風險。AWS Trusted Advisor 是一款可存取核心檢查集的工具，這些檢查提出了優化建議，可能有助您確定優先事項。商業和企業支援客戶可存取針對安全性、可靠性、效能、成本優化以及永續性的其他檢查，從而進一步協助確定他們的優先事項。
AWS 可以協助您教育您的團隊有關 AWS 及其服務的知識，從而增進他們對自己的選擇會如何影響工作負載的了解。使用 AWS 支援 (AWS 知識中心、AWS 論壇和 AWS 支援 中心) 和 AWS 文件中的資源來教育您的團隊。請透過 AWS 支援 Center 聯絡 AWS 支援，尋求 AWS 相關問題的協助。AWS 還分享了我們透過在 Amazon 建置者資料中心的 AWS 操作中學到的最佳實務和模式。您可透過 AWS 部落格和官方 AWS 播客獲得其他各種實用資訊。AWSTraining and Certification 透過 AWS 基礎原理中的自主進度數位課程提供一些培訓。您還可以報名參加講師指導下的培訓，以進一步協助開發團隊的 AWS 技能。
使用能集中管控跨帳戶環境的工具或服務，例如 AWS Organizations，以便協助您管理操作模式。AWS Control Tower 等服務會擴大此管理功能，允許您定義帳戶設定的藍圖 (支援您的操作模式)、使用 AWS Organizations 套用持續管控，以及自動化新帳戶的佈建作業。AWS Managed Services、AWS Managed Services 合作夥伴等受管服務供應商，或 AWS 合作夥伴網路中的受管服務供應商，都會提供實作雲端環境的專業知識，並支援您的安全和合規要求及業務目標。將受管服務加入操作模式後，便可節省時間和資源，讓您的內部團隊精簡並專注於將使您的企業脫穎而出的策略性成果，而非開發新技能和功能。
您可能會發現，您在某個時間點會想要強調一小部分的優先事項。長期利用平衡的方法，以驗證開發所需的功能和管理風險。定期審查優先事項，並隨需求的變更進行更新。如果責任和擁有權未定義或未知，則您會面臨風險，不僅無法及時執行必要的動作，在解決這些需求時還會出現冗餘和可能相互衝突的工作。組織文化對團隊成員工作滿意度和留任率有直接影響。讓團隊成員參與其中並習得能力，以實現業務成功。必需要經由試驗才能實現創新，並讓想法轉化為成果。辨識不想要的結果是代表這是一場成功的試驗，因為可以判斷出不會通往成功途徑。
**Topics**
+ [組織優先事項](organization-priorities.md)
+ [操作模型](operating-model.md)
+ [組織文化](organizational-culture.md)
# 組織優先事項
您的團隊需要對您的整個工作負載，以及團隊成員在其中的作用達成共識，並且擁有共同的業務目標，以便設定能助力業務成功的優先事項。明確定義的優先事項將實現工作的最大收益。定期審查您的優先事項，以便在組織的需求變更時更新優先事項。
**Topics**
+ [OPS01-BP01 評估外部客戶需求](ops_priorities_ext_cust_needs.md)
+ [OPS01-BP02 評估內部客戶需求](ops_priorities_int_cust_needs.md)
+ [OPS01-BP03 評估治理要求](ops_priorities_governance_reqs.md)
+ [OPS01-BP04 評估合規要求](ops_priorities_compliance_reqs.md)
+ [OPS01-BP05 評估威脅態勢](ops_priorities_eval_threat_landscape.md)
+ [OPS01-BP06 評估權衡的同時管理利益和風險](ops_priorities_eval_tradeoffs.md)
# OPS01-BP01 評估外部客戶需求
讓關鍵利害關係人 (包括業務、開發和營運團隊) 參與進來，以確定將工作重點放在哪些外部客戶需求上。這驗證了您對實現預期業務成果所需的營運支援有透徹的了解。
**預期成果：**
+ 您可以透過客戶成果逆向工作。
+ 您了解營運實務如何支援業務成果和目標。
+ 您與所有相關各方接觸。
+ 您擁有捕捉外部客戶需求的機制。
**常見的反模式：**
+ 您已決定不在核心上班時間以外的時間提供客戶支援，但尚未檢閱歷史支援請求資料。您不知道這是否會對您的客戶產生影響。
+ 您正在開發新功能，但尚未與客戶互動，以了解是否需要該功能，若需要又應以何種形式提供，而且未進行試驗以驗證交付的需求和方法。
**建立此最佳實務的優勢：**需求得到滿足的客戶更有可能繼續成為客戶。評估和了解外部客戶的需求，將讓您了解如何安排工作的優先順序來實現商業價值。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
**了解業務需求：**只有業務、開發及營運團隊等利害關係人擁有共同的目標並達成共識，方能讓業務取得成功。
**審查外部客戶的業務目標、需求和優先事項：**與關鍵利害關係人 (包括業務、開發和營運團隊) 進行互動，以討論外部客戶的目標、需求和優先事項。這將確保您對實現業務和客戶成果所需的營運支援有透徹的了解。
**建立共識：**在以下方面建立共識：工作負載的業務功能、每個團隊在工作負載營運過程中的角色，以及這些因素如何支援內外部客戶的共同業務目標。
## 資源
**相關的最佳實務：**
+ [OPS11-BP03 實作回饋迴圈](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_feedback_loops.html)
# OPS01-BP02 評估內部客戶需求
讓關鍵利益相關者 (包括業務、開發和營運團隊) 參與進來，以確定將工作重點放在哪些內部客戶需求上。這將確保您對實現業務成果所需的營運支援有透徹的了解。
**預期成果：**
+ 利用您制定的優先事項，聚焦於改善作業，因為它們能發揮最大的影響力 (例如，發展團隊技能、改善工作負載效能、降低成本、自動化執行手冊或提升監控力)。
+ 根據需求變更更新您的優先順序。
**常見的反模式：**
+ 您已決定在不向產品團隊諮詢的情況下，變更他們的 IP 位址配置，以便更輕鬆地管理網路。您不知道這會對您的產品團隊產生什麼影響。
+ 您正在實作新的開發工具，但尚未讓內部客戶了解是否需要它，或者它是否與他們現有的實務相容。
+ 您正在實作新的監控系統，但尚未聯絡內部客戶，以了解他們是否有應該考慮的監控或報告需求。
**建立此最佳實務的優勢：**評估和了解內部客戶的需求，可讓您了解如何安排工作的優先順序來實現商業價值。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
+ 了解業務需求：只有業務、開發及營運團隊等利益相關者擁有共同的目標並達成共識，方能實現業務成功。
+ 審查內部客戶的業務目標、需求和優先事項：與關鍵利益相關者 (包括業務、開發和營運團隊) 進行互動，以討論內部客戶的目標、需求和優先事項。這將確保您對實現業務和客戶成果所需的營運支援有透徹的了解。
+ 建立共識：在以下方面建立共識，即工作負載的業務功能、每個團隊在工作負載營運過程中的角色，以及這些因素如何支援內外部客戶的共同業務目標。
## 資源
**相關的最佳實務：**
+ [OPS11-BP03 實作意見回饋循環](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_feedback_loops.html)
# OPS01-BP03 評估治理要求
管控是政策、規則或架構的集合，供公司用來達成其業務目標。管控要求產生自您的組織內部。這些要求可能會影響到您所選擇的技術類型，或是您操作工作負載的方式。將組織管控要求納入您的工作負載中。合規是指展現您已實作管控要求的能力。
**預期成果：**
+ 管控要求會併入工作負載的架構設計和操作中。
+ 您可以提供您已遵循管控要求的證明。
+ 定期審查並更新管控要求。
**常見的反模式：**
+ 您的組織規定根帳戶需進行多重要素驗證。您未能實行此要求，根帳戶遭到損害。
+ 在設計工作負載期間，您選擇了未經 IT 部門核准的執行個體類型。您無法啟動工作負載，而必須執行重新設計。
+ 您必須有災難復原計畫。您未建立該計畫，且工作負載遭逢長時間的中斷。
+ 您的團隊想要使用新的執行個體，但您的管理要求尚未更新予以允許。
**建立此最佳實務的優勢：**
+ 遵循管控要求，可讓您的工作負載符合較大組織的政策。
+ 管控要求會反映組織的產業標準和最佳實務。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
與利益相關者和管控組織共同識別管控要求。將管控要求納入您的工作負載中。能夠證明您已遵循管控要求。
**客戶範例**
在 AnyCompany 零售，雲端營運團隊會與整個組織的利益相關者合作，以開發治理要求。例如，它們禁止SSH存取 Amazon EC2執行個體。如果團隊需進行系統存取，他們必須使用 AWS Systems Manager Session Manager。雲端營運團隊會在新服務推出時定期更新管控要求。
**實作步驟**
1. 識別工作負載的利益相關者，包括任何集中團隊。
1. 與利益相關者共同識別管控要求。
1. 產生清單後，請排定改善項目的優先順序，並開始在您的工作負載中加以實作。
1. 使用 等服務[AWS Config](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)來建立 governance-as-code和驗證遵循了治理要求。
1. 如果您使用 [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)，則可以利用服務控制政策來實作管控要求。
1. 提供驗證實作情形的文件。
**實作計劃的工作量：**中。實作遺漏的管控要求可能會導致工作負載重新作業。
## 資源
**相關的最佳實務：**
+ [OPS01-BP04 評估合規要求](ops_priorities_compliance_reqs.md) - 合規性類似於管控，但來自組織外部。
**相關文件：**
+ [AWS 管理和治理雲端環境指南 ](https://docs.aws.amazon.com/wellarchitected/latest/management-and-governance-guide/management-and-governance-cloud-environment-guide.html)
+ [ 多帳戶環境中 AWS Organizations 服務控制政策的最佳實務 ](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [ 中的治理 AWS 雲端：敏捷性與安全之間的正確平衡 ](https://aws.amazon.com/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/)
+ [ 什麼是治理、風險與合規 （GRC）？ ](https://aws.amazon.com/what-is/grc/)
**相關影片：**
+ [AWS 管理和治理：組態、合規和稽核 - AWS 線上技術講座 ](https://www.youtube.com/watch?v=79ud1ZAaoj0)
+ [AWS re：Inforce 2019：雲端時代的治理 （DEM12-R1） ](https://www.youtube.com/watch?v=y3WmHnavuN8)
+ [AWS re：Invent 2020：使用 實現合規作為程式碼 AWS Config](https://www.youtube.com/watch?v=m8vTwvbzOfw)
+ [AWS re：Invent 2020：靈活管理 AWS GovCloud (US)](https://www.youtube.com/watch?v=hv6B17eriHQ)
**相關範例：**
+ [AWS Config Conformance Pack 範例 ](https://docs.aws.amazon.com/config/latest/developerguide/conformancepack-sample-templates.html)
**相關服務：**
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Organizations - 服務控制政策 ](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)
# OPS01-BP04 評估合規要求
法規、產業和內部合規要求是定義組織優先順序的重要因子。您的合規架構可能會禁止使用特定技術或地理位置。若未識別出外部合規架構，請運用盡職調查。產生驗證合規性的稽核或報告。
如果聲明您的產品符合特定的合規標準，您必須有內部程序來確保持續的合規性。合規標準的例子包括 PCI DSS、FedRAMP 和 HIPAA。適用的合規標準取決於各種因素，例如解決方案存放或傳輸的資料類型，以及解決方案支援的地理區域。
**預期成果：**
+ 將法規、產業和內部合規要求併入架構選擇中。
+ 您可以驗證合規性並產生稽核報告。
**常見的反模式：**
+ 您的工作負載有部分屬於支付卡產業資料安全標準 (PCI-DSS) 架構下，但您的工作負載儲存信用卡資料時並未予以加密。
+ 您的軟體開發人員和架構師不知道您的組織必須遵循的合規架構。
+ 年度 Systems and Organizations Control (SOC2) Type II 稽核即將到來，但您無法驗證已設置控制。
**建立此最佳實務的優勢：**
+ 評估和了解套用到工作負載的合規要求，可讓您了解如何安排工作的優先順序來實現商業價值。
+ 您可以選擇與合規架構相符的適當位置和技術。
+ 針對可稽核性設計工作負載，有助於證明您確實遵循合規架構。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
若實作此最佳實務，即表示您會在架構設計程序中併入合規要求。您的團隊成員將得知必要的合規架構。您會驗證合規性符合架構。
**客戶範例**
AnyCompany Retail 儲存客戶的信用卡資訊。卡片儲存團隊的開發人員了解他們必須遵從 PCI-DSS 架構。他們執行了相關步驟，驗證信用卡資訊以安全方式儲存和存取，並遵從 PCI-DSS 架構。他們每年都會與安全團隊共同驗證合規性。
**實作步驟**
1. 與安全和管控團隊合作，確認您的工作負載必須遵循哪些產業、法規或內部合規架構。在您的工作負載中併入合規架構。
1. 使用諸如 [AWS Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/latest/ug/what-is-compute-optimizer.html) 和 [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) 之類的服務驗證 AWS 資源的持續合規性。
1. 讓團隊成員了解合規要求，使其能據以操作及設計工作負載。合規要求應包含在架構和技術選擇中。
1. 根據合規架構，您可能必須產生稽核或合規報告。請與組織合作，盡可能將此程序自動化。
1. 使用諸如 [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html) 等服務來驗證合規性並產生稽核報告。
1. 可以使用 [AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/what-is-aws-artifact.html) 下載 AWS 安全性和合規性文件。
**實作計劃的工作量：**中。實作合規架構可能並不容易。產生稽核報告或合規文件，會增添額外的複雜性。
## 資源
**相關的最佳實務：**
+ [SEC01-BP03 識別並驗證控制目標](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_control_objectives.html) - 安全控制目標是整體合規性的重要組成部分。
+ [SEC01-BP06 自動化管道中安全控制的測試和驗證](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_test_validate_pipeline.html) - 作為管道的一部分，驗證安全控制。您也可以產生新變更的合規文件。
+ [SEC07-BP02 定義資料保護控制](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_data_classification_define_protection.html) - 許多合規性框架都基於資料處理和儲存政策。
+ [SEC10-BP03 準備鑑識功能](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_prepare_forensic.html) - 鑑識功能有時可用於稽核合規性。
**相關文件：**
+ [AWS 合規中心](https://aws.amazon.com/financial-services/security-compliance/compliance-center/)
+ [AWS 合規資源](https://aws.amazon.com/compliance/resources/)
+ [AWS 風險與合規白皮書](https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/welcome.html)
+ [AWS 共同責任模型](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [合規計劃範圍內的 AWS 服務](https://aws.amazon.com/compliance/services-in-scope/)
**相關影片：**
+ [AWS re:Invent 2020：使用 AWS Compute Optimizer 實現合規即程式碼](https://www.youtube.com/watch?v=m8vTwvbzOfw)
+ [AWS re:Invent 2021 - 雲端合規性、保證和稽核](https://www.youtube.com/watch?v=pdrYGVgb08Y)
+ [AWS Summit ATL 2022 - 在 AWS 上實作合規性、保證和稽核 (COP202)](https://www.youtube.com/watch?v=i7XrWimhqew)
**相關範例：**
+ [AWS 上的 PCI DSS 和 AWS 基礎安全最佳實務](https://aws.amazon.com/solutions/partners/compliance-pci-fsbp-remediation/)
**相關服務：**
+ [AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/what-is-aws-artifact.html)
+ [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html)
+ [AWS Compute Optimizer](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)
# OPS01-BP05 評估威脅態勢
評估對業務的威脅 (例如，競爭、業務風險和負債、營運風險和資訊安全威脅)，並將最新的資訊保存在風險登記表內。決定工作重點的領域時，加入風險影響。
[Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/) 強調學習、衡量和改善。它提供一致的方法來評估架構，並實作會隨著時間擴展的設計。 AWS 提供 [AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/)，協助您在開發之前檢閱方法、生產前的工作負載狀態，以及生產中工作負載的狀態。您可以將它們與最新的 AWS 架構最佳實務進行比較，監控工作負載的整體狀態，並深入了解潛在風險。
AWS 客戶有資格接受其任務關鍵工作負載的引導式 Well-Architected Review，以根據 AWS 最佳實務[測量其架構](https://aws.amazon.com/premiumsupport/programs/)。企業支援客戶有資格獲得[營運審查](https://aws.amazon.com/premiumsupport/programs/)，該審查旨在助其識別在雲端營運的方法中的差距。
這些審查的跨團隊參與有助於建立對您的工作負載以及團隊角色可如何助力成功的共識。透過審查識別的需求可以助您確定優先順序。
[AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) 是一款可存取核心檢查集的工具，這些檢查提出了優化建議，可能有助您確定優先事項。[商業和企業支援客戶](https://aws.amazon.com/premiumsupport/plans/)可存取針對安全性、可靠性、效能和成本優化的其他檢查，從而進一步協助確定他們的優先事項。
**預期成果：**
+ 您可以定期檢閱 Well-Architected 和 Trusted Advisor 輸出並採取行動
+ 您已知道服務的最新修補程式狀態
+ 您了解已知威脅的風險和影響，並採取相應的行動
+ 視需要實作緩和措施
+ 對行動和背景進行溝通
**常見的反模式：**
+ 您在產品中使用舊版的軟體程式庫。您不知道程式庫的安全性更新是否會對工作負載產生意外影響。
+ 競爭對手剛剛發布了其產品的一個版本，它可以解決許多客戶對您產品的投訴。您並未優先處理這些已知問題。
+ 監管機構一直在追查像你們這樣不符合法律監管合規要求的公司。您尚未排定處理任何未解決合規要求之事項的優先順序。
**建立此最佳實務的優勢：**識別並了解組織和工作負載所面臨的威脅，有助於您判斷要解決哪些威脅、它們的優先順序以及執行此作業所需的資源。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
+ **評估威脅態勢：**評估對業務的威脅 (例如，競爭、業務風險和負債、營運風險和資訊安全威脅)，以便您可以在決定工作重點時考量其影響。
+ [AWS 最新安全公告](https://aws.amazon.com/security/security-bulletins/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ **維護威脅模型：**建立和維護用於識別潛在威脅、已規劃和就地緩解措施及其優先順序的威脅模型。審查顯示為事件的威脅的機率、從這些事件中復原的成本、導致的預期傷害，以及防止這些事件的成本。當威脅模型的內容變更時，修改優先順序。
## 資源
**相關的最佳實務：**
+ [SEC01-BP07 使用威脅模型識別威脅並排定緩解優先順序](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html)
**相關文件：**
+ [AWS 雲端 合規](https://aws.amazon.com/compliance/)
+ [AWS 最新安全公告](https://aws.amazon.com/security/security-bulletins/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
**相關影片：**
+ [AWS re:Inforce 2023 - 協助改善威脅模型的工具](https://youtu.be/CaYCsmjuiHg?si=e_CXPGqRF4WeBr1u)
# OPS01-BP06 評估權衡的同時管理利益和風險
來自多方的競爭利益可能會使安排工作的優先順序、建立能力、交付與業務策略一致的成果變得具有挑戰性。例如，您可能會被要求加快新功能的上市速度，而不是最佳化 IT 基礎架構成本。這會使利益雙方發生衝突。在這種情況下，需要將決策提交給更高的權利層來解決衝突。需要使用資料來消除決策過程中的情感依戀。
同樣的挑戰可能會發生在戰術層面。例如，選擇使用關聯式或非關聯式資料庫技術，可能會對應用程式的操作產生重大影響。了解各種選擇的可預測結果至關重要。
AWS 可以協助您教育您的團隊有關 AWS 及其服務的知識，從而增進他們對自己的選擇會如何影響工作負載的了解。使用 [支援](https://aws.amazon.com/premiumsupport/programs/) ([AWS 知識中心](https://aws.amazon.com/premiumsupport/knowledge-center/)、[AWS 論壇](https://forums.aws.amazon.com/index.jspa)和 [支援 中心](https://console.aws.amazon.com/support/home/)) 和 [AWS 文件](https://docs.aws.amazon.com/)提供的資源來教育您的團隊。如有其他問題，請聯絡 支援。
AWS 還可以在 [Amazon 建置者資料中心](https://aws.amazon.com/builders-library/)中分享操作最佳實務和模式。您可透過 [AWS 部落格](https://aws.amazon.com/blogs/)和[官方 AWS 播客](https://aws.amazon.com/podcasts/aws-podcast/)獲得其他各種實用資訊。
**預期成果：**您擁有明確定義的決策管控框架，可以促進雲端交付組織內每個層級的重要決策。該框架包括很多功能，例如風險登記表、有權做出決策的已定義角色以及可以做出的每個決策級別的定義模型。此框架預先定義了如何解決衝突，需要呈現哪些資料，以及如何確定選項的優先級，以便一旦做出決定，就可以立即提交。決策框架包括一個標準化方法，可審查和衡量每個決策的利益和風險，以了解權衡。這可能包括外部因素，例如遵守法規合規要求。
**常見的反模式：**
+ 您的投資者要求您證明支付卡產業資料安全標準 (PCI DSS) 的合規性。您沒有考量滿足要求和繼續您目前開發工作之間的權衡取捨。相反地，您繼續開發工作，而不證明合規性。由於對平台安全性及其投資的擔憂，您的投資者會停止對公司的支援。
+ 您已決定包含其中一位開發人員在網際網路上發現的程式庫。您尚未評估從未知來源採用此程式庫的風險，並且不知道它是否包含弱點或惡意程式碼。
+ 遷移的最初業務理由是基於應用程式工作負載 60% 的現代化。然而，由於技術上的困難，決定只對 20% 進行現代化，導致長期計劃收益減少，基礎架構團隊手動支援舊式系統的操作員工作量增加，並且更依賴於在沒有規劃此變更的基礎架構團隊中開發新技能。
**建立此最佳實務的優勢：**充分協調和支援董事會層級的業務優先事項、了解取得成功的風險、制定明智決策，以及在風險阻礙成功機會時採取適當行動。了解決策的影響和後果有助於您優先考慮您的選擇，並更快地讓領導者達成一致，從而改善業務成果。確定您的選擇的可用好處並了解組織的風險，可以幫助您制定資料驅動型決策，而不是依賴於軼事。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
管理利益和風險應由推動關鍵決策要求的管理機構來定義。您希望根據決策如何使組織受益來做出決策並確定優先級，並了解所涉及的風險。準確的資訊對於制定組織決策至關重要。這應該基於可靠的測量結果，並由成本效益分析的常見行業實務進行定義。要做出這些類型的決策，請在集中式和分散式授權之間取得平衡。總有一種權衡，了解每個選擇如何影響定義的策略和期望的業務成果至關重要。
### 實作步驟
1. 在整體式雲端治理架構中正式確定效益衡量實務。
1. 在決策的中央控制與某些決策的分散權力之間取得平衡。
1. 了解強加給每項決策的繁瑣決策流程可能會減緩您的速度。
1. 將外部因素納入決策流程中 (例如合規要求)。
1. 為各級決策建立一個商定的決策框架，其中包括誰需要為受衝突利益影響的決策清除障礙。
1. 集中化可能不可逆轉的單向門決策。
1. 允許由較低級別的組織領導者做出雙向門決策。
1. 了解和管理利益和風險。在決策的收益與所涉及的風險之間取得平衡。
1. **確定收益**：根據業務目標、需求和優先事項確定收益。範例包括企劃案影響、上市時間、安全性、可靠性、效能和成本。
1. **確定風險**：根據業務目標、需求和優先事項確定風險。範例包括上市時間、安全性、可靠性、效能和成本。
1. **根據風險評估收益並做出明智決策**：根據利益相關者 (包括業務、開發和營運團隊) 的目標、需求和優先事項，確定收益和風險的影響。評價收益的價值時要考慮發生風險的可能性及其代價。例如，強調上市速度優先於可靠性，可能提供競爭優勢。不過，如果發生可靠性問題，則可能會縮短正常執行時間。
1. 以程式設計方式強制執行關鍵決策，讓您自動遵守合規要求。
1. 利用已知的產業架構和功能，例如「價值串流分析」和 LEAN，對目前的狀態效能、業務指標進行基準分析，並定義這些指標的進度迭代。
**實作計劃的工作量：**中高
## 資源
**相關的最佳實務：**
+ [OPS01-BP05 評估威脅環境](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_threat_landscape.html)
**相關文件：**
+ [Amazon 的 Day 1 文化要素 \$1 做出高品質、高速度的決策](https://aws.amazon.com/executive-insights/content/how-amazon-defines-and-operationalizes-a-day-1-culture/)
+ [雲端治理](https://aws.amazon.com/cloudops/cloud-governance/)
+ [管理與治理雲端環境](https://docs.aws.amazon.com/wellarchitected/latest/management-and-governance-guide/management-and-governance-cloud-environment-guide.html?did=wp_card&trk=wp_card)
+ [雲端和數位時代的治理：第一部分和第二部分](https://aws.amazon.com/blogs/enterprise-strategy/governance-in-the-cloud-and-in-the-digital-age-part-one/)
**相關影片：**
+ [播客 \$1 Jeff Bezos \$1 關於如何制定決策](https://www.youtube.com/watch?v=VFwCGECvq4I)
**相關範例：**
+ [使用資料做出明智決策 (DevOps Sagas)](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/oa.bcl.10-make-informed-decisions-using-data.html)
+ [使用開發價值串流映射來識別 DevOps 結果的限制](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-devops-value-stream-mapping/introduction.html)
# 操作模型
在本節中，我們提供了一種方法來了解您所使用的操作模型、如何視覺化模型，以及在團隊層級上您應該如何發展以從雲端服務投資中獲取最大價值。透過這樣做，您可以增強操作實務，建置敏捷的團隊和工作負載，並為業務成果做出積極貢獻。
您的團隊通常存在於多個組織層級中，而這些層級都具有現有的工作方式。與您的團隊一起實現業務成果意味著了解您的團隊在這些層級中的位置、與您互動的團隊的位置以及他們的工作方式。此外，團隊需要了解自己在促成其他團隊成功的過程中所扮演的角色、知道其他團隊在促進其成功的過程中所扮演的角色，以及擁有共同目標。
這些層級構成了組織的整體操作模式。組織如何發揮作用來交付業務成果取決於許多因素，例如類型、產業、地理位置、規模和自治程度。但是，它可能分為三大類：
+ 集中
+ 分散式
+ 聯合
這些組織層級拓撲在[成功組織](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/implement-roadmap.html#organize)中加以說明。
您的團隊和工作負載存在於您組織的操作模式中。但是，無法要求單一操作模式支援所有團隊及其工作負載。因此，您的團隊也需要自己的操作模式。這種工作方式取決於您的組織、您的部門、團隊組成，以及工作負載本身的特性。
大多數遷移至雲端的組織都是將其作為企業轉型計畫的一部分，該計畫旨在解鎖新的工作方式 (操作模式) 以支援長期策略目標。此旅程不是一個時間點演練，而是一個需要不斷演進、逐步推進策略目標的過程。這可讓工作負載擁有者以最少的干擾來適應不斷發展的操作模式。
Amazon 經常用作大型組織如何大規模創新的範例，方法是讓團隊貼近客戶、快速推出創新產品和服務，以及利用支援速度和敏捷性的技術架構。這要求我們重組團隊的組織方式，現在稱為*雙披薩團隊*。一個雙披薩團隊內嵌了所有適當的資源 (工程、測試、產品和計畫管理及營運) 來擁有和執行端對端的工作負載。
我們建議將此操作模式作為一種行之有效的方法，讓工作負載團隊快速行動，並以最好的方式為客戶服務，為整體業務成果做出貢獻。
尋求效仿這種成功的組織可能需要在整個轉型之旅中調整其操作模式。在組織和團隊層級，這都需要考慮、規劃和溝通。下節提供了一種方式，視覺化說明這些團隊層級操作模式及其如何發展為*誰開發誰執行*。
# 操作模式 2 x 2 表示法
這些操作模式 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)
# 完全獨立的操作模式
應用程式和平台位於下圖的垂直軸上。應用程式是指幫助實現業務成果的工作負載，可以是自訂開發或採購的軟體。平台是指實體和虛擬基礎設施，以及支援該工作負載的其他軟體。
工程和操作位於水平軸上。工程是指開發、建置和測試應用程式和基礎設施。操作是指部署、更新及持續支援應用程式和基礎設施。
![\[傳統模式圖\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/operational-excellence-pillar/images/full-seperate.png)
從歷史上看，組織採用了 ITIL 等架構或 ISO 等標準，並圍繞這些架構或標準制定營運活動，這通常會導致完全分離的拓撲。在此模式中，各象限中的活動由個別團隊執行。工作透過工作請求、佇列、票證或使用 IT 服務管理 (ITSM) 系統等機制，在團隊之間轉交。
任務轉給團隊或團隊間的任務轉交會讓事情變得更複雜，並形成瓶頸與延誤。除非是要優先處理的請求，否則請求可能延誤處理。如果晚發現缺陷，可能需要大量重新作業，也可能需要再次交由相同的團隊和職務處理。如果發生需由工程團隊採取行動的事件，其回應會因遞交活動而受到延誤。
當業務、開發和營運團隊根據正在執行的活動或職務組織時，目標不一致的風險會升高。如此會導致讓團隊專注於其特定責任，而非專注於達成業務成果。團隊可能專精於狹隘的領域，或在實際或邏輯空間上遭到分離，因而阻礙溝通與合作。
# DevOps 搭配雲端受管服務供應商
「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)
此雲端維運和平台啟用 (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
分散式 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
分散式 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 套用持續管控，以及自動化新帳戶的佈建。
讓應用程式團隊設有請求標準新增和變更的機制，將會帶來好處。他們可以貢獻可使其他應用程式團隊受益的新標準。平台團隊可能會認為，為這些其他功能直接提供支援，能有效幫助實現業務成果。
此模式透過重要技能和團隊成員要求，減少對於創新的限制。它解決了團隊間轉交任務所導致的許多瓶頸和延誤，同時仍促進團隊與客戶之間建立有效的關係。
# 改進您的操作模式
提供的模式在工作負載層級逐步邁向更多自主性，符合「雙比薩團隊」原則。重要的是要了解，從傳統方法到分散式 DevOps (作為持續發展到「雙比薩團隊」模式的基礎) 的旅程可能需要時間，並且需要在許多功能方面建置成熟度。因此，我們提供了一個範例，說明當您的團隊和組織在企業轉型之旅中如何在模式之間轉換。在每個變更或模式中，您都在朝著一個更自主，但仍然與組織保持一致的團隊發展。
![\[從內部部署至自動化價值串流和程序的雲端操作模式發展圖\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/operational-excellence-pillar/images/evolving-ops.en.png)
在評估您的團隊如何支援貴組織發展時，請檢查模式之間的權衡、您的個別團隊位於模式中的哪個階段 (在轉型和發展時)、您團隊的關係和責任可能如何變更，以及效益是否能夠影響貴組織。請記住，變化從來都不是線性的。某些模式更適合旅程中的特定使用案例或時間點，而其中一些模式可能比您環境中的模式具有優勢。
# 關係和擁有權
您的操作模式定義團隊之間的關係，並支援可識別的擁有權和責任。
**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)
# 組織文化
為您的團隊成員提供支援，讓他們能夠更有效地採取*動作以及支援業務成果*。
**Topics**
+ [OPS03-BP01 提供高層支持](ops_org_culture_executive_sponsor.md)
+ [OPS03-BP02 授權團隊成員在成果有風險時採取動作](ops_org_culture_team_emp_take_action.md)
+ [鼓勵 OPS03-BP03 升級](ops_org_culture_team_enc_escalation.md)
+ [OPS03-BP04 溝通需及時、清楚且可行](ops_org_culture_effective_comms.md)
+ [OPS03-BP05 鼓勵進行試驗](ops_org_culture_team_enc_experiment.md)
+ [OPS03-BP06 管理團隊成員維持和發展自己的技能集](ops_org_culture_team_enc_learn.md)
+ [OPS03-BP07 資源團隊適當](ops_org_culture_team_res_appro.md)
# OPS03-BP01 提供高層支持
在最高層面上，高級領導層充當執行倡議者，以清楚地設定組織成果的期望和方向，包括評估其成功。倡議者倡導並推動最佳實務的採用和組織的發展。
**預期成果：**努力採用、轉型和最佳化雲端操作的組織可針對預期成果設定明確的領導層和問責製。該組織了解組織實現新成果所需的每種能力，並將擁有權分配給職能團隊進行開發。領導層積極制定此方向、分配擁有權、承擔責任並定義工作。因此，整個組織的個人都可以調動起來、備受鼓舞並積極朝著預期目標努力。
**常見的反模式：**
+ 在沒有明確的雲端營運倡議者和計劃的情況下，工作負載擁有者必須將工作負載遷移至 AWS。這導致團隊無法自覺地協作以改善和充分發展其營運能力。缺乏營運最佳實務標準使團隊不堪重負 (例如營運商辛苦工作、隨叫隨到以及技術債務)，這會限制創新。
+ 一個新的全組織目標已設定，即在不提供領導倡議者和策略的情況下採用新興技術。團隊以不同的方式闡述目標，這會導致對於將精力集中在哪裡、為什麼重要以及如何衡量影響感到困惑。因此，組織在採用技術方面失去了動力。
**建立此最佳實務的優勢：**當高層的支援明確傳達並分享願景、方向和目標時，團隊成員知道他們的期望是什麼。當領導者積極參與時，個人和團隊開始將精力集中在相同的方向上，以實現定義的目標。因此，組織得以運用最強大的能力來獲得成功。當您評估成功時，您可以更好地識別成功障礙，以便透過高層支持的干預來解決這些障礙。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
+ 在雲端之旅的每個階段 (遷移、採用或最佳化)，成功都需要最高領導層與指定執行倡議者的積極參與。執行倡議者可根據定義的策略來調整團隊的心態、技能組合和工作方式。
+ **解釋*原因*：**澄清並解釋願景和策略背後的原因。
+ **設定期望：**為您的組織定義和發佈目標，包括如何衡量進度和成功。
+ **追蹤目標的達成情況：**定期衡量目標逐步達成的情況 (不只是完成任務)。分享結果，以便在成果有風險時可以採取適當的行動。
+ **提供實現目標所需的資源：**將人員和團隊聚集在一起，共同合作並構建正確的解決方案，以實現定義的成果。這可減少或消除組織摩擦。
+ **倡導您的團隊：**與您的團隊保持互動，以便了解他們的表現以及是否有影響他們的外部因素。找出阻礙您團隊進度的障礙。代表您的團隊來協助解決障礙並消除不必要的負擔。當您的團隊受到外部因素影響時，請重新評估目標並適當地調整目標。
+ **推動採用最佳實務：**確認提供量化效益的最佳實務，並認可建立者和採用者。鼓勵進一步採用，以擴大已達成的效益。
+ **鼓勵團隊發展：**創造持續改進的文化，並主動從取得的進步和失敗中學習。鼓勵人員和組織的成長和發展。利用資料和軼事來發展願景和策略。
**客戶範例**
AnyCompany Retail 正在透過快速重新打造客戶體驗、提高生產力，以及透過生成式 AI 加速成長來實現業務轉型。
### 實作步驟
1. 建立單一執行緒領導，並指派主要執行倡議者來領導和推動轉型。
1. 定義轉型的明確業務成果，並指派擁有權和責任。讓主要執行人員具有領導和做出關鍵決策的權限。
1. 驗證您的轉型策略非常清晰，並且由執行倡議者廣泛傳達到組織的各個層級。
1. 為 IT 和雲端計畫建立明確定義的業務目標。
1. 記錄關鍵業務指標，以推動 IT 和雲端轉型。
1. 將願景一致地傳達給負責策略各部分的所有團隊和個人。
1. 制定溝通規劃矩陣，指定需要傳遞給特定領導人、經理和個別貢獻者的訊息。指定應傳遞此訊息的人員或團隊。
1. 一致且可靠地履行溝通計劃。
1. 定期透過面對面活動設定並管理期望。
1. 接受有關溝通有效性的反饋，並相應地調整溝通並進行計劃。
1. 安排溝通活動以主動了解團隊的挑戰，並建立一致的回饋迴圈，以便在必要時糾正過程。
1. 從領導角度積極參與每項舉措，以驗證所有受影響的團隊都了解他們應負責實現的成果。
1. 在每次狀態會議上，執行倡議者都應該查找阻礙因素，檢查既定的指標、軼事或團隊的反饋，並衡量實現目標的進展情況。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS03-BP04 溝通需及時、清楚且可行](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_effective_comms.html)
+ [OP11-BP01 建立持續改進程序](wellarchitected/latest/operational-excellence-pillar/evolve/learn_share_and_improve/ops_evolve_ops_process_cont_imp.html)
+ [OPS11-BP07 執行營運指標審查](wellarchitected/latest/operational-excellence-pillar/evolve/learn_share_and_improve/ops_evolve_ops_metrics_review.html)
**相關文件：**
+ [解決組織困擾：高度一致](https://aws.amazon.com/blogs/enterprise-strategy/untangling-your-organisational-hairball-highly-aligned/)
+ [正在實施轉型：務實地應對變化](https://aws.amazon.com/blogs/enterprise-strategy/the-living-transformation-pragmatically-approaching-changes/)
+ [成為面向未來的企業](https://aws.amazon.com/blogs/enterprise-strategy/becoming-a-future-ready-enterprise/)
+ [建置 CCOE 時應避開的 7 大陷阱](https://aws.amazon.com/blogs/enterprise-strategy/7-pitfalls-to-avoid-when-building-a-ccoe/)
+ [導覽雲端：成功的關鍵績效指標](https://aws.amazon.com/blogs/enterprise-strategy/navigating-the-cloud-key-performance-indicators-for-success/)
**相關影片：**
+ [AWS re:Invent 2023：生成式 AI 的領導者指南：利用歷史塑造未來 (SEG204)](https://youtu.be/e3snrDsct1o)
**相關範例：**
+ [Prosci：主要倡議者的角色和重要性](https://www.prosci.com/blog/primary-sponsors-role-and-importance)
# OPS03-BP02 授權團隊成員在成果有風險時採取動作
由領導層灌輸的擁有權文化行為使所有員工都感到有權代表整個公司行事，超出了其定義的角色和責任範圍。員工可以採取行動，在風險出現時主動識別風險，並採取適當的措施。這樣的文化使員工能夠在了解情況的同時做出高價值決策。
例如，Amazon 使用[領導方針](https://www.amazon.jobs/content/en/our-workplace/leadership-principles)作為指引，以推動員工在各種情況下前進、解決問題、處理衝突並採取行動的期望行為。
**預期成果：**領導層的影響力擴大，培養出新的文化，讓組織內較低層級的個人和團隊也能做出關鍵決策 (只要是透過可稽核的許可和安全機制來定義決策即可)。失敗並不氣餒，團隊反覆學習以改善他們的決策和應對措施，從而解決未來的類似情況。如果某人的行動導致可以使其他團隊受益的改進，則他們會主動分享此類行動中的知識。領導層會衡量運營改進，並激勵個人和組織採用此類模式。
**常見的反模式：**
+ 在識別風險時，組織中沒有明確的指引或機制來進行應對。例如，當員工發現網路釣魚攻擊時，他們無法向安全團隊報告，導致組織中很大一部分人受到攻擊。這會導致資料外洩。
+ 客戶抱怨服務無法使用，這主要源於部署失敗。SRE 團隊負責部署工具，而部署的自動復原則在他們的長期藍圖中。在最近推出的應用程式中，其中一位工程師設計了一種解決方案，將其應用程式自動還原到舊版本。雖然他們的解決方案可以成為 SRE 團隊的模式，但其他團隊不會採用，因為沒有追蹤此類改進的流程。組織繼續受到部署失敗的困擾，影響了客戶並導致進一步的負面情緒。
+ 為了保持一致，資訊安全團隊會監督一個歷史悠久的流程，以代表連線至其 Amazon EC2 Linux 執行個體的營運商定期輪換共用的 SSH 金鑰。資訊安全團隊需要幾天的時間才能完成輪換金鑰，而且會阻止您連線到這些執行個體。資訊安全團隊內外沒有人建議在 AWS 上使用其他選項來實現相同的結果。
**建立此最佳實務的優勢：**透過分散權限來制定決策，並授權團隊決定關鍵決策，您可以更快地解決問題，提高成功率。此外，團隊開始意識到主人翁精神，並且失敗是可以接受的。實驗成為文化中流砥柱。經理和董事並不覺得他們在工作的各個方面都受到了微觀管理。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
1. 培養一種預期可能會發生失敗的文化。
1. 為組織內各個職能區域定義明確的擁有權和責任。
1. 向每個人傳達擁有權和責任感，以便個人知道誰可以幫助他們促進分散式決策。
1. 定義您的單向和雙向門決策，以幫助個人了解何時需要升級到更高的領導層級。
1. 建立組織意識，讓所有員工有能力在結果出現風險時，在不同層面採取行動。為您的團隊成員提供管控文件、權限級別、工具和機會，以練習有效回應所需的技能。
1. 讓您的團隊成員有機會練習應對各種決策所需的技能。定義決策等級後，請執行演練日，以驗證所有個別參閱者是否了解並能夠演示該過程。
1. 提供替代的安全環境，在其中可測試和培訓流程及程序。
1. 承認並意識到，當結果出現預先定義的風險等級時，團隊成員有權採取行動。
1. 透過指派權限和對其支援的工作負載和元件的存取權，定義團隊成員採取動作的權限。
1. 讓團隊能夠分享學習經驗 (運營成功和失敗)。
1. 使團隊能夠挑戰現狀，並提供機制來追蹤和衡量改進，以及這些改進對組織的影響。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS01-BP06 評估權衡，同時管理收益和風險](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)
+ [OPS02-BP05 存在識別責任和擁有權的機制](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_req_add_chg_exception.html)
**相關文件：**
+ [AWS 部落格文章 \$1 敏捷企業](https://aws.amazon.com/blogs/enterprise-strategy/the-agile-enterprise/)
+ [AWS 部落格文章 \$1 衡量成功：悖論和計畫](https://aws.amazon.com/blogs/enterprise-strategy/measuring-success-a-paradox-and-a-plan/)
+ [AWS 部落格文章 \$1 放手：實現團隊的自主權](https://aws.amazon.com/blogs/enterprise-strategy/letting-go-enabling-autonomy-in-teams/)
+ [集中化還是分散化？](https://aws.amazon.com/blogs/enterprise-strategy/centralize-or-decentralize/)
**相關影片：**
+ [re:Invent 2023 \$1 如何不破壞轉型 (SEG201)](https://www.youtube.com/watch?v=heLvxK5N8Aw)
+ [re:Invent 2021 \$1 Amazon 建置者資料中心：Amazon 的卓越營運](https://www.youtube.com/watch?v=7MrD4VSLC_w)
+ [集中化與分散化](https://youtu.be/jviFsd4hhfE?si=fjt8avVAYxA9jF01)
**相關範例：**
+ [使用架構決策記錄來簡化軟體開發專案的技術決策](https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/welcome.html)
# 鼓勵 OPS03-BP03 升級
如果團隊成員認為預期成果存在風險並且達不到預期標準，領導層鼓勵他們將問題和疑慮向上呈報給更高層級的決策者和利益相關者。這是組織文化的一個特徵，並且在各個層面推動。應該儘早且經常向上呈報，以便識別風險，並防止風險引發事件。領導層不會譴責向上呈報問題的個人。
**預期成果：**整個組織的個人都很樂意將問題呈報給他們的直接和更高級別的領導層。領導層刻意和有意識地建立了期望，即他們的團隊在呈報任何問題時感到非常安全。存在一種機制來呈報組織內每個層級的問題。當員工呈報到經理時，他們共同決定影響的程度，以及是否應該呈報問題。為了啟動呈報，員工需要包含建議的工作計畫以解決問題。如果直接管理層沒有及時採取行動，則鼓勵員工在強烈認為組織面臨的風險需要呈報時，將問題呈報給最高領導層。
**常見的反模式：**
+ 在雲端轉型計畫狀態會議期間，高層主管沒有提出足夠的探究性問題，以找出問題和阻礙發生的位置。只有好消息被呈現為狀態。CIO 已明確表示她只喜歡聽到好消息，因為提出的任何挑戰都會讓 CEO 認為程式失敗。
+ 您是雲端操作工程師，您注意到應用程式團隊並未廣泛採用新的知識管理系統。該公司投入了一年時間和數百萬美元來實作這個新的知識管理系統，但人們仍然在本地編寫他們的執行手冊，並在組織的雲端共享中進行分享，這使得很難找到與所支援的工作負載相關的知識。您試圖引起領導層的注意，因為持續使用此系統可以提高運營效率。當您將其提交給領導該知識管理系統實作的主管時，她會譴責您，因為它讓投資受到質疑。
+ 負責強化運算資源的資訊安全團隊已決定制定程序，該程序需要執行必要的掃描，以確保EC2執行個體在運算團隊釋出資源以供使用之前完全安全。這為要部署的資源建立了額外一週的時間延遲，這會中斷其 SLA。運算團隊害怕透過雲端將此問題呈報給 VP，因為這會讓資訊安全 VP 出醜。
**建立此最佳實務的優勢：**
複雜或重大問題在影響業務之前得到解決。浪費的時間更少。風險最小化。在解決問題時，團隊變得更加積極主動並注重結果。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
在組織的各個層面自由呈報的意願和能力是一個組織和文化基礎，應該透過強調培訓、領導溝通、期望設定以及在組織各個層面的機制部署來有意識地進行發展。
### 實作步驟
1. 定義組織的政策、標準和期望。
1. 確保廣泛採用和理解政策、期望和標準。
1. 在不符合標準時，鼓勵、培訓和授權工人儘早和頻繁呈報。
1. 組織認可儘早且頻繁呈報是最佳實務。接受向上呈報可能經證明是毫無根據的，然而有機會防止事件的發生好過於不向上呈報而錯過機會。
1. 建立呈報機制 (例如 Andon Cord 系統)。
1. 制定書面程序，定義向上呈報的時機與方式。
1. 定義一系列具有越來越多權限可採取或批准行動的人員，以及每個利益相關者的聯絡資訊。
1. 當進行呈報時，它應該繼續下去，直到團隊成員確信透過領導層推動的行動緩解了風險。
1. 呈報應包括：
1. 情況描述和風險性質
1. 情況嚴重性
1. 誰或什麼受到影響
1. 影響有多大
1. 發生影響時的緊迫性
1. 建議的補救措施和緩解計畫
1. 保護向上呈報的員工。如果團隊成員圍繞無回應決策制定者或利益相關者向上呈報，則制定保護團隊成員免受報復的政策。制定機制以識別是否發生此情況，並適當地做出回應。
1. 鼓勵在組織生產的一切產品中建立持續改進回饋迴圈的文化。回饋迴圈充當負責個人的小型呈報，他們可確定改進機會，即使不需要升級。持續改進的文化迫使每個人都更加積極主動。
1. 領導層應定期重新強調政策、標準、機制，以及對公開呈報和持續回饋迴圈而不受報復的願望。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS02-BP05 存在用於要求新增、變更和例外狀況的機制](ops_ops_model_req_add_chg_exception.md)
**相關文件：**
+ [如何培養一種持續改進並向 Andon 和呈報系統學習的文化？](https://www.linkedin.com/advice/0/how-do-you-foster-culture-continuous-improvement-7054190310033145857)
+ [Andon Cord (IT 革命)](https://itrevolution.com/articles/kata/)
+ [AWS DevOps 指引 \$1 建立明確的呈報路徑，並鼓勵建設性的分歧](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/oa.bcl.5-establish-clear-escalation-paths-and-encourage-constructive-disagreement.html)
**相關影片：**
+ [Jeff Bezos 如何制定決策 (並提高速度)](https://www.youtube.com/watch?v=VFwCGECvq4I)
+ [Toyota 產品系統：停止生產，一個按鈕以及一個 Andon 電氣板](https://youtu.be/TUKpxjAftnk?si=qohtCCX0q78GDzJu)
+ [LEAN製造業的 Andon Cord](https://youtu.be/HshopyQk720?si=1XJkpCSqJSpk_zE6)
**相關範例：**
+ [在 Incident Manager 中使用呈報計畫](https://docs.aws.amazon.com/incident-manager/latest/userguide/escalation.html)
# OPS03-BP04 溝通需及時、清楚且可行
領導層負責建立強大而有效的溝通，尤其是當組織採用新策略、技術或工作方式時。領導者應該為所有員工設定期望，以實現公司目標。設計溝通機制，在負責運行由領導資助和贊助計劃的團隊之間可建立和保持意識。利用跨組織的多樣性，並用心聆聽多個獨特觀點。使用此觀點來增加創新、挑戰假設，並降低確認偏差的風險。在團隊中培養包容性、多樣性和可及性，以獲得有益的觀點。
**預期成果：**您的組織設計溝通策略以解決變更對組織的影響。團隊保持知情並積極繼續彼此合作，而不是彼此對抗。個人了解他們的角色對於實現既定目標是多麼重要。電子郵件只是一種被動的溝通機制，並相應地使用。管理層花時間與他們的個人貢獻者溝通，以幫助他們了解其責任、要完成的任務，以及他們的工作如何為整體使命做出貢獻。必要時，領導者直接在較小的場所與人們互動，以傳達訊息並確認這些訊息是否有效地傳遞。由於良好的溝通策略，組織的表現達到或超出領導層的期望。領導層鼓勵和尋求團隊內部和團隊之間的不同意見。
**常見的反模式：**
+ 您的組織有五年計劃，可將所有工作負載遷移至 AWS。雲端的業務案例包括所有工作負載的 25% 進行現代化，以充分利用無伺服器技術。CIO 將此策略傳達給直接下屬，並期望每位領導者將此演示文稿提交給經理、董事和個人貢獻者，而無須進行任何面對面溝通。CIO 退後一步，並期望其組織執行新的策略。
+ 領導層不提供或使用回饋機制，並且預期差距不斷增長，導致專案停滯。
+ 系統會要求您對安全群組進行變更，但不會為您提供任何詳細資訊，說明需要進行哪些變更、變更可能對所有工作負載造成什麼影響，以及何時發生變更。經理會轉發來自資訊安全網副總裁的電子郵件，並新增訊息「去實現 (Make this happen)」。
+ 對您的遷移策略進行了變更，將規劃的現代化數量從 25% 降低到 10%。這對營運組織具有下游影響。他們沒有被告知這一策略變化，因此，他們還沒有準備好足夠的技術能力來支援更多的工作負載平移到 AWS 中。
**建立此最佳實務的優勢：**
+ 您的組織充分了解新的或變更的策略，他們會以強烈的動力採取相應的行動，以幫助彼此實現領導層設定的總體目標和指標。
+ 存在的機制可用來及時通知團隊成員已知的風險和計劃的事件。
+ 組織會更有效地採用新的工作方式 (包括對人員或組織、程序或技術的變更) 以及所需技能，而且您的組織可更快速地實現企業利益。
+ 團隊成員了解溝通事項，他們可以更有效地完成工作。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
若要實作此最佳實務，您必須與組織中的利益相關者合作，以同意溝通標準。在組織內將這些標準公告週知。對於任何重大的 IT 轉型，與忽略此實務的組織相比，已確立的規劃團隊可以更成功地管理變更對其人員的影響。大型組織在管理變更時更具挑戰性，因為與所有個別貢獻者一起建立對新策略的強有力支援至關重要。如果沒有此類轉型規劃團隊，領導層 100% 負責有效溝通。建立轉型規劃團隊時，指派團隊成員與所有組織領導層合作，以定義和管理各個層面的有效溝通。
**客戶範例**
AnyCompany Retail 已註冊 AWS Enterprise Support，並依賴其他第三方提供商進行其雲端運營。該公司透過聊天和 chatops 作為其運營活動的主要溝通媒介。特定管道會填入提醒和其他資訊。人們必須展開行動時，他們會明確說明預期成果，且在許多情況下他們會接收執行手冊或程序手冊以供使用。他們可使用變更行事曆來排程生產系統的重大變更。
### 實作步驟
1. 在組織內建立一個核心團隊，負責為組織內多個層面發生的變更制定和啟動溝通計畫。
1. 建立單線程擁有權以實現監督。賦予各個團隊獨立創新的能力，並平衡使用一致的機制，從而實現適當的檢查水平和方向性願景。
1. 與組織中的利益相關者合作，以同意溝通標準、實務和計劃。
1. 確認核心溝通團隊是否與組織和計劃領導層協作，代表領導者為適當的員工製作訊息。
1. 建立策略性溝通機制，透過公告、共用行事曆、全體會議，以及面對面或一對一的方法來管理變更，讓團隊成員對應採取的行動有適當的期望。
1. 提供必要的背景知識、詳細資訊和時間 (如果可能的話)，以確定是否需要採取行動。當需要採取行動時，請提供所需的動作及其影響。
1. 實作可促進戰術溝通的工具，例如內部聊天、電子郵件和知識管理。
1. 實施機制以衡量和驗證所有溝通是否都能達到預期成果。
1. 建立一種回饋循環，用以衡量所有溝通的有效性，尤其是與整個組織中抗拒改變的力量相關的溝通。
1. 對於所有 AWS 帳戶，建立帳單、安全性和操作的[替代聯絡人](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-alternate.html)。理想情況下，每個聯絡人應該是電子郵件分發，而不是特定的個人聯絡人。
1. 建立呈報和逆向呈報溝通計畫，以與您的內部和外部團隊 (包括 AWS Support 和其他第三方供應商) 互動。
1. 在每個轉型計劃的生命週期中始終如一地啟動和執行溝通策略。
1. 排定可重複動作的優先順序，以便大規模安全地自動化。
1. 在具有自動化動作的情況下進行通訊時，通訊目的應該是通知團隊、進行稽核或作為變更管理流程的一部分。
1. 分析來自提醒系統的通訊，找出不斷建立的誤報或提醒。移除或變更這些提醒，使其僅在需要人為介入時啟動。如果啟動了提醒，請提供執行手冊或程序手冊。
1. 您可以使用 [AWS Systems Manager 文件](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html)，為提醒建立程序手冊和執行手冊。
1. 已設立機制，以清楚且可行的方式提供風險或計劃事件的通知，並提供足夠的通知，以便適當的回應。使用電子郵件清單或聊天管道，在計劃性事件發之前傳送通知。
1. [AWS Chatbot](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html) 可用於在組織訊息傳遞平台中傳送提醒並回應事件。
1. 提供可存取的資訊來源，您可以在其中發現計劃的事件。提供來自相同系統之計劃事件的通知。
1. [AWS Systems Manager 變更行事曆](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html)可用於在發生變更時建立變更時段。這可為團隊成員提供有關於何時可安全進行變更的通知。
1. 監控漏洞通知和修補程式資訊，了解外部漏洞以及與工作負載元件相關的潛在風險。提供通知給團隊成員，以便讓他們可以採取動作。
1. 您可以訂閱 [AWS 安全公告](https://aws.amazon.com/security/security-bulletins/)，以接收 AWS 上的漏洞通知。
1. **尋求不同的意見和觀點：**鼓勵每個人的貢獻。為代表人數不夠的群體提供溝通機會。在會議中輪換角色和職責。
1. **詳細闡述角色和職責：**為團隊成員提供機會，讓他們承擔他們可能不會承擔的角色。他們會透過角色，以及與他們可能不會與之互動的新團隊成員互動，而獲得經驗和觀點。他們還將自己的經驗和觀點帶到新的角色，並帶給和他們互動的團隊成員。隨著觀點增加，確定新興的業務機會或者新的改進機會。在團隊成員之間輪流處理其他人通常執行的常見任務，以了解執行這些任務的需求和影響。
1. **提供安全且友善的環境：**制定政策和控制措施，以保護組織內團隊成員的心理和身體安全。團隊成員應該能夠在不擔心報復行為的情況下進行互動。當團隊成員感到安全且受歡迎時，他們才更有可能參與進來並具備生產力。您的組織越多樣化，您就越能了解所支援的人員，包括您的客戶。當您的團隊成員感到安心、可以自在的暢所欲言，而且有信心他們的聲音不會被淹沒，他們才更有可能分享寶貴的洞見 (例如，行銷機會、可及性的需求、尚未提供服務的市場區隔，以及環境中未確認的風險)。
1. **鼓勵團隊成員充分參與：**提供員工充分參與所有與工作相關的活動所需的資源。面對日常挑戰的團隊成員會發展出解決挑戰的技能。這些以獨特方式發展的技能可為組織提供顯著的效益。為團隊成員提供必要的便利性支援，將可從他們的貢獻中獲得更高的效益。
## 資源
**相關的最佳實務：**
+ [OPS03-BP01 提供高層支持](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_executive_sponsor.html)
+ [OPS07-BP03 使用執行手冊執行程序](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html)
+ [OPS07-BP04 使用程序手冊調查問題](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html)
**相關文件：**
+ [AWS 部落格文章 \$1 問責制和授權是高效能敏捷組織的關鍵](https://aws.amazon.com/blogs/enterprise-strategy/two-pizza-teams-are-just-the-start-accountability-and-empowerment-are-key-to-high-performing-agile-organizations-part-2/)
+ [AWS Executive Insights \$1 學習擴展創新，而不是複雜性 \$1 單線程領導者](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/#Single-Threaded_Leaders)
+ [AWS 安全公告](https://aws.amazon.com/security/security-bulletins)
+ [開放式 CVE](https://www.opencve.io/welcome)
+ [Slack 中用於管理支援案例的 支援 應用程式](https://aws.amazon.com/blogs/aws/new-aws-support-app-in-slack-to-manage-support-cases/)
+ [使用聊天應用程式中的 Amazon Q Developer 來管理 Slack 頻道中的 AWS 資源](https://aws.amazon.com/blogs/mt/manage-aws-resources-in-your-slack-channels-with-aws-chatbot/)
**相關服務：**
+ [聊天應用程式中的 Amazon Q Developer](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html)
+ [AWS Systems Manager 變更行事曆](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html)
+ [AWS Systems Manager 文件](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html)
# OPS03-BP05 鼓勵進行試驗
試驗是將新構想轉化為產品和功能的觸媒。試驗可加速學習，讓團隊成員保持興趣和參與度。我們鼓勵團隊成員經常進行試驗以推動創新。即便結果不如預期仍有其價值，至少我們了解到什麼是不該做的。團隊成員不會因取得不理想結果的成功試驗而受懲罰。
**預期成果：**
+ 您的組織鼓勵試驗以促進創新。
+ 試驗被視為一種學習機會。
**常見的反模式：**
+ 您想要執行 A/B 測試，但沒有相關機制可執行試驗。您在沒有測試能力的情況下部署了 UI 變更。其結果導致了負面客戶體驗。
+ 您的公司只有模擬和生產環境。沒有沙盒環境可用來試驗新功能或產品，因此您必須在生產環境內試驗。
**建立此最佳實務的優勢：**
+ 試驗可帶動創新。
+ 透過試驗，您可以更快回應使用者的意見反映。
+ 組織可培養學習文化。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
試驗應以安全的方式執行。利用多種環境進行試驗，而不會損害生產資源。使用 A/B 測試和功能旗標來測試試驗。為團隊成員提供在沙盒環境中執行試驗的能力。
**客戶範例**
AnyCompany Retail 鼓勵試驗。團隊成員可將其 20% 的工時投入於試驗或學習新技術。他們有沙盒環境可供創新之用。他們可對新功能進行 A/B 測試，用實際使用者的意見反映加以驗證。
**實作步驟**
1. 與組織中的領導階層共同推行試驗風氣。應鼓勵團隊成員以安全的方式執行試驗。
1. 為團隊成員提供可安全進行試驗的環境。他們必須能夠存取類似生產環境的環境。
1. 可以使用單獨的 AWS 帳戶 來建立用於實驗的沙盒環境。[AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 可用於佈建這些帳戶。
1. 使用功能旗標和 A/B 測試安全地進行試驗，並收集使用者的意見反映。
1. [AWS AppConfig Feature Flags](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) 能夠建立功能旗標。
1. 可以使用 [AWS Lambda 版本](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html)部署新版本的函數以進行 beta 測試。
**實作計劃的工作量：**高。為團隊成員提供可安全執行試驗的環境，可能需要可觀的投資。為了使用功能旗標或支援 A/B 測試，您也可能需要修改應用程式程式碼。
## 資源
**相關的最佳實務：**
+ [OPS11-BP02 執行事後分析](ops_evolve_ops_perform_rca_process.md) - 從事件中學習是創新以及實驗的重要驅動力。
+ [OPS11-BP03 實作意見回饋循環](ops_evolve_ops_feedback_loops.md) - 回饋迴圈是實驗的重要組成部分。
**相關文件：**
+ [Amazon 文化內貌：實驗、失敗和客戶至上](https://aws.amazon.com/blogs/industries/an-inside-look-at-the-amazon-culture-experimentation-failure-and-customer-obsession/)
+ [在 AWS 中建立和管理沙盒帳戶的最佳實務](https://aws.amazon.com/blogs/mt/best-practices-creating-managing-sandbox-accounts-aws/)
+ [建立由雲端啟用的實驗文化](https://aws.amazon.com/blogs/enterprise-strategy/create-a-culture-of-experimentation-enabled-by-the-cloud/)
+ [在 SulAmérica Seguros 實現雲端實驗和創新](https://aws.amazon.com/blogs/mt/enabling-experimentation-and-innovation-in-the-cloud-at-sulamerica-seguros/)
+ [實驗越多，失敗越少](https://aws.amazon.com/blogs/enterprise-strategy/experiment-more-fail-less/)
+ [使用多個帳戶來組織您的 AWS 環境 - 沙盒 OU](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/sandbox-ou.html)
+ [使用 AWS AppConfig 功能旗標](https://aws.amazon.com/blogs/mt/using-aws-appconfig-feature-flags/)
**相關影片：**
+ [AWS On Air ft. Amazon CloudWatch Evidently \$1 AWS 活動](https://www.youtube.com/watch?v=ydX7lRNKAOo)
+ [AWS On Air San Fran Summit 2022 ft. AWS AppConfig 功能旗標與 Jira 整合](https://www.youtube.com/watch?v=miAkZPtjqHg)
+ [AWS re:Invent 2022 - 部署不是發行版本：透過功能旗標控制您的啟動 (BOA305-R)](https://www.youtube.com/watch?v=uouw9QxVrE8)
+ [使用 AWS Control Tower 以程式設計方式建立 AWS 帳戶](https://www.youtube.com/watch?v=LxxQTPdSFgw)
+ [設定使用 AWS Organizations 最佳實務的多帳戶 AWS 環境](https://www.youtube.com/watch?v=uOrq8ZUuaAQ)
**相關範例：**
+ [AWS 創新沙盒](https://aws.amazon.com/solutions/implementations/aws-innovation-sandbox/)
+ [電子商務端對端個人化 101](https://catalog.workshops.aws/personalize-101-ecommerce/en-US/labs/ab-testing)
**相關服務：**
+ [Amazon CloudWatch Evidently](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Evidently.html)
+ [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html)
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
# OPS03-BP06 管理團隊成員維持和發展自己的技能集
團隊必須發展自己的技能集，以採用新技術，並支援需求和責任的變更，以支援您的工作負載。新技術的技能成長通常是團隊成員滿意度的來源，並可支援創新。支援團隊成員追求和維持產業認證，以驗證和認可他們不斷成長的技能。交叉培訓以促進知識轉移，並在失去熟練的、經驗豐富且具備機構知識的成員時，降低重大影響的風險。提供學習專用的結構化時間。
AWS 可提供資源，包括 [AWS 入門資源中心](https://aws.amazon.com/getting-started/)、[AWS 部落格](https://aws.amazon.com/blogs/)、[AWS 線上技術講座](https://aws.amazon.com/getting-started/)、[AWS 活動和網路研討會](https://aws.amazon.com/events/)以及 [AWS Well-Architected 實驗室](https://wellarchitectedlabs.com/)，提供指引、範例和詳細的逐步解說來教育您的團隊。
諸如 [支援](https://aws.amazon.com/premiumsupport/programs/) ([AWS re:Post](https://repost.aws/)、[支援 Center](https://console.aws.amazon.com/support/home/)) 等資源和 [AWS 文件](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)有助於消除技術障礙並改善操作。透過 支援 中心聯絡 支援，以獲取相關問題的幫助。
AWS 還分享了我們透過在 [Amazon 建置者資料中心](https://aws.amazon.com/builders-library/)操作 AWS 所學到的最佳實務和模式，以及透過 [AWS 部落格](https://aws.amazon.com/blogs/)和[官方 AWS 部落格](https://aws.amazon.com/podcasts/aws-podcast/)提供的各種其他有用的教育材料。
[AWS 培訓 和認證](https://aws.amazon.com/training/)透過自定進度的數位課程提供免費培訓，以及按角色或領域制定的學習計劃。您還可以報名參加講師指導下的培訓，以進一步協助開發團隊的 AWS 技能。
**預期成果：**您的組織不斷評估技能差距，並透過結構化預算和投資進行彌補。團隊透過提高技能的活動來鼓勵和激勵其會員，例如獲得領先的行業認證。團隊利用專門的交叉分享知識計劃，例如午餐學習會、Immersion Day、黑客松和演練日。您的組織將其知識系統保持在最新狀態，並與交叉培訓團隊成員相關，包括新員工入職培訓。
**常見的反模式：**
+ 在沒有結構化培訓計劃和預算的情況下，團隊會遇到不確定性，因為他們試圖跟上技術發展的步伐，從而增加損耗。
+ 作為遷移到 AWS 的一部分，您的組織展現了團隊間的技能差距和不同的雲端流暢度。如果不努力提高技能，團隊會發現自己被雲端環境的傳統和效率低下的管理所累，這會導致操作員的工作量增加。這種倦怠會加劇員工的不滿。
**建立此最佳實務的優勢：**當您的組織有意識地投資於改善其團隊的技能時，它也有助於加速和擴展雲端採用和最佳化。針對性的學習計劃可推動創新並建立營運能力，讓團隊為處理各種事件做好準備。團隊有意識地投資於最佳實務的實作和發展。團隊士氣高漲，團隊成員重視自己對業務的貢獻。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
為了採用新技術、推動創新、並跟上需求和責任變化的步伐來支援您的工作負載，請不斷投資於團隊的專業成長。
### 實作步驟
1. **使用結構化雲端宣傳計劃**：[AWS Skills Guild](https://aws.amazon.com/training/teams/aws-skills-guild/) 提供諮詢培訓，以提高雲端技能信心並培養持續學習的文化。
1. **提供教育資源：**提供專門的結構化時間，以及取用培訓教材和實驗室資源的權限，並支援參與會議和專業組織，從中為教育工作者和同儕提供學習機會。為資淺團隊成員提供接近資深團隊成員的機會，讓資深團隊成員成為導師，或允許資淺團隊成員參觀資深團隊成員的工作，並接觸他們的方法和技能。鼓勵學習與工作不直接相關的內容，以便取得更廣泛的視野。
1. **鼓勵使用專家技術資源：**利用諸如 [AWS re:Post](https://repost.aws/) 之類的資源來存取精選知識和充滿活力的社群。
1. **建置並維護最新的知識儲存庫：**使用知識共享平台，例如 Wiki 和執行手冊。使用 [AWS re:Post Private](https://aws.amazon.com/repost-private/) 建立您自己的可重複使用的專家知識來源，以簡化協同合作、提高生產力並加速員工入職。
1. **團隊教育和跨團隊參與：**規劃團隊成員的持續教育需求。為團隊成員提供機會 (暫時或永久地) 加入其他團隊，以分享讓整個組織受益的技能和最佳實務。
1. **支援追求和維持產業認證：**支援團隊成員取得與維持可驗證所學知識並認可其成就的產業認證。
**實作計劃的工作量：**高
## 資源
**相關的最佳實務：**
+ [OPS03-BP01 提供高層支持](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_executive_sponsor.html)
+ [OPS11-BP04 執行知識管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**相關文件：**
+ [AWS 白皮書 \$1 雲端採用架構：個人視角](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-people-perspective/aws-caf-people-perspective.html)
+ [投資持續學習以發展組織的未來](https://aws.amazon.com/blogs/publicsector/investing-continuous-learning-grow-organizations-future/)
+ [AWS Skills Guild](https://aws.amazon.com/training/teams/aws-skills-guild/)
+ [AWS 培訓 和認證](https://aws.amazon.com/training/)
+ [支援](https://aws.amazon.com/premiumsupport/programs/)
+ [AWS re:Post](https://repost.aws/)
+ [AWS 資源中心入門](https://aws.amazon.com/getting-started/)
+ [AWS 部落格](https://aws.amazon.com/blogs/)
+ [AWS 雲端 合規](https://aws.amazon.com/compliance/)
+ [AWS 文件](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [官方 AWS 播客](https://aws.amazon.com/podcasts/aws-podcast/)。
+ [AWS 線上技術講座](https://aws.amazon.com/getting-started/)
+ [AWS 活動和研討會](https://aws.amazon.com/events/)
+ [AWS Well-Architected 實驗室](https://wellarchitectedlabs.com/)
+ [Amazon 建置者資料中心](https://aws.amazon.com/builders-library/)
**相關影片：**
+ [AWS re:Invent 2023 \$1 以雲端的速度重塑技能：將員工變為企業家](https://www.youtube.com/watch?v=Ax7JqIDIXEY)
+ [WS re:Invent 2023 \$1 透過遊戲化建立好奇心文化](https://www.youtube.com/watch?v=EqWvSBAmD3w)
# OPS03-BP07 資源團隊適當
提供適量訓練有素的團隊成員，並提供工具和資源來支援工作負載需求。負擔過重的團隊成員會增加人為錯誤的風險。對工具和資源的投資 (例如自動化) 可以提升團隊的效率，並協助他們支援更多工作負載，而不需要額外的生產能力。
**預期成果：**
+ 您已適當地配置團隊，以取得他們 AWS 根據您的遷移計劃操作工作負載所需的技能。由於您的團隊在遷移專案期間自我擴展，因此他們已精通業務計劃在遷移或現代化其應用程式時使用的核心 AWS 技術。
+ 您已經仔細調整人員配置計畫，以利用自動化和工作流程來有效利用資源。較小的團隊現在可以代表應用程式開發團隊管理更多基礎設施。
+ 隨著營運優先順序的轉變，會主動識別任何資源人員配置限制，以保護業務計畫的成功。
+ 審核報告操作辛勞的操作指標 (例如待命疲勞或過度呼叫)，以驗證員工是否不堪重負。
**常見的反模式：**
+ 當您接近多年雲端遷移計畫時，您的員工尚未提高 AWS 技能，這些風險支援工作負載並降低員工士氣。
+ 您的整個 IT 組織正在轉向敏捷的工作方式。企業正優先考慮產品組合，並為需要首先開發的功能設定指標。敏捷流程不需要團隊將故事點分配給他們的工作計畫。因此，不可能了解下一工作量所需的能力水平，或者您是否擁有分配給該工作的正確技能。
+ 您讓 AWS 合作夥伴遷移工作負載，而且一旦合作夥伴完成遷移專案，您就沒有團隊的支援轉換計畫。您的團隊難以高效地支援工作負載。
**建立此最佳實務的優勢：**您的組織中有適當技能的團隊成員來支援工作負載。資源配置可適應不斷變化的優先順序，而不會影響效能。結果是團隊精通工作負載的支援，同時最大限度地利用時間專注於為客戶創新，從而提高員工滿意度。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
雲端遷移的資源規劃應該在組織層級進行，它符合遷移計畫以及為支援新雲端環境而實作的所需操作模型。這應該包括了解為業務和應用程式開發團隊部署哪些雲端技術。基礎設施和營運領導者應該為領導雲端採用的工程師規劃技能差距分析、培訓和角色定義。
### 實作步驟
1. 使用諸如員工生產力等相關營運指標 (例如，支援工作負載的成本或事件期間所花費的操作員時數)，定義團隊成功的標準。
1. 定義資源容量計畫與檢驗機制，以驗證合格容量的適當平衡在需要時可用，並且可隨時間進行調整。
1. 建立機制 (例如，向團隊傳送每月調查問卷)，以了解影響團隊的工作相關挑戰 (例如責任增加、技術變化、人員損失或支援的客戶增加)。
1. 使用這些機制與團隊互動，並發現可能導致員工生產力挑戰的趨勢。當您的團隊受到外部因素影響時，請重新評估目標並適當地調整目標。找出阻礙您團隊進度的障礙。
1. 定期檢閱目前佈建的資源是否仍然足夠，或是否需要額外資源，並做出適當的調整以支援團隊。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS我們鼓勵 03-BP06 團隊成員維護和提升其技能組合](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_enc_learn.html)
+ [OPS09-BP03 檢閱操作指標並排定改善優先順序](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_review_ops_metrics_prioritize_improvement.html)
+ [OPS10-BP01 使用事件、事件和問題管理的程序](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
+ [OPS10-BP07 自動化對事件的回應](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_auto_event_response.html)
**相關文件：**
+ [AWS 雲端 採用架構：人員觀點](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-people-perspective/aws-caf-people-perspective.html)
+ [成為面向未來的企業](https://aws.amazon.com/blogs/enterprise-strategy/becoming-a-future-ready-enterprise/)
+ [優先考慮員工的技能以推動業務增長](https://aws.amazon.com/executive-insights/content/prioritize-your-employees-skills-to-drive-business-growth/)
+ [高效能組織 - Amazon 雙披薩團隊](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/)
+ [雲端成熟企業如何成功](https://aws.amazon.com/blogs/mt/how-cloud-mature-enterprises-succeed/)