

# 組織
<a name="a-organization"></a>

**Topics**
+ [OPS 1  如何決定您的優先事項？](w2aac19b5b5b5.md)
+ [OPS 2  如何建構組織以支援業務成果？](w2aac19b5b5b7.md)
+ [OPS 3  您的組織文化如何支援您的業務成果？](w2aac19b5b5b9.md)

# OPS 1  如何決定您的優先事項？
<a name="w2aac19b5b5b5"></a>

 每個人都必須了解自己在實現商業價值過程中的角色。擁有共同目標以設定資源優先順序。這會充分發揮您所做努力的優勢。 

**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-BP07 管理收益和風險](ops_priorities_manage_risk_benefit.md)

# OPS01-BP01 評估外部客戶需求
<a name="ops_priorities_ext_cust_needs"></a>

 讓關鍵利害關係人 (包括業務、開發和營運團隊) 參與進來，以確定將工作重點放在哪些外部客戶需求上。這將確保您對實現想要的業務成果所需的營運支援有透徹的了解。 

 **常用的反模式：** 
+  您已決定不在核心上班時間以外的時間提供客戶支援，但尚未檢閱歷史支援請求資料。您不知道這是否會影響您的客戶。 
+  您正在開發新功能，但尚未與客戶互動，以了解是否需要該功能，若需要又應以何種形式提供，而且未進行試驗以驗證交付的需求和方法。 

 **建立此最佳實務的優勢：** 需求獲得滿足的客戶更有可能持續回購。評估和了解外部客戶的需求，將讓您了解如何安排工作的優先順序來實現商業價值。 

 **若未建立此最佳實務，暴露的風險等級為：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  了解業務需求：只有業務、開發及營運團隊等利害關係人擁有共同的目標並達成共識，方能讓業務取得成功。 
  +  審查外部客戶的業務目標、需求和優先事項：與關鍵利害關係人 (包括業務、開發和營運團隊) 進行互動，以討論外部客戶的目標、需求和優先事項。這將確保您對實現業務和客戶成果所需的營運支援有透徹的了解。 
  +  建立共識：在以下方面建立共識：工作負載的業務功能、每個團隊在工作負載營運過程中的角色，以及這些因素如何支援內外部客戶的共同業務目標。 

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [AWS Well-Architected Framework 概念 – 反饋迴圈](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.feedback-loop.en.html) 

# OPS01-BP02 評估內部客戶需求
<a name="ops_priorities_int_cust_needs"></a>

 讓關鍵利害關係人 (包括業務、開發和營運團隊) 參與進來，以確定將工作重點放在哪些內部客戶需求上。這將確保您對實現業務成果所需的營運支援有透徹的了解。 

 利用您制定的優先事項，聚焦於改善作業，因為它們能發揮最大的影響力 (例如，發展團隊技能、改善工作負載效能、降低成本、自動化執行手冊或提升監控力)。根據需求變更更新您的優先順序。 

 **常用的反模式：** 
+  您已決定在不向產品團隊諮詢的情況下，變更他們的 IP 地址配置，以便更輕鬆地管理網路。您不知道這會對您的產品團隊造成什麼影響。 
+  您正在實作新的開發工具，但尚未與內部客戶互動，以了解是否需要該工具或其是否與現有的實務相容。 
+  您正在實作新的監控系統，但尚未聯絡內部客戶，以了解他們是否有應該考慮的監控或報告需求。 

 **建立此最佳實務的優勢：** 評估和了解內部客戶的需求，將讓您了解如何安排工作的優先順序來實現商業價值。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  了解業務需求：只有業務、開發及營運團隊等利害關係人擁有共同的目標並達成共識，方能讓業務取得成功。 
  +  審查內部客戶的業務目標、需求和優先事項：與關鍵利害關係人 (包括業務、開發和營運團隊) 進行互動，以討論內部客戶的目標、需求和優先事項。這將確保您對實現業務和客戶成果所需的營運支援有透徹的了解。 
  +  建立共識：在以下方面建立共識：工作負載的業務功能、每個團隊在工作負載營運過程中的角色，以及這些因素如何支援內外部客戶的共同業務目標。 

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [AWS Well-Architected Framework 概念 – 反饋迴圈](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.feedback-loop.en.html) 

# OPS01-BP03 評估管控要求
<a name="ops_priorities_governance_reqs"></a>

 確保您了解由貴組織所定義的、可能要求或強調特定重點的準則或義務。評估內部因素，例如組織政策、標準和要求。確認您設有確定管控變更的機制。如果未確定管控要求，請確保您已對此決定進行盡職調查。 

 **常用的反模式：** 
