# 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 人材能力の確保 OPS07-BP01 人材能力の確保 トレーニングを受けた、ワークロードをサポートするための適切な人数の従業員が配置されていることを検証するメカニズムを導入します。担当者は、ワークロードを構成するプラットフォームとサービスについてのトレーニングを受けている必要があります。ワークロードのオペレーションに必要となるナレッジを提供します。ワークロードの通常の運用サポートと発生したインシデントのトラブルシューティングを行うために、十分な人数のトレーニングを受けた人材が必要です。人員の疲弊を避けるため、オンコール対応と休暇を考慮に入れたローテーションを組むうえで十分な人材を配置します。 **期待される成果:** + ワークロードが利用可能な間、ワークロードのサポートを担当する、十分なトレーニングを受けた人材が確保されています。 + ワークロードを構成するソフトウェアとサービスについて、担当者にトレーニングを提供しています。 **一般的なアンチパターン:** + 使用中のプラットフォームとサービスを運用するにあたって、トレーニングを受けたチームメンバーなしでワークロードをデプロイします。 + オンコール対応と人材の休暇を考慮したローテーションを行ううえで十分な人材が不足しています。 **このベストプラクティスを活用するメリット:** + スキルのあるチームメンバーは、ワークロードの効果的なサポートに役立ちます。 + チームメンバーが十分に配置されていれば、ワークロードをサポートでき、人員の疲弊を引き起こすリスクを軽減しつつ、オンコールローテーションを行うことができます。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス 実装のガイダンス ワークロードをサポートするために、十分にトレーニングを受けた担当者がいることを確認します。オンコール対応を含め、通常の運用アクティビティに対応するうえで十分なチームメンバーが配置されていることを確認します。 **お客様事例** AnyCompany Retail では、ワークロードをサポートするチームが適切に配置され、トレーニングを受けていることを確認しており、オンコールローテーションをサポートするうえで十分な人数のエンジニアがいます。担当者は、ワークロード構築の基盤となっているソフトウェアとプラットフォームについてのトレーニングを受けており、認定資格の取得が奨励されています。十分な人材が配置されているため、ワークロードをサポートし、オンコールローテーションを組みつつ、担当者は休暇を取ることができます。 ### 実装手順 実装手順 1. オンコール職務、セキュリティ問題、ライフサイクルイベント (サポート終了や証明書ローテーションタスクなど) など、ワークロードを運用およびサポートするのに十分な数の担当者を割り当てます。 1. ワークロードを構成するソフトウェアとプラットフォームについてのトレーニングを人材に提供します。 1. [AWS トレーニングと認定](https://aws.amazon.com/training/)には、AWS に関するコースのライブラリがあります。無料および有料のコース、オンラインコース、クラスルーム形式のコースが提供されています。 1. AWS は、AWS エキスパートから学ぶ[イベントやウェビナーを主催します](https://aws.amazon.com/events/)。 1. 以下を定期的に実行します。 + 運用状況やワークロードの変化に応じて、チームの規模とスキルを定期的に評価します。 + 運用要件に合わせてチームの規模とスキルを調整します。 + [計画されたライフサイクルイベント](https://docs.aws.amazon.com/health/latest/ug/aws-health-planned-lifecycle-events.html)、計画外のセキュリティ、運用通知に対処する機能と容量をAWS Health で検証します。 **実装計画に必要な工数レベル:** 高。ワークロードをサポートするチームを雇用し、トレーニングするには、多大な労力が必要になる場合がありますが、長期的に多大な利点があります。 ## リソース リソース **関連するベストプラクティス:** + [OPS11-BP04 ナレッジ管理を実施する](ops_evolve_ops_knowledge_management.md) - チームメンバーは、ワークロードの運用とサポートを行ううえで必要となる情報を持っている必要があります。それを提供する鍵となるのが、ナレッジ管理です。 **関連ドキュメント:** + [AWS イベントスケジュール](https://aws.amazon.com/events/) + [AWS トレーニングと認定](https://aws.amazon.com/training/) # OPS07-BP02 運用準備状況の継続的な確認を実現する 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 の詳細については、「[Operational Readiness Reviews (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 項目以下に制限します。 + 「Operational Readiness Reviews (ORR) ホワイトペーパー」の「[Appendix B: Example ORR questions](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 つ選びます。ローンチ前のワークロード、または内部ワークロードが理想的です。 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) + [Operational Readiness Review Template by 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 サポートs You \$1 Building an Effective Operational Readiness Review (ORR)](https://www.youtube.com/watch?v=Keo6zWMQqS8) **関連する例:** + [Sample Operational Readiness Review (ORR) Lens](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 ランブックを使用して手順を実行する OPS07-BP03 ランブックを使用して手順を実行する ランブックは、特定の成果を達成するための文書化されたプロセスです。ランブックは一連のステップから成り、それをたどることでプロセスを完了できます。ランブックは、飛行機の黎明期から運用に使用されてきました。クラウド運用では、ランブックを使用してリスクを削減し、望ましい成果を達成します。端的に言うと、ランブックはタスクを完了するためのチェックリストです。 ランブックは、ワークロードを運用するための不可欠の一部です。新しいチームメンバーのオンボーディングからメジャーリリースのデプロイまで、ランブックは、使用者に関係なく、一定の成果をもたらすように成文化されたプロセスです。ランブックの更新は変更管理プロセスの重要な要素であるため、ランブックは一箇所で公開し、プロセスの進化に合わせて更新する必要があります。また、エラー処理、ツール、アクセス許可、例外、問題発生時のエスカレーションに関するガイダンスを含める必要があります。 組織が成熟してきたら、ランブックの自動化を始めましょう。短く、頻繁に使用されるランブックから始めます。スクリプト言語を使用して、ステップを自動化するか、ステップを実行しやすくします。最初のいくつかのランブックを自動化したら、より複雑なランブックを自動化するために時間を割くようにします。やがて、ほとんどのランブックが何らかの方法で自動化されるはずです。 **期待される成果:** チームには、ワークロードのタスクを実行するためのステップバイステップのガイド集があります。ランブックには、期待される成果、必要なツールとアクセス許可、エラー処理に関する指示が含まれています。一箇所 (バージョン管理システム) に保管され、頻繁に更新されます。例えば、ランブックは、アプリケーションアラーム、運用上の問題、計画されたライフサイクルイベントの発生時に、重要なアカウントの AWS Health イベントをモニタリング、通知、対応するための機能をチームに提供します。 **一般的なアンチパターン:** + プロセスの各ステップの完了を記憶に頼る。 + チェックリストなしで、変更を手動でデプロイする。 + 異なるチームメンバーが同じプロセスを実行しても、手順や結果が異なる。 + システムの変更や自動化に伴い、ランブックの同期が取れなくなる **このベストプラクティスを活用するメリット:** + 手動タスクのエラー率を削減します。 + 運用が一貫した方法で実行されます。 + 新しいチームメンバーがタスクの実行をすぐに始められます。 + ランブックの自動化により、苦労を減らすことができます。 **このベストプラクティスを活用しない場合のリスクレベル:** 中 ## 実装のガイダンス 実装のガイダンス ランブックは、組織の成熟度に応じて、いくつかの形態をとります。少なくとも、ステップバイステップのテキスト文書で構成されている必要があります。期待される成果が明確に示されている必要があります。必要な特殊なアクセス許可やツールを明確に文書化します。問題発生時にエラー処理とエスカレーションに関する詳細なガイダンスを提供します。ランブックの所有者をリストアップし、一元的な場所で公開します。ランブックが文書化されたら、チームの別のメンバーに使用してもらって検証します。プロセスの進化につれて、変更管理プロセスに従ってランブックを更新します。 組織が成熟するにつれて、テキストのランブックは自動化されるはずです。[AWS Systems Manager Automations](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) **関連ドキュメント:** + [Achieving Operational Excellence using automated playbook and runbook](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) + [Migration playbook for AWS large migrations - Task 4: Improving your migration runbooks](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/task-four-migration-runbooks.html) + [Use AWS Systems Manager Automation runbooks to resolve operational tasks](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/) **関連動画:** + [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response](https://www.youtube.com/watch?v=E1NaYN_fJUo) + [How to automate IT Operations on AWS \$1 Amazon Web Services](https://www.youtube.com/watch?v=GuWj_mlyTug) + [Integrate Scripts into AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE) **関連する例:** + [Well-Architected Labs: プレイブックとランブックによるオペレーションの自動化](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) + [Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake](https://catalog.us-east-1.prod.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US) + [Gitlab - Runbooks](https://gitlab.com/gitlab-com/runbooks) + [Rubix - Jupyter Notebook でランブックを作成するための 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 プレイブックを使用して問題を調査する 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 は、ほとんどのプレイブック自動化システムとの互換性を持っています。プレイブックを一から作成する場合、以下のプレイブックテンプレートの例を使用します。 ``` # 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 プロセスと手順には特定の所有者が存在する](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) **関連ドキュメント:** + [Achieving Operational Excellence using automated playbook and runbook](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) + [Use AWS Systems Manager Automation runbooks to resolve operational tasks](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/) **関連動画:** + [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response (SEC318-R1)](https://www.youtube.com/watch?v=E1NaYN_fJUo) + [AWS Systems Manager Incident Manager - AWS Virtual Workshops](https://www.youtube.com/watch?v=KNOc0DxuBSY) + [Integrate Scripts into AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE) **関連する例:** + [AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework) + [AWS Systems Manager: オートメーションのチュートリアル](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html) + [Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake](https://catalog.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US) + [Rubix - Jupyter Notebook でランブックを作成するための 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 システムや変更をデプロイするために十分な情報に基づいて決定を下す 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 本稼働ワークロード用のサポートプランを作成する OPS07-BP06 本稼働ワークロード用のサポートプランを作成する 本稼働ワークロードが依存しているあらゆるソフトウェアやサービスのサポートを有効にします。本稼働のサービスレベルのニーズに合わせて、適切なサポートレベルを選択します。このような依存関係のためのサポートプランは、サービスの停止時やソフトウェアに問題が発生した場合に必要です。すべてのサービスおよびソフトウェアのベンダーについて、サポートプランやサービスのリクエスト方法を文書化します。サポートの連絡先が最新の状態に保たれていることを検証する仕組みを実装します。 **期待される成果:** + 本稼働ワークロードが依存しているソフトウェアやサービスのサポートプランを実装します。 + サービスレベルのニーズに基づいて適切なサポートプランを選択します。 + サポートプラン、サポートレベル、サポートのリクエスト方法を文書化します。 **一般的なアンチパターン:** + 重要なソフトウェアベンダーのサポートプランがない。ワークロードがその影響を受けたが、修正を急がせる手段もなければ、ベンダーからタイムリーに最新情報を得ることもできない。 + ソフトウェアベンダーの主要連絡先だった開発者が退社した。ベンダーのサポートに直接連絡できなくなった。時間をかけて汎用の問い合わせシステムを検索し移動しなければならず、必要なときに対応してもらうための時間が増えた。 + ソフトウェアベンダーに起因する本稼働の停止が発生した。サポートケースの記録方法に関するドキュメントがない。 **このベストプラクティスを活用するメリット:** + 適切なサポートレベルを受けていると、サービスレベルのニーズを満たすのに必要な時間内で対応を得ることができます。 + サポートを受ける顧客として、本稼働で問題があればエスカレーションできます。 + インシデント発生時にソフトウェアやサービスのベンダーがトラブルシューティングを支援します。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス 実装のガイダンス 本稼働ワークロードが依存しているあらゆるソフトウェアやサービスのベンダーのサポートプランを有効にします。サービスレベルのニーズに合わせた適切なサポートプランをセットアップします。AWS のお客様の場合は、本稼働ワークロードが任意のアカウントで AWS ビジネスサポート以上を有効にすることを意味します。サポートベンダーと定期的に打ち合わせ、サポートのオファー、プロセス、連絡先に関する最新情報を入手します。ソフトウェアやサービスのベンダーにサポートをリクエストする方法を、停止が発生した場合のエスカレーション方法を含めて文書化します。サポートの連絡先を最新の状態に保つ仕組みを実装します。 **お客様事例** AnyCompany Retail では、すべての商用ソフトウェアおよびサービスの依存関係がサポートプランを備えています。例えば、本稼働ワークロードがあるすべてのアカウントで、AWS Enterprise Support が有効になっています。問題が発生した場合は、開発者が誰でもサポートケースを作成できます。サポートのリクエスト方法、通知を受ける担当者、ケースを迅速化するベストプラクティスに関する情報を掲載した wiki ページがあります。 **実装手順** 1. 組織の関係者と協力して、ワークロードが依存しているソフトウェアやサービスのベンダーを特定します。これらの依存関係を文書化します。 1. ワークロードに必要なサービスレベルを判断します。それらに合うサポートプランを選択します。 1. 商用のソフトウェアやサービスの場合は、ベンダーとサポートプランを締結します。 1. すべての本稼働稼働用アカウントで AWS ビジネスサポート以上を契約すると、AWS サポートからの応答時間が短縮されるため、これを強くお勧めします。プレミアムサポートがない場合は、問題に対処するアクションプランが必要となり、これには AWS サポートからの支援が必要です。AWS サポートは、さまざまなツール、テクノロジー、人、プログラムの組み合わせを提供します。これらは、パフォーマンスの最適化、コストの削減、イノベーションの迅速化を積極的に支援するために設計されたものです。さらに、AWS ビジネスサポートには、システムとの統合をプログラムで実現するための AWS Trusted Advisor や AWS Health への API アクセス、AWS マネジメントコンソール や Amazon EventBridge チャネルなどの他のアクセス方法など、追加の利点があります。 1. ナレッジマネジメントツールにサポートプランを記録します。サポートのリクエスト方法、サポートケースが記録された場合の通知先、インシデント中のエスカレーション方法を含めます。wiki は、サポートプロセスや連絡先の変更に気付いた人が誰でも、ドキュメントに必要な更新を行うことができるため、良い仕組みです。 **実装計画に必要な工数レベル:** 低。ソフトウェアやサービスのほとんどのベンダーは、サポートプランの登録を提供しています。ナレッジマネジメントシステムにサポートのベストプラクティスを記録して共有すると、本稼働環境に問題が発生した場合にどうすべきかをチームが確実に把握できます。 ## リソース リソース **関連するベストプラクティス:** + [OPS02-BP02 プロセスと手順に特定の所有者が存在する](ops_ops_model_def_proc_owners.md) **関連ドキュメント:** + [AWS サポート Plans](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/)