# 準備
**Topics**
+ [OPS 4 ワークロードの状態を理解するために、ワークロードをどのように設計すればよいですか?](w2aac19b5b7b5.md)
+ [OPS 5 欠陥を減らし、修正を簡単にし、本番環境へのフローを改善するにはどうすればよいですか?](w2aac19b5b7b7.md)
+ [OPS 6 デプロイのリスクを軽減するにはどうすればよいですか?](w2aac19b5b7b9.md)
+ [OPS 7 ワークロードをサポートする準備が整っていることを確認するにはどうすればよいですか?](w2aac19b5b7c11.md)
# OPS 4 ワークロードの状態を理解するために、ワークロードをどのように設計すればよいですか?
ワークロードを設計する際には、すべてのコンポーネント (メトリクス、ログ、トレースなど) にわたって内部状態を理解するために必要な情報が送出されるようにします。そうすることによって、適時に有用な返答を提供できるようになります。
**Topics**
+ [OPS04-BP01 アプリケーションテレメトリーを実装する](ops_telemetry_application_telemetry.md)
+ [OPS04-BP02 ワークロードテレメトリーを実装して設定する](ops_telemetry_workload_telemetry.md)
+ [OPS04-BP03 ユーザーアクティビティテレメトリーを実装する](ops_telemetry_customer_telemetry.md)
+ [OPS04-BP04 依存関係のテレメトリーを実装する](ops_telemetry_dependency_telemetry.md)
+ [OPS04-BP05 トランザクショントレーサビリティを実装する](ops_telemetry_dist_trace.md)
# OPS04-BP01 アプリケーションテレメトリーを実装する
アプリケーションテレメトリーは、ワークロードの可観測性の基盤です。アプリケーションは、アプリケーションの状態やビジネス成果の達成に関するインサイトを提供するテレメトリーを送信する必要があります。トラブルシューティングから新しい機能の効果測定に至るまで、アプリケーションテレメトリーを使用することで、ワークロードの構築、運用、展開方法に関する情報を得ることができます。
アプリケーションテレメトリーは、メトリクスとログで構成されます。メトリクスは、脈や体温などの診断情報を指します。複数のメトリクスを使用することで、アプリケーションの状態を知ることができます。長期間にわたるメトリクスの収集は、ベースラインの開発や異常の検知に役立ちます。ログは、アプリケーションの内部の状態や発生したイベントに関してアプリケーションが送信するメッセージです。記録されるイベントには、エラーコード、トランザクション識別子、ユーザーアクションなどが含まれます。
**期待される成果:**
+ アプリケーションは、アプリケーションの状態とビジネス成果の達成に関するメトリクスとログを送信します。
+ ワークロードのすべてのアプリケーションのメトリクスとログは、一元的に保存されます。
**一般的なアンチパターン:**
+ アプリケーションはテレメトリーを送出しません。何か問題が生じたときは、顧客から通知してもらう以外に方法はありません。
+ お客様から、アプリケーションが応答しないと報告されました。あなたはテレメトリーを備えておらず、現在のユーザーエクスペリエンスを理解するために自らアプリケーションを使用することなく、問題が存在することを確認したり、問題の特徴を把握したりすることができません。
**このベストプラクティスを活用するメリット:**
+ アプリケーションの状態、ユーザーエクスペリエンス、ビジネス成果の達成を理解できます。
+ アプリケーションの状態の変化にすばやく対応できます。
+ アプリケーションの状態の傾向を知ることができます。
+ アプリケーションの改善に関する情報に基づく意思決定を行えます。
+ アプリケーションの問題をすばやく検知して解決できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
アプリケーションテレメトリーを 3 つ手順で実装する: テレメトリーを保存する場所の特定、アプリケーションの状態を示すテレメトリーの特定、アプリケーションへのテレメトリー送信機能の追加によって、アプリケーションテレメトリーを実装します。
例えば、eコマースの会社はアーキテクチャベースのマイクロサービスを持っています。アーキテクチャ設計プロセスの一環として、この会社は各マイクロサービスの状態を理解するのに役立つアプリケーションテレメトリーを特定しました。例えば、ユーザーのカートサービスは、カートへの追加、カートの削除、アイテムがカートに追加されるまでの時間などのイベントに関するテレメトリーを送信します。すべてのマイクロサービスは、エラー、警告、トランザクション情報を記録します。テレメトリーは Amazon CloudWatch に送信され、保存および分析されます。
**実装手順**
最初の手順は、ワークロード内のアプリケーションテレメトリーを一元保存する場所を特定することです。既存のプラットフォームがない場合、 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch) はテレメトリー収集、ダッシュボード、分析、およびイベント生成機能を提供します。
必要なテレメトリーを特定するには、まず以下の質問から始めます。
+ アプリケーションの状態は正常か。
+ アプリケーションはビジネス成果を達成しているか。
アプリケーションは、これらの質問に対して回答を提示するログやテレメトリーを送信する必要があります。既存のアプリケーションテレメトリーがこれらの質問に答えられない場合、ビジネスおよびエンジニアリングのステークホルダーと協力して、これらの質問に答えるテレメトリーの一覧を作成します。新しいアプリケーションテレメトリーの特定と開発に関しては、AWS アカウント チームに技術的なアドバイスを求めることができます。
新しいアプリケーションテレメトリーを特定できたら、エンジニアリングのステークホルダーと協力して、アプリケーションにテレメトリーの送信機能を追加します。 [AWS Distro for OpenTelemetryは、](https://aws-otel.github.io/) アプリケーションテレメトリーを収集する API、ライブラリ、エージェントを提供します。 [この例は、カスタムメトリクスを使用して JavaScript アプリケーションの状態を計測する方法を示します](https://aws-otel.github.io/docs/getting-started/js-sdk/metric-manual-instr)。
AWS が提供する可観測性サービスを知りたいお客様は、ご自身で [1 つの可観測性ワークショップ](https://catalog.workshops.aws/observability/en-US) を実施したり、AWS アカウント チームにガイダンスとサポートを依頼したりすることができます。このワークショップでは、AWS の可観測性ソリューションの概要を学び、使用例を実際に体験することができます。
アプリケーションテレメトリーの詳細についは、 [Amazon Builder’s Library の](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 「分散システムを装備して、運用の可視性を高める」の記事をご覧ください。この記事では、Amazon によるアプリケーションの計測方法、およびお客様の計測ガイドラインの開発に Amazon がどのように役立つかを紹介しています。
**計画の実装に必要な工数レベル:** ミディアム
## リソース
**関連するベストプラクティス:**
[OPS04-BP02 ワークロードテレメトリーを実装して設定する](ops_telemetry_workload_telemetry.md) - アプリケーションテレメトリーはワークロードテレメトリーのコンポーネントの 1 つです。ワークロード全体の状態を理解するには、ワークロードを構成する個別のアプリケーションの状態を理解する必要があります。
[OPS04-BP03 ユーザーアクティビティテレメトリーを実装する](ops_telemetry_customer_telemetry.md) - ユーザーアクティビティテレメトリーは、アプリケーションテレメトリーのサブセットになることがあります。カートへの追加イベント、ストリームのクリック、トランザクションの完了などのユーザーアクティビティは、ユーザーエクスペリエンスに関するインサイトを提供します。
[OPS04-BP04 依存関係のテレメトリーを実装する](ops_telemetry_dependency_telemetry.md) - 依存関係チェックはアプリケーションテレメトリーに関連しているため、アプリケーションに追加することができます。アプリケーションが DNS やデータベースなどの外部システムに依存している場合、アプリケーションはアクセス性、タイムアウト、および他のイベントに関するメトリクスとログを送信できます。
[OPS04-BP05 トランザクショントレーサビリティを実装する](ops_telemetry_dist_trace.md) - ワークロード全体のトランザクションを追跡するには、各アプリケーションが共有したイベントをどのように処理したかについての情報を送信する必要があります。各アプリケーションがこれらのイベントを処理した方法は、アプリケーションテレメトリーを介して送信されます。
[OPS08-BP02 ワークロードのメトリクスを定義する](ops_workload_health_design_workload_metrics.md) - ワークロードメトリクスは、ワークロードの状態を示す重要なインジケーターです。主要なアプリケーションメトリクスは、ワークロードメトリクスの一部です。
**関連するドキュメント:**
+ [AWS Builders' Library - 分散システムを装備して、運用の可視性を高める](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [AWS Distro for OpenTelemetry](https://aws-otel.github.io/)
+ [AWS Well-Architected 運用上の優秀性の柱のホワイトペーパー - テレメトリーの設計](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design-telemetry.html)
+ [フィルターを使用したログイベントからのメトリクスの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Amazon CloudWatch を使用したログ記録とモニタリングの実装](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/welcome.html)
+ [AWS Distro for OpenTelemetry を使用したアプリケーションの状態とパフォーマンスのモニタリング](https://aws.amazon.com/blogs/opensource/monitoring-application-health-and-performance-with-aws-distro-for-opentelemetry/)
+ [新規 - Amazon CloudWatch エージェントを使用してカスタムアプリケーションメトリクスをより効果的にモニタリングする方法](https://aws.amazon.com/blogs/devops/new-how-to-better-monitor-your-custom-application-metrics-using-amazon-cloudwatch-agent/)
+ [AWS における可観測性](https://aws.amazon.com/products/management-and-governance/use-cases/monitoring-and-observability/)
+ [シナリオ - CloudWatch へのメトリクスの公開](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/PublishMetrics.html)
+ [構築の開始 - アプリケーションを効率的にモニタリングする方法](https://aws.amazon.com/startups/start-building/how-to-monitor-applications/)
+ [AWS SDK での CloudWatch の使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/sdk-general-information-section.html)
**関連動画:**
+ [AWS re:Invent 2021 - オープンソースの可観測性](https://www.youtube.com/watch?v=vAnIhIwE5hY)
+ [CloudWatch エージェントを使用して Amazon EC2 インスタンスからメトリクスとログを収集する](https://www.youtube.com/watch?v=vAnIhIwE5hY)
+ [AWS ワークロードのアプリケーションモニタリングを簡単に設定する方法 - AWS オンラインテックトーク](https://www.youtube.com/watch?v=LKCth30RqnA)
+ [サーバーレスアプリケーションの可観測性をマスターする - AWS オンラインテックトーク](https://www.youtube.com/watch?v=CtsiXhiAUq8)
+ [AWS におけるオープンソースの可観測性 - AWS 仮想ワークショップ](https://www.youtube.com/watch?v=vAnIhIwE5hY)
**関連する例:**
+ [AWS のログ記録およびモニタリングの例に関するリソース](https://github.com/aws-samples/logging-monitoring-apg-guide-examples)
+ [AWS ソリューション: Amazon CloudWatch モニタリングフレームワーク](https://aws.amazon.com/solutions/implementations/amazon-cloudwatch-monitoring-framework/?did=sl_card&trk=sl_card)
+ [AWS ソリューション: 集中ロギング](https://aws.amazon.com/solutions/implementations/centralized-logging/)
+ [1 つの可観測性ワークショップ](https://catalog.workshops.aws/observability/en-US)
# OPS04-BP02 ワークロードテレメトリーを実装して設定する
内部状態や現在のステータスに関する情報 (API 呼び出しのボリューム、HTTP ステータスコード、スケーリングイベントなど) が送出されるよう、ワークロードを設計および設定します。この情報を使用して、応答が必要とされるタイミングを特定します。
Amazon CloudWatch などの [サービスを](https://aws.amazon.com/cloudwatch/) を使用して、ワークロードコンポーネントからのログとメトリクスを集計します (例: API ログ、 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)、 [AWS Lambda メトリクス](https://docs.aws.amazon.com/lambda/latest/dg/lambda-monitoring.html)、 [Amazon VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)、および [その他のサービス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/aws-services-sending-logs.html))。
**一般的なアンチパターン:**
+ 顧客が、パフォーマンスが低いことについて苦情を申し立てています。アプリケーションに最近の変更はないため、あなたは、ワークロードコンポーネントに問題があると考えています。あなたは、パフォーマンスの低さに影響しているコンポーネントを特定するために分析を行うテレメトリーを備えていません。
+ あなたは、アプリケーションにアクセスできません。あなたには、ネットワーキングの問題であるかどうかを判断するためのテレメトリーがありません。
**このベストプラクティスを確立するメリット:** ワークロード内で何が起こっているかを理解することで、必要に応じて対応できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
+ ログとメトリクステレメトリーを実装する: 内部状態、ステータス、およびビジネス成果の達成に関する情報が送出されるよう、ワークロードを計測します。この情報を使用して、応答が必要とされるタイミングを特定します。
+ [Gaining better observability of your VMs with Amazon CloudWatch - AWS Online Tech Talks (Amazon CloudWatch で VM の可観測性を改善する - AWS オンラインテックトーク)](https://youtu.be/1Ck_me4azMw)
+ [Amazon CloudWatch の仕組み](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html)
+ [Amazon CloudWatch とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [Amazon CloudWatch メトリクスを使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Amazon CloudWatch Logs とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ ワークロードテレメトリーを実装して設定する: 内部状態や現在のステータスに関する情報 (API 呼び出しのボリューム、HTTP ステータスコード、スケーリングイベントなど) が送出されるよう、ワークロードを設計および設定します。
+ [Amazon CloudWatch metrics and dimensions reference (Amazon CloudWatch のメトリクスとディメンションのリファレンス)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [AWS CloudTrail とは](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+ [VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
## リソース
**関連するドキュメント:**
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [Amazon CloudWatch ドキュメント](https://docs.aws.amazon.com/cloudwatch/index.html)
+ [Amazon CloudWatch metrics and dimensions reference (Amazon CloudWatch のメトリクスとディメンションのリファレンス)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Amazon CloudWatch の仕組み](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html)
+ [Amazon CloudWatch メトリクスを使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
+ [AWS CloudTrail とは](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+ [Amazon CloudWatch Logs とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [Amazon CloudWatch とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
**関連動画:**
+ [Application Performance Management on AWS (AWS でのアプリケーションのパフォーマンスメトリクス)](https://www.youtube.com/watch?v=5T4stR-HFas)
+ [Gaining Better Observability of Your VMs with Amazon CloudWatch (Amazon CloudWatchで VM の可観測性を改善する)](https://youtu.be/1Ck_me4azMw)
+ [Gaining better observability of your VMs with Amazon CloudWatch - AWS Online Tech Talks (Amazon CloudWatch で VM の可観測性を改善する - AWS オンラインテックトーク)](https://youtu.be/1Ck_me4azMw)
# OPS04-BP03 ユーザーアクティビティテレメトリーを実装する
ユーザーアクティビティに関する情報 (クリックストリームのほか、開始、放棄、完了済みトランザクションなど) が送出されるよう、アプリケーションコードをインストルメント化します。この情報を使用して、アプリケーションの使用方法や使用パターンを理解したり、応答が必要とされるタイミングを特定したりできます。
**一般的なアンチパターン:**
+ 開発者は、ユーザーのテレメトリーなしで新しい機能をデプロイし、使用率が増加しました。あなたは、使用率の増加が新しい機能の使用によるものなのか、あるいは新しいコードで発生した問題なのかを判別できません。
+ 開発者は、ユーザーのテレメトリーなしで新しい機能をデプロイしました。あなたは、顧客に問い合わせて尋ねなければ、顧客が当該機能を使用しているかどうかがわかりません。
**このベストプラクティスを活用するメリット:** 顧客がアプリケーションを使用して使用パターンや予期しない動作を特定し、必要に応じてお客様が対応することを可能にする方法を理解します。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ ユーザーアクティビティテレメトリを実装する: ユーザーアクティビティに関する情報 (クリックストリームのほか、開始、放棄、完了済みトランザクションなど) が送出されるよう、アプリケーションコードを設計します。この情報を使用して、アプリケーションの使用方法や使用パターンを理解したり、応答が必要とされるタイミングを特定したりできます。
# OPS04-BP04 依存関係のテレメトリーを実装する
依存するリソースの状態 (到達可能性や応答時間など) に関する情報を出力するようにワークロードを設計および設定します。外部依存関係の例としては、外部データベース、DNS、ネットワーク接続などがあります。この情報を使用して、応答が必要とされるタイミングを特定します。
**一般的なアンチパターン:**
+ アプリケーションにアクセスできない理由が DNS の問題であるかどうかを判断するには、手動で DNS プロバイダーが動作しているかどうかを確認する必要があります。
+ ショッピングカートアプリケーションはトランザクションを完了できません。クレジットカード処理プロバイダーの問題であるかどうかを確認するには、そのプロバイダーに連絡する必要があります。
**このベストプラクティスを活用するメリット:** 依存関係の状態を理解することで、必要に応じて対応できます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 依存関係のテレメトリーを実装する: ワークロードが依存するシステムの状態やステータスに関する情報が送出されるよう、ワークロードを設計および設定します。たとえば、外部データベース、DNS、ネットワーク接続、外部クレジットカード処理サービスなどがあります。
+ [AWS Systems Manager 統合での Amazon CloudWatch エージェント - Linux および Windows 向けの統合メトリクスおよびログ収集](https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-agent-with-aws-systems-manager-integration-unified-metrics-log-collection-for-linux-windows/)
+ [CloudWatch エージェントを使用した Amazon EC2 インスタンスとオンプレミスサーバーからのメトリクスとログの収集](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
## リソース
**関連するドキュメント:**
+ [AWS Systems Manager 統合での Amazon CloudWatch エージェント - Linux および Windows 向けの統合メトリクスおよびログ収集](https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-agent-with-aws-systems-manager-integration-unified-metrics-log-collection-for-linux-windows/)
+ [CloudWatch エージェントを使用した Amazon EC2 インスタンスとオンプレミスサーバーからのメトリクスとログの収集](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
**関連する例:**
+ [Well-Architected ラボ - 依存関係のモニタリング](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/)
# OPS04-BP05 トランザクショントレーサビリティを実装する
ワークロード全体のトランザクションフローに関する情報が送出されるよう、アプリケーションコードを実装し、ワークロードコンポーネントを設定します。この情報を使用して、応答が必要とされるタイミングを特定し、問題につながる要素の特定に役立てます。
AWS では、次のような分散トレーシングサービスを使用できます。 [AWS X-Ray](https://aws.amazon.com/xray/)では、トランザクションがワークロードを通過するときにトレースを収集して記録したり、マップを生成してワークロードやサービス間でトランザクションがどのように流れるかを確認したり、コンポーネント間の関係を把握したり、さらにはリアルタイムで問題を特定して分析したりできます。
**一般的なアンチパターン:**
+ あなたは、複数のアカウントにまたがるサーバーレスマイクロサービスアーキテクチャを実装しました。断続的なパフォーマンスの問題が顧客に発生しています。アプリケーション内でパフォーマンスの問題が存在する場所と問題の原因の特定を可能にするトレースがないため、どの機能またはコンポーネントが問題を引き起こしているのかを特定できません。
+ あなたは、開発を行う際に対処できるように、ワークロードのパフォーマンスのボトルネックがどこにあるかを特定しようとしています。あなたは、アプリケーションコンポーネントと、それらがやり取りするサービスとの関係を確認できず、アプリケーションのパフォーマンスに影響を及ぼす特定のサービスやパスのドリルダウンを可能にするトレースがないため、ボトルネックがどこにあるかを特定できません。
**このベストプラクティスを確立するメリット:** ワークロード全体のトランザクションフローを理解することで、ワークロードトランザクションの予想される動作と、ワークロード全体の予想される動作のバリエーションを理解できるため、必要に応じて対応できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
+ トランザクショントレーサビリティを実装する: トランザクションステージ、アクティブコンポーネント、アクティビティ完了までの時間など、システムコンポーネント全体のトランザクションフローに関する情報を送出するよう、アプリケーションとワークロードを設計します。この情報を使用して、進行中のもの、完了しているもの、および完了したアクティビティの結果を特定できます。これは、応答が必要とされるタイミングを特定するのに役立ちます。例えば、コンポーネント内のトランザクション応答時間が予想より長い場合、そのコンポーネントに問題があることがわかります。
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [AWS X-Ray とは](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
## リソース
**関連するドキュメント:**
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [AWS X-Ray とは](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
# OPS 5 欠陥を減らし、修正を簡単にし、本番環境へのフローを改善するにはどうすればよいですか?
リファクタリング、品質についてのすばやいフィードバック、バグ修正を可能にし、本番環境への変更のフローを改善するアプローチを採用します。これらにより、本番環境に採用される有益な変更を加速させ、デプロイされた問題を制限できます。またデプロイアクティビティを通じて挿入された問題をすばやく特定し、修復できます。
**Topics**
+ [OPS05-BP01 バージョン管理を使用する](ops_dev_integ_version_control.md)
+ [OPS05-BP02 変更をテストし、検証する](ops_dev_integ_test_val_chg.md)
+ [OPS05-BP03 設定管理システムを使用する](ops_dev_integ_conf_mgmt_sys.md)
+ [OPS05-BP04 構築およびデプロイ管理システムを使用する](ops_dev_integ_build_mgmt_sys.md)
+ [OPS05-BP05 パッチ管理を実行する](ops_dev_integ_patch_mgmt.md)
+ [OPS05-BP06 設計標準を共有する](ops_dev_integ_share_design_stds.md)
+ [OPS05-BP07 コード品質の向上のためにプラクティスを実装する](ops_dev_integ_code_quality.md)
+ [OPS05-BP08 複数の環境を使用する](ops_dev_integ_multi_env.md)
+ [OPS05-BP09 小規模かつ可逆的な変更を頻繁に行う](ops_dev_integ_freq_sm_rev_chg.md)
+ [OPS05-BP10 統合とデプロイを完全自動化する](ops_dev_integ_auto_integ_deploy.md)
# OPS05-BP01 バージョン管理を使用する
変更とリリースの追跡を有効にするにはバージョン管理を使用します。
AWS の多くのサービスには、バージョン管理機能が備わっています。リビジョンまたはソース管理システム、例えば [AWS CodeCommit](https://aws.amazon.com/codecommit/) コードや他のアーティファクト (インフラストラクチャのバージョン管理された [AWS CloudFormation](https://aws.amazon.com/cloudformation/) テンプレートなど) を管理します。
**一般的なアンチパターン:**
+ あなたは、コードを開発し、ワークステーションに保存しました。ワークステーションで回復不可能なストレージ障害が発生し、コードが失われました。
+ 既存のコードを変更で上書きした後、アプリケーションを再起動すると、操作できなくなりました。あなたは、変更を元に戻すことができません。
+ あなたは、レポートファイルへの書き込みをロックされており、他の誰かが編集する必要があります。編集をしようとする者は、タスクを完了できるように、作業を停止するようにあなたに求めています。
+ 研究チームは、今後の業務を形作る詳細な分析に取り組んでいます。誰かが誤って買い物リストを最終レポートに上書きして保存してしまいました。あなたは変更を元に戻すことができず、レポートを再作成する必要があります。
**このベストプラクティスを確立するメリット:** バージョン管理機能を使用すると、既知の良好な状態や以前のバージョンに簡単に戻すことができ、アセットが失われるリスクを低減できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
+ バージョン管理を使用する: バージョン管理されたレポジトリでアセットを維持します。そうすることで、変更の追跡、新しいバージョンのデプロイ、既存バージョンへの変更の検出、以前のバージョンの回復 (障害が発生する場合に、その前の良好な状態に戻すなど) をサポートします。構成管理システムのバージョン管理機能を手順に統合します。
+ [AWS CodeCommit の紹介](https://youtu.be/46PRLMW8otg)
+ [AWS CodeCommit とは](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
## リソース
**関連するドキュメント:**
+ [AWS CodeCommit とは](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
**関連動画:**
+ [AWS CodeCommit の紹介](https://youtu.be/46PRLMW8otg)
# OPS05-BP02 変更をテストし、検証する
エラーの制限と検出に役立てるため、変更をテスト、検証します。手動プロセスによって発生するエラーと、テストにかかる労力を減らすためにテストを自動化します。
AWS の多くのサービスには、バージョン管理機能が備わっています。AWS CodeCommit などのリビジョンまたはソース管理システムを [使用して、](https://aws.amazon.com/codecommit/) コードや他のアーティファクト (インフラストラクチャのバージョン管理された [AWS CloudFormation](https://aws.amazon.com/cloudformation/) テンプレートなど) を管理します。
**一般的なアンチパターン:**
+ あなたが新しいコードを本稼働環境にデプロイしたところ、アプリケーションが機能しなくなったため、顧客からの電話が鳴りはじめました。
+ あなたは、ペリメータセキュリティを強化するために新しいセキュリティグループを適用します。機能しましたが、意図しない結果が発生し、ユーザーがアプリケーションにアクセスできなくなっています。
+ あなたは、新しい機能によって呼び出されるメソッドを変更します。もう 1 つの機能もそのメソッドに依存しており、機能しなくなりました。問題は検出されず、本稼働環境に入ります。もう 1 つの当該機能はしばらくの間呼び出されず、結局、原因との相関なしに本稼働環境で失敗します。
**このベストプラクティスを活用するメリット:** 変更を早期にテストして検証することで、コストを最小限に抑えて問題に対処し、顧客への影響を抑えることができます。デプロイ前にテストすることで、エラーの発生を最小限に抑えることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 変更をテストし、検証する: すべてのライフサイクルステージ (開発、テスト、本番環境など) で変更をテストし、その結果を検証してください。テスト結果を使用して、新機能を確認し、失敗したデプロイのリスクと影響を緩和します。テストと検証を自動化し、レビューの一貫性を確保し、手動プロセスによって発生するエラーとそれにかかる労力を減らすことができます。
+ [AWS CodeBuild とは](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS CodeBuild のローカル構築サポート](https://aws.amazon.com/blogs/devops/announcing-local-build-support-for-aws-codebuild/)
## リソース
**関連するドキュメント:**
+ [AWS デベロッパーツール](https://aws.amazon.com/products/developer-tools/)
+ [AWS CodeBuild のローカル構築サポート](https://aws.amazon.com/blogs/devops/announcing-local-build-support-for-aws-codebuild/)
+ [AWS CodeBuild とは](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
# OPS05-BP03 設定管理システムを使用する
設定を変更し、変更を追跡記録するには、構成管理システムを使用します。これらのシステムは、手動プロセスによって発生するエラーと、変更を導入する労力を減らします。
静的な構成管理では、ライフタイムを通じて一貫性を維持することが期待されるリソースの初期化時に値を設定します。このケースの例として、インスタンス上のアプリケーションサーバーまたはウェブサーバー用の構成を設定する場合や、 [AWS マネジメントコンソール](https://docs.aws.amazon.com/awsconsolehelpdocs/index.html) 内または [AWS CLI](https://aws.amazon.com/cli/) を介して AWS サービスの構成を定義する場合が挙げられます。
動的な構成管理では、ライフタイムを通じて変化する、または変化することが予測されるリソースの初期化時に値を設定します。例えば、構成変更を介してコードの機能を有効にするように機能トグルを設定したり、インシデント発生時にログの詳細レベルを変更してより多くのデータを取得し、インシデント終了時に詳細レベルを元に戻して不要なログや負荷を減らしたりすることができます。
インスタンス、コンテナ、サーバーレス機能、またはデバイスで実行されているアプリケーションで動的な構成を使用している場合、 [AWS AppConfig を使用して](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) 環境全体での管理と実装を行うことができます。
AWS では、 [AWS Config を使用して](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) アカウントおよびリージョン全体の AWS リソース構成を [継続的にモニタリングできます](https://docs.aws.amazon.com/config/latest/developerguide/aggregate-data.html)。そうすることで、構成履歴の追跡、構成変化の他のリソースへの影響、 [AWS Config ルール](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) および [AWS Config コンフォーマンスパックを使用した期待される、または望まれる設定との比較監査を行えます](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html)。
AWS では、以下のサービスを使用して、継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインを構築できます。 [AWS デベロッパーツール](https://aws.amazon.com/products/developer-tools/) (例: AWS CodeCommit、 [AWS CodeBuild](https://aws.amazon.com/codebuild/)、 [AWS CodePipeline](https://aws.amazon.com/codepipeline/)、 [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)、および [AWS CodeStar](https://aws.amazon.com/codestar/))。
変更カレンダーを用意して、変更の実施によって影響を受ける可能性のある重要なビジネスや運用上の活動やイベントが計画されている時期を追跡します。アクティビティを調整して、これらの計画に関するリスクを管理します。 [AWS Systems Manager 変更カレンダー](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html) は、変更に対して時間ブロックがオープンであるかクローズであるか、およびその理由を文書化し、 [その情報を他の ](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-calendar-share.html) AWS アカウント と共有します。AWS Systems Manager Automation スクリプトは、カレンダーの変化に沿って実行されるように設定できます。
[AWS Systems Manager メンテナンスウィンドウは、](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html) AWS SSM Run Command または Automation スクリプト、AWS Lambda 呼び出し、または AWS Step Functions アクティビティの実行を指定した時間にスケジュールできます。これらのアクティビティを評価に含めることができるように、変更カレンダー上で印を付けます。
**一般的なアンチパターン:**
+ あなたがフリート全体でウェブサーバー設定を手動で更新したところ、更新エラーのために多数のサーバーが応答しなくなりました。
+ あなたは、何時間もかけて、アプリケーションサーバーフリートを手動で更新します。変更中の設定の不整合が、予期しない動作を引き起こします。
+ 誰かがセキュリティグループを更新したため、ウェブサーバーにアクセスできなくなりました。変更内容を把握しなければ、問題の調査にかなりの時間を費やすことになり、復旧までより長くの時間を要することになります。
**このベストプラクティスを活用するメリット:** 設定管理システムを採用することで、変更やその追跡の労力のレベルと、手動の手順に起因するエラーの頻度を軽減できます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 設定管理システムを使用する: 設定管理システムを使用して、変更を追跡、実装し、手動プロセスによって発生するエラーと労力を減らすことができます。
+ [インフラストラクチャ設定管理](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Config とは](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS CloudFormation の紹介](https://youtu.be/Omppm_YUG2g)
+ [AWS CloudFormation とは](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [AWS OpsWorks](https://aws.amazon.com/opsworks/)
+ [AWS OpsWorks とは](https://docs.aws.amazon.com/opsworks/latest/userguide/welcome.html)
+ [AWS Elastic Beanstalk の紹介](https://youtu.be/SrwxAScdyT0)
+ [AWS Elastic Beanstalk とは](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html)
## リソース
**関連するドキュメント:**
+ [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html)
+ [AWS デベロッパーツール](https://aws.amazon.com/products/developer-tools/)
+ [AWS OpsWorks](https://aws.amazon.com/opsworks/)
+ [AWS Systems Manager 変更カレンダー](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html)
+ [AWS Systems Manager メンテナンスウィンドウ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html)
+ [インフラストラクチャ設定管理](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/)
+ [AWS CloudFormation とは](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [AWS Config とは](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS Elastic Beanstalk とは](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html)
+ [AWS OpsWorks とは](https://docs.aws.amazon.com/opsworks/latest/userguide/welcome.html)
**関連動画:**
+ [AWS CloudFormation の紹介](https://youtu.be/Omppm_YUG2g)
+ [AWS Elastic Beanstalk の紹介](https://youtu.be/SrwxAScdyT0)
# OPS05-BP04 構築およびデプロイ管理システムを使用する
構築およびデプロイ管理システムを使用します。これらのシステムは、手動プロセスによって発生するエラーと、変更を導入する労力を減らします。
AWS では、以下のサービスを使用して、継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインを構築できます。 [AWS デベロッパーツール](https://aws.amazon.com/products/developer-tools/) (例: AWS CodeCommit、 [AWS CodeBuild](https://aws.amazon.com/codebuild/)、 [AWS CodePipeline](https://aws.amazon.com/codepipeline/)、 [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)、および [AWS CodeStar](https://aws.amazon.com/codestar/))。
**一般的なアンチパターン:**
+ 開発システムでコードをコンパイルした後、あなたは、実行可能ファイルを本稼働システムにコピーし、起動に失敗します。ローカルログファイルは、依存関係がないために失敗したことを示しています。
+ あなたは、開発環境で新機能を使用してアプリケーションを正常に構築し、品質保証 (QA) にコードを提供します。静的アセットがないため、QA が失敗します。
+ 金曜日に、多くの労力をかけて、開発環境でアプリケーションを手動で構築することができました。これには、新しくコード化された機能も含まれます。月曜日に、あなたは、アプリケーションを正常に構築することを可能にするステップを繰り返すことができません。
+ あなたは、新しいリリース用に作成したテストを実行します。その後、あなたは、翌週いっぱいをかけて、テスト環境をセットアップし、すべての既存の統合テストを実行してから、パフォーマンステストを実行します。新しいコードには許容できないパフォーマンスへの影響があり、再開発してから再テストする必要があります。
**このベストプラクティスを活用するメリット:** ビルドとデプロイのアクティビティを管理するメカニズムを提供することで、反復的なタスクを実行するための労力の程度を減らし、チームメンバーは高価値のクリエイティブなタスクに専念し、手動の手順によるエラーの発生を抑制できます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 構築およびデプロイ管理システムを使用する: ビルドおよびデプロイ管理システムを使用して、変更を追跡、実装し、手動プロセスによって発生するエラーと労力を減らすことができます。構築、テスト、デプロイ、検証を通じたコードのチェックインから統合とデプロイのパイプラインを完全自動化します。これにより、リードタイムを削減し、変更の頻度を増やすことが可能になり、それにかかわる労力のレベルを減らすことができます。
+ [AWS CodeBuild とは](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [ソフトウェア開発のための継続的インテグレーションのベストプラクティス](https://www.youtube.com/watch?v=GEPJ7Lo346A)
+ [Slalom: AWS のサーバーレスアプリケーション用の CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
+ [AWS CodeDeploy の紹介 - Amazon Web Services を使用したソフトウェアの自動デプロイ](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [AWS CodeDeploy とは](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
## リソース
**関連するドキュメント:**
+ [AWS デベロッパーツール](https://aws.amazon.com/products/developer-tools/)
+ [AWS CodeBuild とは](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS CodeDeploy とは](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**関連動画:**
+ [ソフトウェア開発のための継続的インテグレーションのベストプラクティス](https://www.youtube.com/watch?v=GEPJ7Lo346A)
+ [AWS CodeDeploy の紹介 - Amazon Web Services を使用したソフトウェアの自動デプロイ](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [Slalom: AWS のサーバーレスアプリケーション用の CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
# OPS05-BP05 パッチ管理を実行する
パッチ管理を実行し、問題を解決して、ガバナンスに準拠するようにします。パッチ管理の自動化により、手動プロセスによって発生するエラーと、パッチにかかる労力を減らすことができます。
パッチと脆弱性の管理は、メリットとリスクを管理するアクティビティの一環です。不変のインフラストラクチャを使用し、検証済みの正常な状態でワークロードをデプロイすることが推奨されます。これが不可能な場合は、残りのオプションとしてパッチの適用があります。
マシンイメージ、コンテナイメージ、または Lambda [カスタムランタイムと追加ライブラリを更新して](https://docs.aws.amazon.com/lambda/latest/dg/security-configuration.html) 脆弱性を取り除くことは、パッチ管理の一環です。Linux または Windows Server イメージの [Amazon マシンイメージ ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) (AMI) への更新については、 [EC2 Image Builderを使用して管理する必要があります](https://aws.amazon.com/image-builder/)。既存のパイプラインに [Amazon Elastic Container Registry ](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) を使用して、 [Amazon ECS イメージの管理](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) および [Amazon EKS イメージの管理ができます](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_EKS.html)。AWS Lambda には、 [バージョン](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html) 管理機能が含まれます。
最初に安全な環境でテストを実施していない状態で、パッチを本番環境のシステムに適用しないでください。パッチは運用上またはビジネス上の成果に対応している場合にのみ適用してください。AWS では、 [AWS Systems Manager パッチマネージャーを使用して](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 管理対象システムにパッチを適用するプロセスを自動化し、 [AWS Systems Manager メンテナンスウィンドウを使用してアクティビティをスケジューリングします](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html)。
**一般的なアンチパターン:**
+ あなたには、すべての新しいセキュリティパッチを 2 時間以内に適用するために権限が付与されました。その結果、アプリケーションにパッチとの互換性がないため、複数の機能停止が発生しました。
+ パッチが適用されていないライブラリは、不明な関係者がライブラリ内の脆弱性を使用してワークロードにアクセスするため、意図しない結果をもたらします。
+ あなたは、開発者に通知することなく、自動的に開発者環境にパッチを適用します。あなたには、開発者から、環境が想定どおりに動作しなくなったという苦情が複数寄せられます。
+ あなたは、永続的なインスタンスの商用オフザシェルフのセルフソフトウェアにパッチを適用していません。ソフトウェアに問題があり、ベンダーに連絡すると、ベンダーから、バージョンがサポートされておらず、サポートを受けるためには、特定のレベルにパッチを適用する必要があることが伝えられます。
+ あなたが使用した暗号化ソフトウェアの最近リリースされたパッチにより、パフォーマンスが大幅に向上します。パッチが適用されていないあなたのシステムには、パッチを適用しない結果として、パフォーマンスの問題が残存しています。
**このベストプラクティスを活用するメリット:** パッチ適用の基準や環境全体への配布方法など、パッチ管理プロセスを確立することで、それらの利点を実現し、影響を制御することができます。これにより、必要な機能と能力の導入、問題の除去、ガバナンスの継続的な遵守が可能になります。パッチ管理システムと自動化を実装して、パッチをデプロイする労力を軽減し、手動プロセスに起因するエラーの発生を抑制します。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ パッチ管理: 問題の修正、希望する機能や能力の取得、ガバナンスポリシーやベンダーのサポート要件への準拠継続を行うためにはシステムをパッチします。変更不可能なシステムでは、必要な成果を達成するために適切なパッチを使用してデプロイします。パッチ管理メカニズムの自動化により、パッチの経過時間、手動プロセスによって発生するエラーと、パッチにかかわる労力を減らすことができます。
+ [AWS Systems Manager パッチマネージャーを使用して](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
## リソース
**関連するドキュメント:**
+ [AWS デベロッパーツール](https://aws.amazon.com/products/developer-tools/)
+ [AWS Systems Manager パッチマネージャー](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
**関連動画:**
+ [AWS のサーバーレスアプリケーション用の CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
+ [Ops を考慮に入れて設計する](https://youtu.be/uh19jfW7hw4)
**関連する例:**
+ [Well-Architected ラボ - インベントリおよびパッチ管理](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/)
# OPS05-BP06 設計標準を共有する
チーム全体でベストプラクティスを共有し、デプロイ作業における利点の認識を高め、それを最大限にします。
AWS では、アプリケーション、コンピューティング、インフラストラクチャ、運用をコードとして定義し、管理できます。これにより、リリース、共有、採用が簡単になります。
多くの AWS のサービスとリソースは、アカウント間で共有されるように設計されているので、作成されたアセットや発見をチーム間で共有できます。たとえば、 [CodeCommit ](https://docs.aws.amazon.com/codecommit/latest/userguide/cross-account.html) リポジトリ、 [Lambda ](https://docs.aws.amazon.com/lambda/latest/dg/lambda-permissions.html) 関数、 [Amazon S3 バケット](https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-s3/)、および [AMI ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html) を特定のアカウントに共有できます。
新しいリソースやアップデートを発行するときは、Amazon SNS を使用して [クロスアカウント通知を発行します](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html)。受信者は Lambda を使って新しいバージョンを入手できます。
組織内で共有された標準が適用されている場合、チームのアクティビティをサポートする標準の追加、変更、例外をリクエストするメカニズムを持つことは重要です。このオプションがなければ、標準はイノベーションの障壁になります。
**一般的なアンチパターン:**
+ あなたは、組織内の他の各開発チームが作成したように、独自のユーザー認証メカニズムを作成しました。ユーザーは、アクセスするシステムの各部分について、個別の一連の認証情報を維持する必要があります。
+ あなたは、組織内の他の各開発チームが作成したように、独自のユーザー認証メカニズムを作成しました。組織には、遵守されなければならない新しいコンプライアンス要件が与えられています。個々の開発チームには、新しい要件を実装するためにリソースに投資する必要が生じました。
+ あなたは、組織内の他の各開発チームが作成したように、独自の画面レイアウトを作成しました。整合性のないインターフェイスを操作することが困難であることについて、ユーザーが苦情を申し出ています。
**このベストプラクティスを活用するメリット:** 標準が複数のアプリケーションや組織の要件を満たしている場合は、ベストプラクティスの採用をサポートし、開発にかける労力から得られる恩恵を最大化するために、共有された標準を使用します。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 設計標準を共有する: 既存のベストプラクティス、設計標準、チェックリスト、運用手順、ガイダンス、ガバナンスの要件をチーム間で共有し、複雑になるのを防ぎながら開発努力の成果を最大化する継続的な改善とイノベーションを支援するために、設計標準の変更、追加、例外を申請する手順を設けます。チームが公開済みのコンテンツを把握していることを確認し、コンテンツを活用して、やり直しや無駄な労力を制限します。
+ [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 デザイナー 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 デザイナー 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)
# OPS05-BP07 コード品質の向上のためにプラクティスを実装する
コード品質の向上のためにプラクティスを実装し、欠陥を最小限に抑えます。例えば、テスト駆動型開発、コードレビュー、標準の導入などがあります。
AWS では、 [Amazon CodeGuru などのサービスを](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) パイプラインと統合し、プログラム分析と機械学習を使用して潜在的なコードと [セキュリティの問題を自動的に特定することができます。](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/how-codeguru-reviewer-works.html) CodeGuru は、これらの問題に対処する AWS のベストプラクティスを実装するためのレコメンデーションを提供します。
**一般的なアンチパターン:**
+ あなたは、機能をより迅速にテストできるように、標準入力サニタイズライブラリを統合しないことに決めました。テスト後、あなたは、ライブラリの組み込みを完了することを思い出すことなく、コードをコミットします。
+ あなたには、処理しているデータセットに関する経験がほとんどないため、データセット内に一連のエッジケースが存在し得ることを認識していません。これらのエッジケースには、実装したコードとの互換性がありません。
**このベストプラクティスを活用するメリット:** コードの品質を向上させるためのプラクティスを採用することは、本稼働環境に発生する問題を最小限に抑えることに役立ちます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ コード品質の向上のためにプラクティスを実装する: プラクティスを実装して、コード品質を向上させ、欠陥と欠陥がデプロイされるリスクを最低限に抑えます。例えば、テスト駆動型デプロイ、ペアプログラミング、コードレビュー、規約の導入などがあります。
+ [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
## リソース
**関連するドキュメント:**
+ [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
# OPS05-BP08 複数の環境を使用する
ワークロードの実験、開発、テストを行うには、複数の環境を使用します。環境が本稼働環境に近づくにつれて増加するコントロールレベルを使用して、デプロイ時にワークロードが意図したとおりに運用するように確信を強化します。
**一般的なアンチパターン:**
+ あなたは、共有開発環境で開発を実行しており、別の開発者があなたのコードの変更を上書きします。
+ 共有開発環境の制限的なセキュリティ制御により、あなたは新しいサービスや機能を試すことができません。
+ あなたは本稼働用システムで負荷テストを実行し、ユーザーの機能停止を引き起こします。
+ データ損失につながる重大なエラーが本稼働環境で発生しました。あなたは、データ損失がどのように発生したかを特定し、これを再び発生させないようにするため、本稼働環境において、データ損失につながる条件を再現しようとします。テスト中のさらなるデータ損失を防ぐため、あなたは、ユーザーがアプリケーションを使用できないようにすることを強制されます。
+ あなたは、マルチテナントサービスを運用しており、専用環境に対する顧客のリクエストをサポートできません。
+ あなたは常にテストするわけではありませんが、テストする場合は本稼働環境で行います。
+ あなたは、単一環境というシンプルさが、環境内での変更の影響範囲に勝ると考えています。
**このベストプラクティスを活用するメリット:** 複数の環境をデプロイすることで、開発者やユーザーコミュニティ間で競合を生じさせることなく、複数の同時開発、テスト、本稼働環境をサポートできます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 複数の環境を使用する: 開発者が実験できるように、最小のコントロールのサンドボックス環境を提供します。連携できるように個々の開発環境を提供し、開発の俊敏性を増します。開発者がイノベーションを試せるように、本番に近い環境でより厳格なコントロールを実装します。コードとしてインフラストラクチャを使用したり、構成管理システムを使用したりして本番環境に存在するコントロールに準拠して設定された環境をデプロイし、システムがデプロイ時に予想どおりに動作することを確認します。環境を使用しない場合は、オフにして、アイドル状態のリソース (夜間や週末の開発システムなど) に関連するコストを避けることができます。ロードテストで妥当な結果を有効にする場合、本番に相当する環境をデプロイします。
+ [AWS CloudFormation とは](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [Amazon EC2 を使用して、AWS Lambda インスタンスを一定の間隔で停止および起動する方法](https://aws.amazon.com/premiumsupport/knowledge-center/start-stop-lambda-cloudwatch/)
## リソース
**関連するドキュメント:**
+ [Amazon EC2 を使用して、AWS Lambda インスタンスを一定の間隔で停止および起動する方法](https://aws.amazon.com/premiumsupport/knowledge-center/start-stop-lambda-cloudwatch/)
+ [AWS CloudFormation とは](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
# OPS05-BP09 小規模かつ可逆的な変更を頻繁に行う
頻繁に、小さく、可逆的な変更を行うことで、変更の範囲と影響を減らします。これにより、トラブルシューティングが容易になり、修復がすばやくできるようになります。また変更を元に戻すこともできます。
**一般的なアンチパターン:**
+ あなたは、四半期ごとに、アプリケーションの新しいバージョンをデプロイします。
+ あなたは、データベーススキーマに対して頻繁に変更を加えます。
+ あなたは、手動のインプレースアップグレードを実行し、既存のインストールと設定を上書きします。
**このベストプラクティスを活用するメリット:** 小さな変更を頻繁にデプロイすることで、開発にかける労力から得られる恩恵をすばやく認識できます。変更が小さい場合、意図しない結果が発生するかどうかを識別することがより容易になります。変更を元に戻すことができる場合、復旧が簡素化されるため、変更を実装するリスクが低減されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ 小規模で可逆的な変更を頻繁に行う: 頻繁に、小さく、可逆的な変更を行うことで、変更の範囲と影響を縮小します。これにより、トラブルシューティングが容易になり、修復がすばやくできるようになります。また変更を元に戻すこともできます。また、ビジネスに価値をもたらす速度も向上します。
# OPS05-BP10 統合とデプロイを完全自動化する
ワークロードのビルド、デプロイ、テストを自動化します。これにより、手動プロセスによって発生するエラーと、変更をデプロイする労力を減らすことができます。
一貫したタグ付け戦略に従って [リソースタグ](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) および [AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/APIReference/Welcome.html) を使用して [メタデータを適用し、](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/) リソースの識別を可能にします。組織、原価計算、アクセスコントロールのリソースにタグを付け、自動化された運用アクティビティの実行に的を絞ります。
**一般的なアンチパターン:**
+ 金曜日に、あなたは、機能ブランチ用の新しいコードの作成を完了します。月曜日に、あなたは、コード品質テストスクリプトと各ユニットテストスクリプトを実行した後、予定された次のリリースのためにコードをチェックインします。
+ あなたは、本稼働中の多数の顧客に影響を与える重要な問題の修正コードを記述するように指示されます。修正をテストした後、あなたは、コードをコミットし、変更管理部門にメールで本番環境へのデプロイの承認を依頼します。
**このベストプラクティスを確立するメリット:** 自動化されたビルドおよびデプロイ管理システムを実装することで、手動プロセスにより発生するエラーを削減し、変更をデプロイする労力を減らして、チームメンバーがビジネス価値の提供に注力できるようにします。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
+ 構築およびデプロイ管理システムを使用する: ビルドおよびデプロイ管理システムを使用して、変更を追跡、実装し、手動プロセスによって発生するエラーと労力を減らすことができます。構築、テスト、デプロイ、検証を通じたコードのチェックインから統合とデプロイのパイプラインを完全自動化します。これにより、リードタイムを削減し、変更の頻度を増やすことが可能になり、それにかかわる労力のレベルを減らすことができます。
+ [AWS CodeBuild とは](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [ソフトウェア開発のための継続的インテグレーションのベストプラクティス](https://www.youtube.com/watch?v=GEPJ7Lo346A)
+ [Slalom: CI/CD for serverless applications on AWS (Slalom: AWS のサーバーレスアプリケーション用の CI/CD)](https://www.youtube.com/watch?v=tEpx5VaW4WE)
+ [Introduction to AWS CodeDeploy - automated software deployment with Amazon Web Services (AWS CodeDeploy の紹介 - Amazon Web Services を使用したソフトウェアの自動デプロイ)](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [AWS CodeDeploy とは](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
## リソース
**関連するドキュメント:**
+ [AWS CodeBuild とは](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS CodeDeploy とは](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**関連動画:**
+ [ソフトウェア開発のための継続的インテグレーションのベストプラクティス](https://www.youtube.com/watch?v=GEPJ7Lo346A)
+ [Introduction to AWS CodeDeploy - automated software deployment with Amazon Web Services (AWS CodeDeploy の紹介 - Amazon Web Services を使用したソフトウェアの自動デプロイ)](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [Slalom: CI/CD for serverless applications on AWS (Slalom: AWS のサーバーレスアプリケーション用の CI/CD)](https://www.youtube.com/watch?v=tEpx5VaW4WE)
# OPS 6 デプロイのリスクを軽減するにはどうすればよいですか?
品質に関する迅速なフィードバックを提供し、望ましい結果をもたらさない変更から迅速に復旧できるようにするアプローチを採用します。このような手法を使用すると、変更のデプロイによって生じる問題の影響を軽減できます。
**Topics**
+ [OPS06-BP01 変更の失敗に備える](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 変更をテストし、検証する](ops_mit_deploy_risks_test_val_chg.md)
+ [OPS06-BP03 デプロイ管理システムを使用する](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [OPS06-BP04 限定的なデプロイを使用してテストする](ops_mit_deploy_risks_test_limited_deploy.md)
+ [OPS06-BP05 並列環境でデプロイする](ops_mit_deploy_risks_deploy_to_parallel_env.md)
+ [OPS06-BP06 小規模で可逆的な変更を頻繁にデプロイする](ops_mit_deploy_risks_freq_sm_rev_chg.md)
+ [OPS06-BP07 統合とデプロイを完全自動化する](ops_mit_deploy_risks_auto_integ_deploy.md)
+ [OPS06-BP08 テストとロールバックを自動化する](ops_mit_deploy_risks_auto_testing_and_rollback.md)
# OPS06-BP01 変更の失敗に備える
変更が望ましい結果をもたらさない場合に、既知の良好な状態に戻すか、本番環境で修正を行うことを計画します。この準備を行うことで、迅速な対応によって復旧時間を短縮できます。
**一般的なアンチパターン:**
+ あなたがデプロイを実行したところ、アプリケーションが不安定になりましたが、システムにはアクティブなユーザーがいるように見えます。あなたは、変更をロールバックしてアクティブなユーザーに影響を与えるか、またはユーザーが影響を受ける可能性があることを考慮して変更をロールバックするのを待つかを判断しなければなりません。
+ ルーティンを変更すると、新しい環境はアクセスできますが、サブネットの 1 つにアクセスできなくなります。あなたは、すべてをロールバックするか、アクセスできないサブネットを修正するかを判断しなければなりません。その判断がなされるまでの間、サブネットはアクセスできないままとなります。
**このベストプラクティスを活用するメリット:** 計画を事前に立てることで、失敗からの平均復旧時間 (MTTR) を短縮し、エンドユーザーへの影響を抑えることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 変更の失敗に備える: 変更が望ましい結果をもたらさない場合に、既知の良好な状態に戻す (変更をロールバックする) か、本番環境で修正を行う (変更をロールフォワードする) ことを計画します。失敗した変更をロールバックできないことがわかった場合は、変更をコミットする前にデューデリジェンスを適用します。
# OPS06-BP02 変更をテストし、検証する
あらゆるライフサイクルステージで変更をテストし、その結果を検証することで、新しい機能を確認するとともに、デプロイの失敗のリスクと影響を最小限に抑えます。
AWS では、実験やテストのリスク、労力、コストを削減するために一時的な並列環境を作成できます。これらの環境のデプロイを [AWS CloudFormation](https://aws.amazon.com/cloudformation/) を使用して自動化し、一時環境の実装に一貫性を持たせます。
**一般的なアンチパターン:**
+ あなたは、斬新な新機能をアプリケーションにデプロイします。動作しません。理由はわかりません。
+ あなたは、証明書を更新します。あなたは、意図せずに、誤ったコンポーネントに証明書をインストールします。理由はわかりません。
**このベストプラクティスを活用するメリット:** デプロイ後の変更をテストして検証することで、問題を早期に特定し、顧客への影響を軽減する機会が得られます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 変更をテストし、検証する: あらゆるライフサイクルステージ (開発、テスト、本番など) で変更をテストし、その結果を検証することで、新しい機能を確認するとともに、デプロイの失敗のリスクと影響を最小限に抑えます。
+ [AWS Cloud9](https://aws.amazon.com/cloud9/)
+ [AWS Cloud9 とは](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html)
+ [コードを送信する前に AWS CodeDeploy をローカルでテスト/デバッグする方法](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/)
## リソース
**関連するドキュメント:**
+ [AWS Cloud9](https://aws.amazon.com/cloud9/)
+ [AWS デベロッパーツール](https://aws.amazon.com/products/developer-tools/)
+ [コードを送信する前に AWS CodeDeploy をローカルでテスト/デバッグする方法](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/)
+ [AWS Cloud9 とは](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html)
# OPS06-BP03 デプロイ管理システムを使用する
デプロイ管理システムを使用して変更を追跡および実装します。これにより、手動プロセスによって発生するエラーと、変更をデプロイする労力を減らすことができます。
AWS では、以下のサービスを使用して、継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインを構築できます [AWS デベロッパーツール](https://aws.amazon.com/products/developer-tools/) (例: AWS CodeCommit、 [AWS CodeBuild](https://aws.amazon.com/codebuild/)、 [AWS CodePipeline](https://aws.amazon.com/codepipeline/)、 [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)、および [AWS CodeStar](https://aws.amazon.com/codestar/))。
**一般的なアンチパターン:**
+ あなたがフリート全体でアプリケーションサーバーに対して手動で更新をデプロイしたところ、更新エラーのために多数のサーバーが応答しなくなりました。
+ あなたは、何時間もかけて、アプリケーションサーバーフリートを手動でデプロイします。変更中のバージョンの不整合が、予期しない動作を引き起こします。
**このベストプラクティスを活用するメリット:** デプロイ管理システムを採用することで、変更のデプロイにかける労力のレベルと、手動の手順に起因するエラーの頻度を軽減できます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ デプロイ管理システムを使用する: デプロイ管理システムを使用して変更を追跡および実装します。これにより、手動プロセスによって発生するエラーと、変更をデプロイする労力が減ります。テスト、デプロイ、検証を通じたコードのチェックインから統合とデプロイのパイプラインを自動化します。これにより、リードタイムが減り、変更の頻度を増やすことが可能になるとともに、必要な労力がさらに減ります。
+ [AWS CodeDeploy の紹介 - Amazon Web Services を使用したソフトウェアの自動デプロイ](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [AWS CodeDeploy とは](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Elastic Beanstalk とは](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html)
+ [Amazon API Gateway とは](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)
## リソース
**関連するドキュメント:**
+ [AWS CodeDeploy ユーザーガイド](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS デベロッパーツール](https://aws.amazon.com/products/developer-tools/)
+ [AWS CodeDeploy でブルー/グリーンデプロイのサンプルを試す](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [AWS CodeDeploy とは](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Elastic Beanstalk とは](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html)
+ [Amazon API Gateway とは](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)
**関連動画:**
+ [AWS を使用した高度な継続的デリバリーテクニックの詳細](https://www.youtube.com/watch?v=Lrrgd0Kemhw)
+ [AWS CodeDeploy の紹介 - Amazon Web Services を使用したソフトウェアの自動デプロイ](https://www.youtube.com/watch?v=Wx-ain8UryM)
# OPS06-BP04 限定的なデプロイを使用してテストする
完全なデプロイを行う前に、既存のシステムと並行して限定的なデプロイを実施してテストを行い、望ましい結果が得られるかどうか確認します。例えば、デプロイ Canary テストまたはワンボックスデプロイを使用します。
**一般的なアンチパターン:**
+ あなたは、失敗した変更を一度にすべての本稼働環境にデプロイします。あなたにはわかりません。
**このベストプラクティスを確立するメリット:** 制限されたデプロイ後の変更をテストして検証することで、顧客への影響を最小限に抑えながら、問題を早期に特定し、顧客への影響をさらに軽減する機会が得られます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 限定的なデプロイを使用してテストする: 本格的なデプロイの前に、既存のシステムと一緒に限定的にデプロイしてテストを行い、期待される結果が得られるかどうかを確認します。例えば、デプロイ Canary テストまたはワンボックスデプロイを使用します。
+ [AWS CodeDeploy ユーザーガイド](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Elastic Beanstalk を使用したブルー/グリーンデプロイ](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
+ [API Gateway Canary リリースデプロイの設定](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [Try a Sample Blue/Green Deployment in AWS CodeDeploy (AWS CodeDeploy でブルー/グリーンデプロイのサンプルを試す)](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [Working with deployment configurations in AWS CodeDeploy (AWS CodeDeploy でのデプロイ構成の操作)](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
## リソース
**関連するドキュメント:**
+ [AWS CodeDeploy ユーザーガイド](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Elastic Beanstalk を使用したブルー/グリーンデプロイ](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
+ [API Gateway Canary リリースデプロイの設定](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [Try a Sample Blue/Green Deployment in AWS CodeDeploy (AWS CodeDeploy でブルー/グリーンデプロイのサンプルを試す)](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [Working with deployment configurations in AWS CodeDeploy (AWS CodeDeploy でのデプロイ構成の操作)](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
# OPS06-BP05 並列環境でデプロイする
並列環境に変更を実装し、その後、新しい環境に移行します。デプロイの成功を確認するまで、以前の環境を維持します。こうすることで、以前の環境へのロールバックが可能になり、復旧時間を最小限に抑えることができます。
**一般的なアンチパターン:**
+ あなたは、既存のシステムを変更することにより、変更可能なデプロイを実行します。変更が失敗したことを検出した後、あなたは、システムを再度変更して古いバージョンを復元するよう命じられ、これにより、復旧までの時間がより長くかかります。
+ あなたは、メンテナンスウィンドウ中に、古い環境を停止してから、新しい環境の構築を開始します。この手順には何時間もかかり、あなたは、デプロイに復旧できない問題を検出します。非常に疲れていますが、あなたは、以前のデプロイの手順を探し、古い環境の再構築を開始するように命じられます。
**このベストプラクティスを活用するメリット:** 並列環境を使用することで、新しい環境を事前にデプロイし、必要に応じて環境に移行できます。新しい環境が失敗した場合は、元の環境に戻すことで、すばやく復旧できます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 並列環境でデプロイする: 並列環境に変更を実装し、その後、新しい環境に移行またはカットオーバーします。デプロイの成功を確認するまで、以前の環境を維持します。こうすることで、以前の環境へのロールバックが可能になり、復旧時間を最小限に抑えることができます。例えば、ブルー/グリーンデプロイでイミュータブルインフラストラクチャを使用します。
+ [AWS CodeDeploy でのデプロイ構成の操作](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
+ [AWS Elastic Beanstalk を使用したブルー/グリーンデプロイ](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
+ [API Gateway Canary リリースデプロイの設定](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [AWS CodeDeploy でブルー/グリーンデプロイのサンプルを試す](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
## リソース
**関連するドキュメント:**
+ [AWS CodeDeploy ユーザーガイド](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Elastic Beanstalk を使用したブルー/グリーンデプロイ](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
+ [API Gateway Canary リリースデプロイの設定](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [AWS CodeDeploy でブルー/グリーンデプロイのサンプルを試す](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [AWS CodeDeploy でのデプロイ構成の操作](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
**関連動画:**
+ [AWS を使用した高度な継続的デリバリーテクニックの詳細](https://www.youtube.com/watch?v=Lrrgd0Kemhw)
# OPS06-BP06 小規模で可逆的な変更を頻繁にデプロイする
小規模で可逆的な変更を頻繁に行うことで、変更の範囲を減らします。これにより、トラブルシューティングが容易になり、修復がすばやくできるようになります。また、変更をロールバックすることもできます。
**一般的なアンチパターン:**
+ あなたは、四半期ごとに、アプリケーションの新しいバージョンをデプロイします。
+ あなたは、データベーススキーマに対して頻繁に変更を加えます。
+ あなたは、手動のインプレースアップグレードを実行し、既存のインストールと設定を上書きします。
**このベストプラクティスを活用するメリット:** 小さな変更を頻繁にデプロイすることで、開発にかける労力から得られる恩恵をすばやく認識できます。変更が小さい場合、意図しない結果が発生するかどうかを識別することがより容易になります。変更を元に戻すことができる場合、復旧が簡素化されるため、変更を実装するリスクが低減されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ 小規模で可逆的な変更を頻繁にデプロイする: 頻繁に、小さく、可逆的な変更を使用することで、変更の範囲を縮小します。これにより、トラブルシューティングが容易になり、修復がすばやくできるようになります。また、変更をロールバックすることもできます。
# OPS06-BP07 統合とデプロイを完全自動化する
ワークロードのビルド、デプロイ、テストを自動化します。これにより、手動プロセスによって発生するエラーと、変更をデプロイする労力を減らすことができます。
一貫したタグ付け戦略に従って [リソースタグ](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) および [AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/APIReference/Welcome.html) を使用して [メタデータを適用し、](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/) リソースの識別を可能にします。組織、原価計算、アクセスコントロールのリソースにタグを付け、自動化された運用アクティビティの実行に的を絞ります。
**一般的なアンチパターン:**
+ 金曜日に、あなたは、機能ブランチ用の新しいコードの作成を完了します。月曜日に、あなたは、コード品質テストスクリプトと各ユニットテストスクリプトを実行した後、予定された次のリリースのためにコードをチェックインします。
+ あなたは、本稼働中の多数の顧客に影響を与える重要な問題の修正コードを記述するように指示されます。修正をテストした後、あなたは、コードと E メールの変更管理をコミットして、本稼働環境にデプロイするための承認をリクエストします。
**このベストプラクティスを活用するメリット:** 自動化されたビルドおよびデプロイ管理システムを実装することで、手動プロセスにより発生するエラーを削減し、変更をデプロイする労力を減らして、チームメンバーがビジネス価値の提供に注力できるようにします。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ 構築およびデプロイ管理システムを使用する: ビルドおよびデプロイ管理システムを使用して、変更を追跡、実装し、手動プロセスによって発生するエラーと労力を減らすことができます。構築、テスト、デプロイ、検証を通じたコードのチェックインから統合とデプロイのパイプラインを完全自動化します。これにより、リードタイムを削減し、変更の頻度を増やすことが可能になり、それにかかわる労力のレベルを減らすことができます。
+ [AWS CodeBuild とは](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [ソフトウェア開発のための継続的インテグレーションのベストプラクティス](https://www.youtube.com/watch?v=GEPJ7Lo346A)
+ [Slalom: AWS のサーバーレスアプリケーション用の CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
+ [AWS CodeDeploy の紹介 - Amazon Web Services を使用したソフトウェアの自動デプロイ](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [AWS CodeDeploy とは](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS を使用した高度な継続的デリバリーテクニックの詳細](https://www.youtube.com/watch?v=Lrrgd0Kemhw)
## リソース
**関連するドキュメント:**
+ [AWS CodeDeploy でブルー/グリーンデプロイのサンプルを試す](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [AWS CodeBuild とは](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS CodeDeploy とは](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**関連動画:**
+ [ソフトウェア開発のための継続的インテグレーションのベストプラクティス](https://www.youtube.com/watch?v=GEPJ7Lo346A)
+ [AWS を使用した高度な継続的デリバリーテクニックの詳細](https://www.youtube.com/watch?v=Lrrgd0Kemhw)
+ [AWS CodeDeploy の紹介 - Amazon Web Services を使用したソフトウェアの自動デプロイ](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [Slalom: AWS のサーバーレスアプリケーション用の CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
# OPS06-BP08 テストとロールバックを自動化する
デプロイした環境のテストを自動化し、望ましい結果が得られるかどうか確認します。結果が得られなかった場合に、以前の正常な状態へのロールバックを自動化し、復旧時間を最小限に抑え、手動プロセスによるエラーを低減します。
**一般的なアンチパターン:**
+ あなたは、ワークロードに変更をデプロイします。変更が完了したことを確認した後、あなたは、デプロイ後のテストを開始します。テストが完了したことを確認した後、あなたは、ワークロードが操作不可であり、顧客の接続が切断されたことに気づきます。その後、あなたは、以前のバージョンへのロールバックを開始します。問題を検出するのに長い時間をかけた後、復旧にかかる時間は、手動による再デプロイによってさらに長くなります。
**このベストプラクティスを確立するメリット:** デプロイ後の変更をテストして検証することで、問題をすぐに特定できます。以前のバージョンに自動的にロールバックすることで、顧客への影響を最小限に抑えることができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
+ テストとロールバックを自動化する: デプロイした環境のテストを自動化し、望ましい結果が得られるかどうか確認します。結果が得られなかった場合に、以前の正常な状態へのロールバックを自動化し、復旧時間を最小限に抑え、手動プロセスによるエラーを低減します。例えば、デプロイ後に詳細な合成ユーザートランザクションを実施し、その結果を確認して、失敗した場合にはロールバックします。
+ [Redeploy and roll back a deployment with AWS CodeDeploy (AWS CodeDeploy を使用した再デプロイとロールバック)](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html)
## リソース
**関連するドキュメント:**
+ [Redeploy and roll back a deployment with AWS CodeDeploy (AWS CodeDeploy を使用した再デプロイとロールバック)](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html)
# 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 システムや変更をデプロイするために十分な情報に基づいて決定を下す
ワークロードと、ワークロードのガバナンスとのコンプライアンスをサポートするためにチームの能力を評価します。システムを移行するか、本番環境に変更するかどうかを判断する際に、これらをデプロイの利点に対して評価します。メリットとリスクを理解し、十分な情報に基づく決定を下します。
プレモータムは、チームが行う演習で、ここでは軽減戦略を策定するために障害のシミュレーションを行います。プレモータムを使用して、障害を予測し、必要に応じて手順を作成します。ワークロードを評価するために使用するチェックリストに変更を加える場合は、もう準拠していない本番システムで行うことを計画します。
**一般的なアンチパターン:**
+ ワークロードに存在するセキュリティリスクを理解することなく当該ワークロードのデプロイを決定する。
+ ワークロードがガバナンスと標準に準拠しているかどうかを理解することなく当該ワークロードのデプロイを決定する。
+ チームがサポートできるかどうかを理解することなくワークロードのデプロイを決定する。
+ 組織にどのようなメリットがあるかを理解することなくワークロードのデプロイを決定する。
**このベストプラクティスを活用するメリット:** スキルのあるチームメンバーを持つことで、ワークロードを効果的にサポートできます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ ワークロードや変更をデプロイするために十分な情報に基づいて決定を下す: ワークロードと、ワークロードのガバナンスとのコンプライアンスをサポートするためにチームの能力を評価します。システムを移行するか、本番環境に変更するかどうかを判断する際に、これらをデプロイの利点に対して評価します。メリットとリスクを理解し、十分な情報に基づく決定を下します。