+  您正在接受稽核，並經要求需提供內部管控的合規證明。您從未評估合規要求，因此您不知道自己是否合規。 
+  您已遭受導致經濟損失的洩露。您發現，可能涵蓋經濟損失的保險取決於您是否實作了特定安全控制措施，而您的管控要求實作這些控制措施，但其尚未落實到位。 
+  您的管理帳戶遭到入侵，導致公司網站遭到破壞，並使得客戶信任受損。您的內部管控要求使用多重因素驗證 (MFA) 來保護管理帳戶的安全。您未使用 MFA 保護管理帳戶的安全，可能受到處罰。 

 **建立此最佳實務的優勢：** 評估和了解組織套用到工作負載的管控要求，將可讓您了解如何安排工作的優先順序來實現商業價值。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  了解管控要求：評估內部管控因素，例如，計畫或組織政策、計畫政策、問題或系統特定政策、標準、程序、基準和準則。確認您設有確定管控變更的機制。如果未確定管控要求，請確保您已對此決定進行盡職調查。 

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [AWS 雲端 合規](https://aws.amazon.com/compliance/) 

# OPS01-BP04 評估合規要求
<a name="ops_priorities_compliance_reqs"></a>

 評估外部因素，例如合規要求和產業標準，以確保您了解可能要求或強調特定重點的準則或義務。如果未確定合規要求，請確保對此決定進行盡職調查。 

 **常用的反模式：** 
+  您正在接受稽核，並經要求需提供產業規範的合規證明。您從未評估合規要求，因此您不知道自己是否合規。 
+  您的管理帳戶遭到入侵，導致客戶資料遭到下載，並使客戶信任受損。您的產業最佳實務要求使用 MFA 來保護管理帳戶的安全。您未使用 MFA 保護管理帳戶的安全，可能受到客戶訴訟。 

 **建立此最佳實務的優勢：** 評估和了解套用到工作負載的合規要求，可讓您了解如何安排工作的優先順序來實現商業價值。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  了解合規要求：評估外部因素，例如合規要求和產業標準，以確保您了解可能要求或強調特定重點的準則或義務。如果未確定合規要求，請確保已對此決定進行盡職調查。 
  +  了解法規合規要求：確定您在法律上有義務滿足的法規合規要求。根據這些要求來找到工作重點。範例包括隱私權和資料保護法規定的義務。 
    +  [AWS 合規](https://aws.amazon.com/compliance/) 
    +  [AWS 合規計劃](https://aws.amazon.com/compliance/programs/) 
    +  [AWS 合規最新資訊](https://aws.amazon.com/compliance/compliance-latest-news/) 
  +  了解產業標準和最佳實務：識別適用於工作負載的產業標準和最佳實務要求，例如，支付卡產業資料安全標準 (PCI DSS)。根據這些要求來找到工作重點。 
    +  [AWS 合規計劃](https://aws.amazon.com/compliance/programs/) 
  +  了解內部合規要求：確定您的組織建立的合規要求和最佳實務。根據這些要求來找到工作重點。範例包括資訊安全政策和資料分類標準。 

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [AWS 雲端 合規](https://aws.amazon.com/compliance/) 
+  [AWS 合規](https://aws.amazon.com/compliance/) 
+  [AWS 合規最新資訊](https://aws.amazon.com/compliance/compliance-latest-news/) 
+  [AWS 合規計劃](https://aws.amazon.com/compliance/programs/) 

# OPS01-BP05 評估威脅態勢
<a name="ops_priorities_eval_threat_landscape"></a>

 評估對業務的威脅 (例如，競爭、業務風險和負債、營運風險和資訊安全威脅)，並將最新的資訊保存在風險登記表內。決定工作重點的領域時，加入風險影響。 

 AWS Well-Architected 架構 [強調](https://aws.amazon.com/architecture/well-architected/) 學習、衡量和改善。它為您提供可評估架構並實作將隨時間擴展之設計的一致方法。AWS 提供 [AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/) ，以協助您在部署前檢閱方法、在生產前檢閱工作負載狀態，以及檢閱生產中的工作負載狀態。您可以將它們與最新的 AWS 架構最佳實務做比較、監控工作負載的整體狀態，以及深入了解潛在風險。 

 AWS 客戶還有資格獲得對其關鍵任務工作負載的指導式 Well-Architected 審查， [進而依循 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/) 可存取針對安全性、可靠性、效能和成本優化的其他檢查，從而進一步協助確定他們的優先事項。 

 **常用的反模式：** 
+  您在產品中使用舊版的軟體程式庫。您不知道，程式庫的安全性更新是否存在可能對工作負載產生意外影響的問題。 
+  您的競爭對手剛發佈的產品版本，可解決客戶對您產品的許多抱怨。您尚未排定處理這些已知問題之事項的優先順序。 
+  監管機構一直在追尋像您這樣不符合法律法規合規要求的公司。您尚未排定處理任何未解決合規要求之事項的優先順序。 

 **建立此最佳實務的優勢：** 識別和了解組織和工作負載所面臨的威脅，讓您可以判斷要解決哪些威脅、它們的優先順序，以及執行此作業所需的資源。 

 **若未建立此最佳實務，暴露的風險等級為：** 中 

## 實作指引
<a name="implementation-guidance"></a>
+  評估威脅態勢：評估對業務的威脅 (例如，競爭、業務風險和負債、營運風險和資訊安全威脅)，以便您在決定工作重點時考量其影響。 
  +  [AWS 最新安全公告](https://aws.amazon.com/security/security-bulletins/) 
  +  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
  +  維護威脅模型：建立和維護用於識別潛在威脅、已規劃和就地緩解措施及其優先順序的威脅模型。審查顯示為事件的威脅的機率、從這些事件中復原的成本、導致的預期傷害，以及防止這些事件的成本。當威脅模型的內容變更時，修改優先順序。 

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [AWS 雲端 合規](https://aws.amazon.com/compliance/) 
+  [AWS 最新安全公告](https://aws.amazon.com/security/security-bulletins/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 

# OPS01-BP06 評估權衡
<a name="ops_priorities_eval_tradeoffs"></a>

 評估在相互衝突的利益或替代方法之間做出權衡的影響，以幫助您在確定工作重點或選擇行動方案時做出明智的決定。例如，新功能加速上市可能是成本優化所強調的重點，或您可為非關聯式資料選擇關聯式資料庫，以便更輕鬆地遷移系統，而非遷移至針對您的資料類型優化的資料庫並更新您的應用程式。 

 AWS 可以協助您教育您的團隊有關 AWS 及其服務的知識，從而增進他們對自己的選擇會如何影響工作負載的了解。您應使用 [AWS 支援](https://aws.amazon.com/premiumsupport/programs/) ([AWS 知識中心](https://aws.amazon.com/premiumsupport/knowledge-center/)， [AWS 開發論壇](https://forums.aws.amazon.com/index.jspa)和 [AWS 支援中心](https://console.aws.amazon.com/support/home/)) 和 [AWS 文件](https://docs.aws.amazon.com/) 資源來教育您的團隊。透過 AWS 支援中心聯絡 AWS 支援，以獲取 AWS 相關問題的幫助。 

 AWS 也分享了我們透過 [在 Amazon Builders' Library 中](https://aws.amazon.com/builders-library/)營運 AWS 所學到的最佳實務和模式。您可透過 [AWS 部落格](https://aws.amazon.com/blogs/) 和 [官方 AWS 播客](https://aws.amazon.com/podcasts/aws-podcast/)。 

 **常用的反模式：** 
+  您使用關聯式資料庫來管理時間序列和非關聯式資料。有針對支援您使用的資料類型進行最佳化的資料庫選項，但您並不了解其優點，因為您尚未評估解決方案之間的權衡。 
+  您的投資者要求您證明支付卡產業資料安全標準 (PCI DSS) 的合規性。您沒有考量滿足要求和繼續您目前開發工作之間的權衡取捨。相反地，您繼續開發工作，而不證明合規性。由於對平台安全性及其投資的擔憂，您的投資者會停止對公司的支援。 

 **建立此最佳實務的優勢：** 了解您所選擇的影響和後果，讓您可以排定選項的優先順序。 

 **若未建立此最佳實務，暴露的風險等級：** 中 

## 實作指引
<a name="implementation-guidance"></a>
+  評估權衡：評估在相互衝突的利益之間做出權衡的影響，以幫助您在確定工作重點時做出明智的決定。例如，相比成本優化更強調新功能加速上市。 
+  AWS 可以協助您教育您的團隊有關 AWS 及其服務的知識，從而增進他們對自己的選擇會如何影響工作負載的了解。您應使用 AWS 支援 (AWS 知識中心、AWS 論壇和 AWS 支援 中心) 和 AWS 文件中的資源來教育您的團隊。透過 AWS 支援中心聯絡 AWS 支援，以獲取 AWS 相關問題的幫助。 
+  AWS 也分享了我們透過在 Amazon Builders' Library 中營運 AWS 所學到的最佳實務和模式。您可透過 AWS 部落格和官方 AWS 播客獲得其他各種實用資訊。 

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [AWS 部落格](https://aws.amazon.com/blogs/) 
+  [AWS 雲端 合規](https://aws.amazon.com/compliance/) 
+  [AWS 開發論壇](https://forums.aws.amazon.com/index.jspa) 
+  [AWS 文件](https://docs.aws.amazon.com/) 
+  [AWS 知識中心](https://aws.amazon.com/premiumsupport/knowledge-center/) 
+  [AWS 支援](https://aws.amazon.com/premiumsupport/) 
+  [AWS 支援中心](https://console.aws.amazon.com/support/home/) 
+  [在 Amazon Builders' Library 中](https://aws.amazon.com/builders-library/) 
+  [官方 AWS 播客](https://aws.amazon.com/podcasts/aws-podcast/) 

# OPS01-BP07 管理收益和風險
<a name="ops_priorities_manage_risk_benefit"></a>

 管理收益和風險，以便在確定工作重點時做出明智的決定。例如，部署具有未解決問題的工作負載可能有益，以便可以為客戶提供重要的新功能。相關風險可能得以減輕，也可能出現無法接受風險存在的事實，在此情況下，您將需要採取動作來解決風險。 

 您可能會發現，您在某個時間點會想要強調一小部分的優先事項。長期利用平衡的方法，以確保開發所需的功能和管理風險。根據需求變更更新您的優先順序 

 **常用的反模式：** 
+  您已決定包含一個程式庫，該程式庫會執行其中一個開發人員在網際網路上找到的您所需的任何項目。您尚未評估從未知來源採用此程式庫的風險，並且不知道它是否包含弱點或惡意程式碼。 
+  您已決定開發和部署新功能，而不是修正現有問題。在部署功能之前，您一直未評估將問題置之不理的風險，而且不知道會對客戶造成什麼影響。 
+  由於合規團隊的不明疑慮，您決定不部署客戶經常請求的功能。 

 **建立此最佳實務的優勢：** 識別您選擇的可用優勢，並了解組織面臨的風險，讓您可以做出明智的決策。 

 **若未建立此最佳實務，暴露的風險等級：** 低 

## 實作指引
<a name="implementation-guidance"></a>
+  管理收益和風險：在決策的收益與所涉及的風險之間取得平衡。 
  +  確定收益：根據業務目標、需求和優先事項確定收益。範例包括上市時間、安全性、可靠性、效能和成本。 
  +  確定風險：根據業務目標、需求和優先事項確定風險。範例包括上市時間、安全性、可靠性、效能和成本。 
  +  評估風險與收益並做出明智決定：根據關鍵利害關係人 (包括業務、開發和營運團隊) 的目標、需求和優先事項，確定收益和風險的影響。評價收益的價值時要考慮發生風險的可能性及其代價。例如，強調上市速度優先於可靠性，可能提供競爭優勢。不過，如果發生可靠性問題，則可能會縮短正常執行時間。 

# OPS 2  如何建構組織以支援業務成果？
<a name="w2aac19b5b5b7"></a>

 您的團隊必須了解其在達成業務成果中所扮演的角色。團隊需要了解自己在促成其他團隊成功的過程中所扮演的角色、其他團隊在促進其成功的過程中所扮演的角色，以及擁有共同目標。了解責任、擁有權、決策方式，以及誰有權制定決策，將有助於找到工作重點，並充分發揮團隊的優勢。 

**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_know_my_job.md)
+ [OPS02-BP05 存在機制用來識別責任和擁有權](ops_ops_model_find_owner.md)
+ [OPS02-BP06 存在用於請求新增、變更和例外狀況的機制](ops_ops_model_req_add_chg_exception.md)
+ [OPS02-BP07 團隊之間的責任為預先定義或經過協商](ops_ops_model_def_neg_team_agreements.md)

# OPS02-BP01 已為資源識別擁有者
<a name="ops_ops_model_def_resource_owners"></a>

 了解誰擁有各個應用程式、工作負載、平台和基礎設施元件、該元件提供什麼商業價值，以及該擁有權為何存在。透過了解這些個別元件的商業價值，以及其如何支援業務成果，可得知對元件套用的流程和程序。 

 **建立此最佳實務的優勢：** 透過了解擁有權，可識別誰可以核准改進項目和/或實作這些改進項目。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  已為資源識別擁有者：定義擁有權對環境中的資源使用案例的意義。指定並記錄資源的擁有者，至少包括名稱、聯絡資訊、組織和團隊。借助使用中繼資料 (例如標籤或資源群組) 的資源來儲存資源擁有權資訊。使用 AWS Organizations 建構帳戶並實作政策，以確保擷取擁有權和聯絡資訊。 
  +  定義擁有權形式及其指派方式：擁有權在您具有不同使用案例的組織中可能有多個定義。您可能希望將工作負載擁有者定義為承擔工作負載營運風險和責任的個人，以及最終有權對工作負載做出決策的個人。在將擁有權累計到父組織時，您可能希望根據財務或管理責任來定義擁有權。開發人員可能是其開發環境的擁有者，並負責其操作造成的事件。他們的產品主管可能自行負擔與開發環境營運相關的財務成本。 
  +  定義擁有組織、帳戶、資源集合或個別元件的人員：在可適當存取的位置中定義和記錄擁有權，該位置已經過組織，可支援探索。更新變更的定義和擁有權詳細資訊。 
  +  擷取資源中繼資料中的擁有權：使用標籤或資源群組等中繼資料擷取資源擁有權，並指定擁有權和聯絡資訊。使用 AWS Organizations 建構帳戶並確保擷取擁有權和聯絡資訊。 

# OPS02-BP02 已為流程和程序識別擁有者
<a name="ops_ops_model_def_proc_owners"></a>

 了解誰具有個別流程和程序的擁有權、為何使用特定流程和程序，以及為何該擁有權存在。了解使用特定流程和程序的原因，能夠幫助發現改進機會。 

 **建立此最佳實務的優勢：** 透過了解擁有權，可識別誰可以核准改進項目和/或實作這些改進項目。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  已為流程和程序識別負責其定義的擁有者：擷取環境中使用的流程和程序，以及負責其定義的個人或團隊。 
  +  識別流程和程序：識別為支援工作負載所執行的營運活動。將這些活動記錄在可探索的位置中。 
  +  定義擁有流程或程序定義的人員：唯一識別負責活動規格的個人或團隊。他們負責確保具備適當技能的團隊成員能夠成功執行該活動，且該團隊成員具備正確許可、存取權和工具。如果執行該活動時發生問題，執行該活動的團隊成員需負責提供改善活動所需的詳細回饋。 
  +  擷取活動成品中繼資料中的擁有權：在 AWS Systems Manager 等服務中，透過文件和做為函數的 AWS Lambda 自動化的程序，支援以標籤形式擷取中繼資料資訊。使用標籤或資源群組擷取資源擁有權，並指定擁有權和聯絡資訊。使用 AWS Organizations 建立標記政策，並確保擷取擁有權和聯絡資訊。 

# OPS02-BP03 已為營運活動識別負責其效能的擁有者
<a name="ops_ops_model_def_activity_owners"></a>

 了解誰負責在已定義的工作負載上執行特定活動，以及為什麼該責任存在。透過了解誰負責執行活動，可得知誰將會進行活動、驗證結果，以及提供回饋給活動擁有者。 

 **建立此最佳實務的優勢：** 透過了解誰負責執行活動，可得知在需要採取動作時通知誰，以及誰將會執行動作、驗證結果，以及提供回饋給活動擁有者。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  已為營運活動識別負責其效能的擁有者：擷取執行環境中所使用之流程和程序的責任 
  +  識別流程和程序：識別為支援工作負載所執行的營運活動。將這些活動記錄在可探索的位置中。 
  +  定義負責執行每個活動的人員：識別負責活動的團隊。確保他們擁有活動的詳細資訊，以及執行活動所需的技能和正確的許可、存取權和工具。他們必須了解活動執行條件 (例如，事件或排程)。讓此資訊可供探索，如此組織的成員便能夠識別他們針對特定需求需要聯絡的人員 (團隊或個人)。 

# OPS02-BP04 團隊成員知道他們負責的項目
<a name="ops_ops_model_know_my_job"></a>

 透過了解您角色的責任以及您為業務成果做出貢獻的方式，可得知任務的優先順序以及您的角色為何很重要。如此可讓團隊成員辨識需求並適當地回應。 

 **建立此最佳實務的優勢：** 透過了解您的責任，可得知您所做的決定、您採取的動作，以及如何將活動交給其適當的擁有者。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  確保團隊成員了解其角色和責任：識別團隊成員的角色和責任，並確保他們了解其角色的期望。讓此資訊可供探索，如此組織的成員便能夠識別他們針對特定需求需要聯絡的人員 (團隊或個人)。 

# OPS02-BP05 存在機制用來識別責任和擁有權
<a name="ops_ops_model_find_owner"></a>

 如果沒有識別個人或團隊，就會有定義的向某人向上呈報的路徑，該人員有權指派擁有權或為需解決的需求進行規劃。 

 **建立此最佳實務的優勢：** 透過了解有責任或擁有權的人員，讓您可以聯絡適當的團隊或團隊成員，以提出請求或轉換任務。擁有有權指派責任或擁有權或為解決需求進行規劃的已識別人員，可降低無作為和需求得不到解決的風險。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  存在機制用來識別責任和擁有權：為您的組織成員提供可存取的機制，以探索和識別擁有權和責任。這些機制讓他們可以針對特定需求識別要聯絡的人員 (團隊或個人)。 

# OPS02-BP06 存在用於請求新增、變更和例外狀況的機制
<a name="ops_ops_model_req_add_chg_exception"></a>

 您可以向流程、程序和資源的擁有者提出請求。評估收益和風險後，若可行並經判斷是合適的行為，則應制定明智的決策以核准請求。 

 **建立此最佳實務的優勢：** 機制存在的目的應為請求新增、變更和例外狀況，以支援團隊的活動。如果沒有此選項，目前狀態就會成為創新的限制。 

 **若未建立此最佳實務，暴露的風險等級：** 中 

## 實作指引
<a name="implementation-guidance"></a>
+  存在用於請求新增、變更和例外狀況的機制：當標準很嚴格時，創新會受到限制。為您的組織成員提供機制，讓他們可向流程、程序和資源的擁有者提出請求，以支援其業務需求。 

# OPS02-BP07 團隊之間的責任為預先定義或經過協商
<a name="ops_ops_model_def_neg_team_agreements"></a>

 團隊間已定義或協商說明如何相互配合及支援的協議 (例如，回應時間、服務等級目標或服務等級協議)。透過了解團隊工作對於業務成果和其他團隊及組織成果的影響，可得知其任務的優先順序，並讓他們能做出適當的回應。 

 如果責任和擁有權未定義或未知，則您會面臨風險，不僅無法及時處理必要的活動，在解決這些需求時還會出現冗餘和可能相互衝突的工作。 

 **建立此最佳實務的優勢：** 透過建立團隊、目標和溝通需求之方法之間的責任，可簡化請求的流程，並協助確保提供必要的資訊。此舉可減少團隊之間的轉換任務所造成的延遲，並協助支援達成業務成果。 

 **若未建立此最佳實務，暴露的風險等級：** 低 

## 實作指引
<a name="implementation-guidance"></a>
+  團隊之間的責任為預先定義或經過協商：指定團隊互動的方法以及彼此支援所需的資訊，有助於將請求反覆審查和釐清時產生的延遲降到最低。擁有定義期望的特定協議 (例如，回應時間或履行時間)，讓團隊可以適當地制定有效的計畫和資源。 

# OPS 3  您的組織文化如何支援您的業務成果？
<a name="w2aac19b5b5b9"></a>

 為您的團隊成員提供支援，讓他們能夠更有效地採取動作以及支援業務成果。 

**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-BP08 鼓勵並尋求來自團隊內部和跨團隊的多樣化建議](ops_org_culture_diverse_inc_access.md)

# OPS03-BP01 高層的支持
<a name="ops_org_culture_executive_sponsor"></a>

 資深領導階層清楚地設定對組織的期望並評估成功情況。資深領導階層是採用最佳實務和組織演進的發起者、倡導者和推動者 

 **建立此最佳實務的優勢：** 積極參與的領導階層、清楚傳達的期望和共同目標，能夠確保團隊成員知道對他們的期望。評估成功情況可識別成功的障礙，因此可藉由發起者、倡導者及其代表的介入來解決這些障礙。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  高層的支持：資深領導階層清楚設定對組織的期望並評估成功情況。資深領導階層是採用最佳實務和組織演進的發起者、倡導者和推動者 
  +  設定期望：為您的組織定義和發佈目標，包括衡量目標的方式。 
  +  追蹤目標的達成情況：定期衡量目標逐步達成的情況，並分享結果，以便在成果有風險時採取適當的動作。 
  +  提供實現目標所需的資源：根據新資訊、目標的變更、責任或您的業務環境等，定期檢閱資源是否仍然適當，或者是否需要其他資源。 
  +  倡導您的團隊：保持與團隊的合作，讓您了解團隊的情況，以及是否有外部因素正影響著他們。當您的團隊受到外部因素影響時，請重新評估目標並適當地調整目標。找出阻礙您團隊進度的障礙。代表您的團隊來協助解決障礙並消除不必要的負擔。 
  +  成為採用最佳實務的推動者：確認提供量化效益的最佳實務，並認可建立者和採用者。鼓勵進一步採用，以擴大已達成的效益。 
  +  成為團隊演變的推動者：建立持續改進的文化。鼓勵人員和組織的成長和發展。提供需要隨時間逐步達成的長期奮鬥目標。調整這個願景，以在需求、業務目標以及業務環境變化時，配合您的需求、業務目標和業務環境。 

# OPS03-BP02 授權團隊成員在成果有風險時採取動作
<a name="ops_org_culture_team_emp_take_action"></a>

 工作負載擁有者已定義指引和範圍，授權團隊成員在成果有風險時做出回應。當事件超出定義的範圍時，採取向上呈報機制來取得方向。 

 **建立此最佳實務的優勢：** 透過及早測試和驗證變更，您能以最低的成本來解決問題，並限制對客戶的影響。在部署前進行測試，可將引入的錯誤數量降到最低。 

 **若未建立此最佳實務，暴露的風險等級為：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  授權團隊成員在成果有風險時採取動作：為您的團隊成員提供許可、工具和機會，以練習有效回應所需的技能。 
  +  讓您的團隊成員有機會練習回應所需的技能：提供替代的安全環境，在其中可安全地測試和培訓流程及程序。執行演練日，讓團隊成員可以在模擬的安全環境中獲得回應實際事件的體驗。 
  +  定義並認可團隊成員採取動作的權限：透過指派許可和對其支援的工作負載和元件的存取權，明確地定義團隊成員採取動作的權限。認可他們有權在成果有風險時採取動作。 

# OPS03-BP03 鼓勵向上呈報
<a name="ops_org_culture_team_enc_escalation"></a>

 如果團隊成員認為成果有風險，則其機制可協助將疑慮向上呈報至決策制定者和利害關係人，而且我們鼓勵這麼做。應該儘早且經常向上呈報，以便識別風險，並防止風險引發事件。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  鼓勵儘早且經常向上呈報：組織認可儘早且經常呈報是最佳實務。組織認可並接受，向上呈報可能經證明是毫無根據的，然而有機會防止事件的發生，則好過於不向上呈報而錯過該機會。 
  +  制定向上呈報的機制：制定定義進行向上呈報的時機與方式的記錄程序。記錄擁有越來越多採取動作或核准動作的權限的人員及其聯絡資訊。向上呈報應持續進行，直到團隊成員確信已將風險交給能夠解決問題的人員，或已聯絡承擔工作負載營運風險和責任的人員。該人員最終負責與工作負載相關的所有決策。向上呈報的內容應包括風險的本質、工作負載的關鍵性、受影響者、影響為何，以及緊急性 (也就是預期影響的時間為何)。 
  +  保護向上呈報的員工：如果團隊成員圍繞無回應決策制定者或利害關係人向上呈報，則制定保護團隊成員免受報復的政策。制定機制以識別是否發生此情況，並適當地做出回應。 

# OPS03-BP04 溝通需及時、清楚且可行
<a name="ops_org_culture_effective_comms"></a>

 存在的機制可用來及時通知團隊成員已知的風險和計劃的事件。提供必要的內容、詳細資訊和時間 (如果可能) 來支援判斷是否需要採取動作、需要什麼動作，並及時採取動作。例如，提供軟體漏洞的通知，以便加快修補的速度，或提供計劃的銷售促銷活動的通知，如此就能實作變更凍結，避免服務中斷的風險。 

 計劃的事件可以記錄在變更行事曆或維護排程中，讓團隊成員可以確定哪些活動待處理。 

 在 AWS 上， [AWS Systems Manager 變更行事曆](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html) 可用來記錄這些詳細資訊。它支援以程式設計方式檢查行事曆狀態，以判斷行事曆在特定時間點是否有活動。可根據特定已核准時段來規劃 *營運活動，* 該特定時段是針對潛在破壞性活動而預留。AWS Systems Manager Maintenance Windows 可讓您針對執行個體和其他 [支援的資源](https://docs.aws.amazon.com/ARG/latest/userguide/supported-resources.html#supported-resources-console) 來排定活動，以自動化活動並讓這些活動可供探索。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  溝通需及時、清楚且可行：已設立機制，以清楚且可行的方式提供風險或計劃事件的通知，並提供足夠的通知，以便適當的回應。 
  +  記錄變更行事曆上計劃的活動，並提供通知：提供可存取的資訊來源，您可以在其中發現計劃的事件。提供來自相同系統之計劃事件的通知。 
  +  追蹤可能影響工作負載的事件和活動：監控漏洞通知和修補程式資訊，了解外部漏洞以及與工作負載元件相關的潛在風險。提供通知給團隊成員，以便讓他們可以採取動作。 

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [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/systems-manager-maintenance.html) 

# OPS03-BP05 鼓勵進行試驗
<a name="ops_org_culture_team_enc_experiment"></a>

 試驗可加速學習，讓團隊成員保持興趣和參與度。不理想的結果是成功的試驗，因其已識別出不會助力成功的路徑。團隊成員不會因取得不理想結果的成功試驗而受懲罰。必需要經由試驗才能實現創新，並讓想法轉化為成果。 

 **若未建立此最佳實務，暴露的風險等級：** 中 

## 實作指引
<a name="implementation-guidance"></a>
+  鼓勵進行試驗：鼓勵試驗以支援學習和創新。 
  +  試驗各種技術：鼓勵對現在或未來可能具有適用性的技術進行試驗，以實現業務成果。這些知識可能會幫助未來的創新。 
  +  帶著目標進行試驗：鼓勵對團隊成員要達成的特定目標進行試驗，或對近期可能具有適用性的技術進行試驗。這些知識可能會幫助您的創新。 
  +  提供實驗的結構化時間：指定團隊成員可以免於其正常責任的特定時間，讓他們可以專注於自己的試驗。 
  +  提供資源以支援試驗：為進行試驗所需的資源提供資金 (例如，軟體或雲端資源)。 
  +  認可成功：識別由試驗所產生的價值。了解含有不理想成果的試驗是成功的，並且這種試驗識別了不會助力成功的路徑。團隊成員不會因試驗而來的不理想成果受到懲罰。 

# OPS03-BP06 團隊成員得以並受到鼓勵來維持和發展自己的技能集
<a name="ops_org_culture_team_enc_learn"></a>

 團隊必須發展自己的技能集，以採用新技術，並支援需求和責任的變更，以支援您的工作負載。新技術的技能成長通常是團隊成員滿意度的來源，並可支援創新。支援團隊成員追求和維持產業認證，以驗證和認可他們不斷成長的技能。交叉培訓以促進知識轉移，並在失去熟練的、經驗豐富且具備機構知識的成員時，降低重大影響的風險。提供學習專用的結構化時間。 

 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/)，而這些資源均提供了可教育您的團隊的說明、範例和演練。 

 AWS 也分享了我們透過 [在 Amazon Builders' Library 中](https://aws.amazon.com/builders-library/) 操作 AWS 所學到的最佳實務和模式，以及透過 [不同途徑獲得的各種教材，例如 AWS 部落格](https://aws.amazon.com/blogs/) 和 [官方 AWS 播客](https://aws.amazon.com/podcasts/aws-podcast/)。 

 您應該利用 AWS 提供的教育資源，例如 Well-Architected 實驗室、 [AWS 支援](https://aws.amazon.com/premiumsupport/programs/) ([AWS 知識中心](https://aws.amazon.com/premiumsupport/knowledge-center/)， [AWS 開發論壇](https://forums.aws.amazon.com/index.jspa)和 [AWS 支援中心](https://console.aws.amazon.com/support/home/)) 和 [AWS 文件](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 資源來教育您的團隊。透過 AWS 支援中心聯絡 AWS 支援，以獲取 AWS 相關問題的幫助。 

 [AWS 培訓 和認證](https://aws.amazon.com/training/) 透過 AWS 基礎原理自主進度數位課程提供一些免費培訓。您還可以報名參加講師指導下的培訓，以進一步協助開發團隊的 AWS 技能。 

 **若未建立此最佳實務，暴露的風險等級為：** 中 

## 實作指引
<a name="implementation-guidance"></a>
+  團隊成員得以並受到鼓勵來維持和發展自己的技能集：若要採用新技術、支援創新、需求和責任的變更以支援工作負載，必需進行持續的教育。 
  +  為教育提供資源：提供專門的結構化時間、培訓教材和實驗室資源存取權，並支援參與會議和專業組織，這些會議和組織可為教育工作者和同儕提供學習的機會。為資淺團隊成員提供接近資深團隊成員的機會，讓資深團隊成員成為導師，或允許資深團隊成員伴隨資淺團隊成員工作，並展示他們的方法和技能。鼓勵學習與工作不直接相關的內容，以便取得更廣泛的視野。 
  +  團隊教育和跨團隊參與：針對團隊成員持續的教育需求進行規劃。為團隊成員提供機會 (暫時或永久地) 加入其他團隊，以分享讓整個組織受益的技能和最佳實務 
  +  支援產業認證的追求和維持：支援團隊成員取得與維持可驗證所學知識並認可其成就的產業認證。 

## 資源
<a name="resources"></a>

 **相關文件：** 
+  [AWS 入門資源中心](https://aws.amazon.com/getting-started/) 
+  [AWS 部落格](https://aws.amazon.com/blogs/) 
+  [AWS 雲端 合規](https://aws.amazon.com/compliance/) 
+  [AWS 開發論壇](https://forums.aws.amazon.com/index.jspa) 
+  [AWS 文件](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+  [AWS 線上技術會談](https://aws.amazon.com/getting-started/) 
+  [AWS 活動和網路研討會](https://aws.amazon.com/events/) 
+  [AWS 知識中心](https://aws.amazon.com/premiumsupport/knowledge-center/) 
+  [AWS 支援](https://aws.amazon.com/premiumsupport/programs/) 
+  [AWS 培訓 和認證](https://aws.amazon.com/training/) 
+  [AWS Well-Architected 實驗室](https://wellarchitectedlabs.com/)， 
+  [在 Amazon Builders' Library 中](https://aws.amazon.com/builders-library/) 
+  [官方 AWS 播客](https://aws.amazon.com/podcasts/aws-podcast/)。 

# OPS03-BP07 適當地為團隊提供資源
<a name="ops_org_culture_team_res_appro"></a>

 維持團隊成員能力，並提供工具和資源，以支援您的工作負載需求。為團隊成員指派過多的任務會增加因人為錯誤所造成的事件風險。對工具和資源的投資 (例如，為經常執行的活動提供自動化) 可以提高團隊的有效性，讓他們能夠支援其他的活動。 

 **若未建立此最佳實務，暴露的風險等級：** 中 

## 實作指引
<a name="implementation-guidance"></a>
+  適當地為團隊提供資源：確保您了解團隊的成功，以及促成他們成功或不成功的因素。以適當的資源來支援團隊。 
  +  了解團隊效能：衡量團隊營運成果的達成情況與資產的開發。追蹤一段時間內輸出和錯誤率的變更。與團隊合作，了解影響他們的工作相關挑戰 (例如，責任增加、技術變更、人員損失或客戶支援增加)。 
  +  了解對團隊效能的影響：保持與團隊的合作，讓您了解團隊的情況，以及是否有外部因素正影響著他們。當您的團隊受到外部因素影響時，請重新評估目標並適當地調整目標。找出阻礙您團隊進度的障礙。代表您的團隊來協助解決障礙並消除不必要的負擔。 
  +  提供團隊取得成功所需的資源：定期檢閱資源是否仍然適當、或是否需要額外資源，並做出適當的調整以支援團隊。 

# OPS03-BP08 鼓勵並尋求來自團隊內部和跨團隊的多樣化建議
<a name="ops_org_culture_diverse_inc_access"></a>

 利用跨組織的多樣性，尋求多種獨特的觀點。使用此觀點來增加創新、挑戰假設，並降低確認偏差的風險。在團隊中增加包容性、多樣性和可及性，以獲得有益的觀點。 

 組織文化對團隊成員工作滿意度和留任率有直接影響。讓團隊成員參與其中並習得能力，以便讓業務得以成功。 

 **若未建立此最佳實務，暴露的風險等級：** 低 

## 實作指引
<a name="implementation-guidance"></a>
+  尋求多樣化的意見和觀點：鼓勵每個人做出貢獻。為代表性不足的群體發聲。在會議中輪換角色和責任。 
  +  擴展角色和責任：為團隊成員提供機會，以擔任他們可能不會擔任的角色。他們會透過角色，以及與他們可能不會與之互動的新團隊成員互動，而獲得經驗和觀點。他們會將自己的經驗和觀點帶到新的角色，並帶給和他們互動的團隊成員。隨著觀點增加，可能會出現額外的商機，或者可能識別出新的改進機會。讓團隊內的成員輪流處理其他人通常執行的常見任務，以了解執行這些任務的需求和影響。 
  +  提供安全且友善的環境：制定政策與控制措施，保護組織內團隊成員在精神和身體上的安全。團隊成員應該能夠在不擔心報復行為的情況下進行互動。當團隊成員感到安全且受歡迎時，他們才更有可能參與進來並具備生產力。您的組織越多樣化，您就越能了解所支援的人員，包括您的客戶。當您的團隊成員感到安心、可以自在的暢所欲言，而且有信心他們的聲音不會被淹沒，他們才更有可能分享寶貴的洞見 (例如，行銷機會、可及性的需求、尚未有服務的市場區段、環境中未確認的風險)。 
  +  讓團隊成員能夠充分參與：提供員工充分參與所有與工作相關的活動所需的資源。面對日常挑戰的團隊成員已發展出解決挑戰的技能。這些以獨特方式發展的技能可為組織提供顯著的效益。為團隊成員提供必要住宿支援，將可提高從他們的貢獻中所獲得的效益。 