# 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 採用可快速導入永續性改進的方法 採用相關方法和程序來驗證潛在改善、盡可能降低測試成本，以及提供小幅改善。 **常見的反模式：** + 審查應用程式的永續性是僅需在專案開始時執行一次的任務。 + 您的工作負載已過時，因為發行程序太繁瑣而無法導入資源效率的小幅變更。 + 您沒有改善工作負載以維持永續性的機制。 **建立此最佳實務的優勢：**建立導入和追蹤永續性改善的程序後，您將可持續採用新的特性和功能、消除問題，並改善工作負載效率。 **未建立此最佳實務時的風險暴露等級：**中 ## 實作指引 在將潛在永續性改善部署到生產環境之前，先加以測試和驗證。在計算改善所帶來的未來潛在利益時，應考慮測試成本。開發低成本測試方法以提供小幅改善。 **實作步驟** + 在開發積存中新增永續性改善的要求。 + 使用迭代[改善程序](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/) + [以 AWS CodeCommit 為基礎的可擴展敏捷開發實務](https://aws.amazon.com/blogs/devops/scalable-agile-development-practices-based-on-aws-codecommit/) **相關影片：** + [提供永續、高效能的架構](https://www.youtube.com/watch?v=FBc9hXQfat0) **相關範例：** + [Well-Architected 實驗室 - 將成本和用量報告轉換為效率報告](https://www.wellarchitectedlabs.com/sustainability/300_labs/300_cur_reports_as_efficiency_reports/) # SUS06-BP02 讓工作負載保持在最新狀態 將工作負載保持在最新狀態，以採用高效功能、去除問題，以及改善工作負載的整體效率。 **常見的反模式：** + 您假設目前的架構是靜態的，且不會隨著時間而更新。 + 您沒有任何系統或定期規律可評估更新的軟體與套件是否與您的工作負載相容。 **建立此最佳實務的優勢：**建立讓工作負載保持在最新狀態的程序後，您將可採用新的特性和功能、解決問題，並改善工作負載效率。 **未建立此最佳實務時的風險暴露等級：**低 ## 實作指引 最新的作業系統、執行階段、中介軟體、程式庫和應用程式可改善工作負載效率，讓您更輕鬆地採用更有效率的技術。隨著供應商提供符合自身永續性目標的功能，最新軟體也可能包含更準確測量工作負載對永續性影響的功能。定期以最新的功能和版本將工作負載保持在最新狀態。 **實作步驟** + 定義相關程序和排程來評估工作負載的新功能和執行個體。利用雲端的靈活性快速測試新功能對您的工作負載有何改善，藉以： + 降低永續性的影響。 + 獲得效能效率。 + 消除已計劃改善的障礙。 + 提升測量和管理永續性影響的能力。 + 清查工作負載軟體和架構，並識別需要更新的元件。 + 您可以使用 [AWS Systems Manager Inventory](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/zh_tw/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 維護時段](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 實驗室 - 清查和修補程式管理](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/) + [實驗室：AWS Systems Manager](https://mng.workshop.aws/ssm.html) # SUS06-BP03 提高建置環境的使用率 提高資源的使用率以開發、測試及建置您的工作負載。 **常見的反模式：** + 您以手動方式佈建或終止您的建置環境。 + 您讓建置環境在測試、建置或發行活動以外執行 (例如，在開發團隊成員的非上班時間執行環境)。 + 您為建置環境過度佈建資源。 **建立此最佳實務的優勢：**藉由提高建置環境的使用率，您將可改善雲端工作負載的整體效率，同時為建置人員配置有效開發、測試和建置所需的資源。 **未建立此最佳實務時的風險暴露等級：**低 ## 實作指引 使用自動化和基礎設施即程式碼，在需要時啟動建置環境，並在不使用時將其關閉。常見的模式是排程可用性時間，使之與開發團隊成員的工作時間一致。您的測試環境應該會與生產組態近似。不過，請找機會使用具有高載容量的執行個體類型、Amazon EC2 Spot 執行個體、自動調整規模資料庫服務、容器和無伺服器技術，以根據使用量調整開發和測試容量。將資料量限定為剛好達到測試要求。如果在測試中使用生產資料，請尋求從生產環境共用資料的可能性，而不要移動資料。 **實作步驟** + 使用基礎設施即程式碼佈建您的建置環境。 + 使用自動化來管理開發和測試環境的生命週期，並且讓建置資源發揮最大效益。 + 利用策略讓開發和測試環境達到最大的使用率。 + 使用最低可行的代表環境來開發和測試潛在改善。 + 在情況允許時使用無伺服器技術。 + 使用隨需執行個體補充開發人員裝置。 + 使用具有高載容量的執行個體類型、Spot 執行個體和其他技術，以根據使用量調整建置容量。 + 採用原生雲端服務來獲得安全的執行個體 Shell 存取，而非部署堡壘主機機群。 + 根據您的建置任務自動調整建置資源規模。 ## 資源 **相關文件：** + [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/) **相關影片：** + [持續整合最佳實務](https://www.youtube.com/watch?v=77HvSGyBVdU) # SUS06-BP04 使用受管 Device Farm 進行測試 使用受管 Device Farm 有效測試代表性硬體集上的新功能。 **常見的反模式：** + 您在個別實體裝置上手動測試及部署應用程式。 + 您未在真正的實體裝置上使用應用程式測試服務來測試及操作應用程式 (例如 Android、iOS 和 Web 應用程式)。 **建立此最佳實務的優勢：**使用受管 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) 排程及執行您的測試。 + [整合 AWS Device Farm 與您的 CI/CD 管道以執行跨瀏覽器 Selenium 測試](https://aws.amazon.com/blogs/devops/integrating-aws-device-farm-with-ci-cd-pipeline-to-run-cross-browser-selenium-tests/) + [使用 AWS DevOps 和行動服務建置及測試 iOS 和 iPadOS 應用程式](https://aws.amazon.com/blogs/devops/building-and-testing-ios-and-ipados-apps-with-aws-devops-and-mobile-services/) + 持續審查測試結果並進行必要的改進。 ## 資源 **相關文件：** + [AWS Device Farm 裝置清單](https://awsdevicefarm.info/) + [檢視 CloudWatch RUM 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM-view-data.html) **相關範例：** + [Android 的 AWS Device Farm 範例應用程式](https://github.com/aws-samples/aws-device-farm-sample-app-for-android) + [iOS 的 AWS Device Farm 範例應用程式](https://github.com/aws-samples/aws-device-farm-sample-app-for-ios) + [AWS Device Farm 的 Appium Web 測試](https://github.com/aws-samples/aws-device-farm-sample-web-app-using-appium-python) **相關影片：** + [透過最終使用者洞察與 Amazon CloudWatch RUM 優化應用程式](https://www.youtube.com/watch?v=NMaeujY9A9Y)