# 演進
**Topics**
+ [OPS 11 您如何改善營運？](w2aac19b5c11b5.md)
# 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 建立持續改進程序
定期評估改進機會並排定其優先順序，以專注於它們可在其中提供最大效益的工作。
**常用的反模式：**
+ 您已記錄建立開發或測試環境所需的程序。您可以使用 CloudFormation 將該程序自動化，但您卻從主控台手動執行程序。
+ 您的測試顯示，應用程式內絕大多數的 CPU 使用率都屬於一小組缺乏效率的功能。您可以專注於改進這些功能並降低成本，但您的任務是建立新的可用性功能。
**建立此最佳實務的優勢：** 透過持續改進提供一種機制，以定期評估改進機會、排定機會的優先順序，並專注於它們可在其中提供最大效益的工作。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 定義持續改進程序：定期評估改進機會並確定優先級，以將精力集中在可以帶來最大收益的機會上。實作變更以改善結果，並進行評估以確定成功與否。如果結果未能達到目標，並且改進仍然是優先事項，則使用其他行動方案重複進行。您的營運流程應設立專門的時間和資源，用於持續逐漸改善。
# OPS11-BP02 執行事故後分析
審查影響客戶的事件，並識別造成問題的因素和預防性措施。使用此資訊來開發緩解措施，以限制或防止事件再次發生。制定可快速有效回應的程序。適當地傳達成因和為目標受眾量身打造的糾正措施。
**常用的反模式：**
+ 您管理應用程式伺服器。大約每 23 小時 55 分鐘，所有作用中工作階段都會終止。您已嘗試識別應用程式伺服器上發生了什麼問題。您懷疑這反而可能是網路問題，但無法與網路團隊合作，因為他們太忙而無法為您提供支援。您缺少可遵循的預先定義程序來取得支援與收集必要資訊，以判斷發生的情況。
+ 您的工作負載內發生資料遺失問題。這是第一次發生，原因尚不確定。您確定它並不重要，因為您可以重新建立資料。資料遺失以影響客戶的較高頻率開始發生。當您還原遺失的資料時，這也會為您帶來額外的操作負擔。
**建立此最佳實務的優勢：** 透過預先定義的程序來判斷造成事件的元件、條件、動作和事件，讓您能夠找出改進機會。
**若未建立此最佳實務，暴露的風險等級為：** 高
## 實作指引
+ 使用程序判斷成因：審查所有影響客戶的事故。建立程序來識別和記錄事件的成因，以便您可以制定緩解措施來限制或防止事件再次發生。另外，您還可以制定快速有效地做出回應的程序。根據目標受眾的不同以適當的方式告知根本原因。
# OPS11-BP03 實作回饋迴圈
回饋迴圈提供可推動決策的可行洞察。在程序和工作負載中建立回饋迴圈。此可協助您找出問題和需要改善的地方。回饋迴圈也會驗證在改善中所做的投資。這些回饋迴圈是持續改善工作負載的基礎。
回饋迴圈分為兩種： *即時回饋* 和 *追溯性分析*。透過審查營運活動的績效和成果來收集即時的回饋。此回饋來自團隊成員、客戶或活動的自動化輸出。接收 A/B 測試和交付新功能等方面的即時回饋，對於快速檢錯非常重要。
定期進行追溯性分析，以從對營運成果和指標的審查中獲取回饋。這些追溯性分析會在衝刺結束，按規律或在主要版本或事件後發生。這類回饋迴圈會驗證對營運或工作負載所做的投資。其可協助您衡量成功並驗證策略。
**預期成果：** 您使用即時回饋和追溯性分析來推動改善。存在可擷取使用者和團隊成員回饋的機制。追溯性分析會用來找出可推動改善的趨勢。
**常見的反模式：**
+ 您推出新功能，但沒有辦法收到客戶對該功能的回饋。
+ 針對營運改善投入資源和時間後，您無法執行追溯性分析來進行驗證。
+ 您收集客戶的回饋，但未能定期審查回饋。
+ 回饋迴圈讓我們得以提議行動項目，但軟體開發程序中未納入這些項目。
+ 客戶沒有收到他們提議之改善的回饋。
**建立此最佳實務的優勢：**
+ 您可以反過來與客戶合作來推動新功能。
+ 您的組織文化可以更快速地應對變化。
+ 趨勢會用來找出改善的機會。
+ 追溯性分析可驗證對工作負載和營運所做的投資。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
實作此最佳實務表示您同時使用即時回饋和追溯性分析。這些回饋迴圈可推動改善。有許多機制可用來處理即時回饋，包含調查、客戶投票和回饋表單。組織也會使用追溯性分析來找出改善的機會並驗證計劃。
**客戶範例**
AnyCompany Retail 建立網頁表單，客戶可在其中提供回饋或回報問題。在每週 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)：營運指標審查會找出趨勢和待改善的地方。
**相關文件：**
+ [建置 CCOE 時應避開的 7 大陷阱](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 審查建立回饋迴圈](https://aws.amazon.com/blogs/architecture/establishing-feedback-loops-based-on-the-aws-well-architected-framework-review/)
+ [IBM Garage Methodology - 進行回顧](https://www.ibm.com/garage/method/practices/learn/practice_retrospective_analysis/)
+ [Investopedia – 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)
+ [TIL 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 解決方案 - AWS 上的 QnABot](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 知識管理
存在的機制讓您的團隊成員可以及時探索他們所需的資訊、存取資訊，並識別其是否為最新且完整的資訊。存在的機制是用來識別所需的內容、需要重新整理的內容，以及應存檔的內容，以便該內容不再供其他人參考。
**常用的反模式：**
+ 一個感到沮喪的客戶開立了新產品功能請求的支援案例，以處理感知的問題。它會新增到優先改進項目的清單中。
**若未建立此最佳實務，暴露的風險等級為：** 高
## 實作指引
+ 知識管理：確保存在的機制讓您的團隊成員可以及時探索他們所需的資訊、存取資訊，並識別其是否為最新且完整的資訊。維護機制，以識別所需的內容、需要重新整理的內容，以及應存檔的內容，以便該內容不再供其他人參考。
# OPS11-BP05 定義改進驅動因素
確定改進驅動因素，以幫助您評估改進機會並排定其優先順序。
在 AWS 上，您可以彙整所有營運活動、工作負載和基礎設施的日誌，以建立詳細的活動歷史記錄。然後，您可以使用 AWS 工具，分析某段時間內的營運和工作負載運作狀態 (例如，識別趨勢、將事件和活動與成果關聯，以及在環境間和跨系統進行比較和對比)，根據驅動因素來發現改善機會。
您應使用 CloudTrail 追蹤 API 活動 (透過 AWS 管理主控台、CLI、SDK 和 API)，以了解整個帳戶中發生的情況。使用 CloudTrail 和 CloudWatch 追蹤您的 AWS 開發人員工具部署活動。這樣會將部署及其成果的詳細活動歷史記錄新增至 CloudWatch Logs 日誌資料中。
[將日誌資料匯出至 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 以進行長期儲存。您可以使用 [AWS Glue](https://aws.amazon.com/glue/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)，您可以探索和準備 Amazon S3 中的日誌資料以進行分析。使用 [Amazon Athena](https://aws.amazon.com/athena/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)，透過與 AWS Glue 原生整合來分析日誌資料。使用 [Quick](https://aws.amazon.com/quicksight/) 這類商業智慧工具來視覺化、探索和分析您的資料
**常用的反模式：**
+ 您有一個可運作但不巧妙的指令碼。您投入時間來重新撰寫它。現在該指令碼相當出色。
+ 您的新創公司正嘗試從創投家獲得另一批資金。他們希望您證明 PCI DSS 的合規性。您想要讓客戶滿意，因此您以文件記錄合規情況，但錯過提供給客戶的交付日期，而失去該客戶。做這件事沒有錯，但現在您不知道這是否是對的。
**建立此最佳實務的優勢：** 藉由決定您想要用於改進的條件，您可以將事件型動機或情緒投資的影響降到最低。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 了解改進驅動因素：僅在支援理想結果時才對系統進行變更。
+ 所需能力：在評估改進機會時，評估所需的功能和能力。
+ [AWS 最新消息](https://aws.amazon.com/new/)
+ 不可接受的問題：在評估改進機會時，評估不可接受的問題、錯誤和弱點。
+ [AWS 最新安全公告](https://aws.amazon.com/security/security-bulletins/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ 合規要求：在審查改進機會時，評估保持法規、政策的遵從性或保持受到第三方支援所需的更新和變更。
+ [AWS 合規](https://aws.amazon.com/compliance/)
+ [AWS 合規計劃](https://aws.amazon.com/compliance/programs/)
+ [AWS 合規最新資訊](https://aws.amazon.com/compliance/compliance-latest-news/)
## 資源
**相關文件：**
+ [Amazon Athena](https://aws.amazon.com/athena/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)
+ [Quick](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/)
# OPS11-BP06 驗證洞見
與跨職能團隊和企業擁有者一起審查您的分析結果和回應。透過這些審查建立共識，確定其他影響並確定行動方案。適當調整回應。
**常用的反模式：**
+ 您看到系統上的 CPU 使用率為 95%，並優先找出降低系統負載的方法。您確定最佳行動方案是擴充。該系統是轉碼器，系統會擴展到一直以 95% 的 CPU 使用率執行。系統擁有者可能向您解釋情況，並讓您聯絡他們。您的時間被浪費了。
+ 系統擁有者堅稱系統是任務關鍵性系統。系統未放置在高安全性的環境中。為改善安全性，您實作任務關鍵性系統所需的額外偵測和預防性控制措施。您通知系統擁有者工作已完成，且其需為其他資源支付相應費用。在此通知之後的討論中，系統擁有者了解了其系統不符合的任務關鍵系統的正式定義。
**建立此最佳實務的優勢：** 透過與企業擁有者和領域專家驗證洞見，您可以建立共識並更有效地引導改進。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 驗證洞見：與企業擁有者和領域專家互動，確保您收集資料的意義得到眾人理解和同意。識別其他疑慮、潛在影響，並確定行動方案。
# OPS11-BP07 執行營運指標審查
與來自不同業務領域的跨團隊參與者定期進行營運指標的追溯性分析。透過這些審查確定改進機會、可能的行動方案並分享獲得的經驗。
尋找所有環境 (例如開發、測試和生產) 中的改善機會。
**常用的反模式：**
+ 您的維護時段中斷了重要的零售促銷。如果還有其他影響企業的事件，企業仍然不知道是否有可能會延遲的標準維護時段。
+ 您使用組織中常用的錯誤程式庫，因此您經歷了長時間的中斷。之後您已遷移到可靠的程式庫。組織中的其他團隊不知道他們正面臨風險。如果你們定期會面並審查此事故，他們就會注意風險。
+ 轉碼器的效能一直在穩定地下降，並影響媒體團隊。這還不是很令人震驚。除非該情況嚴重到足以造成事故，否則您將無法查明該情況。如果您與媒體團隊審查營運指標，則有機會識別指標及其體驗的變更並解決問題。
+ 您沒有審查對客戶 SLA 的滿意度。您有不符合客戶 SLA 的趨勢。不符合客戶 SLA，會產生相關的財務處罰。如果你們定期會面，並審查這些 SLA 的指標，您將有機會識別並解決問題。
**建立此最佳實務的優勢：** 透過定期會議以審查營運指標、事件和事故，您可以在團隊間維持共識、分享獲得的經驗，並可以排定改進項目的優先順序並鎖定改進目標。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
+ 營運指標審查：與來自不同業務領域的跨團隊參與者定期進行營運指標的追溯性分析。與包括業務、開發和營運團隊在內的利害關係人進行互動，以驗證您從即時回饋和追溯性分析獲得的發現，並分享經驗教訓。利用這些洞見確定改進機會和可能的行動方案。
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [使用 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Amazon CloudWatch 指標和維度參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.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)
# OPS11-BP08 記錄和分享獲得的經驗
記錄並分享從營運活動中獲得的經驗，以便您可以在內部以及跨團隊使用它們。
您應分享您的團隊獲得的經驗，以提高整個組織的效益。您希望分享資訊和資源，以防止可避免的錯誤並簡化開發工作。如此可讓您聚焦於提供所需的功能。
使用 AWS Identity and Access Management (IAM) 定義權限，從而實現對您希望在帳戶內及帳戶間分享的資源的受控存取。然後，您使用版本控制的 AWS CodeCommit 儲存器來分享應用程式程式庫、執行指令碼的程序、程序文件及其他系統文件。透過分享對 AMI 的存取以及授權跨帳戶使用 Lambda 函數，進而分享您的運算標準。您還應將基礎設施標準作為 AWS CloudFormation 範本進行分享。
透過 AWS API 和 SDK，您可以整合外部和第三方工具及儲存器 (例如 GitHub、BitBucket 和 SourceForge)。分享您獲得的經驗和開發的知識時，請小心建構權限，以確保分享的儲存器的完整性。
**常用的反模式：**
+ 您使用組織中常用的錯誤程式庫，因此您經歷了長時間的中斷。之後您已遷移到可靠的程式庫。組織中的其他團隊不知道他們正面臨風險。如果您在此程式庫中記錄和分享您的經驗，他們會注意風險。
+ 您已在內部共用的微型服務中找出導致工作階段終止的邊緣案例。您已更新對服務的呼叫，以避免此邊緣案例。組織中的其他團隊不知道他們正面臨風險。如果您在此程式庫中記錄和分享您的經驗，他們會注意風險。
+ 您已找到一個方法，可大幅降低其中一個微型服務所需的 CPU 使用率。您不知道是否有任何其他團隊可以利用此技術。如果您在此程式庫中記錄和分享您的經驗，其他團隊將有機會這樣做。
**建立此最佳實務的優勢：** 分享獲得的經驗以協助改進並將經驗的好處發揮到最大。
**若未建立此最佳實務，暴露的風險等級：** 低
## 實作指引
+ 記錄和分享獲得的經驗：制定程序來記錄從執行營運活動和追溯性分析中學到的經驗教訓，以便其他團隊可以使用。
+ 分享經驗：制定程序來在團隊之間分享經驗教訓和相關成品。例如，透過可存取的 Wiki 分享更新的程序、指引、管控和最佳實務。透過公共儲存庫共用指令碼、程式碼和程式庫。
+ [委託存取您的 AWS 環境](https://www.youtube.com/watch?v=0zJuULHFS6A&t=849s)
+ [共用 AWS CodeCommit 儲存庫](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-share-repository.html)
+ [輕鬆授權 AWS Lambda 函數](https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/)
+ [與特定 AWS 帳戶共用 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html)
+ [使用 AWS CloudFormation Designer URL 加速範本共用](https://aws.amazon.com/blogs/devops/speed-template-sharing-with-an-aws-cloudformation-designer-url/)
+ [搭配 Amazon SNS 使用 AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html)
## 資源
**相關文件：**
+ [輕鬆授權 AWS Lambda 函數](https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/)
+ [共用 AWS CodeCommit 儲存庫](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-share-repository.html)
+ [與特定 AWS 帳戶共用 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html)
+ [使用 AWS CloudFormation Designer URL 加速範本共用](https://aws.amazon.com/blogs/devops/speed-template-sharing-with-an-aws-cloudformation-designer-url/)
+ [搭配 Amazon SNS 使用 AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html)
**相關影片：**
+ [委託存取您的 AWS 環境](https://www.youtube.com/watch?v=0zJuULHFS6A&t=849s)
# OPS11-BP09 分配改進時間
在流程中投入時間和資源，以持續逐漸改善。
在 AWS 上，您可以建立臨時環境複本，從而降低試驗和測試的風險、工作量及成本。這些重複的環境可用於測試從您的分析、試驗和開發得出的結論，以及測試計劃的改善。
**常用的反模式：**
+ 您的應用程式伺服器存在已知的效能問題。它會新增到每個計劃功能實作的待辦項目中。如果計劃功能的新增速率保持不變，則效能問題永遠不會解決。
+ 為協助持續改進，您核准管理員和開發人員使用他們額外的時間來選取和實作改進項目。進改永遠不會有完成的一天。
**建立此最佳實務的優勢：** 透過在程序中投入時間和資源，您可以實現持續逐漸改善。
**若未建立此最佳實務，暴露的風險等級：** 低
## 實作指引
+ 分配改進時間：在流程中投入時間和資源，以持續逐漸改善。實作變更以改進和評估結果，從而確定成功與否。如果結果未能達到目標，並且改進仍然是優先事項，則應採取替代行動方案。