# OPS 11. 如何改善營運？
投入時間和資源，盡量持續逐漸改善，以加強營運的效果和效率。
**Topics**
+ [OPS11-BP01 建立持續改進程序](ops_evolve_ops_process_cont_imp.md)
+ [OPS11-BP02 執行事後分析](ops_evolve_ops_perform_rca_process.md)
+ [OPS11-BP03 實作意見回饋循環](ops_evolve_ops_feedback_loops.md)
+ [OPS11-BP04 執行知識管理](ops_evolve_ops_knowledge_management.md)
+ [OPS11-BP05 定義改進驅動因素](ops_evolve_ops_drivers_for_imp.md)
+ [OPS11-BP06 驗證洞察](ops_evolve_ops_validate_insights.md)
+ [OPS11-BP07 執行操作指標檢閱](ops_evolve_ops_metrics_review.md)
+ [OPS11-BP08 記錄和分享獲得的經驗](ops_evolve_ops_share_lessons_learned.md)
+ [OPS11-BP09 分配時間進行改善](ops_evolve_ops_allocate_time_for_imp.md)
# OPS11-BP01 建立持續改進程序
根據內部和外部架構最佳實務評估您的工作負載。進行頻繁、有目的的工作負載審查。根據您的軟體開發步調制定改進機會的優先順序。
**預期成果：**
+ 根據架構最佳實務頻繁分析工作負載。
+ 在軟體開發過程中，改進機會與功能獲得同等優先級。
**常見的反模式：**
+ 您在數年前部署工作負載後，即未對其執行過架構審查。
+ 您給予改進機會較低的優先級。與新功能相比，這些機會仍在待辦事項中。
+ 沒有針對組織的最佳實務實作修改標準。
**建立此最佳實務的優勢：**
+ 您的工作負載在架構最佳實務中保持最新狀態。
+ 您以故意的方式發展工作負載。
+ 您可以利用組織最佳實務來改進所有工作負載。
+ 您可以獲得具有累積影響的邊際收益，從而提高效率。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
經常對工作負載進行架構審查。使用內部和外部最佳實務，評估您的工作負載並識別改進機會。根據您的軟體開發步調制定改進機會的優先順序。
### 實作步驟
1. 以商定的頻率對生產工作負載進行定期架構審查。使用包含 AWS 特定最佳實務的已記載架構標準。
1. 使用內部定義的標準進行這些審查。如果沒有內部標準，可使用 AWS Well-Architected Framework。
1. 使用 AWS Well-Architected Tool 來建立內部最佳實務的自訂聚焦，並執行架構審查。
1. 請聯絡您的 AWS 解決方案架構師或技術客戶經理，在引導下執行工作負載的 Well-Architected Framework 審查。
1. 在您的軟體開發程序中，為在審查期間找出的改進機會制定優先順序。
**實作計劃的工作量：**低。可以使用 AWS Well-Architected Framework 進行每年的架構審查。
## 資源
**相關的最佳實務：**
+ [OPS11-BP02 執行事件後分析](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_perform_rca_process.html)
+ [OPS11-BP08 記錄和分享獲得的經驗](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_share_lessons_learned.html)
+ [OPS04 實作可觀測性](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_process_cont_imp.html)
**相關文件：**
+ [AWS Well-Architected Tool - 自訂聚焦](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)
+ [AWS Well-Architected 白皮書 - 審查程序](https://docs.aws.amazon.com/wellarchitected/latest/framework/the-review-process.html)
+ [使用自訂聚焦和 AWS Well-Architected Tool 來自訂 Well-Architected 審查](https://aws.amazon.com/blogs/mt/customize-well-architected-reviews-using-custom-lenses-and-the-aws-well-architected-tool/)
+ [在您的組織中實作 AWS Well-Architected 自訂聚焦生命週期](https://aws.amazon.com/blogs/architecture/implementing-the-aws-well-architected-custom-lens-lifecycle-in-your-organization/)
**相關影片：**
+ [AWS re:Invent 2023 - 擴展組織的 AWS Well-Architected 最佳實務](https://youtu.be/UXtZCoE9qfQ?si=OPATCOY2YAwiF2TS)
**相關範例：**
+ [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html)
# OPS11-BP02 執行事後分析
審查影響客戶的事件，並識別造成問題的因素和預防性動作。使用此資訊來開發緩解措施，以限制或防止事件再次發生。制定可快速有效回應的程序。適當地傳達成因和為目標受眾量身打造的糾正措施。
**預期成果：**
+ 您已建立包含事件後分析的事件管理程序。
+ 您已制定可觀測性計畫，可收集有關事件的資料。
+ 透過這些資料，您就可以了解並收集支援事件後分析程序的指標。
+ 您可以從事件中學習，以改善未來的成果。
**常見的反模式：**
+ 管理應用程式伺服器。大約每 23 小時 55 分鐘，您的所有活動工作階段都會終止。您試圖確定應用程式伺服器出了什麼問題。您懷疑這可能是網路問題，但由於網路團隊太忙而無法支援您，因此無法與他們合作。您缺乏可遵循的預定義流程來獲得支援並收集所需資訊以確定發生了什麼。
+ 您的工作負載中有資料遺失。這是第一次發生，原因尚不清楚。您認為這並不重要，因為您可以重新建立資料。資料遺失開始更頻繁地出現，從而影響客戶。當您還原遺失的資料時，這也會為您帶來額外的操作負擔。
**建立此最佳實務的優勢：**
+ 您有一個預先定義的程序來判斷造成事故的元件、條件、動作和事件，這有助於您找出改進機會。
+ 可以使用事件後分析的資料進行改善。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
使用程序判斷成因。審查所有影響客戶的事件。建立程序來識別和記錄事件的成因，以便您可以制定緩解措施來限制或防止事件再次發生。另外，您還可以制定快速有效地做出回應的程序。酌情溝通事件根本原因，並根據目標受眾量身定制溝通方式。在組織內公開分享學習成果。
### 實作步驟
1. 收集諸如部署變更、組態變更、事件開始時間、警示時間、參與時間、緩解開始時間和事件解決時間等指標。
1. 描述時間軸上的關鍵時間點，以了解事故的事件。
1. 請提出以下問題：
1. 您可以縮短偵測時間嗎？
1. 是否有指標和警示的更新，可以更快地檢測到事件？
1. 可以改善診斷時間嗎？
1. 回應計畫或呈報計劃是否有更新，可以更快地吸引合適的回應方？
1. 可以改善緩解時間嗎？
1. 是否有可以新增或改善的執行手冊或說明手冊步驟？
1. 可以防止未來的事件發生嗎？
1. 建立檢查清單和動作。追蹤並傳遞所有動作。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS11-BP01 建立持續改進程序](ops_evolve_ops_process_cont_imp.md)
+ [ OPS 4 - 實作可觀測性 ](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/implement-observability.html)
**相關文件：**
+ [在 Incident Manager 中執行事件後分析](https://docs.aws.amazon.com/incident-manager/latest/userguide/analysis.html)
+ [營運準備情況審核](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/iteration.html)
# OPS11-BP03 實作意見回饋循環
回饋迴圈提供可推動決策的可行洞見。在程序和工作負載中建立回饋迴圈。此可協助您找出問題和需要改善的地方。回饋迴圈也會驗證在改善中所做的投資。這些回饋迴圈是持續改善工作負載的基礎。
回饋迴圈分為兩類：*即時回饋*和*追溯性分析*。透過審查營運活動的績效和成果來收集即時的回饋。此回饋來自團隊成員、客戶或活動的自動化輸出。接收 A/B 測試和交付新功能等方面的即時回饋，對於快速檢錯非常重要。
定期進行追溯性分析，以從對營運成果和指標的審查中獲取回饋。這些追溯性分析會在衝刺結束，按規律或在主要版本或事件後發生。這類回饋迴圈會驗證對營運或工作負載所做的投資。其可協助您衡量成功並驗證策略。
**預期成果：**您使用即時回饋和追溯性分析來推動改善。存在可擷取使用者和團隊成員回饋的機制。追溯性分析會用來找出可推動改善的趨勢。
**常見的反模式：**
+ 您推出新功能，但沒有辦法收到客戶對該功能的回饋。
+ 針對營運改善投入資源和時間後，您無法執行追溯性分析來進行驗證。
+ 您收集客戶的回饋，但未能定期審查回饋。
+ 回饋迴圈讓我們得以提議行動項目，但軟體開發程序中未納入這些項目。
+ 客戶沒有收到他們提議之改善的回饋。
**建立此最佳實務的優勢：**
+ 您可以反過來與客戶合作來推動新功能。
+ 您的組織文化可以更快速地應對變化。
+ 趨勢會用來找出改善的機會。
+ 追溯性分析可驗證對工作負載和營運所做的投資。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
實作此最佳實務表示您同時使用即時回饋和追溯性分析。這些回饋迴圈可推動改善。有許多機制可用來處理即時回饋，包含調查、客戶投票和回饋表單。組織也會使用追溯性分析來找出改善的機會並驗證計畫。
**客戶範例**
AnyCompany 零售建立了一個 Web 表單，客戶可以提供意見回饋或報告問題。在每週 Scrum 期間，軟體開發團隊會評估使用者回饋。該團隊會定期使用回饋來為其平台的發展釐清方向。他們會在每次衝刺結束時執行追溯性分析，來找出他們想要改善的項目。
## 實作步驟
1. 即時回饋
+ 您需要制定機制來接收來自客戶和團隊成員的回饋。您也可以設定營運活動來提供自動化的回饋。
+ 組織需要制定程序來審查此回饋、判斷需要改善的項目，並安排改善項目。
+ 您必須將回饋新增至軟體開發程序。
+ 在您著手改善後，請與回饋提交者追蹤後續進展。
+ 您可以使用 [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) 來建立和追蹤這些改進，如 [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-working-with-OpsItems.html)。
1. 追溯性分析
+ 在開發週期結束時，以固定的規律或在主要版本之後，執行追溯性分析。
+ 召集工作負載中參與的利益相關者，進行回顧會議。
+ 在白板或試算表建立三個欄位：停止、開始和持續。
+ *停止*是指您希望團隊停止做的任何事。
+ *開始*是指您希望開始執行的想法。
+ *保持*是指您希望持續執行的項目。
+ 詢問在場人士的想法，收集利益相關者的回饋。
+ 排列回饋的優先順序。將動作和利益相關者指派至任何「開始」或「持續」項目。
+ 將動作新增至軟體開發程序中，並在您執行改善項目時向利益相關者告知最新的狀態。
**實作計劃的工作量：**中。若要實作此最佳實務，您需要找到方法來擷取即時回饋並進行分析。此外，您需要建立追溯性分析程序。
## 資源
**相關的最佳實務：**
+ [OPS01-BP01 評估外部客戶需求](ops_priorities_ext_cust_needs.md)：回饋迴圈是一種機制，可收集外部客戶的需求。
+ [OPS01-BP02 評估內部客戶需求](ops_priorities_int_cust_needs.md)：內部利益相關者可以使用回饋迴圈來表達需要和需求。
+ [OPS11-BP02 執行事後分析](ops_evolve_ops_perform_rca_process.md)：事件後分析是在事件後執行的追溯性分析的一種重要形式。
+ [OPS11-BP07 執行操作指標檢閱](ops_evolve_ops_metrics_review.md)：營運指標審查會找出趨勢和待改善的地方。
**相關文件：**
+ [建置 時要避免的 7 個陷阱 CCOE](https://aws.amazon.com/blogs/enterprise-strategy/7-pitfalls-to-avoid-when-building-a-ccoe/)
+ [Atlassian 團隊程序手冊 - 追溯性](https://www.atlassian.com/team-playbook/plays/retrospective)
+ [電子郵件定義：回饋迴圈](https://aws.amazon.com/blogs/messaging-and-targeting/email-definitions-feedback-loops/)
+ [根據 AWS Well-Architected Framework Review 建立意見回饋循環](https://aws.amazon.com/blogs/architecture/establishing-feedback-loops-based-on-the-aws-well-architected-framework-review/)
+ [IBM 車庫方法 - 保留回溯性](https://www.ibm.com/garage/method/practices/learn/practice_retrospective_analysis/)
+ [投資 – PDCS週期](https://www.investopedia.com/terms/p/pdca-cycle.asp)
+ [最大化開發人員的效能 (作者：Tim Cochran)](https://martinfowler.com/articles/developer-effectiveness.html)
+ [操作就緒審核 （ORR） 白皮書 - 迭代](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/iteration.html)
+ [ITIL CSI - 持續服務改進](https://wiki.en.it-processmaps.com/index.php/ITIL_CSI_-_Continual_Service_Improvement)
+ [當 Toyota 遇見電子商務：Amazon 的精實原則](https://www.mckinsey.com/capabilities/operations/our-insights/when-toyota-met-e-commerce-lean-at-amazon)
**相關影片：**
+ [建立有效的客戶回饋迴圈](https://www.youtube.com/watch?v=zz_VImJRZ3U)
**相關範例：**
+ [Astuto - 開放原始碼客戶回饋工具](https://github.com/riggraz/astuto)
+ [AWS 解決方案 - Q nABot on AWS](https://aws.amazon.com/solutions/implementations/qnabot-on-aws/)
+ [Fider - 整理客戶回饋的平台](https://github.com/getfider/fider)
**相關服務：**
+ [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
# OPS11-BP04 執行知識管理
知識管理可協助團隊成員尋找資訊以執行其作業。在學習組織中，資訊是任意共用的，助個人一臂之力。資訊可以探索和搜尋。資訊是準確且最新的。存在機制以建立新資訊、更新現有資訊，以及封存過時資訊。最常見的知識管理平台範例是內容管理系統，例如 Wiki。
**預期成果：**
+ 團隊成員可以存取及時、準確的資訊。
+ 資訊是可搜尋的。
+ 存在機制以新增、更新和封存資訊。
**常見的反模式：**
+ 沒有集中式知識儲存。團隊成員會在他們的本機電腦上管理他們自己的備註。
+ 您有自我託管的 Wiki，但是沒有管理資訊的機制，導致資訊過時。
+ 某人識別遺漏的資訊，但是沒有要求在團隊 Wiki 中新增它的程序。他們自行新增，但是遺漏關鍵步驟，導致中斷。
**建立此最佳實務的優勢：**
+ 因為資訊任意共用，所以團隊成員握有能力。
+ 因為文件是最新的且可搜尋，所以新的團隊成員可以更快上線。
+ 資訊是及時、準確且可行的。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
知識管理是學習組織的重要面向。若要開始，您需要集中儲存庫來存放您的知識 (常見的範例是自我託管的 Wiki)。您必須開發新增、更新和封存知識的程序。開發應該記載哪些項目的標準，並且讓所有人做出貢獻。
**客戶範例**
AnyCompany 零售託管儲存所有知識的內部 Wiki。團隊成員受到鼓勵在他們執行每日職責時新增至知識庫。跨功能團隊每季會評估哪些頁面最少更新，並且判斷它們是否應該封存或更新。
**實作步驟**
1. 從識別存放知識所在的內容管理系統開始。跨組織取得利益相關者的同意。
1. 如果您沒有現有內容管理系統，請考慮執行自我託管 Wiki 或使用版本控制儲存庫做為起點。
1. 開發新增、更新和封存資訊的執行手冊。向您的團隊教育這些程序。
1. 識別哪些知識應該存放在內容管理系統中。從團隊成員執行的每日活動 (執行手冊和程序手冊) 開始。與利益相關者合作來排列新增知識的優先順序。
1. 定期與利益相關者合作，以識別 out-of-date資訊並將其封存或更新。
**實作計劃的工作量：**中。如果您沒有現有內容管理系統，您可以設定自我託管 Wiki 或版本控制文件儲存庫。
## 資源
**相關的最佳實務：**
+ [OPS11-BP08 記錄和分享獲得的經驗](ops_evolve_ops_share_lessons_learned.md) - 知識管理可促進所學習課程的資訊共用。
**相關文件：**
+ [ Atlassian - 知識管理](https://www.atlassian.com/itsm/knowledge-management)
**相關範例：**
+ [ DokuWiki ](https://www.dokuwiki.org/dokuwiki)
+ [ Gollum ](https://github.com/gollum/gollum)
+ [ MediaWiki ](https://www.mediawiki.org/wiki/MediaWiki)
+ [ Wiki.js ](https://github.com/Requarks/wiki)
# OPS11-BP05 定義改進驅動因素
確定改進驅動因素，以幫助您依據資料和回饋迴圈來評估改進機會並排定其優先順序。探索系統和程序中的改進機會，並在適當的情況下自動化。
**預期成果：**
+ 可以追蹤您的整個環境的資料。
+ 可以將事件和活動與業務成果相關聯。
+ 可以在環境和系統之間進行比較和對比。
+ 可以維護部署和成果的詳細活動歷史記錄。
+ 可收集資料以支援您的安全狀態。
**常見的反模式：**
+ 可以從整個環境中收集資料，但不會關聯事件和活動。
+ 可以從整個資產中收集詳細資料，這會導致較高的 Amazon CloudWatch 和 AWS CloudTrail 活動與成本。但是，您不會有目的地使用此資料。
+ 在定義改進驅動因素時，您不會考慮業務成果。
+ 您不會測量新功能的效果。
**建立此最佳實務的優勢：**
+ 透過確定改進標準，可以將事件型動機或情緒投資的影響降到最低。
+ 您可以回應商業活動，而不僅僅是技術事件。
+ 測量您的環境，以確定需要改進的領域。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
+ 了解改進驅動因素：僅在支援理想結果時才對系統進行變更。
+ 所需能力：在評估改進機會時，評估所需的功能和能力。
+ [AWS 最新消息](https://aws.amazon.com/new/)
+ 不可接受的問題：在評估改進機會時，評估不可接受的問題、錯誤和漏洞。追蹤合適的選項，並尋求優化機會。
+ [AWS 最新安全公告](https://aws.amazon.com/security/security-bulletins/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ [雲端智慧儀表板](https://www.wellarchitectedlabs.com/cloud-intelligence-dashboards/)
+ 合規要求：在審查改進機會時，評估保持法規、政策的遵從性或保持受到第三方支援所需的更新和變更。
+ [AWS 合規](https://aws.amazon.com/compliance/)
+ [AWS 合規計劃](https://aws.amazon.com/compliance/programs/)
+ [AWS 合規性最新資訊](https://aws.amazon.com/compliance/compliance-latest-news/)
## 資源
**相關的最佳實務：**
+ [OPS01 組織優先事項](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/organization-priorities.html)
+ [OPS02 關係和擁有權](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/relationships-and-ownership.html)
+ [OPS04-BP01 識別關鍵績效指標](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html)
+ [OPS08 利用工作負載可觀測性](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/utilizing-workload-observability.html)
+ [OPS09 了解運作狀態](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-operational-health.html)
+ [OPS11-BP03 實作回饋迴圈](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_feedback_loops.html)
**相關文件：**
+ [Amazon Athena](https://aws.amazon.com/athena/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)
+ [快速](https://aws.amazon.com/quicksight/)：
+ [AWS 合規](https://aws.amazon.com/compliance/)
+ [AWS 合規性最新資訊](https://aws.amazon.com/compliance/compliance-latest-news/)
+ [AWS 合規計劃](https://aws.amazon.com/compliance/programs/)
+ [AWS Glue](https://aws.amazon.com/glue/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)
+ [AWS 最新安全公告](https://aws.amazon.com/security/security-bulletins/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ [將日誌資料匯出至 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [AWS 最新消息](https://aws.amazon.com/new/)
+ [以客戶為中心的創新的必要條件](https://aws.amazon.com/executive-insights/content/the-imperatives-of-customer-centric-innovation/)
+ [數位轉型：炒作還是戰略需要？](https://aws.amazon.com/blogs/enterprise-strategy/digital-transformation-hype-or-a-strategic-necessity/)
**相關影片**
+ [AWS re:Invent 2023 - 透過 支援 (SUP310) 提高營運效率和彈性](https://youtu.be/jaehZYBNG0Y?si=UNEaLZsXDrxcBgYo)
# OPS11-BP06 驗證洞察
與跨職能團隊和企業擁有者一起審查您的分析結果和回應。透過這些審查建立共識，確定其他影響並確定行動方案。適當調整回應。
**預期成果：**
+ 定期與企業擁有者審查洞見。企業擁有者為新獲得的洞察提供額外的內容。
+ 可以檢閱洞見並請求技術同儕們的意見回饋，並在各個團隊之間分享您的學習成果。
+ 可以發布資料和洞見，供其他技術和業務團隊審核。將所學知識納入其他部門的新實務中。
+ 與資深主管一起總結和審查新洞見。資深主管使用新洞見來定義策略。
**常見的反模式：**
+ 您發佈了一個新功能。此功能會變更部分客戶行為。您的可觀測性不會考慮這些變更。您不會量化這些變更的好處。
+ 您推送新的更新並忽略重新整理您的 CDN。CDN 快取不再與最新版本相容。測量發生錯誤的請求百分比。您的所有使用者在與後端伺服器通訊時，都會報告 HTTP 400 個錯誤。調查用戶端錯誤，並發現由於您測量了錯誤的維度，所以時間被浪費了。
+ 您的服務水準協議規定正常執行時間為 99.9%，而您的復原點目標為四小時。服務擁有者維護系統為零停機時間。實作昂貴且複雜的複寫解決方案，這會浪費時間和金錢。
**建立此最佳實務的優勢：**
+ 與企業擁有者和領域專家驗證洞見時，建立共識並更有效地引導改進。
+ 您會發現隱藏的問題，並將其納入未來決策中。
+ 重點從技術成果轉移到業務成果。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
+ **驗證洞見：**與企業擁有者和領域專家互動，確保您收集資料的意義得到眾人理解和同意。識別其他疑慮、潛在影響，並確定行動方案。
## 資源
**相關的最佳實務：**
+ [OPS01-BP06 在管理效益和風險時評估權衡](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)
+ [OPS團隊之間的 02-BP06 責任已預先定義或協商](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_neg_team_agreements.html)
+ [OPS11-BP03 實作意見回饋循環](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_feedback_loops.html)
**相關文件：**
+ [設計 Cloud Center of Excellence （CCOE）](https://aws.amazon.com/blogs/enterprise-strategy/designing-a-cloud-center-of-excellence-ccoe/)
**相關影片：**
+ [建立可觀測性以提高復原能力](https://youtu.be/6bJkYtrMMPI?si=yu8tVMz4a6ax9f34&t=2695)
# OPS11-BP07 執行操作指標檢閱
與來自不同業務領域的跨團隊參與者定期進行營運指標的追溯性分析。透過這些審查確定改進機會、可能的行動方案並分享獲得的經驗。尋找所有環境 (例如開發、測試和生產) 中的改善機會。
**預期成果：**
+ 經常審查影響業務的指標
+ 可以透過可觀測性功能來偵測和審查異常
+ 可以使用資料來支援業務成果和目標
**常見的反模式：**
+ 維護時段會中斷重要的零售促銷活動。如果還有其他影響企業的事件，企業仍然不知道是否有可能會延遲的標準維護時段。
+ 您經歷了長時間的中斷，因為您經常使用組織中過時的程式庫。之後您已遷移到支援的程式庫。組織中的其他團隊不知道他們正面臨風險。
+ 您不會定期檢閱客戶 的達成情況SLAs。您即將不符合您的客戶 SLAs。未滿足客戶 會受到財務處罰SLAs。
**建立此最佳實務的優勢：**
+ 當您定期開會以審查營運指標、事件和事故時，可以在團隊之間保持共識。
+ 您的團隊會定期會面，以檢閱指標和事件，這些指標和事件可讓您針對風險採取行動並識別客戶 SLAs。
+ 您分享學到的經驗教訓，為業務成果的優先順序和有針對性的改進提供資料。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
+ 與來自不同業務領域的跨團隊參與者定期進行營運指標的追溯性分析。
+ 與包括業務、開發和營運團隊在內的利益相關者進行互動，以驗證您從即時回饋和追溯性分析獲得的發現，並分享經驗教訓。
+ 利用這些洞見確定改進機會和可能的行動方案。
## 資源
**相關的最佳實務：**
+ [OPS08-BP05 建立儀表板](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_workload_observability_create_dashboards.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)
**相關文件：**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [使用 的儀表板和視覺化 CloudWatch](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/cloudwatch-dashboards-visualizations.html)
# OPS11-BP08 記錄和分享獲得的經驗
記錄並分享在操作活動中獲得的經驗，以便您可以在內部以及跨團隊使用它們。應分享您的團隊獲得的經驗，以提高整個組織的效益。共用資訊和資源，以防止可避免的錯誤及簡化開發工作，並專注於交付所需的功能。
使用 AWS Identity and Access Management (IAM) 來定義權限，允許對您希望在帳戶內及帳戶間分享的資源的受控存取。
**預期成果：**
+ 使用版本控制的儲存器來分享應用程式程式庫、執行指令碼的程序、程序文件及其他系統文件。
+ 可以將基礎設施標準共用為版本控制的 AWS CloudFormation 範本。
+ 審核團隊學到的經驗教訓。
**常見的反模式：**
+ 您經歷了長時間的中斷，因為您的組織經常使用錯誤的程式庫。之後您已遷移到可靠的程式庫。組織中的其他團隊不知道他們正面臨風險。沒有人記錄和分享有關此程式庫的經驗，他們沒有意識到風險。
+ 您已在內部共用的微型服務中找出導致工作階段終止的邊緣案例。您已更新對服務的呼叫，以避免此邊緣案例。組織中的其他團隊不知道他們正面臨風險。
+ 您已找到一個方法，可大幅降低其中一個微型服務所需的 CPU 使用率。您不知道是否有任何其他團隊可以利用此技術。
**建立此最佳實務的優勢：**分享經驗教訓以支援改進並最大限度地發揮經驗的優勢。
**未建立此最佳實務時的曝險等級：**低
## 實作指引
+ **記錄和分享獲得的經驗：**制定程序來記錄從執行營運活動和追溯性分析中學到的經驗教訓，以便其他團隊可以使用。
+ **分享經驗：**制定程序在團隊之間分享經驗教訓和相關成品。例如，透過可存取的 Wiki 分享更新的程序、指南、管控和最佳實務；透過公共儲存庫分享指令碼、程式碼和程式庫。
+ 利用 [AWS re:Post Private](https://aws.amazon.com/repost-private/) 做為知識服務，讓組織內的協作和知識共享更順暢。
## 資源
**相關的最佳實務：**
+ [OPS02-BP06 團隊之間的責任是預先定義或經過協商的](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_neg_team_agreements.html)
+ [OPS05-BP01 使用版本控制](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_version_control.html)
+ [OPS05-BP06 共用設計標準](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_share_design_stds.html)
+ [OPS11-BP03 實作回饋迴圈](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_feedback_loops.html)
+ [OPS11-BP07 執行營運指標審查](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_metrics_review.html)
**相關文件：**
+ [利用 AWS re:Post Private 增進協作並安全地共享雲端知識](https://aws.amazon.com/blogs/aws/increase-collaboration-and-securely-share-cloud-knowledge-with-aws-repost-private/)
+ [利用文件即程式碼解決方案減少專案延遲](https://aws.amazon.com/blogs/infrastructure-and-automation/reduce-project-delays-with-docs-as-code-solution/)
**相關影片：**
+ [AWS re:Invent 2023 - 利用 AWS re:Post Private 在您的公司內協作並與 AWS 合作](https://www.youtube.com/watch?v=HNq_kU2QJLU)
+ [支援 為您提供支援 \$1 探索事件管理桌上模擬演練](https://www.youtube.com/watch?v=0m8sGDx-pRM)
# OPS11-BP09 分配時間進行改善
在流程中投入時間和資源，以持續逐漸改善。
**預期成果：**
+ 您可以建立臨時環境複本，從而降低試驗和測試的風險、工作量及成本。
+ 這些重複的環境可用於測試從您的分析、試驗和開發得出的結論，以及測試計劃的改善。
+ 您會執行遊戲日，並使用 Fault Injection Service （FIS） 提供團隊在類似生產環境中執行實驗所需的控制項和防護機制。
**常見的反模式：**
+ 您的應用程式伺服器存在已知的效能問題。它會新增到每個計劃功能實作的待辦項目中。如果計劃功能的新增速率保持不變，則效能問題永遠不會解決。
+ 為協助持續改進，您核准管理員和開發人員使用他們額外的時間來選取和實作改進項目。改進永遠不會有完成的一天。
+ 操作驗收已完成，您不會再測試操作實務。
**建立此最佳實務的優勢：**透過在程序中投入時間和資源，您可以實現持續逐漸改善。
**未建立此最佳實務時的曝險等級：**低
## 實作指引
+ 分配時間進行改進：在流程中投入時間和資源，以持續逐漸改善。
+ 實作變更以改進和評估結果，從而確定成功與否。
+ 如果結果未能達到目標，並且改進仍然是優先事項，則應採取替代行動方案。
+ 在演練日模擬生產工作負載，並利用這些模擬中的知識進行改進。
## 資源
**相關的最佳實務：**
+ [OPS05-BP08 使用多個環境](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_multi_env.html)
**相關影片：**
+ [AWS re：Invent 2023 - 使用 AWS Fault Injection Service 改善應用程式彈性](https://youtu.be/N0aZZVVZiUw?si=ivYa9ScBfHcj-IAq)