

# OPS 5 欠陥を減らし、修正を簡単にし、本番環境へのフローを改善するにはどうすればよいですか?
<a name="w2aac19b5b7b7"></a>

 リファクタリング、品質についてのすばやいフィードバック、バグ修正を可能にし、本番環境への変更のフローを改善するアプローチを採用します。これらにより、本番環境に採用される有益な変更を加速させ、デプロイされた問題を制限できます。またデプロイアクティビティを通じて挿入された問題をすばやく特定し、修復できます。 

**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 バージョン管理を使用する
<a name="ops_dev_integ_version_control"></a>

 変更とリリースの追跡を有効にするにはバージョン管理を使用します。 

 AWS の多くのサービスには、バージョン管理機能が備わっています。リビジョンまたはソース管理システム、例えば [AWS CodeCommit](https://aws.amazon.com/codecommit/) コードや他のアーティファクト (インフラストラクチャのバージョン管理された [AWS CloudFormation](https://aws.amazon.com/cloudformation/) テンプレートなど) を管理します。 

 **一般的なアンチパターン:** 
+  あなたは、コードを開発し、ワークステーションに保存しました。ワークステーションで回復不可能なストレージ障害が発生し、コードが失われました。 
+  既存のコードを変更で上書きした後、アプリケーションを再起動すると、操作できなくなりました。あなたは、変更を元に戻すことができません。 
+  あなたは、レポートファイルへの書き込みをロックされており、他の誰かが編集する必要があります。編集をしようとする者は、タスクを完了できるように、作業を停止するようにあなたに求めています。 
+  研究チームは、今後の業務を形作る詳細な分析に取り組んでいます。誰かが誤って買い物リストを最終レポートに上書きして保存してしまいました。あなたは変更を元に戻すことができず、レポートを再作成する必要があります。 

 **このベストプラクティスを確立するメリット:** バージョン管理機能を使用すると、既知の良好な状態や以前のバージョンに簡単に戻すことができ、アセットが失われるリスクを低減できます。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  バージョン管理を使用する: バージョン管理されたレポジトリでアセットを維持します。そうすることで、変更の追跡、新しいバージョンのデプロイ、既存バージョンへの変更の検出、以前のバージョンの回復 (障害が発生する場合に、その前の良好な状態に戻すなど) をサポートします。構成管理システムのバージョン管理機能を手順に統合します。 
  +  [AWS CodeCommit の紹介](https://youtu.be/46PRLMW8otg) 
  +  [AWS CodeCommit とは](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS CodeCommit とは](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) 

 **関連動画:** 
+  [AWS CodeCommit の紹介](https://youtu.be/46PRLMW8otg) 

# OPS05-BP02 変更をテストし、検証する
<a name="ops_dev_integ_test_val_chg"></a>

 エラーの制限と検出に役立てるため、変更をテスト、検証します。手動プロセスによって発生するエラーと、テストにかかる労力を減らすためにテストを自動化します。 

 AWS の多くのサービスには、バージョン管理機能が備わっています。AWS CodeCommit などのリビジョンまたはソース管理システムを [使用して、](https://aws.amazon.com/codecommit/) コードや他のアーティファクト (インフラストラクチャのバージョン管理された [AWS CloudFormation](https://aws.amazon.com/cloudformation/) テンプレートなど) を管理します。 

 **一般的なアンチパターン:** 
+  あなたが新しいコードを本稼働環境にデプロイしたところ、アプリケーションが機能しなくなったため、顧客からの電話が鳴りはじめました。 
+  あなたは、ペリメータセキュリティを強化するために新しいセキュリティグループを適用します。機能しましたが、意図しない結果が発生し、ユーザーがアプリケーションにアクセスできなくなっています。 
+  あなたは、新しい機能によって呼び出されるメソッドを変更します。もう 1 つの機能もそのメソッドに依存しており、機能しなくなりました。問題は検出されず、本稼働環境に入ります。もう 1 つの当該機能はしばらくの間呼び出されず、結局、原因との相関なしに本稼働環境で失敗します。 

 **このベストプラクティスを活用するメリット:** 変更を早期にテストして検証することで、コストを最小限に抑えて問題に対処し、顧客への影響を抑えることができます。デプロイ前にテストすることで、エラーの発生を最小限に抑えることができます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  変更をテストし、検証する: すべてのライフサイクルステージ (開発、テスト、本番環境など) で変更をテストし、その結果を検証してください。テスト結果を使用して、新機能を確認し、失敗したデプロイのリスクと影響を緩和します。テストと検証を自動化し、レビューの一貫性を確保し、手動プロセスによって発生するエラーとそれにかかる労力を減らすことができます。 
  +  [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/) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [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 設定管理システムを使用する
<a name="ops_dev_integ_conf_mgmt_sys"></a>

 設定を変更し、変更を追跡記録するには、構成管理システムを使用します。これらのシステムは、手動プロセスによって発生するエラーと、変更を導入する労力を減らします。 

 静的な構成管理では、ライフタイムを通じて一貫性を維持することが期待されるリソースの初期化時に値を設定します。このケースの例として、インスタンス上のアプリケーションサーバーまたはウェブサーバー用の構成を設定する場合や、 [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 アクティビティの実行を指定した時間にスケジュールできます。これらのアクティビティを評価に含めることができるように、変更カレンダー上で印を付けます。 

 **一般的なアンチパターン:** 
+  あなたがフリート全体でウェブサーバー設定を手動で更新したところ、更新エラーのために多数のサーバーが応答しなくなりました。 
+  あなたは、何時間もかけて、アプリケーションサーバーフリートを手動で更新します。変更中の設定の不整合が、予期しない動作を引き起こします。 
+  誰かがセキュリティグループを更新したため、ウェブサーバーにアクセスできなくなりました。変更内容を把握しなければ、問題の調査にかなりの時間を費やすことになり、復旧までより長くの時間を要することになります。 

 **このベストプラクティスを活用するメリット:** 設定管理システムを採用することで、変更やその追跡の労力のレベルと、手動の手順に起因するエラーの頻度を軽減できます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  設定管理システムを使用する: 設定管理システムを使用して、変更を追跡、実装し、手動プロセスによって発生するエラーと労力を減らすことができます。 
  +  [インフラストラクチャ設定管理](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) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [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 構築およびデプロイ管理システムを使用する
<a name="ops_dev_integ_build_mgmt_sys"></a>

 構築およびデプロイ管理システムを使用します。これらのシステムは、手動プロセスによって発生するエラーと、変更を導入する労力を減らします。 

 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 が失敗します。 
+  金曜日に、多くの労力をかけて、開発環境でアプリケーションを手動で構築することができました。これには、新しくコード化された機能も含まれます。月曜日に、あなたは、アプリケーションを正常に構築することを可能にするステップを繰り返すことができません。 
+  あなたは、新しいリリース用に作成したテストを実行します。その後、あなたは、翌週いっぱいをかけて、テスト環境をセットアップし、すべての既存の統合テストを実行してから、パフォーマンステストを実行します。新しいコードには許容できないパフォーマンスへの影響があり、再開発してから再テストする必要があります。 

 **このベストプラクティスを活用するメリット:** ビルドとデプロイのアクティビティを管理するメカニズムを提供することで、反復的なタスクを実行するための労力の程度を減らし、チームメンバーは高価値のクリエイティブなタスクに専念し、手動の手順によるエラーの発生を抑制できます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  構築およびデプロイ管理システムを使用する: ビルドおよびデプロイ管理システムを使用して、変更を追跡、実装し、手動プロセスによって発生するエラーと労力を減らすことができます。構築、テスト、デプロイ、検証を通じたコードのチェックインから統合とデプロイのパイプラインを完全自動化します。これにより、リードタイムを削減し、変更の頻度を増やすことが可能になり、それにかかわる労力のレベルを減らすことができます。 
  +  [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) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [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 パッチ管理を実行する
<a name="ops_dev_integ_patch_mgmt"></a>

 パッチ管理を実行し、問題を解決して、ガバナンスに準拠するようにします。パッチ管理の自動化により、手動プロセスによって発生するエラーと、パッチにかかる労力を減らすことができます。 

 パッチと脆弱性の管理は、メリットとリスクを管理するアクティビティの一環です。不変のインフラストラクチャを使用し、検証済みの正常な状態でワークロードをデプロイすることが推奨されます。これが不可能な場合は、残りのオプションとしてパッチの適用があります。 

 マシンイメージ、コンテナイメージ、または 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 時間以内に適用するために権限が付与されました。その結果、アプリケーションにパッチとの互換性がないため、複数の機能停止が発生しました。 
+  パッチが適用されていないライブラリは、不明な関係者がライブラリ内の脆弱性を使用してワークロードにアクセスするため、意図しない結果をもたらします。 
+  あなたは、開発者に通知することなく、自動的に開発者環境にパッチを適用します。あなたには、開発者から、環境が想定どおりに動作しなくなったという苦情が複数寄せられます。 
+  あなたは、永続的なインスタンスの商用オフザシェルフのセルフソフトウェアにパッチを適用していません。ソフトウェアに問題があり、ベンダーに連絡すると、ベンダーから、バージョンがサポートされておらず、サポートを受けるためには、特定のレベルにパッチを適用する必要があることが伝えられます。 
+  あなたが使用した暗号化ソフトウェアの最近リリースされたパッチにより、パフォーマンスが大幅に向上します。パッチが適用されていないあなたのシステムには、パッチを適用しない結果として、パフォーマンスの問題が残存しています。 

 **このベストプラクティスを活用するメリット:** パッチ適用の基準や環境全体への配布方法など、パッチ管理プロセスを確立することで、それらの利点を実現し、影響を制御することができます。これにより、必要な機能と能力の導入、問題の除去、ガバナンスの継続的な遵守が可能になります。パッチ管理システムと自動化を実装して、パッチをデプロイする労力を軽減し、手動プロセスに起因するエラーの発生を抑制します。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  パッチ管理: 問題の修正、希望する機能や能力の取得、ガバナンスポリシーやベンダーのサポート要件への準拠継続を行うためにはシステムをパッチします。変更不可能なシステムでは、必要な成果を達成するために適切なパッチを使用してデプロイします。パッチ管理メカニズムの自動化により、パッチの経過時間、手動プロセスによって発生するエラーと、パッチにかかわる労力を減らすことができます。 
  +  [AWS Systems Manager パッチマネージャーを使用して](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [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 設計標準を共有する
<a name="ops_dev_integ_share_design_stds"></a>

 チーム全体でベストプラクティスを共有し、デプロイ作業における利点の認識を高め、それを最大限にします。 

 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 を使って新しいバージョンを入手できます。 

 組織内で共有された標準が適用されている場合、チームのアクティビティをサポートする標準の追加、変更、例外をリクエストするメカニズムを持つことは重要です。このオプションがなければ、標準はイノベーションの障壁になります。 

 **一般的なアンチパターン:** 
+  あなたは、組織内の他の各開発チームが作成したように、独自のユーザー認証メカニズムを作成しました。ユーザーは、アクセスするシステムの各部分について、個別の一連の認証情報を維持する必要があります。 
+  あなたは、組織内の他の各開発チームが作成したように、独自のユーザー認証メカニズムを作成しました。組織には、遵守されなければならない新しいコンプライアンス要件が与えられています。個々の開発チームには、新しい要件を実装するためにリソースに投資する必要が生じました。 
+  あなたは、組織内の他の各開発チームが作成したように、独自の画面レイアウトを作成しました。整合性のないインターフェイスを操作することが困難であることについて、ユーザーが苦情を申し出ています。 

 **このベストプラクティスを活用するメリット:** 標準が複数のアプリケーションや組織の要件を満たしている場合は、ベストプラクティスの採用をサポートし、開発にかける労力から得られる恩恵を最大化するために、共有された標準を使用します。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  設計標準を共有する: 既存のベストプラクティス、設計標準、チェックリスト、運用手順、ガイダンス、ガバナンスの要件をチーム間で共有し、複雑になるのを防ぎながら開発努力の成果を最大化する継続的な改善とイノベーションを支援するために、設計標準の変更、追加、例外を申請する手順を設けます。チームが公開済みのコンテンツを把握していることを確認し、コンテンツを活用して、やり直しや無駄な労力を制限します。 
  +  [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) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [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 コード品質の向上のためにプラクティスを実装する
<a name="ops_dev_integ_code_quality"></a>

 コード品質の向上のためにプラクティスを実装し、欠陥を最小限に抑えます。例えば、テスト駆動型開発、コードレビュー、標準の導入などがあります。 

 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 のベストプラクティスを実装するためのレコメンデーションを提供します。 

 **一般的なアンチパターン:** 
+  あなたは、機能をより迅速にテストできるように、標準入力サニタイズライブラリを統合しないことに決めました。テスト後、あなたは、ライブラリの組み込みを完了することを思い出すことなく、コードをコミットします。 
+  あなたには、処理しているデータセットに関する経験がほとんどないため、データセット内に一連のエッジケースが存在し得ることを認識していません。これらのエッジケースには、実装したコードとの互換性がありません。 

 **このベストプラクティスを活用するメリット:** コードの品質を向上させるためのプラクティスを採用することは、本稼働環境に発生する問題を最小限に抑えることに役立ちます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  コード品質の向上のためにプラクティスを実装する: プラクティスを実装して、コード品質を向上させ、欠陥と欠陥がデプロイされるリスクを最低限に抑えます。例えば、テスト駆動型デプロイ、ペアプログラミング、コードレビュー、規約の導入などがあります。 
  +  [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) 

# OPS05-BP08 複数の環境を使用する
<a name="ops_dev_integ_multi_env"></a>

 ワークロードの実験、開発、テストを行うには、複数の環境を使用します。環境が本稼働環境に近づくにつれて増加するコントロールレベルを使用して、デプロイ時にワークロードが意図したとおりに運用するように確信を強化します。 

 **一般的なアンチパターン:** 
+  あなたは、共有開発環境で開発を実行しており、別の開発者があなたのコードの変更を上書きします。 
+  共有開発環境の制限的なセキュリティ制御により、あなたは新しいサービスや機能を試すことができません。 
+  あなたは本稼働用システムで負荷テストを実行し、ユーザーの機能停止を引き起こします。 
+  データ損失につながる重大なエラーが本稼働環境で発生しました。あなたは、データ損失がどのように発生したかを特定し、これを再び発生させないようにするため、本稼働環境において、データ損失につながる条件を再現しようとします。テスト中のさらなるデータ損失を防ぐため、あなたは、ユーザーがアプリケーションを使用できないようにすることを強制されます。 
+  あなたは、マルチテナントサービスを運用しており、専用環境に対する顧客のリクエストをサポートできません。 
+  あなたは常にテストするわけではありませんが、テストする場合は本稼働環境で行います。 
+  あなたは、単一環境というシンプルさが、環境内での変更の影響範囲に勝ると考えています。 

 **このベストプラクティスを活用するメリット:** 複数の環境をデプロイすることで、開発者やユーザーコミュニティ間で競合を生じさせることなく、複数の同時開発、テスト、本稼働環境をサポートできます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  複数の環境を使用する: 開発者が実験できるように、最小のコントロールのサンドボックス環境を提供します。連携できるように個々の開発環境を提供し、開発の俊敏性を増します。開発者がイノベーションを試せるように、本番に近い環境でより厳格なコントロールを実装します。コードとしてインフラストラクチャを使用したり、構成管理システムを使用したりして本番環境に存在するコントロールに準拠して設定された環境をデプロイし、システムがデプロイ時に予想どおりに動作することを確認します。環境を使用しない場合は、オフにして、アイドル状態のリソース (夜間や週末の開発システムなど) に関連するコストを避けることができます。ロードテストで妥当な結果を有効にする場合、本番に相当する環境をデプロイします。 
  +  [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/) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [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 小規模かつ可逆的な変更を頻繁に行う
<a name="ops_dev_integ_freq_sm_rev_chg"></a>

 頻繁に、小さく、可逆的な変更を行うことで、変更の範囲と影響を減らします。これにより、トラブルシューティングが容易になり、修復がすばやくできるようになります。また変更を元に戻すこともできます。 

 **一般的なアンチパターン:** 
+  あなたは、四半期ごとに、アプリケーションの新しいバージョンをデプロイします。 
+  あなたは、データベーススキーマに対して頻繁に変更を加えます。 
+  あなたは、手動のインプレースアップグレードを実行し、既存のインストールと設定を上書きします。 

 **このベストプラクティスを活用するメリット:** 小さな変更を頻繁にデプロイすることで、開発にかける労力から得られる恩恵をすばやく認識できます。変更が小さい場合、意図しない結果が発生するかどうかを識別することがより容易になります。変更を元に戻すことができる場合、復旧が簡素化されるため、変更を実装するリスクが低減されます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 低 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  小規模で可逆的な変更を頻繁に行う: 頻繁に、小さく、可逆的な変更を行うことで、変更の範囲と影響を縮小します。これにより、トラブルシューティングが容易になり、修復がすばやくできるようになります。また変更を元に戻すこともできます。また、ビジネスに価値をもたらす速度も向上します。 

# OPS05-BP10 統合とデプロイを完全自動化する
<a name="ops_dev_integ_auto_integ_deploy"></a>

 ワークロードのビルド、デプロイ、テストを自動化します。これにより、手動プロセスによって発生するエラーと、変更をデプロイする労力を減らすことができます。 

 一貫したタグ付け戦略に従って [リソースタグ](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/) リソースの識別を可能にします。組織、原価計算、アクセスコントロールのリソースにタグを付け、自動化された運用アクティビティの実行に的を絞ります。 

 **一般的なアンチパターン:** 
+  金曜日に、あなたは、機能ブランチ用の新しいコードの作成を完了します。月曜日に、あなたは、コード品質テストスクリプトと各ユニットテストスクリプトを実行した後、予定された次のリリースのためにコードをチェックインします。 
+  あなたは、本稼働中の多数の顧客に影響を与える重要な問題の修正コードを記述するように指示されます。修正をテストした後、あなたは、コードをコミットし、変更管理部門にメールで本番環境へのデプロイの承認を依頼します。 

 **このベストプラクティスを確立するメリット:** 自動化されたビルドおよびデプロイ管理システムを実装することで、手動プロセスにより発生するエラーを削減し、変更をデプロイする労力を減らして、チームメンバーがビジネス価値の提供に注力できるようにします。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  構築およびデプロイ管理システムを使用する: ビルドおよびデプロイ管理システムを使用して、変更を追跡、実装し、手動プロセスによって発生するエラーと労力を減らすことができます。構築、テスト、デプロイ、検証を通じたコードのチェックインから統合とデプロイのパイプラインを完全自動化します。これにより、リードタイムを削減し、変更の頻度を増やすことが可能になり、それにかかわる労力のレベルを減らすことができます。 
  +  [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) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [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) 