# 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-BP06 建立生產工作負載的支援計劃
](ops_ready_to_support_enable_support_plans.md)
# OPS07-BP01 確保人員能力
建立一種機制，用於驗證您有適當數量受過培訓的人員來支援工作負載。他們必須受過組成您的工作負載的平台和服務的培訓。為他們提供操作工作負載所需的知識。您必須擁有足夠受過培訓的人員，才能支援工作負載的一般操作，並且針對會發生的任何事件進行疑難排解。擁有足夠的人員，以便您可以輪替待命和休假的人員，避免倦怠。
**預期成果：**
+ 有足夠受過培訓的人員可以在工作負載可用時支援工作負載。
+ 您為人員提供組成您的工作負載的軟體和服務的培訓。
**常見的反模式：**
+ 在沒有受過培訓操作使用中平台和服務的團隊成員之情況下，部署工作負載。
+ 沒有足夠的人員可以支援待命輪替或人員休假。
**建立此最佳實務的優勢：**
+ 擁有熟練的團隊成員有助於有效支援您的工作負載。
+ 具有足夠的團隊成員，您可以支援工作負載和待命輪替，同時降低倦怠風險。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
驗證人員是否已經過充分培訓，可支援工作負載。確認擁有足夠且訓練有素的團隊成員，以妥善應對一般營運活動，包括待命輪替。
**客戶範例**
AnyCompany Retail 確保支援工作負載的團隊有適當的配備人員且訓練有素。他們有足夠的工程師可以支援待命輪替。人員會獲得工作負載建置基礎的軟體和平台的培訓，並且鼓勵他們考取認證。有足夠的人員讓員工可以休假，同時仍然支援工作負載和待命輪替。
### 實作步驟
1. 指派足夠的人員來操作和支援工作負載，包括待命職責、安全問題和生命週期事件，例如終止支援和憑證輪換任務。
1. 為您的人員提供組成您的工作負載的軟體和平台的培訓。
1. [AWS 培訓和認證](https://aws.amazon.com/training/)有一個關於 AWS 的課程庫。它們提供免費和付費的線上或面授課程。
1. [AWS 舉辦活動和網路研討會](https://aws.amazon.com/events/)，您可向 AWS 專家學習。
1. 定期執行下列工作：
+ 隨著操作條件和工作負載變更，評估團隊規模和技能。
+ 調整團隊大小和技能以符合操作要求。
+ 透過 AWS Health 驗證[處理規劃的生命週期事件](https://docs.aws.amazon.com/health/latest/ug/aws-health-planned-lifecycle-events.html)、意外的安全性和操作通知的能力和容量。
**實作計劃的工作量：**高。招聘和培訓團隊來支援工作負載需要大量的努力，但是會有重大的長期優點。
## 資源
**相關的最佳實務：**
+ [OPS11-BP04 執行知識管理](ops_evolve_ops_knowledge_management.md) - 團隊成員必須擁有操作和支援工作負載所需的資訊。知識管理是提供這項能力的關鍵。
**相關文件：**
+ [AWS 活動和研討會](https://aws.amazon.com/events/)
+ [AWS 培訓和認證](https://aws.amazon.com/training/)
# 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 Guardrails](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. 請每位利益相關者提供至少一個需求。對於第一次的反覆測試，請嘗試將項目數限制在三十個以下。
+ 《營運準備度審查 (ORR)》白皮書的[附錄 B：ORR 問題範例](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html)包含您可以開始使用的範例問題。
1. 將需求集中放在試算表中。
+ 您可以在 [AWS Well-Architected Tool](https://console.aws.amazon.com/wellarchiected/) 中使用[自訂聚焦](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)來開發 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)
+ [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html)
# OPS07-BP03 使用執行手冊執行程序
*執行手冊*是為了達成特定成果而記錄的程序。執行手冊由一系列可供遵循以完成某項工作的步驟組成。早在航空業早期，就已使用執行手冊。在雲端操作中，我們使用執行手冊來降低風險及達到預期成果。簡言之，執行手冊就是完成一項工作的檢查清單。
執行手冊是操作工作負載的重要組成部分。從新團隊成員入職到部署重大版本，執行手冊是經過編纂的流程，無論誰使用這些執行手冊，都能提供一致的成果。應該在中央位置發佈執行手冊，並隨著流程的發展進行更新，因為更新執行手冊是變更管理流程的關鍵組成部分。它們還應該包括當發生問題時有關錯誤處理、工具、權限、異常以及向上呈報的指引。
隨著組織的成熟，開始自動化執行手冊。從簡短且經常使用的執行手冊開始。使用指令碼語言來自動化步驟或讓步驟更容易執行。當您自動化前幾個執行手冊時，將花費時間來自動化更複雜的執行手冊。隨著時間的推移，大多數執行手冊都應該以某種方式自動化。
**預期成果：**您的團隊擁有一系列用於執行工作負載任務的分步指南。執行手冊中包含預期成果、必要的工具和許可，以及錯誤處理指示。它們會集中存放 (版本控制系統)，並且經常更新。例如，執行手冊可讓您的團隊在應用程式警示、操作問題和計劃的生命週期事件期間監控、溝通和回應關鍵帳戶的 AWS Health 事件。
**常見的反模式：**
+ 依靠記憶體來完成流程的每個步驟。
+ 手動部署變更，無須檢查清單。
+ 不同的團隊成員執行相同的過程，但具有不同的步驟或成果。
+ 讓執行手冊脫離系統變更和自動化。
**建立此最佳實務的優勢：**
+ 降低手動任務的錯誤率。
+ 以一致的方式執行操作。
+ 新的團隊成員可以更快地開始執行任務。
+ 可以自動化執行手冊以減少辛勞。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
執行手冊可以根據組織的成熟度等級採用多種形式。至少，其中應包含一個循序漸進的文字文件。應明確指出預期成果。清楚記錄必要的特殊權限或工具。如果發生問題，提供有關錯誤處理和呈報的詳細指引。列出執行手冊擁有者並將其發佈在中央位置。執行手冊被記錄下來之後，透過讓團隊中的其他人執行它來進行驗證。隨著程序的發展，請根據您的變更管理流程來更新執行手冊。
隨著組織的成熟，應自動化文字執行手冊。使用 [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 等服務，可以將純文字轉換為可針對工作負載執行的自動化功能。可以執行這些自動化功能以回應事件，減少維護工作負載的操作負擔。AWSSystems Manager Automation 也提供低程式碼的[視覺化設計體驗](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-visual-designer.html)，以便更輕鬆地建立自動化執行手冊。
**客戶範例**
AnyCompany Retail 必須在軟體部署期間執行資料庫結構描述更新。雲端操作團隊與資料庫管理團隊合作，建立用於手動部署這些變更的執行手冊。執行手冊以檢查清單的形式列出流程中的每個步驟。它包括發生問題時關於錯誤處理的部分。他們在其內部 wiki 中發布該執行手冊以及其他執行手冊。雲端操作團隊計劃在未來的衝刺中自動化該執行手冊。
### 實作步驟
如果您沒有現有的文件儲存庫，版本控制儲存庫是開始建置執行手冊庫的好地方。可以使用 Markdown 來構建執行手冊。我們提供了一個執行手冊範本範例，您可以使用它來開始構建執行手冊。
```
# Runbook Title
## Runbook Info
| Runbook ID | Description | Tools Used | Special Permissions | Runbook Author | Last Updated | Escalation POC |
|-------|-------|-------|-------|-------|-------|-------|
| RUN001 | What is this runbook for? What is the desired outcome? | Tools | Permissions | Your Name | 2022-09-21 | Escalation Name |
## Steps
1. Step one
2. Step two
```
1. 如果您沒有現有的文件儲存庫或 wiki，請在版本控制系統中建立新的版本控制儲存庫。
1. 識別沒有執行手冊的流程。理想的流程是半定期執行，步驟數量少，並且具有低影響故障。
1. 在文件儲存庫中，使用範本建立新的 Markdown 草稿文件。填寫執行手冊標題和執行手冊資訊下的必填欄位。
1. 從第一個步驟開始，填寫執行手冊的「步驟」部分。
1. 將執行手冊交給團隊成員。讓他們使用執行手冊來驗證步驟。如果缺少某些內容或需要澄清，請更新執行手冊。
1. 將執行手冊發佈到您的內部文件存放區。發布後，告知您的團隊和其他利益相關者。
1. 隨著時間的推移，您將建置執行手冊的程式庫。隨著程式庫的增長，開始努力自動化執行手冊。
**實作計劃的工作量：**低。執行手冊的最低標準是循序漸進的文字指南。自動化執行手冊可以增加實作工作量。
## 資源
**相關的最佳實務：**
+ [OPS02-BP02 流程和程序已識別擁有者](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS07-BP04 使用程序手冊調查問題](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html)
+ [OPS10-BP01 使用程序進行事件、事故和問題管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
+ [OPS10-BP02 每個提醒建立一個程序](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_process_per_alert.html)
+ [OPS11-BP04 執行知識管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**相關文件：**
+ [使用自動化程序手冊和執行手冊實現卓越的營運](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 Automation 執行手冊來解決操作任務](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**相關影片：**
+ [AWS re:Invent 2019：執行手冊、事件報告和事件回應的 DIY 指南](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [如何在 AWS 上自動執行 IT 操作 \$1 Amazon Web Services](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [將指令碼整合到 AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**相關範例：**
+ [Well-Architected 實驗室：使用程序手冊和執行手冊將操作自動化](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
+ [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 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)
+ [使用文件建置器建立自訂執行手冊](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
**相關服務：**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
# OPS07-BP04 使用程序手冊來調查問題
*程序手冊*是用來調查事件的逐步指南。事件發生時，我們會使用程序手冊來調查、確認影響範圍和找出根本原因。程序手冊適用於各種情況，從失敗的部署到安全性事故。在許多案例中，程序手冊可釐清根本原因，而執行手冊則用來緩解該根本原因。程序手冊是組織事件應變計劃的關鍵要素。
一個好的程序手冊有幾個關鍵功能。它循序漸進地引導使用者完成探索過程。從外到內思考，應該遵循哪些步驟來診斷事件？ 在程序手冊中明確定義程序手冊中是否需要特殊工具或更高權限。制定溝通計劃，向利益相關者通報調查進展情況，這非常關鍵。在無法確定根本原因的情況下，程序手冊應具有升級計劃。如果確定了根本原因，程序手冊應該指向說明如何解決問題的執行手冊。程序手冊應集中存放並定期維護。如果程序手冊用於特定提醒，請在提醒中為您的團隊提供指向程序手冊的指引。
隨著組織的成熟，會將您的程序手冊自動化。從涵蓋低風險事件的程序手冊開始。使用指令碼自動執行探索步驟。確認您有配套的執行手冊來減輕常見根本原因。
**預期成果：**您的組織擁有常見事件的程序手冊。程序手冊存放在中心位置，並可供您的團隊成員使用。程序手冊會經常更新。對於任何已知的根本原因，都會構建配套的執行手冊。
**常見的反模式：**
+ 調查事件沒有標準方法。
+ 團隊成員依賴肌肉記憶或機構知識來疑難排解失敗的部署。
+ 新團隊成員學習如何透過試驗和錯誤來調查問題。
+ 調查問題的最佳實務不會跨團隊共用。
**建立此最佳實務的優勢：**
+ 程序手冊可加強您減輕事故的努力。
+ 不同的團隊成員可以使用相同的程序手冊，以一致的方式識別根本原因。
+ 您可以為已知的根本原因制定執行手冊，進而縮短復原時間。
+ 程序手冊有助於團隊成員更快地開始做出貢獻。
+ 團隊可以透過可重複的程序手冊擴展其程序。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
建置和使用程序手冊的方式取決於組織的成熟度。如果您是雲端新手，請在中央文件儲存庫中以文字形式建立程序手冊。隨著組織的成熟，程序手冊可以使用 Python 之類的指令碼語言進行半自動化。這些指令碼可以在 Jupyter 筆記本內部運行，以加快發現速度。進階組織具有完全自動化的程序手冊，可解決使用執行手冊自動修復的常見問題。
列出工作負載發生的常見事件，開始建置程序手冊。為低風險並且根本原因已縮小到幾個問題的事件選擇程序手冊以開始。在您擁有更簡單案例的程序手冊之後，請轉到風險較高的案例或根本原因尚不明確的案例。
隨著組織的成熟，應自動化文字程序手冊。使用 [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) 來回應事故。此服務提供單一介面來分類事故、在發現和緩解期間通知利益相關者，並在整個事故中進行協同合作。它使用 AWS Systems Manager Automation 來加速偵測和復原。
**客戶範例**
生產事故影響了 AnyCompany Retail。隨時待命的工程師使用程序手冊來調查問題。隨著他們逐步完成這些步驟，他們會讓程序手冊中確定的關鍵利益相關者了解最新狀況。工程師將根本原因確定為後端服務中的競爭條件。使用執行手冊，工程師重新啟動了服務，使 AnyCompany Retail 重新上線。
### 實作步驟
如果您沒有現有的文件儲存庫，建議您為程序手冊庫建立版本控制儲存庫。您可以使用 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 Automation 等工具開始進行自動化，讓自動化和程序手冊保持同步。
**實作計劃的工作量：**低。您的程序手冊應該是存放在中央位置的文字文件。更成熟的組織將推進程序手冊自動化。
## 資源
**相關的最佳實務：**
+ [OPS02-BP02 流程和程序已識別擁有者](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS07-BP03 使用執行手冊執行程序](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html)
+ [OPS10-BP01 使用程序進行事件、事故和問題管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
+ [OPS10-BP02 每個提醒建立一個程序](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_process_per_alert.html)
+ [OPS11-BP04 執行知識管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**相關文件：**
+ [使用自動化程序手冊和執行手冊實現卓越的營運](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)
+ [使用文件建置器建立自訂執行手冊](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
**相關服務：**
+ [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 做出部署系統和變更的明智決策
為成功和失敗的工作負載變更建立程序。事前剖析是一種演練，團隊可藉此模擬失敗，制定緩解策略。使用事前剖析可預測失敗並適時建立程序。評估將變更部署到您的工作負載的優點和風險。確認所有變更都符合管控。
**預期成果：**
+ 您在將變更部署到您的工作負載時做出明智決策。
+ 變更符合管控。
**常見的反模式：**
+ 將變更部署到我們的工作負載，而沒有處理失敗部署的程序。
+ 對不符合管控要求的生產環境進行變更。
+ 部署新版本的工作負載，而未建立資源使用率的基準。
**建立此最佳實務的優勢：**
+ 您對工作負載的失敗變更已做好準備。
+ 變更您的工作負載符合管控政策。
**未建立此最佳實務時的曝險等級：**低
## 實作指引
使用事前剖析來開發失敗變更的程序。記載失敗變更的程序。確定所有變更都符合管控。評估將變更部署到您的工作負載的優點和風險。
**客戶範例**
AnyCompany Retail 定期執行事前剖析來驗證他們失敗變更的程序。他們在共用 Wiki 中記載程序並且頻繁更新。所有變更都符合管控要求。
**實作步驟**
1. 在將變更部署到您的工作負載時做出明智決策。建立及審核成功部署的準則。開發會啟動變更回復的情境或準則。權衡部署變更的優點與失敗變更的風險。
1. 確認所有變更都符合管控政策。
1. 使用事前剖析為失敗變更進行規劃並且記載緩解策略。執行桌上模擬演練來建立失敗變更的模型，並且驗證回復程序。
**實作計劃的工作量：**中。實作事前剖析的實務需要貴組織利益相關者的協調和努力
## 資源
**相關的最佳實務：**
+ [OPS01-BP03 評估治理要求](ops_priorities_governance_reqs.md) - 管控要求是判斷是否部署變更的關鍵因素。
+ [OPS06-BP01 計畫變更失敗](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) - 建立計畫來緩解失敗的部署並且使用事前剖析來進行驗證。
+ [OPS06-BP02 測試部署](ops_mit_deploy_risks_test_val_chg.md) - 每個軟體變更都應該在部署之前先適當的進行測試，以便在生產中減少缺陷。
+ [OPS07-BP01 確保人員能力](ops_ready_to_support_personnel_capability.md) - 擁有支援工作負載的足夠受過培訓的人員，對於為部署系統變更做出明智決策相當重要。
**相關文件：**
+ [Amazon Web Services：風險與合規](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/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/)
# OPS07-BP06 建立生產工作負載的支援計劃
針對您的生產工作負載所依賴的任何軟體和服務啟用支援。根據您的生產服務層級需求選取適當的支援等級。這些相依性的支援計劃的存在有其必要性，以便應對服務中斷或軟體問題。記錄支援計劃，以及如何要求所有服務和軟體供應商的支援。實作相關機制以確認支援的聯絡窗口是最新的。
**預期成果：**
+ 為生產工作負載所依賴的軟體和服務實作支援計劃。
+ 根據服務層級需求選擇適當的支援計劃。
+ 記錄支援計劃、支援等級，以及如何要求支援。
**常見的反模式：**
+ 您沒有主要軟體供應商的支援計劃。您的工作負載因此受到影響，且您無法加速進行修正，或及時獲得供應商提供的更新。
+ 擔任軟體供應商主要聯絡窗口的開發人員已離開公司。您無法直接聯繫供應商支援人員。您必須花時間研究及瀏覽通用聯絡系統，因此必要時的回應將更為耗時。
+ 軟體供應商發生生產中斷。目前沒有文件說明如何提出支援案例。
**建立此最佳實務的優勢：**
+ 透過適當的支援等級，您將可在必要的時間範圍內獲得回應以滿足服務層級需求。
+ 受支援的客戶可在遇到生產問題時加以呈報。
+ 軟體和服務供應商可在事件發生期間協助進行疑難排解。
**未建立此最佳實務時的曝險等級：**低
## 實作指引
針對您的生產工作負載所依賴的任何軟體和服務供應商啟用支援計劃。設定適當的支援計劃以滿足服務層級需求。對於 AWS 客戶而言，這意味著在任何有生產工作負載的帳戶上啟動 AWS Business Support 或更高等級。定期與支援供應商聯繫，取得關於支援優惠、程序和聯絡人的更新。記錄如何要求軟體和服務供應商的支援，包括如何在中斷發生時加以呈報。實作相關機制以保有最新的支援聯絡資料。
**客戶範例**
在 AnyCompany Retail，所有商業軟體和服務相依性都有支援計劃。例如，他們在所有具有生產工作負載的帳戶上啟動了 AWS Enterprise Support。任何開發人員都可在問題發生時提出支援案例。有 Wiki 頁面提供了相關資訊說明如何要求支援、應通知誰，以及加速處理案例的最佳實務為何。
**實作步驟**
1. 與組織中的利益相關者合作，識別您的工作負載所依賴的軟體和服務供應商。記錄這些相依性。
1. 確認工作負載的服務層級需求。選取相對應的支援計劃。
1. 針對商業軟體和服務，與供應商共同建立支援計劃。
1. 為所有生產帳戶訂閱 AWS Business Support 或更高等級可獲得 AWS 支援 更快的回應時間，極力建議這麼做。如果您沒有付費支援，則必須有處理問題的行動計劃，而這需要 AWS 支援 的協助。AWS 支援 提供了多種工具和技術、人員及方案，旨在主動協助您最佳化效能、降低成本和加快創新速度。此外，AWS Business Support 提供額外的權益，包括透過 API 存取 AWS Trusted Advisor 和 AWS Health，以便與您的系統進行程式設計整合，以及其他存取方法，例如 AWS 管理主控台 和 Amazon EventBridge 管道。
1. 在您的知識管理工具中記錄支援計劃。納入如何要求支援、在提出支援案例時應通知誰，以及在事件發生時如何加以呈報等資訊。任何人在得知支援程序或聯絡資料有所變更時，都可以利用 Wiki 這項機制對文件進行必要的更新。
**實作計劃的工作量：**低。大部分的軟體和服務供應商都提供選擇加入支援計劃。在您的知識管理系統上記錄並分享支援最佳實務，可確保您的團隊知道在生產問題發生時應如何因應。
## 資源
**相關的最佳實務：**
+ [OPS02-BP02 流程和程序已識別擁有者](ops_ops_model_def_proc_owners.md)
**相關文件：**
+ [AWS 支援 計劃](https://docs.aws.amazon.com/awssupport/latest/user/aws-support-plans.html)
**相關服務：**
+ [AWS 商業支援](https://aws.amazon.com/premiumsupport/plans/business/)
+ [AWS 企業支援](https://aws.amazon.com/premiumsupport/plans/enterprise/)