# SUS 6 組織のプロセスは、持続可能性目標の達成にどのように役立ちますか?
開発、テスト、デプロイのプラクティスを変更することで、持続可能性に対する影響を減らす機会を探します。
**Topics**
+ [SUS06-BP01 持続可能性の改善を迅速に導入できる方法を採用する](sus_sus_dev_a2.md)
+ [SUS06-BP02 ワークロードを最新に保つ](sus_sus_dev_a3.md)
+ [SUS06-BP03 ビルド環境の利用率を高める](sus_sus_dev_a4.md)
+ [SUS06-BP04 マネージド型 Device Farm を使用してテストする](sus_sus_dev_a5.md)
# SUS06-BP01 持続可能性の改善を迅速に導入できる方法を採用する
改善の可能性の検証、テストコストの最小化、小規模な改善の提供を行う手段やプロセスを導入します。
**一般的なアンチパターン:**
+ 持続可能性についてアプリケーションをレビューするのは、プロジェクトの開始時に 1 回だけである。
+ リリースプロセスが複雑すぎてリソース効率化のための小規模な変更を導入しづらいため、ワークロードが古くなった。
+ 持続可能性のためにワークロードを改善する仕組みがない。
**このベストプラクティスを活用するメリット:** 持続可能性に関する改善を導入および追跡するプロセスを確立することで、継続的に新しい機能や能力を導入し、問題を排除して、ワークロードの効率を向上させることができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 中
## 実装のガイダンス
本稼働環境にデプロイする前に、持続可能性を改善できるかをテストして検証します。改善に際して将来的に起こりうる利点を計算する際のテストにかかるコストを考慮します。低コストのテスト方法を開発し、小規模な改善を実施します。
**実装手順**
+ 持続可能性の改善に関する要件を開発バックログに追加します。
+ 反復的な[改善プロセス](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/improvement-process.html)を使用して、これらの改善を特定、評価、優先順位付け、テスト、デプロイします。
+ 開発プロセスを継続的に改善および合理化します。例えば、[継続的な統合および配信 (CI/CD) パイプラインを使用してソフトウェア配信プロセスを自動化して](https://aws.amazon.com/getting-started/hands-on/set-up-ci-cd-pipeline/)、工数レベルを削減し手動プロセスで発生するエラーを減らす可能性のある改善をテストしデプロイします。
+ 最小限に実行可能である代表的なコンポーネントを使用して、潜在的な改善を開発およびテストし、テストのコストを削減します。
+ 改善の影響を継続的に評価し、必要に応じて調整します。
## リソース
**関連するドキュメント:**
+ [AWS がサステナビリティソリューションを実現](https://aws.amazon.com/sustainability/)
+ [ Scalable agile development practices based on AWS CodeCommit](https://aws.amazon.com/blogs/devops/scalable-agile-development-practices-based-on-aws-codecommit/)(AWS CodeCommit に基づいたスケーラブルなアジャイル開発の実践)
**関連動画:**
+ [ Delivering sustainable, high-performing architectures ](https://www.youtube.com/watch?v=FBc9hXQfat0)(持続可能でパフォーマンスが高いアーキテクチャを実現する)
**関連する例:**
+ [Well-Architected Lab - Turning cost & usage reports into efficiency reports](https://www.wellarchitectedlabs.com/sustainability/300_labs/300_cur_reports_as_efficiency_reports/) (Well-Architected ラボ - コストと使用状況レポートを効率性レポートに変える)
# SUS06-BP02 ワークロードを最新に保つ
ワークロードを最新の状態に保ち、効率的な機能を導入し、問題を排除し、ワークロード全体の効率性を向上させます。
**一般的なアンチパターン:**
+ 現在のアーキテクチャが今後は静的なものとなり、しばらく更新されないと考えている。
+ 更新されたソフトウェアおよびパッケージがワークロードと互換性があるかどうかを評価するためのシステムまたは定期的な予定がない。
**このベストプラクティスを活用するメリット:** ワークロードを最新に保つプロセスを確立することで、新しい機能と能力を採用し、問題を解決し、ワークロードの効率性を高めることができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
最新のオペレーティングシステム、ランタイム、ミドルウェア、ライブラリ、アプリケーションを使用すると、ワークロードの効率が上がり、さらに効率的なテクノロジーを簡単に導入できます。最新のソフトウェアにはまた、ワークロードの持続可能性に対する影響をより正確に測定する機能が含まれている場合があります。これは、ベンダーが独自の持続可能性の目標を満たすための機能でもあります。定期的に最新の機能やリリースを導入し、ワークロードを最新に保ちます。
**実装手順**
+ ワークロードに応じた新しい機能やインスタンスを評価するプロセスとスケジュールを定義します。クラウドの俊敏性を利用して、新しい機能がワークロードをどのように改善するかをすばやくテストします。
+ 持続可能性への影響を削減する。
+ パフォーマンスの効率を高める。
+ 計画した改善にとっての障壁を取り除く。
+ 持続可能性に対する影響の測定能力と管理能力を高める。
+ ワークロードソフトウェアおよびアーキテクチャをインベントリに登録して、更新する必要があるコンポーネントを特定する。
+ [AWS Systems Manager インベントリ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html)を使用して、Amazon EC2 インスタンスからオペレーティングシステム (OS)、アプリケーション、インスタンスのメタデータを収集し、どのインスタンスがソフトウェアポリシーで要求されるソフトウェアと設定を実行しているか、どのインスタンスが更新する必要があるかを迅速に把握できます。
+ ワークロードのコンポーネントを更新する方法を理解します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/sus_sus_dev_a3.html)
+ 更新プロセスにオートメーションを使用して、新しい機能をデプロイする労力のレベルを軽減し、手動プロセスに起因するエラーを抑制します。
+ [CI/CD](https://aws.amazon.com/blogs/devops/complete-ci-cd-with-aws-codecommit-aws-codebuild-aws-codedeploy-and-aws-codepipeline/) を使用して、AMI、コンテナイメージ、その他クラウドアプリケーションに関連するアーティファクトを自動的に更新できます。
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) などのツールを使用して、システム更新のプロセスを自動化し、[AWS Systems Manager Maintenance Windows](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html) を使用してアクティビティをスケジュールできます。
## リソース
**関連するドキュメント:**
+ [AWS アーキテクチャセンター](https://aws.amazon.com/architecture)
+ [AWS の最新情報](https://aws.amazon.com/new/?ref=wellarchitected&ref=wellarchitected)
+ [AWS のデベロッパー用ツール](https://aws.amazon.com/products/developer-tools/)
**関連する例:**
+ [ Well-Architected Labs: Inventory and Patch Management ](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/)(Well-Architected ラボ: インベントリおよびパッチ管理)
+ [Lab: AWS Systems Manager](https://mng.workshop.aws/ssm.html) (ラボ: AWS Systems Manager)
# SUS06-BP03 ビルド環境の利用率を高める
リソースの使用率を上げて、ワークロードを開発、テスト、構築します。
**一般的なアンチパターン:**
+ ビルド環境を手動でプロビジョニングおよび停止している。
+ テスト、ビルド、リリースアクティビティとは無関係にビルド環境を実行し続けている (例えば、開発チームメンバーの就業時間外に環境を実行している)。
+ ビルド環境にリソースを過剰プロビジョニングしている。
**このベストプラクティスを活用するメリット:** ビルド環境の使用率を上げることで、構築者が効率的に開発、テスト、構築できるようにリソースを配分しながら、クラウドワークロード全体の効率を上げることができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
オートメーションと Infrastructure as Code を使用して、必要に応じてビルド環境を起動し、使用しないときは停止します。一般的なパターンとしては、開発チームのメンバーの勤務時間と重なるように可用性期間のスケジュールを設定することがあります。テスト環境は、本稼働構成とよく似たものにする必要があります。ただし、バーストキャパシティ、Amazon EC2 スポットインスタンス、自動スケールするデータベースサービス、コンテナ、サーバーレステクノロジーを備えたインスタンスタイプを使用して、開発およびテストのキャパシティを使用に合わせて調整できる機会を探ります。データ量を、テスト要件を満たす量だけに制限します。本稼働データをテストに使用する場合は、データを移動するのではなく、本稼働環境とデータを共有できる可能性を探ります。
**実装手順**
+ Infrastructure-as-Code を使用してビルド環境をプロビジョニングします。
+ オートメーションを使用して開発環境とテスト環境のライフサイクルを管理し、ビルド用リソースの効率を最大化します。
+ 開発環境とテスト環境を最大限に活用する戦略を使用します。
+ 最小限に実行可能である代表的な環境を使用して、潜在的な改善を開発およびテストします。
+ 可能な限り、サーバーレス技術を利用します。
+ オンデマンドインスタンスを使用して開発者のデバイスを補完します。
+ バーストキャパシティ、スポットインスタンス、その他のテクノロジーを備えたインスタンスタイプを使用して、ビルドキャパシティを使用状況に合わせて調整します。
+ 踏み台ホストのフリートをデプロイするのではなく、ネイティブなクラウドサービスを採用して、インスタンスシェルのアクセスを保護します。
+ ビルドジョブに合わせてビルドリソースを自動的にスケールします。
## リソース
**関連するドキュメント:**
+ [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)
+ [Amazon EC2 バーストパフォーマンスインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html)
+ [AWS CloudFormation の概要](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [AWS CodeBuild とは](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS での Instance Scheduler ](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/)
**関連動画:**
+ [ Continuous Integration Best Practices ](https://www.youtube.com/watch?v=77HvSGyBVdU)(継続的インテグレーションのベストプラクティス)
# SUS06-BP04 マネージド型 Device Farm を使用してテストする
マネージド型 Device Farm を使用して、ハードウェアの代表的なセットで新機能を効率的にテストします。
**一般的なアンチパターン:**
+ 個別の物理デバイス上で、アプリケーションを手動でテストおよびデプロイしている。
+ アプリケーションテストサービスを使用せずに、実際の物理デバイス上でアプリケーションをテストおよび操作している (Android、iOS、ウェブアプリケーションなど)。
**このベストプラクティスを活用するメリット:** マネージド型 Device Farm を使用してクラウド対応アプリケーションをテストすると、多くのメリットがあります。
+ 幅広い種類のデバイスでアプリケーションをテストする、より効率的な機能などです。
+ これにより、テスト用の社内インフラストラクチャが必要なくなります。
+ あまり使われない古いハードウェアを含む、さまざまデバイスタイプが提供されているため、不要なデバイスをアップグレードする必要がなくなります。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
マネージド型 Device Farm を使用すると、代表的な一連のハードウェアで新機能をテストするプロセスを合理化できます。マネージド型 Device Farm は、あまり使われない古いハードウェアを含むさまざまなデバイスタイプを提供するため、不要なデバイスのアップグレードによるお客様の持続可能性に対する影響を回避できます。
**実装手順**
+ テストの要件と計画 (テストの種類、オペレーティングシステム、テストのスケジュールなど) を定義します。
+ [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) を使用して、クライアント側のデータを収集および分析し、テスト計画を策定できます。
+ テスト要件をサポートできるマネージド型 Device Farm を選択します。例えば、[AWS Device Farm](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html) を使用して、代表的な一連のハードウェア上での変更の影響をテストし把握できます。
+ 継続的統合/継続的デプロイ (CI/CD) を使用して、テストをスケジュールし実行します。
+ [ Integrating AWS Device Farm with your CI/CD pipeline to run cross-browser Selenium tests ](https://aws.amazon.com/blogs/devops/integrating-aws-device-farm-with-ci-cd-pipeline-to-run-cross-browser-selenium-tests/)(AWS Device Farm を CI/CD パイプラインに統合してブラウザ間で Selenium のテストを実行する)
+ [ Building and testing iOS and iPadOS apps with AWS DevOps and mobile services ](https://aws.amazon.com/blogs/devops/building-and-testing-ios-and-ipados-apps-with-aws-devops-and-mobile-services/)(AWS DevOps およびモバイルサービスを使用して iOS および iPadOS アプリケーションを構築およびテストする)
+ テスト結果を継続的に見直し、必要な改善を行います。
## リソース
**関連するドキュメント:**
+ [AWS Device Farm デバイスリスト ](https://awsdevicefarm.info/)
+ [ CloudWatch RUM ダッシュボードの表示 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM-view-data.html)
**関連する例:**
+ [AWS Device Farm Sample App for Android ](https://github.com/aws-samples/aws-device-farm-sample-app-for-android)
+ [AWS Device Farm Sample App for iOS ](https://github.com/aws-samples/aws-device-farm-sample-app-for-ios)
+ [ Appium Web tests for AWS Device Farm](https://github.com/aws-samples/aws-device-farm-sample-web-app-using-appium-python)
**関連動画:**
+ [ Optimize applications through end user insights with Amazon CloudWatch RUM ](https://www.youtube.com/watch?v=NMaeujY9A9Y)(Amazon CloudWatch RUM を使用したエンドユーザーインサイトを通してアプリケーションを最適化する)