# 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 の多くのサービスは、バージョン管理機能を備えています。[Git](https://aws.amazon.com/devops/source-control/git/) などのリビジョンまたは[ソース管理](https://aws.amazon.com/devops/source-control/)システムを使用して、コードやその他のアーティファクト (インフラストラクチャのバージョン管理された [AWS CloudFormation](https://aws.amazon.com/cloudformation/) テンプレートなど) を管理しています。
**期待される成果:** チームが協力してコード作業に取り組みます。コードをマージすると、コードの一貫性が維持され、変更点が失われることはありません。エラーは、適正なバージョニングによって簡単に元に戻すことができます。
**一般的なアンチパターン:**
+ コードを開発し、ワークステーションに保存したのに、そのワークステーションで回復不可能なストレージ障害が発生し、コードが失われる。
+ 既存のコードを変更で上書きした後、アプリケーションを再起動すると、操作できなくなる。変更を元に戻すことができない。
+ レポートファイルへの書き込みがロックされていて、別のユーザーが編集する必要があるとき、編集をしようとするユーザーは、ほかのユーザーに作業を停止するように求める。
+ 研究チームは、今後の業務を形作る詳細な分析に取り組んでいます。誰かが誤って最終レポートを買い物リストで上書きして保存してしまう。変更を元に戻すことができず、レポートを再作成する必要がある。
**このベストプラクティスを活用する利点:** バージョン管理機能を使用すると、既知の良好な状態や以前のバージョンに簡単に戻すことができ、アセットが失われるリスクを低減できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
バージョン管理されたレポジトリでアセットを維持します。そうすることで、変更の追跡、新しいバージョンのデプロイ、既存バージョンへの変更の検出、以前のバージョンの回復 (障害が発生する場合に、その前の良好な状態に戻すなど) をサポートします。構成管理システムのバージョン管理機能を手順に統合します。
## リソース
**関連するベストプラクティス:**
+ [OPS05-BP04 構築およびデプロイ管理システムを使用する](ops_dev_integ_build_mgmt_sys.md)
**関連動画:**
+ [AWS re:Invent 2023 - How Lockheed Martin builds software faster, powered by DevSecOps](https://www.youtube.com/watch?v=Q1OSyxYkl5w)
+ [AWS re:Invent 2023 - How GitHub operationalizes AI for team collaboration and productivity](https://www.youtube.com/watch?v=cOVvGaiusOI)
# OPS05-BP02 変更をテストし、検証する
デプロイされた変更はすべてテストし、本稼働でのエラーを回避する必要があります。このベストプラクティスは、バージョンコントロールからアーティファクトビルドへの変更をテストすることに重点を置いています。テストには、アプリケーションコードの変更に加えて、インフラストラクチャ、設定、セキュリティコントロール、運用手順も含める必要があります。テストは、単体テストからソフトウェアコンポーネント分析 (SCA) まで、さまざまな形態があります。ソフトウェアの統合および配信プロセスでテストをさらに早めると、アーティファクト品質の確実性が増します。
組織はすべてのソフトウェアアーティファクトにおいてテスト基準を作成する必要があります。テストを自動化すると、手間を軽減し、手動テストによるエラーを回避できます。手動テストが必要な場合もあります。デベロッパーは自動テストの結果を確認して、ソフトウェアの品質を向上させるフィードバックループを構築する必要があります。
**期待される成果:** ソフトウェアの変更は、配信前にすべてテストされています。デベロッパーはテスト結果と検証にアクセスできます。組織には、すべてのソフトウェア変更に適用されるテスト基準があります。
**一般的なアンチパターン:**
+ ソフトウェアの新しい変更を、テストせずにデプロイする。本稼働で実行に失敗し、その結果サービスが停止する。
+ 新しいセキュリティグループが、本番前環境でのテストをせずに AWS CloudFormation にデプロイされる。そのセキュリティグループによって、ユーザーがアプリにアクセスできなくなる。
+ メソッドが変更されても単体テストを行わない。本稼働へのデプロイ時にソフトウェアが失敗する。
**このベストプラクティスを活用する利点:** ソフトウェアデプロイの変更の失敗率が減ります。ソフトウェアの品質が向上します。デベロッパーのコードの実行可能性に関する意識が向上します。確信を持ってセキュリティポリシーをロールアウトし、組織のコンプライアンスをサポートできます。自動スケーリングポリシーの更新などインフラストラクチャの変更を事前にテストし、トラフィックのニーズを満たすことができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
継続的統合の実践の一部として、アプリケーションコードからインフラストラクチャまで、すべての変更に対してテストを行います。テスト結果は、デベロッパーが迅速にフィードバックを得られるように公開します。組織で、すべてのソフトウェア変更に適用されるテスト基準を施行します。
Amazon Q Developer の生成 AI の力を活用して、開発者の生産性とコード品質を高めます。Amazon Q Developer には、コード提案の生成 (大規模言語モデルに基づく)、ユニットテストの作成 (境界条件を含む)、セキュリティ脆弱性の検出と修復を通じたコードセキュリティの強化が含まれます。
**お客様事例**
AnyCompany Retail は、継続的な統合パイプラインの一部として、すべてのソフトウェアアーティファクトに対して複数種類のテストを実行しています。テスト駆動開発を実践しているため、すべてのソフトウェアに単体テストがあります。アーティファクトがビルドされると、エンドツーエンドのテストが実行されます。1 ラウンド目のテストが完了すると、静的アプリケーションセキュリティスキャンを実行し、既知の脆弱性を探します。デベロッパーは、各テストに合格するたびにメッセージを受け取ります。すべてのテストが完了すると、ソフトウェアアーティファクトはアーティファクトリポジトリに保存されます。
### 実装手順
1. 組織の関係者と協力して、ソフトウェアアーティファクトのテスト基準を作成します。すべてのアーティファクトが合格しなければならない基準のテストとは何でしょうか。テスト範囲に含める必要があるコンプライアンスやガバナンスの要件はありますか。コード品質テストを実施する必要がありますか。テストが完了した際に通知が必要なのは誰ですか?
1. [AWS Deployment Pipeline Reference Architecture](https://pipelines.devops.aws.dev/) には、統合パイプラインの一部としてソフトウェアアーティファクトに対して実行できる、さまざまな種類のテストの、信頼できるリストが含まれています。
1. ソフトウェアテスト基準に基づいて必要なテストを行い、アプリケーションを計測します。テストの各セットは 10 分以内に完了する必要があります。テストは統合パイプラインの一部として実行する必要があります。
1. 生成 AI ツールである [Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html) は、ユニットテストケース (境界条件を含む) の作成、コードとコメントを使用した関数の生成、一般的なアルゴリズムの実装に役立ちます。
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 バージョン管理を使用する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_version_control.html)
+ [OPS05-BP06 設計標準を共有する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_share_design_stds.html)
+ [OPS05-BP07 コード品質の向上のためにプラクティスを実装する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_code_quality.html)
+ [OPS05-BP10 統合とデプロイを完全自動化する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_auto_integ_deploy.html)
**関連ドキュメント:**
+ [テスト駆動型の開発アプローチを採用](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)
+ [Amazon Q でソフトウェア開発ライフサイクルを加速](https://aws.amazon.com/blogs/devops/accelerate-your-software-development-lifecycle-with-amazon-q/)
+ [デベロッパーエクスペリエンスを再構想する新たな機能が搭載された Amazon Q Developer の一般提供開始](https://aws.amazon.com/blogs/aws/amazon-q-developer-now-generally-available-includes-new-capabilities-to-reimagine-developer-experience/)
+ [IDE における Amazon Q Developer の使用に関する究極のチートシート](https://community.aws/content/2eYoqeFRqaVnk900emsknDfzhfW/the-ultimate-cheat-sheet-for-using-amazon-q-developer-in-your-ide)
+ [テスト作成に AI を使用したシフトレフトワークロード](https://community.aws/content/2gBZtC94gPzaCQRnt4P0rIYWuBx/shift-left-workload-leveraging-ai-for-test-creation)
+ [Amazon Q デベロッパーセンター](https://aws.amazon.com/developer/generative-ai/amazon-q/)
+ [Amazon CodeWhisperer でアプリケーションをより速く構築する 10 の方法](https://aws.amazon.com/blogs/devops/10-ways-to-build-applications-faster-with-amazon-codewhisperer/)
+ [Amazon CodeWhisperer でコードカバレッジの先を見る](https://aws.amazon.com/blogs/devops/looking-beyond-code-coverage-with-amazon-codewhisperer/)
+ [Amazon CodeWhisperer を使ったプロンプトエンジニアリングのベストプラクティス](https://aws.amazon.com/blogs/devops/best-practices-for-prompt-engineering-with-amazon-codewhisperer/)
+ [TaskCat と CodePipeline を使用した自動 AWS CloudFormation テストパイプライン](https://aws.amazon.com/blogs/devops/automated-cloudformation-testing-pipeline-with-taskcat-and-codepipeline/)
+ [オープンソースの SCA、SAST、DAST ツールを使用してエンドツーエンドの AWS DevSecOps CI/CD パイプラインを構築する](https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/)
+ [サーバーレスアプリケーションのテストの開始](https://aws.amazon.com/blogs/compute/getting-started-with-testing-serverless-applications/)
+ [CI/CD パイプラインがリリースキャプテンに](https://aws.amazon.com/builders-library/cicd-pipeline/)
+ [AWS での継続的インテグレーションと継続的デリバリーの実践 (ホワイトペーパー)](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html)
**関連動画:**
+ [Implement an API with Amazon Q Developer Agent for Software Development](https://www.youtube.com/watch?v=U4XEvJUvff4)
+ [Installing, Configuring, & Using Amazon Q Developer with JetBrains IDEs (How-to)](https://www.youtube.com/watch?v=-iQfIhTA4J0)
+ [Mastering the art of Amazon CodeWhisperer - YouTube playlist](https://www.youtube.com/playlist?list=PLDqi6CuDzubxzL-yIqgQb9UbbceYdKhpK)
+ [AWS re:Invent 2020: テスト可能なインフラストラクチャ: AWS](https://www.youtube.com/watch?v=KJC380Juo2w) での統合テスト
+ [AWS Summit ANZ 2021 - Driving a test-first strategy with CDK and test driven development](https://www.youtube.com/watch?v=1R7G_wcyd3s)
+ [Testing Your Infrastructure as Code with AWS CDK](https://www.youtube.com/watch?v=fWtuwGSoSOU)
**関連リソース:**
+ [AWS デプロイパイプラインリファレンスアーキテクチャ - アプリケーション](https://pipelines.devops.aws.dev/application-pipeline/index.html)
+ [AWS Kubernetes DevSecOps Pipeline](https://github.com/aws-samples/devsecops-cicd-containers)
+ [AWS CodeBuild を使用して GitHub から Node.js アプリケーションのユニットテストを実施する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/run-unit-tests-for-a-node-js-application-from-github-by-using-aws-codebuild.html)
+ [インフラストラクチャコードのテスト駆動型開発に Serverspec を使用する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/use-serverspec-for-test-driven-development-of-infrastructure-code.html)
**関連サービス:**
+ [Amazon Q Developer](https://aws.amazon.com/q/developer/)
+ [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 構成管理システムを使用する
設定を変更し、変更を追跡記録するには、構成管理システムを使用します。これらのシステムは、手動プロセスによって発生するエラーと、変更を導入する労力を減らします。
静的な構成管理では、ライフタイムを通じて一貫性を維持することが期待されるリソースの初期化時に値を設定します。動的な構成管理では、ライフタイムを通じて変化する、または変化することが予測されるリソースの初期化時に値を設定します。例えば、構成変更を介してコードの機能を有効にするように機能トグルを設定したり、インシデント発生時にログの詳細レベルを変更してより多くのデータを取得したりすることができます。
設定は、既知の一貫性のある状態でデプロイする必要があります。環境やリージョン全体でリソース設定を継続的にモニタリングするには、自動検査を使用する必要があります。これらの制御は、環境間でルールが一貫性をもって適用されるように、自動化されたコードおよび管理として定義する必要があります。設定の変更は、合意済みの変更管理手順に従って更新し、バージョン管理に則って、一貫性をもって適用する必要があります。アプリケーションの設定は、アプリケーションとインフラストラクチャコードとは無関係に管理する必要があります。そうすることで、複数の環境間で一貫性をもってデプロイできます。設定を変更しても、アプリケーションの再構築や再デプロイは行われません。
**期待される成果:** 継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインの一部として設定、検証、デプロイを行います。モニタリングして、設定が正しいことを確認します。これにより、エンドユーザーや顧客への影響を最小限に抑えることができます。
**一般的なアンチパターン:**
+ あなたがフリート全体でウェブサーバー設定を手動で更新したところ、更新エラーのために多数のサーバーが応答しなくなりました。
+ あなたは、何時間もかけて、アプリケーションサーバーフリートを手動で更新します。変更中の設定の不整合が、予期しない動作を引き起こします。
+ 誰かがセキュリティグループを更新したため、ウェブサーバーにアクセスできなくなりました。変更内容を把握しなければ、問題の調査にかなりの時間を費やすことになり、復旧までより長くの時間を要することになります。
+ 検証をせずに CI/CD を使用して本番稼働前の設定を本番環境にプッシュします。ユーザーと顧客に正確でないデータやサービスを提供してしまいます。
**このベストプラクティスを活用する利点:** 構成管理システムを採用することで、変更やその追跡の労力のレベルと、手動の手順に起因するエラーの頻度を軽減できます。構成管理システムを使用すると、ガバナンス、コンプライアンス、規制要件に関して保証が得られます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
構成管理システムは、アプリケーションと環境の設定変更を追跡して実装するために使用されます。構成管理システムは、手動プロセスを原因として発生するエラーを低減し、設定の変更を繰り返し可能かつ監査可能にして、労力を軽減するためにも使用されます。
AWS では、[AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) を使用することで、[アカウントおよびリージョンを横断して](https://docs.aws.amazon.com/config/latest/developerguide/aggregate-data.html) AWS リソース設定を継続的にモニタリングできます。それにより、設定履歴を追跡し、設定変更が他のリソースに与える影響を把握して、[AWS Config ルール](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) および [AWS Config Conformance Packs](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html) を使用して、予測または期待される設定に照らしてそれらを監査することができます。
Amazon EC2 インスタンス、AWS Lambda、コンテナ、モバイルアプリケーション、IoT デバイスで実行されているアプリケーションの動的設定には、[AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) を使用することで、環境全体で設定、検証、デプロイ、モニタリングを行うことができます。
### 実装手順
1. 設定担当者を特定します。
1. コンプライアンス、ガバナンス、または規制上のニーズを設定担当者に伝えます。
1. 設定項目と成果物を特定します。
1. 設定項目とは、CI/CD パイプライン内のデプロイにより影響を受けるすべてのアプリケーション設定と環境設定です。
1. 成果物には、達成基準、検証、モニタリング対象などがあります。
1. ビジネス要件とデリバリーパイプラインに基づいて、構成管理ツールを選択します。
1. 誤設定の影響を最小限に抑えるために、設定を大幅に変更する場合は、カナリアデプロイなどの加重デプロイを検討します。
1. 構成管理を CI/CD パイプラインに統合します。
1. プッシュされたすべての変更を検証します。
## リソース
**関連するベストプラクティス:**
+ [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_auto_testing_and_rollback.md)
**関連ドキュメント:**
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS Landing Zone Accelerator](https://aws.amazon.com/solutions/implementations/landing-zone-accelerator-on-aws/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Config とは](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html)
+ [AWS CloudFormation とは](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [AWS 開発者用ツール](https://aws.amazon.com/products/developer-tools/)
+ [AWS CodeBuild](https://aws.amazon.com/codebuild/)
+ [AWS CodePipeline](https://aws.amazon.com/codepipeline/)
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
**関連動画:**
+ [AWS re:Invent 2022 - Proactive governance and compliance for AWS workloads ](https://youtu.be/PpUnH9Y52X0?si=82wff87KHXcc6nbT)
+ [AWS re:Invent 2020: AWS Config](https://youtu.be/m8vTwvbzOfw?si=my4DP0FLq1zwKjho) を使用してコードとしてのコンプライアンスを実現する
+ [Manage and Deploy Application Configurations with AWS AppConfig](https://youtu.be/ztIxMY3IIu0?si=ovYGsxWOBysyQrg0)
# OPS05-BP04 構築およびデプロイ管理システムを使用する
構築およびデプロイ管理システムを使用します。これらのシステムは、手動プロセスによって発生するエラーと、変更を導入する労力を減らします。
AWS では、[AWS デベロッパーツール](https://aws.amazon.com/products/developer-tools/)などのサービスを使用して、継続的インテグレーション/継続的デプロイ (CI/CD) パイプラインを構築できます ([AWS CodeBuild](https://aws.amazon.com/codebuild/)、[AWS CodePipeline](https://aws.amazon.com/codepipeline/)、[AWS CodeDeploy](https://aws.amazon.com/codedeploy/) など)。
**期待される成果:** 組織の構築およびデプロイ管理システムは、適正な設定で安全なロールアウトを自動化する機能を提供する、継続的インテグレーションと継続的デリバリー (CI/CD) システムをサポートします。
**一般的なアンチパターン:**
+ 開発システムでコードをコンパイルした後に、実行可能ファイルを本稼働システムにコピーすると、起動に失敗する。ローカルログファイルは、依存関係がないために失敗したことを示す。
+ 開発環境でアプリケーションの新機能の構築を正常に完了し、品質保証 (QA) にコードを提供しても、静的アセットが欠如していたために、QA に合格しない。
+ 金曜日に、多くの労力をかけて、開発環境でアプリケーションを手動で構築でき、これには、新しくコード化された機能も含まれるけれど、月曜日に、アプリケーションを正常に構築することを可能にするステップを繰り返すことができない。
+ そこで、新しいリリース用に作成したテストを実行する。その後、あなたは、翌週いっぱいをかけて、テスト環境をセットアップし、すべての既存の統合テストを実行してから、パフォーマンステストを実行する。新しいコードには許容できないパフォーマンスへの影響があり、再開発してから再テストする必要がある。
**ベストプラクティスを活用する利点:** ビルドとデプロイのアクティビティを管理するメカニズムを提供することで、反復的なタスクを実行するための労力の程度を減らし、チームメンバーは高価値のクリエイティブなタスクに専念し、手動の手順によるエラーの発生を抑制できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
構築およびデプロイ管理システムを使用すると、変更の追跡と実装、手動プロセスが原因で発生するエラーの削減、安全なデプロイに必要な労力の軽減につながります。コードのチェックインから、ビルド、テスト、デプロイ、検証を通じて統合とデプロイのパイプラインを完全自動化します。これにより、リードタイム短縮、コスト低減、変更頻度の増加、労力の軽減、コラボレーションの強化につながります。
### 実装手順
![\[AWS CodePipeline と関連サービスを使用した CI/CD を説明する図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/deployment-pipeline-tooling.png)
1. バージョン管理システムを使用して、アセット (ドキュメント、ソースコード、バイナリファイルなど) を保存および管理します。
1. CodeBuild を使用してソースコードをコンパイルし、ユニットテストを実行して、すぐにデプロイ可能なアーティファクトを作成します。
1. CodeDeploy は、[Amazon EC2](https://aws.amazon.com/ec2/) インスタンス、オンプレミスインスタンス、[サーバーレス AWS Lambda 関数](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)、[Amazon ECS](https://aws.amazon.com/ecs/) へのアプリケーションのデプロイを自動化するデプロイメントサービスとして使用します。
1. 環境をモニタリングします。
## リソース
**関連するベストプラクティス:**
+ [OPS06-BP04 テストとロールバックを自動化する](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**関連ドキュメント:**
+ [AWS 開発者用ツール](https://aws.amazon.com/products/developer-tools/)
+ [AWS CodeBuild とは](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS CodeBuild](https://aws.amazon.com/codebuild/)
+ [What is AWS CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**関連動画:**
+ [AWS re:Invent 2022 - AWS Well-Architected best practices for DevOps on AWS](https://youtu.be/hfXokRAyorA)
# OPS05-BP05 パッチ管理を実行する
パッチ管理を実行し、問題を解決して、ガバナンスに準拠するようにします。パッチ管理の自動化により、手動プロセスによって発生するエラーを低減し、スケールして、パッチに関連する労力を減らすことができます。
パッチと脆弱性の管理は、利点とリスク管理のアクティビティの一環です。不変のインフラストラクチャを使用し、検証済みの正常な状態でワークロードをデプロイすることが推奨されます。これが現実的でない場合のオプションには、パッチの適用があります。
[AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) は、AWS クラウド リソースの正常性に影響を与える、計画されたライフサイクルイベントやその他のアクションが必要なイベントに関する情報の信頼できるソースです。今後行われる変更や更新に注意する必要があります。計画された主要なライフサイクルイベントは、少なくとも 6 か月前に送信されます。
[Amazon EC2 Image Builder](https://aws.amazon.com/image-builder/) には、マシンイメージを更新するためのパイプラインがあります。パッチ管理の一環として、[AMI イメージパイプライン](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html)を使用する [Amazon マシンイメージ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html ) (AMI) または [Docker イメージパイプライン](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-container-pipeline.html)を備えたコンテナイメージを検討します。一方、AWS Lambda には脆弱性を排除するための[カスタムランタイムと追加ライブラリ](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html)のパターンが用意されています。
Linux 用 [Amazon マシンイメージ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)または Windows Server イメージの更新は、[Amazon EC2 Image Builder](https://aws.amazon.com/image-builder/) を使用して管理します。既存のパイプラインで [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) を使用することで、Amazon ECS イメージと Amazon EKS イメージを管理できます。Lambda には[バージョン管理機能](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html)があります。
パッチの本番環境のシステムへの適用は、まず安全な環境でテストした後とする必要があります。パッチは運用上またはビジネス上の成果に対応している場合にのみ適用してください。AWS では、[AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) を使用して管理対象システムへのパッチ適用プロセスを自動化でき、[Systems Manager Maintenance Windows](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html) を使用してアクティビティをスケジュールできます。
**期待される成果:** AMI とコンテナイメージにパッチが適用されて最新の状態であり、起動の準備が整っています。デプロイされたすべてのイメージのステータスを追跡し、パッチのコンプライアンスを把握できます。現在のステータスを報告でき、コンプライアンスのニーズを満たすプロセスが施行されています。
**一般的なアンチパターン:**
+ あなたには、すべての新しいセキュリティパッチを 2 時間以内に適用するために権限が付与されました。その結果、アプリケーションにパッチとの互換性がないため、複数の機能停止が発生しました。
+ パッチが適用されていないライブラリは、不明な関係者がライブラリ内の脆弱性を使用してワークロードにアクセスするため、意図しない結果をもたらします。
+ あなたは、デベロッパーに通知することなく、自動的にデベロッパー環境にパッチを適用します。あなたには、デベロッパーから、環境が想定どおりに動作しなくなったという苦情が複数寄せられます。
+ 永続的なインスタンスの商用オフザシェルフのセルフソフトウェアにパッチを適用していない。ソフトウェアに問題があり、ベンダーに連絡すると、ベンダーから、バージョンがサポートされておらず、サポートを受けるためには、特定のレベルにパッチを適用する必要があることが伝えられます。
+ 使用した暗号化ソフトウェアの最近リリースされたパッチにより、パフォーマンスが大幅に向上しますが、パッチが適用されていないシステムには、パッチを適用しない結果として、パフォーマンスの問題が残存している。
+ 緊急に修正が必要なゼロデイ脆弱性についての通知を受けて、すべての環境に手動でパッチを適用する必要がある。
+ 計画されたライフサイクルイベントやその他の情報を確認しないため、必須のバージョン更新など、リソースの維持に必要な重要なアクションを認識していません。計画と実行のための重要な時間を失うと、チームに関する緊急の変更、潜在的な影響や予期しないダウンタイムにつながります。
**このベストプラクティスを活用する利点:** パッチ適用の基準や環境全体にわたる配布方法など、パッチ管理プロセスを確立することで、パッチレベルのスケールとレポート作成が実現します。これにより、セキュリティパッチの適用が保証され、実施されている既知の修正のステータスを明確に把握できます。これにより、必要な機能の導入、問題の迅速な解決、継続的なガバナンスへの遵守が実現します。パッチ管理システムと自動化を実装して、パッチをデプロイする労力を軽減し、手動プロセスに起因するエラーの発生を抑制します。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
問題の修正、希望する機能や能力の取得、ガバナンスポリシーやベンダーのサポート要件への準拠継続を行うためにはシステムをパッチします。変更不可能なシステムでは、必要な成果を達成するために適切なパッチを使用してデプロイします。パッチ管理メカニズムを自動化することで、パッチ適用の経過時間、手動プロセスが原因で発生するエラー、パッチに関する労力を低減できます。
### 実装手順
Amazon EC2 Image Builder の場合:
1. Amazon EC2 Image Builder を使用して、次のパイプラインの詳細を指定します。
1. イメージパイプラインの作成と命名
1. パイプラインのスケジュールとタイムゾーンの定義
1. すべての依存関係の設定
1. 次のレシピを選択します。
1. 既存のレシピを選択するか、新しいレシピを作成します
1. イメージのタイプを選択します
1. レシピに名前を付けてバージョンを付けます
1. ベースイメージを選択します
1. ビルドコンポーネントを追加して、ターゲットレジストリに追加します
1. オプション - インフラストラクチャの設定を定義します。
1. オプション - 設定を定義します。
1. 設定の確認
1. レシピのハイジーンを定期的に管理します。
Systems Manager Patch Manager の場合:
1. パッチベースラインの作成
1. パッチ適用オペレーションの方法を選択します。
1. コンプライアンスレポートとスキャンを有効にします。
## リソース
**関連するベストプラクティス:**
+ [OPS06-BP04 テストとロールバックを自動化する](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**関連ドキュメント:**
+ [What is Amazon EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html)
+ [Create an image pipeline using the Amazon EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html)
+ [Create a container image pipeline](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-container-pipeline.html)
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ [Patch Managerの使用 (コンソール)](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-console.html)
+ [パッチコンプライアンスレポートの使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-compliance-reports.html)
+ [AWS Developer Tools](https://aws.amazon.com/products/developer-tools)
**関連動画:**
+ [CI/CD for Serverless Applications on AWS](https://www.youtube.com/watch?v=tEpx5VaW4WE)
+ [Design with Ops in Mind](https://youtu.be/uh19jfW7hw4)
**関連する例:**
+ [AWS Systems Manager Patch Manager のチュートリアル](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-tutorials.html)
# 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 を Account Factory で強化する](https://aws.amazon.com/blogs/mt/aws-service-catalog-account-factory-enhanced/)
+ [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/)
+ [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 Service Catalog – Getting Started ](https://www.youtube.com/watch?v=A9kKy6WhqVA)
+ [AWS re:Invent 2020: Manage your AWS Service Catalog portfolios like an expert ](https://www.youtube.com/watch?v=lVfXkWHAtR8)
**関連する例:**
+ [AWS Service Catalog Reference Architecture ](https://github.com/aws-samples/aws-service-catalog-reference-architectures)
+ [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 コード品質の向上のためにプラクティスを実装する
コード品質の向上のためにプラクティスを実装し、欠陥を最小限に抑えます。例としては、テスト駆動型デプロイ、コードレビュー、標準の導入、ペアプログラミングなどがあります。このようなプラクティスを継続的インテグレーションと継続的デリバリープロセスに組み込みます。
**期待される成果:** 組織はコードレビューやペアプログラミングなどのベストプラクティスを使用し、コード品質が向上します。デベロッパーとオペレーターは、ソフトウェア開発ライフサイクルの一環として、コード品質のベストプラクティスを採用しています。
**一般的なアンチパターン:**
+ コードレビューを行わずに、アプリケーションの主幹にコードをコミットしています。変更が自動的に本番環境にデプロイされ、アプリケーションの停止が発生します。
+ 新しいアプリケーションの開発が、ユニットテスト、エンドツーエンドテスト、または統合テストなしで行われています。デプロイする前にアプリケーションをテストする方法がありません。
+ エラーの対応には、本番環境でチームが手動の変更を加えています。テストやコードレビューを行わずに変更を加えており、継続的インテグレーションと継続的デリバリープロセスを介して変更がキャプチャされたりログに記録されたりしていません。
**このベストプラクティスを活用する利点:** コードの品質を向上させるためのプラクティスを採用することは、本稼働環境に発生する問題を最小限に抑えることに役立ちます。コード品質に関するベストプラクティスには、ペアプログラミング、コードレビュー、AI 生産性ツールの実装などが含まれます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
プラクティスを実装して、コード品質を向上し、デプロイする前にエラーを最低限に抑えます。テスト駆動開発、コードレビュー、ペアプログラミングなどのプラクティスを採用して、開発の質を向上します。
Amazon Q Developer の生成 AI の力を活用して、開発者の生産性とコード品質を高めます。Amazon Q Developer には、コード提案の生成 (大規模言語モデルに基づく)、ユニットテストの作成 (境界条件を含む)、セキュリティ脆弱性の検出と修復を通じたコードセキュリティの強化が含まれます。
**お客様事例**
AnyCompany Retail では、コード品質の向上のためにいくつかのプラクティスを採用しており、アプリケーションのコーディング基準として、テスト駆動開発を採用しています。新しい機能には、スプリント中にデベロッパーが協力してペアプログラミングを行うことを予定しているものもあります。すべてのプルリクエストは、インテグレーションとデプロイ前に、シニアデベロッパーによるコードレビューを受けます。
### 実装手順
1. テスト駆動型開発、コードレビュー、ペアプログラミングなどのコード品質プラクティスを、継続的インテグレーションと継続的デリバリープロセスに採用します。このような手法を使用して、ソフトウェアの品質を向上させます。
1. [Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html) を使用します。Amazon Q Developer は生成 AI ツールで、ユニットテストケース (境界条件を含む) の作成、コードやコメントを使った関数の生成、一般的なアルゴリズムの実装、コード内でのセキュリティポリシー違反や脆弱性の検出、シークレットの検出、Infrastructure as Code (IaC) のスキャン、コードの記録、サードパーティーのコードライブラリの迅速な学習などに役立ちます。
1. [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) は、機械学習を利用した Java と Python コードのプログラミングについてのレコメンデーションを提供します。
**実装計画に必要な工数レベル:** 中 ベストプラクティスを実施する方法は数多くありますが、組織全体での導入が難しい場合があります。
## リソース
**関連するベストプラクティス:**
+ [OPS05-BP02 変更をテストし、検証する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_test_val_chg.html)
+ [OPS05-BP06 設計標準を共有する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_share_design_stds.html)
**関連ドキュメント:**
+ [テスト駆動型の開発アプローチを採用](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)
+ [Amazon Q でソフトウェア開発ライフサイクルを加速](https://aws.amazon.com/blogs/devops/accelerate-your-software-development-lifecycle-with-amazon-q/)
+ [デベロッパーエクスペリエンスを再構想する新たな機能が搭載された Amazon Q Developer の一般提供開始](https://aws.amazon.com/blogs/aws/amazon-q-developer-now-generally-available-includes-new-capabilities-to-reimagine-developer-experience/)
+ [IDE における Amazon Q Developer の使用に関する究極のチートシート](https://community.aws/content/2eYoqeFRqaVnk900emsknDfzhfW/the-ultimate-cheat-sheet-for-using-amazon-q-developer-in-your-ide)
+ [テスト作成に AI を使用したシフトレフトワークロード](https://community.aws/content/2gBZtC94gPzaCQRnt4P0rIYWuBx/shift-left-workload-leveraging-ai-for-test-creation)
+ [Amazon Q デベロッパーセンター](https://aws.amazon.com/developer/generative-ai/amazon-q/)
+ [Amazon CodeWhisperer でアプリケーションをより速く構築する 10 の方法](https://aws.amazon.com/blogs/devops/10-ways-to-build-applications-faster-with-amazon-codewhisperer/)
+ [Amazon CodeWhisperer でコードカバレッジの先を見る](https://aws.amazon.com/blogs/devops/looking-beyond-code-coverage-with-amazon-codewhisperer/)
+ [Amazon CodeWhisperer を使ったプロンプトエンジニアリングのベストプラクティス](https://aws.amazon.com/blogs/devops/best-practices-for-prompt-engineering-with-amazon-codewhisperer/)
+ [Agile Software Guide](https://martinfowler.com/agile.html)
+ [CI/CD パイプラインがリリースキャプテンに](https://aws.amazon.com/builders-library/cicd-pipeline/)
+ [Amazon CodeGuru Reviewer でのコードレビューの自動化](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)
+ [テスト駆動型の開発アプローチを採用](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)
+ [DevFactory による Amazon CodeGuru を使用したより良いアプリケーションの構築方法](https://aws.amazon.com/blogs/machine-learning/how-devfactory-builds-better-applications-with-amazon-codeguru/)
+ [On Pair Programming](https://martinfowler.com/articles/on-pair-programming.html)
+ [株式会社レンガにおける CodeGuru を使ったコードレビューの自動化](https://aws.amazon.com/blogs/machine-learning/renga-inc-automates-code-reviews-with-amazon-codeguru/)
+ [The Art of Agile Development: Test-Driven Development](http://www.jamesshore.com/v2/books/aoad1/test_driven_development)
+ [コードレビューが重要である (かつ時間の節約になる) 理由](https://www.atlassian.com/agile/software-development/code-reviews)
**関連動画:**
+ [Implement an API with Amazon Q Developer Agent for Software Development](https://www.youtube.com/watch?v=U4XEvJUvff4)
+ [Installing, Configuring, & Using Amazon Q Developer with JetBrains IDEs (How-to)](https://www.youtube.com/watch?v=-iQfIhTA4J0)
+ [Mastering the art of Amazon CodeWhisperer - YouTube playlist](https://www.youtube.com/playlist?list=PLDqi6CuDzubxzL-yIqgQb9UbbceYdKhpK)
+ [AWS re:Invent 2020: Continuous improvement of code quality with Amazon CodeGuru](https://www.youtube.com/watch?v=iX1i35H1OVw)
+ [AWS Summit ANZ 2021 - Driving a test-first strategy with CDK and test driven development](https://www.youtube.com/watch?v=1R7G_wcyd3s)
**関連サービス:**
+ [Amazon Q Developer](https://aws.amazon.com/q/developer/)
+ [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)
# OPS05-BP08 複数の環境を使用する
ワークロードの実験、開発、テストを行うには、複数の環境を使用します。本番環境に近い環境ほど使用するコントロールレベルを増大し、デプロイ時にはワークロードを意図したとおりに運用できるという確信を得ます。
**期待される成果:** コンプライアンスとガバナンスのニーズを反映した環境が複数あります。本番環境への移行過程で、次の環境に移行する前にコードのテストを実施しています。
1. 組織は、ガバナンス、コントロール、アカウントの自動化、ネットワーク、セキュリティ、運用上のオブザーバビリティを提供するランディングゾーンの確立を通じてこれを行います。複数の環境を使用して、これらのランディングゾーン機能を管理します。一般的な例は、[AWS Control Tower](https://aws.amazon.com/controltower/) ベースのランディングゾーンへの変更を開発およびテストするためのサンドボックス組織です。これには、[AWS IAM アイデンティティセンター](https://aws.amazon.com/iam/identity-center/) および[サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) などのポリシーが含まれます。これらの要素はすべて、ランディングゾーン内の AWS アカウント へのアクセスとオペレーションに大きな影響を与える可能性があります。
1. これらのサービスに加えて、チームは、AWS および AWS パートナーによって公開されたソリューション、または組織内で開発されたカスタムソリューションを使用してランディングゾーンの機能を拡張します。AWS によって公開されるソリューションの例には、[Customizations for AWS Control Tower (CfCT)](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/) と [AWS Control Tower Account Factory for Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) があります。
1. 組織は、本番稼働へのパス上の環境を通じて、ランディングゾーンのテスト、昇格コード、ポリシーの変更と同じ原則を適用します。この戦略によって、アプリケーションチームとワークロードチームに安定した安全なランディングゾーン環境が実現します。
**一般的なアンチパターン:**
+ あなたは、共有開発環境で開発を実行しており、別のデベロッパーがあなたのコードの変更を上書きします。
+ 共有開発環境の制限的なセキュリティ制御により、あなたは新しいサービスや機能を試すことができません。
+ あなたは本稼働用システムで負荷テストを実行し、ユーザーの機能停止を引き起こします。
+ データ損失につながる重大なエラーが本稼働環境で発生しました。あなたは、データ損失がどのように発生したかを特定し、これを再び発生させないようにするため、本稼働環境において、データ損失につながる条件を再現しようとします。テスト中のさらなるデータ損失を防ぐため、あなたは、ユーザーがアプリケーションを使用できないようにすることを強制されます。
+ あなたは、マルチテナントサービスを運用していますが、専用環境を求める顧客のリクエストをサポートできません。
+ テストは常に実行するとは限らず、テストを行う場合は本番環境でテストします。
+ あなたは、単一環境というシンプルさが、環境内での変更の影響範囲に勝ると考えています。
+ キーランディングゾーン機能をアップグレードしましたが、変更によって新しいプロジェクトまたは既存のワークロードのアカウントを公開するチームの能力が損なわれます。
+ AWS アカウント に新しいコントロールを適用しましたが、その変更はワークロードチームが AWS アカウント 内に変更をデプロイできるかどうかに影響します。
**このベストプラクティスを活用するメリット:** 複数の環境を展開すると、デベロッパーやユーザーコミュニティ間で競合を生じさせることなく、複数の同時開発、テスト、本番環境をサポートできます。ランディングゾーンなどの複雑な機能では、変更のリスクが大幅に軽減され、改善プロセスが簡素化され、環境への重要な更新のリスクが低減されます。ランディングゾーンを使用する組織は、アカウント構造、ガバナンス、ネットワーク、セキュリティ設定など、AWS 環境内のマルチアカウントからメリットを得られます。時間の経過と共に、組織が成長するにつれて、ランディングゾーンは進化し、ワークロードとリソースを保護および整理できるようになります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
複数の環境を使用して、実験を行える最小限のコントロールを備えたサンドボックス環境をデベロッパーに提供します。並行して作業が進められるように個別の開発環境を提供して、開発の俊敏性を高めます。デベロッパーがイノベーションを試せるように、本番環境に近い環境でより厳格なコントロールを実装します。コードとしてインフラストラクチャを使用したり、構成管理システムを使用したりして本番環境に存在するコントロールに準拠して設定された環境をデプロイし、システムがデプロイ時に予想どおりに動作することを確認します。環境を使用しない場合は、オフにして、アイドル状態のリソース (夜間や週末の開発システムなど) に関連するコストを避けることができます。テスト結果の有効性を向上させるためにロードテストを行う場合は、本番環境と同等の環境をデプロイします。
プラットフォームエンジニアリング、ネットワーキング、セキュリティオペレーションなどのチームは、組織レベルでさまざまな要件を持つ機能を管理していることがよくあります。アカウントの分離だけでは、実験、開発、テストのための個別の環境を提供および維持するには不十分です。このような場合は、AWS Organizations の個別のインスタンスを作成します。
## リソース
**関連ドキュメント:**
+ [AWS での Instance Scheduler](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/)
+ [AWS CloudFormation とは](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [複数のアカウントを使用して AWS 環境を整理する - 複数の組織 - AWS 環境全体に対する変更をテストする](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/multiple-organizations.html#test-changes-to-your-overall-aws-environment)
+ [AWS Control Tower ガイド](https://catalog.workshops.aws/control-tower)
# OPS05-BP09 小規模かつ可逆的な変更を頻繁に行う
頻繁に、小規模で、可逆的な変更を行うことで、変更の範囲と影響を減らします。変更管理システム、構成管理システム、ビルドおよび配信システムと組み合わせて使用して、頻繁かつ小規模で可逆的な変更を行うことは、変更の範囲と影響の低減につながります。これにより、トラブルシューティングの効果が向上し、変更をロールバックするオプションを使用すると、迅速に修復できるようになります。
**一般的なアンチパターン:**
+ アプリケーションの新しいバージョンを変更期間を設けて四半期ごとにデプロイするが、変更期間中は、コアサービスがオフになる。
+ 管理システムで変更を追跡せずに、データベーススキーマを頻繁に変更する。
+ インプレースアップデートを手動で実行して、既存のインストールと設定を上書きし、明確なロールバック計画がない。
**このベストプラクティスを活用するメリット:** 小規模な変更を頻繁にデプロイすることで、開発作業はより迅速になります。変更が小規模である場合、意図しない結果が発生するかどうかの識別や元に戻すことがより容易になります。変更を元に戻すことができる場合、復旧が簡素化されるため、変更を実装するリスクが低減されます。このような変更プロセスによりリスクが軽減され、変更が失敗した場合の影響も軽減されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
変更の範囲と影響を低減するために、頻繁かつ小規模で可逆的な変更を行います。これにより、トラブルシューティングが容易になり、迅速に修復できるようになります。また変更を元に戻すこともできます。また、ビジネスに価値をもたらす速度も向上します。
## リソース
**関連するベストプラクティス:**
+ [OPS05-BP03 構成管理システムを使用する](ops_dev_integ_conf_mgmt_sys.md)
+ [OPS05-BP04 構築およびデプロイ管理システムを使用する](ops_dev_integ_build_mgmt_sys.md)
+ [OPS06-BP04 テストとロールバックを自動化する](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**関連ドキュメント:**
+ [AWS でのマイクロサービスの実装](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [Microservices - Observability](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/observability.html)
# 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 マネジメントコンソールにログインする必要なく、更新を提供できます。変更と設定についての完全な監査証跡があるため、ガバナンスとコンプライアンスのニーズを満たせます。プロセスは反復可能であり、複数チーム間で標準化できます。デベロッパーは開発とコードのプッシュに注力する時間ができるため、生産性が向上します。
**一般的なアンチパターン:**
+ 金曜日に、機能ブランチ用の新しいコードの作成を完了します。月曜日になって、コード品質テストスクリプトと各ユニットテストスクリプトを実行した後、予定された次のリリースに向けてコードをチェックインします。
+ 本番環境の多数のお客様に影響を及ぼす重要な問題の修正のコーディング作業を担当することになります。この修正をテストした後、コードと E メールの変更管理をコミットして、本番環境でのデプロイに向けて承認をリクエストします。
+ デベロッパーは、AWS マネジメントコンソールにログインして、標準以外の方法やシステムを使用して新しい開発環境を作成します。
**このベストプラクティスを活用するメリット:** 自動化された構築およびデプロイ管理システムを実装することで、手動プロセスが原因で発生するエラーを削減し、変更をデプロイする労力を低減して、チームメンバーがビジネス価値の実現に注力できるようにします。本番環境への移行の提供が高速化します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
構築およびデプロイ管理システムを使用して、変更を追跡、実装し、手動プロセスが原因で発生するエラーと労力を低減できます。コードのチェックインから、ビルド、テスト、デプロイ、検証を通じて統合とデプロイのパイプラインを完全自動化します。これにより、リードタイムが短縮され、変更頻度が増加し、労力が軽減され、市場投入までの時間が短縮され、生産性が向上し、本番環境に移行する際のコードのセキュリティが強化されます。
## リソース
**関連するベストプラクティス:**
+ [OPS05-BP03 構成管理システムを使用する](ops_dev_integ_conf_mgmt_sys.md)
+ [OPS05-BP04 構築およびデプロイ管理システムを使用する](ops_dev_integ_build_mgmt_sys.md)
**関連ドキュメント:**
+ [AWS CodeBuild とは](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [What is AWS CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**関連動画:**
+ [AWS re:Invent 2022 - AWS Well-Architected best practices for DevOps on AWS](https://youtu.be/hfXokRAyorA)