# OPS 7 您如何知道自己準備好支援工作負載？
評估工作負載、流程和程序及人員的營運準備度，了解工作負載相關營運風險。
**Topics**
+ [OPS07-BP01 確保人員能力](ops_ready_to_support_personnel_capability.md)
+ [OPS07-BP02 確保對營運準備度進行一致的審查](ops_ready_to_support_const_orr.md)
+ [OPS07-BP03 使用執行手冊執行程序](ops_ready_to_support_use_runbooks.md)
+ [OPS07-BP04 使用程序手冊來調查問題](ops_ready_to_support_use_playbooks.md)
+ [OPS07-BP05 做出部署系統和變更的明智決策](ops_ready_to_support_informed_deploy_decisions.md)
# OPS07-BP01 確保人員能力
建立一種機制，用於驗證您有適當數量受過培訓的人員來為營運需求提供支援。培訓人員並根據需要調整人員能力，以保持有效的支援。
您需要擁有足夠的團隊成員，以妥善應對所有活動 (包括隨時待命)。確保您的團隊具備取得成功所需的必要技能，並進行工作負載、操作工具和 AWS 的培訓。
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 培訓 和認證](https://aws.amazon.com/training/) 透過 AWS 基礎原理自主進度數位課程提供一些免費培訓。您還可以報名參加講師指導下的培訓，以進一步協助開發團隊的 AWS 技能。
**常用的反模式：**
+ 在沒有能夠支援使用中平台和服務的熟練團隊成員之情況下，部署工作負載。
+ 在預期支援時數內無團隊成員可用的情況下部署工作負載。
+ 在團隊成員休假或生病請假而無足夠團隊成員提供支援的情況下，部署工作負載。
+ 在未檢閱對支援該工作負載和其他工作負載之團隊成員的額外影響情況下，部署額外工作負載。
**建立此最佳實務的優勢：** 擁有熟練的團隊成員可有效支援您的工作負載。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 人員能力：驗證人員是否已經過充分培訓，可有效支援工作負載。
+ 團隊規模：確保擁有足夠且訓練有素的團隊成員，以妥善應對營運活動，包括隨時待命。
+ 團隊技能：確保您的團隊成員就 AWS、工作負載和營運工具獲得足夠培訓，可履行其職責。
+ [AWS 活動和網路研討會](https://aws.amazon.com/about-aws/events/)
+ [歡迎來到 AWS 培訓 培訓與認證](https://aws.amazon.com/training/)
+ 審查能力：隨著營運條件和工作負載變化，審查團隊的規模和技能，以確保有足夠能力維持卓越營運。進行調整以確保團隊規模和技能與團隊支援的工作負載的營運要求相匹配。
## 資源
**相關文件：**
+ [AWS 部落格](https://aws.amazon.com/blogs/)
+ [AWS 活動和網路研討會](https://aws.amazon.com/about-aws/events/)
+ [AWS 入門資源中心](https://aws.amazon.com/getting-started/)
+ [AWS 線上技術會談](https://aws.amazon.com/getting-started/)
+ [歡迎來到 AWS 培訓 培訓與認證](https://aws.amazon.com/training/)
**相關範例：**
+ [Well-Architected 實驗室](https://wellarchitectedlabs.com/)
# OPS07-BP02 確保對營運準備度進行一致的審查
使用營運準備度審查 (ORR)，來確認您可以運行工作負載。 ORR 是在 Amazon 開發的機制，可確認團隊是否可放心地運行工作負載。ORR 是使用需求檢查清單的審查和檢查程序。ORR 是一種自助服務體驗，團隊會透過此體驗來進行工作負載的認證。ORR 包含的最佳實務皆汲取我們多年來建置軟體所獲得的經驗。
ORR 檢查清單包含架構建議、營運程序、事件管理和發行品質。錯誤糾正 (CoE) 程序是這些項目的主要驅動要素。您專屬的事件後分析應有助於專屬 ORR 的發展。ORR 不只是遵循最佳實務，還能防止先前發生過的事件再發。最後，ORR 中也能夠包含安全性、管控和合規需求。
在工作負載啟動以全面供應前，並在整個軟體開發生命週期執行 ORR。在啟動前執行 ORR 可改善安全運行工作負載的能力。定期針對工作負載重新執行 ORR 可捕捉最佳實務中的任何偏移。您可以為新服務的推出制定 ORR 檢查清單，並為定期審查制定 ORR。此可協助您掌握新出現的最佳實務最新狀態，並採納從事件後分析獲得的經驗。隨著您可以更熟練地使用雲端後，您就可以在架構中建置 ORR 需求作為預設值。
**預期成果：** 您制定 ORR 檢查清單，內含組織的最佳實務。ORR 會在工作負載啟動前執行。ORR 會在工作負載生命週期的過程中定期執行。
**常見的反模式：**
+ 您啟動工作負載，但不知道自己是否能夠運行工作負載。
+ 啟動工作負載的認證中未納入管控和安全性需求。
+ 不會定期重新評估工作負載。
+ 工作負載啟動，但不需設置必要的程序。
+ 您可以在多個工作負載中看到重複出現的相同根本原因失敗。
**建立此最佳實務的優勢：**
+ 工作負載包含架構、程序和管理最佳實務。
+ 經驗已納入 ORR 程序中。
+ 工作負載啟動時，已設置必要的程序。
+ ORR 會在工作負載的整個軟體生命週期執行。
**若未建立此最佳實務的風險等級：** 高
## 實作指引
ORR 有兩個部分：程序和檢查清單。貴組織應採用 ORR 程序，並由執行主辦人支援此程序。至少，必須在工作負載啟動以全面供應前執行 ORR。在整個軟體開發生命週期執行 ORR，使其與最佳實務或新需求保持同步。ORR 檢查清單應包含組態項目、安全性和管控需求，以及來自貴組織的最佳實務。在經過一段時間後，您可以使用服務，例如 [AWS Config](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)，和 [AWS Control Tower 防護機制](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)，來將 ORR 中的最佳實務建置在防護機制中，以便自動偵測最佳實務。
**客戶範例**
在發生數個生產事件後，AnyCompany Retail 決定實作 ORR 程序。他們建立了一份檢查清單，其中由最佳實務、管控和合規需求，以及從中斷中汲取的經驗教訓所組成。在工作負載啟動前，新的工作負載會執行 ORR。每個工作負載每年都會使用一部分的最佳實務來執行 ORR，以便納入在 ORR 檢查清單中新增的最佳實務和需求。經過一段時間後，AnyCompany Retail 使用 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 來偵測最佳實務，進而縮短 ORR 程序的時間。
**實作步驟**
若要進一步了解 ORR，請閱讀 [「營運準備度審查 (ORR)」白皮書](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)。其中提供詳細的資訊，說明 ORR 程序的歷史、如何建立您專屬的 ORR 實務，以及如何制定 ORR 檢查清單。以下步驟是該文件的精簡版本。如需深入了解 ORR 是什麼，以及如何建立您專屬的 ORR，我們建議閱讀該白皮書。
1. 召集關鍵利害關係人，包含安全性、營運和開發等團隊的代表人員。
1. 請每位利害關係人提供至少一個需求。對於第一次的反覆測試，請嘗試將項目數限制在三十個以下。
+ [附錄 B：來自「營運準備度審查 (ORR)」白皮書的](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html) ORR 問題範例包含您可以開始使用的範例問題。
1. 將需求集中放在試算表中。
+ 您可以使用 [在](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) AWS Well-Architected Tool 中 [使用自訂聚焦](https://console.aws.amazon.com/wellarchiected/) 來制定 ORR 並在帳戶和 AWS 組織之間進行共用。
1. 找出要在其中執行 ORR 的一個工作負載。啟動前的工作負載或內部工作負載是理想的選擇。
1. 演練 ORR 檢查清單，並記下任何所探索的項目。如果採取緩解措施，那就可能無法進行探索。對於缺少緩解措施的任何探索，請將那些探索新增至項目的待辦清單中，然後在啟動前加以實作。
1. 隨著時間持續在 ORR 檢查清單中新增最佳實務和需求。
使用 Enterprise Support 的 支援 客戶可請求 [「營運準備度審查」研討會](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) (透過其技術客戶經理)。研討會是互動式的 *逆向思維* 課程，可讓您制定自己的 ORR 檢查清單。
**實作計劃的工作量：** 高。在組織中採用 ORR 實務需要高層和利害關係人的支持。使用貴組織提供的各方意見，來建立和更新檢查清單。
## 資源
**相關的最佳實務：**
+ [OPS01-BP03 評估管控要求](ops_priorities_governance_reqs.md) – ORR 檢查清單原本就很適合用來管控需求。
+ [OPS01-BP04 評估合規要求](ops_priorities_compliance_reqs.md) – ORR 檢查清單中有時會包含合規需求。有些時候，它們會是獨立的程序。
+ [OPS03-BP07 適當地為團隊提供資源](ops_org_culture_team_res_appro.md) – 團隊能力是 ORR 需求的絕佳候選項。
+ [OPS06-BP01 為失敗變更進行規劃](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – 啟動工作負載前，必須先建立回復或向前回復計劃。
+ [OPS07-BP01 確保人員能力](ops_ready_to_support_personnel_capability.md) – 若要支援工作負載，您必須具備所需的人員。
+ [SEC01-BP03 識別和驗證控制目標](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_control_objectives.html) – 安全性控制目標是絕佳的 ORR 需求。
+ [REL13-BP01 定義停機和資料遺失的復原目標](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_objective_defined_recovery.html) – 災難復原計劃是絕佳的 ORR 需求。
+ [COST02-BP01 根據貴組織的需求制定政策](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_policies.html) – 將成本管理政策納入 ORR 檢查清單是很棒的做法。
**相關文件：**
+ [AWS Control Tower - AWS Control Tower 中的防護機制](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [AWS Well-Architected Tool - 自訂聚焦](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)
+ [Adrian Hornsby 提供的營運準備度審查範本](https://medium.com/the-cloud-architect/operational-readiness-review-template-e23a4bfd8d79)
+ [「營運準備度審查 (ORR)」白皮書](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)
**相關影片：**
+ [AWS 支援 為您提供支援 \$1 建立有效的營運準備度審查 (ORR)](https://www.youtube.com/watch?v=Keo6zWMQqS8)
**相關範例：**
+ [營運準備度審查 (ORR) 聚焦範例](https://github.com/aws-samples/custom-lens-wa-sample/tree/main/ORR-Lens)
**相關服務：**
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)
+ [使用自訂聚焦](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html)
# OPS07-BP03 使用執行手冊執行程序
路由層 *執行手冊* 是為了實現特定結果而記錄的程序。執行手冊由一系列可供遵循以完成某項工作的步驟組成。早在航空器製造初期，操作過程中就會使用執行手冊。在雲端操作中，我們使用執行手冊來降低風險及達到預期成果。簡言之，執行手冊就是完成一項工作的檢查清單。
執行手冊是工作負載的運作不可或缺的部分。從新團隊成員的上線到部署主要版本，執行手冊無論由誰使用，都是可提供一致結果的編碼程序。執行手冊應在集中發佈，並隨著程序的演進而更新，因為更新執行手冊是變更管理程序的重要環節。其中也應包含關於問題發生時的錯誤處理、工具、許可、例外狀況和呈報的指引。
隨著組織的成熟，您可以開始將執行手冊自動化。請從簡短且常用的執行手冊開始著手。使用指令碼語言自動執行步驟，或使步驟較容易執行。前幾個執行手冊完成自動化後，您會專注於將較複雜的執行手冊自動化。經過一段時間後，您大多數的執行手冊應該都已做了某種程度的自動化。
**預期成果：** 您的團隊有一系列執行工作負載任務的逐步指南。執行手冊中包含預期成果、必要的工具和許可，以及錯誤處理指示。這些執行手冊會集中存放，並且經常更新。
**常見的反模式：**
+ 憑藉記憶完成程序中的每個步驟。
+ 手動部署變更而不使用檢查清單。
+ 不同的團隊成員執行相同程序，但使用的步驟不同，或結果不同。
+ 執行手冊失去與系統變更和自動化的同步。
**建立此最佳實務的優勢：**
+ 降低手動工作的錯誤率。
+ 以一致的方式執行操作：
+ 新的團隊成員可更快開始執行工作。
+ 可將執行手冊自動化以節省人力。
**未建立此最佳實務時的曝險等級：** 中
## 實作指引
根據組織的成熟度，執行手冊採取數種形式。其中至少應包含逐步說明文字文件。預期成果應明確指出。明確記載必要的特殊許可或工具。提供詳細指引，說明在發生狀況時應如何處理錯誤及呈報。列出執行手冊擁有者，並將其集中發佈。執行手冊列入文件後，應請團隊的其他成員加以執行，以進行驗證。隨著程序的演進，請根據您的變更管理程序更新執行手冊。
隨著組織逐漸成熟，您的文字執行手冊應該要自動化。使用諸如 [AWS Systems Manager 自動化的服務](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)，您可以將一般文字轉換為可對工作負載執行的自動化。這些自動化可作為事件的應變動作來執行，以降低您維持工作負載的操作負擔。
**客戶範例**
AnyCompany Retail 必須在軟體部署期間執行資料庫結構描述更新。雲端維運團隊與資料庫管理團隊共同建置用來手動部署這些變更的執行手冊。執行手冊以檢查清單格式列出了程序中的每個步驟。其中包含相關發生狀況時進行錯誤處理的章節。他們將執行手冊發佈於內部 Wiki，與其他執行手冊放在一起。雲端維運團隊規劃要在未來的衝刺期間將執行手冊自動化。
## 實作步驟
如果您沒有現有的文件儲存庫，版本控制儲存庫將是您開始建置執行手冊程式庫的絕佳選擇。您可以使用 Markdown 來建置執行手冊。我們提供了範例執行手冊範本，讓您用來開始建置執行手冊。
```
# 執行手冊標題 ## 執行手冊資訊 | 執行手冊 ID | 描述 | 使用的工具 | 特殊許可 | 執行手冊作者 | 上次更新日期 | 呈報 POC | |-------|-------|-------|-------|-------|-------|-------| | RUN001 | 此執行手冊的用途為何？ 預期成果為何？ | 工具 | 許可 | 您的名稱 | 2022-09-21 | 呈報名稱 | ## 步驟 1.步驟一 2.步驟二
```
1. 如果您沒有現有的文件儲存庫或 Wiki，請在您的版本控制系統中建立新的版本控制儲存庫。
1. 識別沒有執行手冊的程序。經常執行、步驟數較少，且失敗的影響程度不高的程序，就是理想的程序。
1. 在您的文件儲存庫中，使用範本建立新的草稿 Markdown 文件。填入 `「執行手冊標題」` 和必要欄位 (在 `「執行手冊資訊」底下)`。
1. 從第一個步驟開始，填入執行手冊的 `「步驟」` 部分。
1. 將執行手冊提供給團隊成員。讓他們使用執行手冊來驗證步驟。如有任何事項缺漏或需要釐清，請更新執行手冊。
1. 將執行手冊發佈至您的內部文件存放區。發佈後，請告知團隊和其他利害關係人。
1. 一段時間後，您會建置執行手冊程式庫。隨著該程式庫的擴增，您應開始設法將執行手冊自動化。
**實作計劃的工作量：** 低。執行手冊的最低標準是逐步文字指南。將執行手冊自動化可能會增加實作工作量。
## 資源
**相關的最佳實務：**
+ [OPS02-BP02 已為流程和程序識別擁有者](ops_ops_model_def_proc_owners.md)：執行手冊應有擁有者負責加以維護。
+ [OPS07-BP04 使用程序手冊來調查問題](ops_ready_to_support_use_playbooks.md)：執行手冊和程序手冊兩者相類似，但有一項顯著差異：執行手冊有預期成果。在許多情況下，當程序手冊識別出根本原因時，就會觸發執行手冊。
+ [OPS10-BP01 使用程序進行事件、事故和問題管理](ops_event_response_event_incident_problem_process.md)：執行手冊是良好事件、事故和問題管理實務的一部分。
+ [OPS10-BP02 每個提醒建立一個程序](ops_event_response_process_per_alert.md)：執行手冊和程序手冊應用來回應提醒。一段時間後，這些因應動作應該要自動化。
+ [OPS11-BP04 知識管理](ops_evolve_ops_knowledge_management.md)：維護執行手冊是知識管理的重要環節。
**相關文件：**
+ [使用自動化的執行手冊和程序手冊達成卓越營運](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager：使用執行手冊](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [AWS 大型遷移的遷移程序手冊 - 任務 4：改進您的遷移執行手冊](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/task-four-migration-runbooks.html)
+ [使用 AWS Systems Manager 自動化執行手冊完成營運任務](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**相關影片：**
+ [AWS re:Invent 2019：執行手冊、事故報告和事故應變的 DIY 指南 (SEC318-R1)](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [如何使用 AWS \$1 Amazon Web Services 將 IT 營運自動化](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [將指令碼整合到 AWS Systems Manager 中](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**相關範例：**
+ [AWS Systems Manager：自動化演練](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [AWS Systems Manager：從最新的快照執行手冊還原根磁碟區](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-document-sample-restore.html)
+ [使用 Jupyter 筆記本和 CloudTrail Lake 建置 AWS 事故應變執行手冊](https://catalog.us-east-1.prod.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [Gitlab - 執行手冊](https://gitlab.com/gitlab-com/runbooks)
+ [Rubix - 用來在 Jupyter 筆記本中建置執行手冊的 Python 程式庫](https://github.com/Nurtch/rubix)
+ [使用 Document Builder 建立自訂執行手冊](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
+ [Well-Architected 實驗室：使用程序手冊和執行手冊將操作自動化](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
**相關服務：**
+ [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
# OPS07-BP04 使用程序手冊來調查問題
程序手冊是用來調查事件的逐步指南。事件發生時，我們會使用程序手冊來調查、確認影響範圍和找出根本原因。程序手冊可用於各種情境，從部署失敗到安全性事件皆涵蓋在內。在許多案例中，程序手冊可釐清根本原因，而執行手冊則用來緩解該根本原因。程序手冊是組織事件應變計劃的關鍵要素。
優良的程序手冊有幾個重要的特點。它會透過探索的過程來逐步引導使用者。請試著從各種角度思考，我們應遵循哪些步驟來診斷事件？ 透過程序手冊明確定義，在程序手冊中是否需要特殊工具或提高權限。制定溝通計劃，向利害關係人告知調查的最新狀態是關鍵要素。在無法釐清根本原因的狀況下，程序手冊應具備呈報計劃。如果已確定根本原因，程序手冊應指向執行手冊，後者會描述如何解決該根本原因。程序手冊應集中存放並定期維護。如果您使用程序手冊來發出特定警示，請為團隊提供警示中該程序手冊的指標。
隨著組織逐漸成熟，將程序手冊自動化。從涵蓋低風險事件的程序手冊開始。使用指令碼來自動化探索步驟。確保您有配套執行手冊來緩解常見的根本原因。
**預期成果：** 您的組織具備常見事件的程序手冊。該程序手冊存放在集中的位置，可供團隊成員使用。程序手冊會頻繁更新。對於任何已知的根本原因，都已建立配套執行手冊。
**常見的反模式：**
+ 調查事件並沒有標準的方法。
+ 團隊成員依賴肌肉記憶或機構知識，來針對失敗的部署進行疑難排解。
+ 新團隊成員會學習如何透過試錯來調查問題。
+ 各個團隊間並未共用調查問題的最佳實務。
**建立此最佳實務的優勢：**
+ 程序手冊可為您省下緩解事件所需的心力。
+ 不同的團隊成員可以使用相同的程序手冊，以一致的方式找出根本原因。
+ 您可以為已知的根本原因制定執行手冊，進而縮短復原時間。
+ 程序手冊可協助團隊成員更快開始做出貢獻。
+ 團隊可以透過可重複的程序手冊擴展其程序。
**若未建立此最佳實務，暴露的風險等級：** 中
## 實作指引
您如何根據組織的成熟度來建立和使用程序手冊。如果您剛接觸雲端，請在中央文件儲存庫中建立文字形式的程序手冊。隨著組織逐漸成熟，您就可以透過 Python 之類的指令碼語言將程序手冊半自動化。您可以在 Jupyter 筆記本中執行這些指令碼來加快探索速度。先進的組織具有全自動化的程序手冊，這些手冊適用於透過執行手冊自動修復的常見問題。
透過列出在您工作負載中發生的常見事件，來開始建立程序手冊。為低風險以及根本原因的範圍已縮減至幾個問題的事件選擇程序手冊，然後開始。在您為較簡單情境建立程序手冊後，請接著嘗試風險較高或尚未確定根本原因的情境。
隨著組織逐漸成熟，應將您的文字程序手冊自動化。使用諸如 [AWS Systems Manager Automations 的服務](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)，可以將一般文字轉換為自動化。您可以針對工作負載執行這些自動化來加快調查速度。您可以啟動這些自動化來回應事件、縮短事件探索和解決的平均時間。
客戶可使用 [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 來回應事件。此服務提供單一介面，來分類事件、在探索和緩解期間通知利害關係人，並在整個事件期間進行合作。其使用 AWS Systems Manager Automations 來加快偵測和復原速度。
**客戶範例**
生產事件會影響 AnyCompany Retail。待命的工程師使用程序手冊來調查問題。隨著透過步驟取得進展時，該工程師會確保程序手冊中識別的重要利害關係人都能了解最新進展。他發現根本原因是後端服務中的一項競賽條件。該工程師使用執行手冊，重新啟動服務，使 AnyCompany Retail 重新上線。
## 實作步驟
如果您沒有現有的文件儲存庫，我們建議為程序手冊程式庫建立版本控制儲存庫。您可以使用 Markdown 建立程序手冊，Markdown 與多數程序手冊自動化系統都相容。如果您是從頭開始建立，請使用以下範例程序手冊範本。
```
# Playbook Title ## Playbook Info | Playbook ID | Description | Tools Used | Special Permissions | Playbook Author | Last Updated | Escalation POC | Stakeholders | Communication Plan | |-------|-------|-------|-------|-------|-------|-------|-------|-------| | RUN001 | What is this playbook for? What incident is it used for? | Tools | Permissions | Your Name | 2022-09-21 | Escalation Name | Stakeholder Name | How will updates be communicated during the investigation? | ## Steps 1.Step one 2.Step two
```
1. 如果您沒有現有的文件儲存庫或 Wiki，請在版本控制系統中為程序手冊建立新的版本控制儲存庫。
1. 找出需要調查的常見問題。應存在根本原因僅限於幾個問題的情境，解決方案的風險很低。
1. 使用 Markdown 範本，填寫 `程序手冊名稱` 區段以及程序手冊資訊 `下的欄位`。
1. 填寫疑難排解步驟。盡可能清楚說明要執行哪些動作或應調查哪些地方。
1. 將程序手冊提供給團隊成員，讓成員透過該手冊來進行驗證。如果缺少任何資訊或內容不清楚，請更新程序手冊。
1. 在文件儲存庫中發佈程序手冊，並通知團隊和任何利害關係人。
1. 此程序手冊程式庫會隨著您新增更多程序手冊而成長。在您有數本程序手冊後，請開始使用 AWS Systems Manager Automations 之類的工具來進行自動化，進而確保自動化和程序手冊都能保持同步。
**實作計劃的工作量：** 低。程序手冊應為集中存放的文字文件。越來越多發展成熟的組織會開始自動化程序手冊。
## 資源
**相關的最佳實務：**
+ [OPS02-BP02 已為流程和程序識別擁有者](ops_ops_model_def_proc_owners.md)：程序手冊應有擁有者，擁有者會負責維護這類手冊。
+ [OPS07-BP03 使用執行手冊執行程序](ops_ready_to_support_use_runbooks.md)：執行手冊和程序手冊兩者相類似，但有一項顯著差異：執行手冊有預期成果。在許多情況下，當程序手冊找出根本原因時，就會使用執行手冊。
+ [OPS10-BP01 使用程序進行事件、事故和問題管理](ops_event_response_event_incident_problem_process.md)：程序手冊是正常事件、事故和問題管理實務的一部分。
+ [OPS10-BP02 每個提醒建立一個程序](ops_event_response_process_per_alert.md)：執行手冊和程序手冊應用來回應警示。一段時間後，應將這些因應措施自動化。
+ [OPS11-BP04 知識管理](ops_evolve_ops_knowledge_management.md)：維護程序手冊是知識管理的重要環節。
**相關文件：**
+ [ 使用自動化的執行手冊和程序手冊達成卓越營運 ](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager：使用執行手冊](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [ 使用 AWS Systems Manager Automation 執行手冊解決營運任務 ](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**相關影片：**
+ [AWS re:Invent 2019：執行手冊、事件報告和事件應變的 DIY 指南 (SEC318-R1) ](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [AWS Systems Manager Incident Manager - AWS 虛擬研討會 ](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [ 將指令碼整合到 AWS Systems Manager 中 ](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**相關範例：**
+ [AWS 客戶程序手冊架構 ](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS Systems Manager：自動化演練 ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [ 使用 Jupyter 筆記本和 CloudTrail Lake 建置 AWS 事件應變執行手冊 ](https://catalog.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [ Rubix - 用來在 Jupyter 筆記本中建置執行手冊的 Python 程式庫 ](https://github.com/Nurtch/rubix)
+ [ 使用 Document Builder 建立自訂執行手冊 ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
+ [ Well-Architected 實驗室：使用程序手冊和執行手冊將操作自動化 ](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
+ [ Well-Architected 實驗室：使用 Jupyter 事件應變程序手冊 ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
**相關服務：**
+ [AWS Systems Manager Automation ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
# OPS07-BP05 做出部署系統和變更的明智決策
評估團隊支援工作負載的能力以及工作負載對管控的遵從性。在確定是否轉換系統或將系統投入生產時，比照這些評估部署的收益。了解收益和風險，以做出明智決策。
事前剖析是一種演練，其中團隊會模擬失敗以開發緩解策略。使用事前剖析可預測失敗並適時建立程序。當您變更您用於評估工作負載的檢查清單時，請計劃如何處理不再合規的即時系統。
**常用的反模式：**
+ 在不了解工作負載中存在安全性風險的情況下，決定部署工作負載。
+ 在不了解工作負載是否符合您的管控和標準的情況下，決定部署工作負載。
+ 在不了解您的團隊是否能支援此工作負載的情況下，決定部署工作負載。
+ 在不了解工作負載對組織有何好處的情況下，決定部署工作負載。
**建立此最佳實務的優勢：** 擁有熟練的團隊成員可有效支援您的工作負載。
**若未建立此最佳實務，暴露的風險等級為：** 低
## 實作指引
+ 做出部署工作負載和變更的明智決策：評估團隊支援工作負載的能力以及工作負載對管控的合規性。在確定是否轉換系統或將系統投入生產時，比照這些評估部署的收益。了解收益和風險，並做出明智的決策。