# 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 が開発した仕組みの 1 つで、チームがワークロードを安全に運用できることを検証します。ORR は、要件のチェックリストを使用したレビューおよび検証プロセスです。ORR は、ワークロードの検証をチームが自分たちで行うことができるセルフサービスエクスペリエンスです。ORR には、Amazon がソフトウェアを開発する中で学んだ知識や経験に基づくベストプラクティスが含まれます。
ORR チェックリストは、アーキテクチャレコメンデーション、運用プロセス、イベント管理、リリース品質によって構成されます。Amazon のエラーの修正 (CoE) プロセスは、主にこれらの項目によって推進されます。組織の ORR の発展を推進するには、独自のインシデント後の分析を使用する必要があります。ORR はベストプラクティスに従うためだけでなく、過去に経験したイベントの再発を防ぐためのものです。また、セキュリティ、ガバナンス、コンプライアンスの各要件も ORR に含めることができます。
ワークロードの一般提供前に ORR を実施し、その後はソフトウェア開発ライフサイクルをとおして実施し続けます。ワークロードのローンチ前に ORR を実施することで、ワークロードをより安全に運用することができます。ORR をワークロードで定期的に実施することで、ベストプラクティスからの逸脱を検知することができます。ORR チェックリストは、新しいサービスのローンチや、ORR の定期的なレビューに使用できます。そうすることで、新しいベストプラクティスに沿って更新したり、インシデント後の分析で学んだ知識や経験を反映したりできます。クラウドの使用に慣れていくにしたがって、組織のアーキテクチャのデフォルトの要件として ORR を組み込むことができます。
**期待される成果:** 組織にはベストプラクティスを含む ORR チェックリストがあります。ORR はワークロードのローンチ前に実施されます。ORR はワークロードライフサイクルを通じて定期的に実施されます。
**一般的なアンチパターン:**
+ 運用できるかどうか不明なままワークロードをローンチする。
+ ガバナンスおよびセキュリティ要件は、ワークロードのローンチ要件に含まれていない。
+ ワークロードは定期的に評価されていない。
+ 必要な手続きなしでワークロードがローンチされる。
+ 複数のワークロードで同じ根本原因の故障が繰り返される。
**このベストプラクティスを活用するメリット:**
+ 組織のワークロードには、アーキテクチャ、プロセス、および管理のベストプラクティスが含まれる。
+ 学んだ知識や経験は ORR プロセスに反映される。
+ 必要な手続きでワークロードがローンチされる。
+ ORR はワークロードのソフトウェアライフサイクルを通じて実施される。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
ORR は、プロセスとチェックリストの 2 つの要素で構成されます。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. 各関係者に少なくとも 1 つの要件を提供してもらいます。初回に提供される要件は、30 項目以下に制限します。
+ [付録 B: 運用準備状況の確認 (ORR) に関する](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html) ホワイトペーパーの ORR 質問の例には、使用できるいくつかの質問の例が含まれています。
1. 要件をスプレッドシートにまとめます。
+ ここでは AWS Well-Architected Tool の [カスタムレンズを](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) 使用して [ ORR を作成し、](https://console.aws.amazon.com/wellarchiected/) アカウントや AWS 組織全体で共有することができます。
1. ORR を実施するワークロードを 1 つ選びます。ローンチ前のワークロード、または内部ワークロードが理想的です。
1. ORR チェックリストを実施し、発見した事柄をメモします。定められた緩和がある場合、発見は問題になる可能性があります。緩和が定められていない発見については、対応予定の項目に追加して、ローンチ前に対応を実施します。
1. 時間の経過とともに、ベストプラクティスや要件を ORR に継続的に追加します。
エンタープライズサポートのある サポート の顧客は、 [運用準備状況の確認に関するワークショップ](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)
+ [ ORR を作成し、](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html)
# OPS07-BP03 ランブックを使用して手順を実行する
A *ランブック* は、特定の成果を達成するために文書化されたプロセスです。ランブックは一連のステップから成り、それをたどることでプロセスを完了できます。ランブックは、飛行機の黎明期から運用に使用されてきました。クラウド運用では、ランブックを使用してリスクを削減し、望ましい成果を達成します。端的に言うと、ランブックはタスクを完了するためのチェックリストです。
ランブックは、ワークロードを運用するための不可欠の一部です。新しいチームメンバーのオンボーディングからメジャーリリースのデプロイまで、ランブックは、使用者に関係なく、一定の成果をもたらすように成文化されたプロセスです。ランブックの更新は変更管理プロセスの重要な要素であるため、ランブックは一箇所で公開し、プロセスの進化に合わせて更新する必要があります。また、エラー処理、ツール、アクセス許可、例外、問題発生時のエスカレーションに関するガイダンスを含める必要があります。
組織が成熟してきたら、ランブックの自動化を始めましょう。短く、頻繁に使用されるランブックから始めます。スクリプト言語を使用して、ステップを自動化するか、ステップを実行しやすくします。最初のいくつかのランブックを自動化したら、より複雑なランブックを自動化するために時間を割くようにします。やがて、ほとんどのランブックが何らかの方法で自動化されるはずです。
**期待される成果:** チームには、ワークロードのタスクを実行するためのステップバイステップのガイド集があります。ランブックには、期待される成果、必要なツールとアクセス許可、エラー処理に関する指示が含まれています。一箇所に保管され、頻繁に更新されます。
**一般的なアンチパターン:**
+ プロセスの各ステップの完了を記憶に頼る。
+ チェックリストなしで、変更を手動でデプロイする。
+ 異なるチームメンバーが同じプロセスを実行しても、手順や結果が異なる。
+ システムの変更や自動化に伴い、ランブックの同期がとれなくなる
**このベストプラクティスを活用するメリット:**
+ 手動タスクのエラー率を削減します。
+ 運用が一貫した方法で実行されます。
+ 新しいチームメンバーがタスクの実行をすぐに始められます。
+ ランブックの自動化により、苦労を減らすことができます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
ランブックは、組織の成熟度に応じて、いくつかの形態をとります。少なくとも、ステップバイステップのテキスト文書で構成されている必要があります。期待される成果が明確に示されている必要があります。必要な特殊なアクセス許可やツールを明確に文書化します。問題発生時にエラー処理とエスカレーションに関する詳細なガイダンスを提供します。ランブックの所有者をリストアップし、一元的な場所で公開します。ランブックが文書化されたら、チームの別のメンバーに使用してもらって検証します。プロセスの進化につれて、変更管理プロセスに従ってランブックを更新します。
組織が成熟するにつれて、テキストのランブックは自動化されるはずです。例えば、 [AWS Systems Manager オートメーション](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)などのサービスを使用すると、フラットなテキストを、ワークロードに対して実行可能なオートメーションに変換できます。これらのオートメーションはイベントに反応して実行でき、ワークロードを保守する運用上の負担が軽減されます。
**顧客の事例**
AnyCompany Retail は、ソフトウェアのデプロイ時にデータベーススキーマの更新を行う必要があります。クラウド運用チームはデータベース管理チームと協力して、これらの変更を手動でデプロイするためのランブックを作成しました。ランブックには、プロセスの各ステップがチェックリスト形式で記載されました。問題発生時のエラー処理のセクションも含まれています。このランブックは、他のランブックとともに社内 Wiki で公開されました。クラウド運用チームは、将来のスプリントでランブックを自動化する予定です。
## 実装手順
既存のドキュメントリポジトリがない場合、バージョン管理リポジトリはランブックライブラリの構築を始める場所として最適です。ランブックは Markdown を使用して作成できます。ランブック作成の開始に使用できるサンプルのランブックテンプレートを提供しています。
```
# ランブックタイトル ## ランブック情報 | ランブック ID | 説明 | 使用ツール | 特別なアクセス許可 | ランブック作成者 | 最終更新日 | エスカレーション POC | |-------|-------|-------|-------|-------|-------|-------| | RUN001 | このランブックの目的 期待される成果 | ツール | アクセス許可 | ユーザー名 | 2022 年 9 月 21 日 | エスカレーション名 | ## ステップ 1。ステップ 1 2。ステップ 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): ランブックとプレイブックは似ていますが、1 つだけ違うのは、ランブックには期待される成果があることです。多くの場合、プレイブックが根本原因を特定すると、ランブックがトリガーさ れます。
+ [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 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 \$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 Notebook と 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 Notebook でランブックを作成するための 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 Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
# OPS07-BP04 プレイブックを使用して問題を調査する
プレイブックは、インシデントの調査に使用するステップバイステップガイドです。インシデントが発生した際は、プレイブックを使用して調査を行い、影響の範囲と根本原因を特定します。プレイブックは、デプロイの失敗からセキュリティインシデントに至るまで、さまざまなシナリオで使用されます。ランブックを使用して緩和する根本原因は、多くの場合プレイブックによって特定します。プレイブックは、組織のインシデント対応計画の基幹的なコンポーネントです。
優れたプレイブックには、いくつかの重要な特徴があります。プレイブックは検出プロセスにおける各手順をユーザーに示します。外側から内側への思考を使って、インシデントの診断に必要な手順を示します。 特別なツールやより高い権限が必要な場合は、プレイブックで明確に定義します。インシデント調査のステータスを関係者と共有するためのコミュニケーションプランの策定は重要なコンポーネントです。根本原因を特定できない場合に備え、プレイブックにはエスカレーションプランが必要です。根本原因を特定できる場合、プレイブックは問題の解決方法が記載されているランブックを示す必要があります。プレイブックは一元的に保管し、定期的に更新する必要があります。特定のアラートにプレイブックを使用する場合、使用すべきプレイブックをアラート内でチームに示します。
組織が成熟するにしたがって、プレイブックを自動化します。最初に、低リスクインシデント用のプレイブックを作成します。スクリプトを使用して検出手順を自動化します。一般的な根本原因を緩和するための関連するランブックも作成します。
**期待される成果:** 組織には一般的なインシデントに対するプレイブックがあります。プレイブックは一元的に保管され、チームメンバーに提供されます。プレイブックは頻繁に更新されます。既知の根本原因については、関連するランブックが作成されています。
**一般的なアンチパターン:**
+ インシデントを調査する標準的な方法はない。
+ チームメンバーは過去の経験や社内で蓄積した知識に基づいて、失敗したデプロイの問題を解決している。
+ 新しいチームメンバーは、トライアンドエラーを通じて問題の調査方法を学んでいる。
+ 問題調査のベストプラクティスは、チーム間で共有されていない。
**このベストプラクティスを活用するメリット:**
+ プレイブックはインシデント緩和の工数を削減します。
+ さまざまなチームメンバーが同じプレイブックを使って、一貫した方法で根本原因の特定を行えます。
+ 既知の根本原因にはランブックが用意されており、復旧時間を短縮できます。
+ プレイブックによって、新しいチームメンバーはすぐにチームに貢献できるようになります。
+ 繰り返し使用可能なプレイブックを持つことで、チームはプロセスをスケールすることができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 中
## 実装のガイダンス
プレイブックの作成方法と使用方法は、組織の成熟度によって異なります。組織がクラウドに慣れていない場合、文章によるプレイブックを作成し、中央ドキュメントリポジトリに保管します。組織が成熟するにしたがって、Python などのスクリプト言語を使用して、プレイブックを半自動化できます。これらのスクリプトは Jupyter Notebook 内で実行でき、復旧を迅速化します。高度な組織では、一般的な問題のプレイブックを完全に自動化し、ランブックを使用して自動的に問題を緩和します。
プレイブックの作成は、組織のワークロードで発生する一般的なインシデントを一覧化することから始めます。最初に、根本原因がいくつかの問題に絞られている、低リスクインシデント用のプレイブックを作成します。シンプルなシナリオ用のプレイブックの作成後、高リスクシナリオや根本原因があまり知られていないシナリオ用のプレイブックを作成します。
組織が成熟するにつれて、文章によるプレイブックを自動化します。例えば、 [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 はプレイブックに記載されている主要な関係者と情報を共有し続けました。エンジニアは、根本原因がバックエンドサービス内の競合状態であることを特定しました。エンジニアはランブックを使用してサービスを再起動し、AnyCompany Retail をオンライン状態に戻しました。
## 実装手順
既存のドキュメントリポジトリがない場合、プレイブックライブラリ用のバージョン管理リポジトリを作成することをお勧めします。プレイブックは Markdown を使用して作成できます。Markdown は、ほとんどのプレイブック自動化システムとの互換性を持っています。プレイブックを一から作成する場合、以下のプレイブックテンプレートの例を使用します。
```
# プレイブックタイトル ## プレイブック情報 | プレイブック ID | 説明 | 使用されるツール | 特別な権限 | プレイブックの作成者 | 最終更新日 | エスカレーション POC | 関係者 | コミュニケーションプラン | |-------|-------|-------|-------|-------|-------|-------|-------|-------| | RUN001 | プレイブックの目的は何か? どのインシデントに使用するか? | ツール | 権限 | 自分の名前 | 2022-09-21 | エスカレーション名 | 関係者名 | 調査中の情報更新の通知方法は? | ## 手順 1.手順 1 2手順 2
```
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): ランブックとプレイブックは似ていますが、重要な違いが 1 つあり、それはランブックには期待される成果があることです。多くの場合、ランブックは、プレイブックで根本原因を特定したときに使用されます。
+ [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 Notebook と CloudTrail Lake を使用して、AWS インシデント対応ランブックを作成する ](https://catalog.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [ Rubix - Jupyter Notebook でランブックを作成するための 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 システムや変更をデプロイするために十分な情報に基づいて決定を下す
ワークロードと、ワークロードのガバナンスとのコンプライアンスをサポートするためにチームの能力を評価します。システムを移行するか、本番環境に変更するかどうかを判断する際に、これらをデプロイの利点に対して評価します。メリットとリスクを理解し、十分な情報に基づく決定を下します。
プレモータムは、チームが行う演習で、ここでは軽減戦略を策定するために障害のシミュレーションを行います。プレモータムを使用して、障害を予測し、必要に応じて手順を作成します。ワークロードを評価するために使用するチェックリストに変更を加える場合は、もう準拠していない本番システムで行うことを計画します。
**一般的なアンチパターン:**
+ ワークロードに存在するセキュリティリスクを理解することなく当該ワークロードのデプロイを決定する。
+ ワークロードがガバナンスと標準に準拠しているかどうかを理解することなく当該ワークロードのデプロイを決定する。
+ チームがサポートできるかどうかを理解することなくワークロードのデプロイを決定する。
+ 組織にどのようなメリットがあるかを理解することなくワークロードのデプロイを決定する。
**このベストプラクティスを活用するメリット:** スキルのあるチームメンバーを持つことで、ワークロードを効果的にサポートできます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ ワークロードや変更をデプロイするために十分な情報に基づいて決定を下す: ワークロードと、ワークロードのガバナンスとのコンプライアンスをサポートするためにチームの能力を評価します。システムを移行するか、本番環境に変更するかどうかを判断する際に、これらをデプロイの利点に対して評価します。メリットとリスクを理解し、十分な情報に基づく決定を下します。