# 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 変更をテストし、検証する
デプロイされた変更はすべてテストし、本稼働でのエラーを回避する必要があります。このベストプラクティスは、バージョンコントロールからアーティファクトビルドへの変更をテストすることに重点を置いています。テストには、アプリケーションコードの変更に加えて、インフラストラクチャ、設定、セキュリティコントロール、運用手順も含める必要があります。テストは、単体テストからソフトウェアコンポーネント分析 (SCA) まで、さまざまな形態があります。ソフトウェアの統合および配信プロセスでテストをさらに早めると、アーティファクト品質の確実性が増します。
組織はすべてのソフトウェアアーティファクトにおいてテスト基準を作成する必要があります。テストを自動化すると、手間を軽減し、手動テストによるエラーを回避できます。手動テストが必要な場合もあります。開発者は自動テストの結果を確認して、ソフトウェアの品質を向上させるフィードバックループを作成する必要があります。
**期待される成果:**
+ ソフトウェアの変更は、配信前にすべてテストされる。
+ 開発者はテスト結果を利用できる。
+ 組織に、すべてのソフトウェア変更に適用されるテスト基準がある。
**一般的なアンチパターン:**
+ ソフトウェアの新しい変更を、テストせずにデプロイする。本稼働で実行に失敗し、その結果サービスが停止する。
+ 新しいセキュリティグループが、本番前環境でのテストをせずに CloudFormation にデプロイされる。そのセキュリティグループによって、ユーザーがアプリにアクセスできなくなる。
+ メソッドが変更されたが単体テストがなかった。本稼働にデプロイされた際にソフトウェアが失敗した。
**このベストプラクティスを活用するメリット:**
+ ソフトウェアのデプロイにおける変更失敗率が軽減されます。
+ ソフトウェアの品質が向上します。
+ 開発者のコードの成立性に対する意識が上がります。
+ セキュリティポリシーを確信を持ってロールアウトし、組織のコンプライアンスをサポートできます。
+ 自動スケーリングポリシーの更新などインフラストラクチャの変更を事前にテストし、トラフィックのニーズを満たすことができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
継続的統合の実践の一部として、アプリケーションコードからインフラストラクチャまで、すべての変更に対してテストを行います。テスト結果は、開発者が迅速にフィードバックを得られるように公開します。組織に、すべてのソフトウェア変更に適用されるテスト基準を備えます。
**お客様事例**
AnyCompany Retail は、継続的な統合パイプラインの一部として、すべてのソフトウェアアーティファクトに対して複数種類のテストを実行しています。テスト駆動開発を実践しているため、すべてのソフトウェアに単体テストがあります。アーティファクトがビルドされると、エンドツーエンドのテストが実行されます。1 ラウンド目のテストが完了すると、静的アプリケーションセキュリティスキャンを実行し、既知の脆弱性を探します。開発者は、各テストに合格するたびにメッセージを受け取ります。すべてのテストが完了すると、ソフトウェアアーティファクトはアーティファクトリポジトリに保存されます。
**実装手順**
1. 組織の関係者と協力して、ソフトウェアアーティファクトのテスト基準を作成します。すべてのアーティファクトが合格しなければならない基準のテストとは何でしょうか? テスト範囲に含める必要があるコンプライアンスやガバナンスの要件はありますか? コード品質テストを実施する必要がありますか? テストが完了した際に通知が必要なのは誰ですか?
1. [AWS デプロイパイプラインリファレンスアーキテクチャ](https://pipelines.devops.aws.dev/)には、統合パイプラインの一部としてソフトウェアアーティファクトに対して実行できる、テストの種類の信頼できるリストが含まれています。
1. ソフトウェアテスト基準に基づいて必要なテストを行い、アプリケーションを計測します。テストの各セットは 10 分以内に完了する必要があります。テストは統合パイプラインの一部として実行する必要があります。
1. [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) では、アプリケーションコードをテストして欠陥を検出できます。
1. [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) を使用して、ソフトウェアアーティファクトに対しテストを実施できます。
1. [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアテストをパイプラインに組み込むことができます。
## リソース
**関連するベストプラクティス:**
+ [OPS05-BP01 バージョン管理を使用する](ops_dev_integ_version_control.md) - すべてのソフトウェアアーティファクトはバージョン管理されたリポジトリにバックアップされる必要があります。
+ [OPS05-BP06 設計標準を共有する](ops_dev_integ_share_design_stds.md) - 組織のソフトウェアテスト基準によって、設計基準がわかります。
+ [OPS05-BP10 統合とデプロイを完全自動化する](ops_dev_integ_auto_integ_deploy.md) - ソフトウェアテストは、より大きな統合およびデプロイパイプラインの一部として、自動で実行する必要があります。
**関連するドキュメント:**
+ [ Adopt a test-driven development approach ](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)(テスト駆動の開発アプローチを導入する)
+ [ Automated CloudFormation Testing Pipeline with TaskCat and CodePipeline ](https://aws.amazon.com/blogs/devops/automated-cloudformation-testing-pipeline-with-taskcat-and-codepipeline/)(TaskCat と CodePipeline を使用した自動 CloudFormation テストパイプライン)
+ [ Building end-to-end AWS DevSecOps CI/CD pipeline with open source SCA, SAST, and DAST tools ](https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/)(オープンソースの SCA、SAST、DAST ツールを使用してエンドツーエンドの AWS DevSecOps CI/CD パイプラインを構築する)
+ [ Getting started with testing serverless applications ](https://aws.amazon.com/blogs/compute/getting-started-with-testing-serverless-applications/)(サーバーレスアプリケーションのテストを開始する)
+ [ My CI/CD pipeline is my release captain ](https://aws.amazon.com/builders-library/cicd-pipeline/) (CI/CD パイプラインが自分のリリースキャプテン)
+ [「AWS における継続的インテグレーションと継続的デリバリーの実践」ホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html)
**関連動画:**
+ [AWS re:Invent 2020: Testable infrastructure: Integration testing on AWS](https://www.youtube.com/watch?v=KJC380Juo2w)(re:Invent 2020: テスト可能なインフラストラクチャ: AWS での統合テスト)
+ [AWS Summit ANZ 2021 - Driving a test-first strategy with CDK and test driven development ](https://www.youtube.com/watch?v=1R7G_wcyd3s)(Summit ANZ 2021 - CDK とテスト駆動開発でテストファースト戦略を獲得する)
+ [ Testing Your Infrastructure as Code with AWS CDK ](https://www.youtube.com/watch?v=fWtuwGSoSOU)(AWS CDK で Infrastructure as Code をテストする)
**関連リソース:**
+ [AWS デプロイパイプラインリファレンスアーキテクチャ - アプリケーション](https://pipelines.devops.aws.dev/application-pipeline/index.html)
+ [AWS Kubernetes DevSecOps パイプライン ](https://github.com/aws-samples/devsecops-cicd-containers)
+ [ Policy as Code Workshop – Test Driven Development ](https://catalog.us-east-1.prod.workshops.aws/workshops/9da471a0-266a-4d36-8596-e5934aeedd1f/en-US/pac-tools/cfn-guard/tdd)(Policy as Code ワークショップ - テスト駆動開発)
+ [ Run unit tests for a Node.js application from GitHub by using AWS CodeBuild](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/run-unit-tests-for-a-node-js-application-from-github-by-using-aws-codebuild.html)(AWS CodeBuild を使用して GitHub から Node.js アプリケーションの単体テストを実行する)
+ [ Use Serverspec for test-driven development of infrastructure code ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/use-serverspec-for-test-driven-development-of-infrastructure-code.html)(インフラストラクチャコードのデータ駆動開発に Serverspec を使用する)
**関連サービス:**
+ [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/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 設計標準を共有する
チーム全体でベストプラクティスを共有し、デプロイ作業における利点の認識を高め、それを最大限にします。標準を文書化し、アーキテクチャの進化に応じて最新の内容となるよう維持します。組織内で共有された標準が適用されている場合、標準の追加、変更、例外を申請するメカニズムを持つことは重要です。このオプションがなければ、標準はイノベーションの障壁になります。
**期待される成果:**
+ 設計標準が組織のチーム間で共有されています。
+ 設計標準が文書化され、ベストプラクティスの進化に合わせて最新の内容に維持されています。
**一般的なアンチパターン:**
+ 2 つの開発チームがそれぞれ独自のユーザー認証サービスを作成しました。ユーザーは、アクセスするシステムの各部分について、個別の一連の認証情報を維持する必要があります。
+ 両チームは独自のインフラストラクチャを管理しています。新しいコンプライアンス要件により、インフラストラクチャの変更が必要になり、両チームは別々の方法で新たな要件を実装します。
**このベストプラクティスを活用するメリット:**
+ 共有の標準を使用すると、ベストプラクティスの採用に役立ち、開発作業の利点の最大化につながります。
+ 設計標準を文書化して更新することにより、組織はベストプラクティス、セキュリティ、コンプライアンス要件を最新の内容に維持することができます。
**このベストプラクティスを確立しない場合のリスクレベル:** 中
## 実装のガイダンス
既存のベストプラクティス、設計標準、チェックリスト、業務手順、ガイダンス、ガバナンス要件をチーム間で共有します。改善とイノベーションを支援するために、設計標準の変更、追加、例外を申請する手順を設けます。公開されたコンテンツについてチームに周知させます。新しいベストプラクティスの登場に合わせて設計標準を最新の内容に維持するメカニズムを設けます。
**お客様事例**
AnyCompany Retail には、ソフトウェアアーキテクチャのパターンを作成する機能横断的なアーキテクチャチームがあります。このチームでは、コンプライアンスとガバナンスを組み込んだアーキテクチャを構築しています。この共有標準を採用するチームは、コンプライアンスとガバナンスが組み込み済みであるという利点が得られ、この設計標準を基盤に迅速に構築できます。このアーキテクチャチームは四半期ごとのミーティングでアーキテクチャのパターンを検討し、必要に応じて更新します。
**実装手順**
1. 設計標準の開発と更新を担当する機能横断的なチームを特定します。このチームは、組織全体にわたるステークホルダーと協力して、設計標準、チェックリスト、業務手順、ガイダンス、ガバナンス要件を開発し、設計標準を文書化して、組織内で共有します。
1. [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) を使用すると、IaC (Infrastructure as Code) を使用して設計標準を提示するポートフォリオを作成でき、ポートフォリオをアカウント間で共有できます。
1. 新しいベストプラクティスが特定されると、設計標準を最新の内容に維持するメカニズムを施行します。
1. 設計標準が一元的に施行されていれば、変更、更新、例外を申請するプロセスを設けます。
**実装計画に必要な工数レベル:** 中。設計標準を作成して共有するプロセスを開発するには、組織全体のステークホルダーとの調整と協力が必要です。
## リソース
**関連するベストプラクティス:**
+ [OPS01-BP03 ガバナンス要件を評価する](ops_priorities_governance_reqs.md) - ガバナンス要件は設計標準に影響を及ぼします。
+ [OPS01-BP04 コンプライアンス要件を評価する](ops_priorities_compliance_reqs.md) - コンプライアンスは設計標準作成の際に重要な情報を提供します。
+ [OPS07-BP02 運用準備状況の継続的な確認を実現する](ops_ready_to_support_const_orr.md) - 運用準備状況チェックリストは、ワークロード設計時に設計標準を実装するメカニズムです。
+ [OPS11-BP01 継続的改善のプロセスを用意する](ops_evolve_ops_process_cont_imp.md) - 設計標準の更新は継続的改善の一環です。
+ [OPS11-BP04 ナレッジ管理を実施する](ops_evolve_ops_knowledge_management.md) - ナレッジ管理プラクティスの一環として、設計標準を文書化して共有します。
**関連するドキュメント:**
+ [ Automate AWS Backups with AWS Service Catalog](https://aws.amazon.com/blogs/mt/automate-aws-backups-with-aws-service-catalog/)(AWS Service Catalog を使用して AWS Backup を自動化する)
+ [AWS Service Catalog Account Factory-Enhanced ](https://aws.amazon.com/blogs/mt/aws-service-catalog-account-factory-enhanced/)(AWS Service Catalog Account Factory の機能を拡張)
+ [ How Expedia Group built Database as a Service (DBaaS) offering using AWS Service Catalog](https://aws.amazon.com/blogs/mt/how-expedia-group-built-database-as-a-service-dbaas-offering-using-aws-service-catalog/) (Expedia Group が AWS Service Catalog を使用してDatabase as a Service (DBaaS) サービスを構築した方法)
+ [ Maintain visibility over the use of cloud architecture patterns ](https://aws.amazon.com/blogs/architecture/maintain-visibility-over-the-use-of-cloud-architecture-patterns/)(クラウドアーキテクチャパターンの使用に関する可視性を維持する)
+ [ Simplify sharing your AWS Service Catalog portfolios in an AWS Organizations setup ](https://aws.amazon.com/blogs/mt/simplify-sharing-your-aws-service-catalog-portfolios-in-an-aws-organizations-setup/) (AWS Organizations を設定して AWS Service Catalog のポートフォリオの共有を簡素化する)
**関連動画:**
+ [AWS Service Catalog – Getting Started ](https://www.youtube.com/watch?v=A9kKy6WhqVA)(AWS Service Catalog - 開始方法)
+ [AWS re:Invent 2020: Manage your AWS Service Catalog portfolios like an expert ](https://www.youtube.com/watch?v=lVfXkWHAtR8) (AWS re:Invent 2020: エキスパートに学ぶ AWS Service Catalog ポートフォリオの管理)
**関連する例:**
+ [AWS Service Catalog Reference Architecture ](https://github.com/aws-samples/aws-service-catalog-reference-architectures)(AWS Service Catalog リファレンスアーキテクチャ)
+ [AWS Service Catalog ワークショップ ](https://catalog.us-east-1.prod.workshops.aws/workshops/d40750d7-a330-49be-9945-cde864610de9/en-US)
**関連サービス:**
+ [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html)
# OPS05-BP07 コード品質の向上のためにプラクティスを実装する
コード品質の向上のためにプラクティスを実装し、欠陥を最小限に抑えます。例としては、テスト駆動型デプロイ、コードレビュー、標準の導入、ペアプログラミングなどがあります。このようなプラクティスを継続的インテグレーションと継続的デリバリープロセスに組み込みます。
**期待される成果:**
+ 組織はコードレビューやペアプログラミングなどのベストプラクティスを使用し、コード品質が向上します。
+ デベロッパーとオペレーション担当者は、ソフトウェア開発ライフサイクルの一環として、コード品質のベストプラクティスを採用しています。
**一般的なアンチパターン:**
+ コードレビューを行わずに、アプリケーションの主幹にコードをコミットしています。変更が自動的に本番環境にデプロイされ、アプリケーションの停止が発生します。
+ 新しいアプリケーションの開発が、ユニットテスト、エンドツーエンドテスト、または統合テストなしで行われています。デプロイする前にアプリケーションをテストする方法がありません。
+ エラーの対応には、本番環境でチームが手動の変更を加えています。テストやコードレビューを行わなわずに変更を加えており、継続的インテグレーションと継続的デリバリープロセスを介して変更がキャプチャされたりログに記録されたりしていません。
**このベストプラクティスを活用するメリット:**
+ コードの品質を向上させるためのプラクティスを採用することは、本稼働環境に発生する問題を最小限に抑えることに役立ちます。
+ ペアプログラミングやコードレビューなどのベストプラクティスを使用すると、コード品質が向上します。
**このベストプラクティスを確立しない場合のリスクレベル:** 中
## 実装のガイダンス
プラクティスを実装して、コード品質を向上し、デプロイする前にエラーを最低限に抑えます。テスト駆動開発、コードレビュー、ペアプログラミングなどのプラクティスを採用して、開発の質を向上します。
**お客様事例**
AnyCompany Retail では、コード品質の向上のためにいくつかのプラクティスを採用しており、アプリケーションのコーディング基準として、テスト駆動開発を採用しています。新しい機能には、スプリント中にデベロッパーが協力してペアプログラミングを行うことを予定しているものもあります。すべてのプルリクエストは、インテグレーションとデプロイ前に、シニアデベロッパーによるコードレビューを受けます。
**実装手順**
1. テスト駆動型開発、コードレビュー、ペアプログラミングなどのコード品質プラクティスを、継続的インテグレーションと継続的デリバリープロセスに採用します。このような手法を使用して、ソフトウェアの品質を向上させます。
1. [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) は、機械学習を利用した Java と Python コードのプログラミングについてのレコメンデーションを提供します。
1. [AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html) を使用して共有開発環境を作成すると、コードの共同開発ができます。
**実装計画に必要な工数レベル:** 中。ベストプラクティスを実施する方法は数多くありますが、組織全体での導入が難しい場合があります。
## リソース
**関連するベストプラクティス:**
+ [OPS05-BP06 設計標準を共有する](ops_dev_integ_share_design_stds.md) - コード品質プラクティスの一環として、設計標準を共有できます。
**関連するドキュメント:**
+ [ Agile Software Guide ](https://martinfowler.com/agile.html)(アジャイルソフトウェアガイド)
+ [ My CI/CD pipeline is my release captain (CI/CD パイプラインが自分のリリースキャプテン)](https://aws.amazon.com/builders-library/cicd-pipeline/)
+ [ Automate code reviews with Amazon CodeGuru Reviewer ](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)(Amazon CodeGuru Reviewer を使用したコードレビューの自動化)
+ [ Adopt a test-driven development approach ](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)(テスト駆動の開発アプローチを導入する)
+ [ How DevFactory builds better applications with Amazon CodeGuru ](https://aws.amazon.com/blogs/machine-learning/how-devfactory-builds-better-applications-with-amazon-codeguru/)(DevFactory を使用してアプリケーション構築を向上する方法)
+ [ On Pair Programming ](https://martinfowler.com/articles/on-pair-programming.html)(ペアプログラミングについて)
+ [ RENGA Inc. automates code reviews with Amazon CodeGuru ](https://aws.amazon.com/blogs/machine-learning/renga-inc-automates-code-reviews-with-amazon-codeguru/)(RENGA Inc. が Amazon CodeGuru を使用してコードレビューを自動化)
+ [ The Art of Agile Development: Test-Driven Development ](http://www.jamesshore.com/v2/books/aoad1/test_driven_development)(アジャイル開発の技術: テスト駆動開発)
+ [ Why code reviews matter (and actually save time\$1) ](https://www.atlassian.com/agile/software-development/code-reviews)(コードレビューが重要である理由 (そして実際に時間の節約になる理由))
**関連動画:**
+ [AWS re:Invent 2020: Continuous improvement of code quality with Amazon CodeGuru ](https://www.youtube.com/watch?v=iX1i35H1OVw)(AWS re:Invent 2020: Amazon CodeGuru を使用したコード品質の継続的改善)
+ [AWS Summit ANZ 2021 - Driving a test-first strategy with CDK and test driven development ](https://www.youtube.com/watch?v=1R7G_wcyd3s)(Summit ANZ 2021 - CDK とテスト駆動開発でテストファースト戦略を獲得する)
**関連サービス:**
+ [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [ Amazon CodeGuru Profiler ](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html)
+ [AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/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)