

# 2 - SAP 변경의 결함 축소, 수정 용이화 및 워크플로 개선
<a name="design-principle-2"></a>

 **귀사는 어떻게 결함을 줄이고 수정 작업을 쉽게 수행하고 프로덕션으로 이어지는 흐름을 개선하십니까?** 리팩터링, 품질과 관련된 빠른 피드백 및 버그 수정이 가능하도록 프로덕션 환경으로 변경 사항을 전달하는 흐름을 개선하는 방식을 도입합니다. 이러한 방식을 도입하면 유용한 변경 사항을 프로덕션 환경으로 빠르게 전달할 수 있고, 문제 배포 가능성을 제한할 수 있으며, 배포 활동을 통해 발생하는 문제를 빠르게 파악하고 해결할 수 있습니다. 

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/sap-lens/design-principle-2.html)

 자세한 내용은 다음 링크 및 정보를 참조하세요. 
+  AWS 동영상: [운영 설계를 염두에 두세요](https://youtu.be/uh19jfW7hw4?ref=wellarchitected) 
+  AWS 설명서: [AWS 개발자 도구](https://aws.amazon.com/products/developer-tools/?ref=wellarchitected) 
+  AWS 설명서: [AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/what-is-launch-wizard-sap.html#:~:text=AWS%20Launch%20Wizard%20for%20SAP%20is%20a%20service%20that%20guides,deploy%20SAP%20applications%20on%20AWS.) 
+  SAP on AWS 블로그: [DevOps for SAP – Driving Innovation and Lowering Costs(SAP용 DevOps - 혁신을 촉진하고 비용을 절감)](https://aws.amazon.com/blogs/awsforsap/devops-for-sap-driving-innovation-and-lowering-costs/) 

# 모범 사례 2.1 - 버전 관리 및 구성 관리 사용
<a name="best-practice-2-1"></a>

구성 관리 시스템에서는 수동 프로세스에서 발생하는 오류와 변경 사항 배포를 위한 작업량을 줄일 수 있습니다. 이렇게 하면 변경 사항을 추적하고, 새 버전을 배포하고, 기존 버전의 변경 사항을 감지하고, 장애 시 알려진 정상 상태로 롤백하는 등 이전 버전으로 되돌릴 수 있습니다. 구성 관리 시스템의 버전 ​​제어 기능을 인프라, 데이터베이스, 애플리케이션, SAP 사용자 정의 코드 및 개발(예: ABAP, Java, UI5/JavaScript) 등 SAP 전반의 모든 절차에 통합합니다.

각 구성 유형마다 다른 버전 관리 시스템을 고려하되 지표를 중앙 릴리스 계획 도구로 통합합니다. 환경 간에 전송할 수 없는 구성 및 바이너리 버전 관리가 관리되는 방식을 고려합니다(예: SAP Kernel 버전이 전체 환경에서 일치하는지 확인할 수 있는 방법).

 **제안 사항 2.1.1 - SAP 개발 코드 및 버전 관리를 관리하기 위한 SAP 변경 제어 또는 기타 서드 파티 도구를 구현** 

 SAP 애플리케이션을 지원하는 모든 개발 접근 방식 및 사용자 정의 코드(예: ABAP, Java, UI5/JavaScript 및 기타 확장 또는 스크립팅 영역)에 대한 변경 제어를 구현하도록 합니다. 모든 SAP 애플리케이션과 여러 SAP 배포 패턴에서 코드 배포를 오케스트레이션하는 방법(예: AWS 및 SAP Business Technology Platform에서 호스트되는 관련 개발을 동시에 릴리스하는 방법)을 고려합니다. 
+  AWS 서비스: [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html?ref=wellarchitected) 
+  AWS 동영상: [AWS CodeCommit 소개](https://youtu.be/46PRLMW8otg?ref=wellarchitected) 
+  SAP on AWS 블로그: [SAP용 AWS DevOps 도구, 1부: Cloud Foundry](https://aws.amazon.com/blogs/awsforsap/aws-devops-tools-for-sap-part-1-cloud-foundry-apps/) 
+  SAP on AWS 블로그: [SAP용 AWS DevOps 도구, 2부: SAP Fiori Apps](https://aws.amazon.com/blogs/awsforsap/aws-devops-tools-for-sap-part-2-sap-fiori-apps/) 
+  SAP 설명서: [SAP 변경 제어 관리](https://help.sap.com/viewer/8b923a2175be4939816f0981b73856c7/LATEST/en-US/2b614e1cb8204f35b477eac703073589.html) 
+  SAP 설명서: [SAP BTP의 모범 사례 - 수명 주기 관리](https://help.sap.com/viewer/df50977d8bfa4c9a8a063ddb37113c43/Cloud/en-US) 

 **제안 사항 2.1.2 - SAP 애플리케이션에 대한 구성 관리 시스템을 구현** 

 ABAP, Java 및 기타 SAP 기술을 위한 구성 관리 도구를 구현하고 환경 간에 전송할 수 없는 구성 및 바이너리 버전 관리가 관리되는 방식을 고려합니다(예: SAP Kernel 버전이 전체 환경에서 일치하는지 확인할 수 있는 방법). SAP Solution Manager를 사용하여 SAP 애플리케이션에 대한 구성 및 버전 변경을 계획 및 구현합니다. 
+  SAP 설명서: [고급 변경 및 전송 시스템(CTS\$1)](https://support.sap.com/en/tools/software-logistics-tools/enhanced-change-and-transport-system.html) 
+  SAP 설명서: [SAP Solution Manager: 환경 변경 계획](https://www.sap.com/germany/documents/2016/08/8ea1d93a-857c-0010-82c7-eda71af511fa.html) 

 **제안 사항 2.1.3 - 운영 체제에 대한 구성 관리 시스템을 구현** 

 AMI 베이킹 또는 현재 위치 구성 관리 소프트웨어(예: Ansible, Chef 또는 Puppet)를 사용하여 SAP 워크로드 운영 체제 간에 구성 관리를 조정합니다. 취약성에 대해 경고하고 운영 체제에 패치를 적용하여 강화하도록 안내하는 보안 중심 구성 관리 도구를 고려합니다. 
+  AWS 설명서: [AWS Systems Manager - 상태 관리자](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state.html) 
+  AWS 설명서: [Amazon EC2의 구성 관리](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/configuration-management.html) 
+  AWS 설명서: [AWS OpsWorks란 무엇입니까?](https://docs.aws.amazon.com/opsworks/latest/userguide/welcome.html?ref=wellarchitected) 
+  AWS 설명서: [Amazon Inspector란 무엇입니까?](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html) 

 **제안 사항 2.1.4 - 데이터베이스에 대한 구성 관리 시스템을 구현** 

 데이터베이스 소프트웨어 공급 업체와 협력하여 데이터베이스에 대한 구성 관리 접근 방식을 이해합니다. 
+  SAP 설명서: [SAP HANA 플랫폼 수명 주기 관리](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/LATEST/en-US/571d0bb4b1b2402f8e7caf0fe0290b61.html) 

 **제안 사항 2.1.5 - 인프라에 대한 구성 관리 시스템을 구현** 

 코드형 인프라(IaC) 접근 방식을 사용하여 SAP 워크로드를 지원하는 AWS 리소스를 프로비저닝 및 관리합니다. AWS CloudFormation 및 AWS Cloud Development Kit는 프로그래밍 방식으로 AWS 리소스의 구성을 프로비저닝하고 관리하는 데 사용할 수 있는 도구입니다. 규칙 및 정책을 작성하여 주기적으로 인프라를 평가함으로써 규정 준수를 평가하고 문제를 해결할 수 있는 구성 감사 및 제어 도구를 고려합니다. 
+  AWS 설명서: [AWS Launch Wizard for SAP](https://aws.amazon.com/launchwizard/) 
+  AWS 설명서: [AWS Systems Manager 인벤토리](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html) 
+  AWS 설명서: [AWS Systems Manager Change Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html) 
+  SAP on AWS 블로그: [코드형 인프라 예: Terraform 및 SAP on AWS](https://aws.amazon.com/blogs/awsforsap/terraform-your-sap-infrastructure-on-aws/) 
+  SAP Lens [안정성]: [모범 사례 11.3 - 서비스 가용성 복원을 위한 접근 방식 정의](best-practice-11-3.md) 

# 모범 사례 2.2 - 코드 품질 개선을 위한 사례 구현
<a name="best-practice-2-2"></a>

코드 품질을 개선하고 결함을 최소화하는 사례를 구현합니다. 테스트 중심 개발, 코드 검토, 표준 도입 등을 예로 들 수 있습니다. SAP Code Inspector 도구 사용을 최소화합니다.

 **제안 사항 2.2.1 - 코드 품질 개선을 위한 사례를 구현** 

테스트 중심 개발, 페어 프로그래밍, 코드 검토, 표준 도입 등을 예로 들 수 있습니다.

 **제안 사항 2.2.2 - SAP 개발에 Amazon Inspector 도구를 사용하고 이 프로세스를 CI/CD 파이프라인에 통합** 

 SAP 워크로드에서 코드 검사 및 린팅을 자동화하기 위해 다음 도구를 고려합니다. 
+  AWS 설명서: [Amazon CodeGuru - AWS Java 및 Python 개발용](https://aws.amazon.com/codeguru/) 
+  SAP 설명서: [SAP Code Inspector - ABAP 및 SAP 관련 개발용](https://help.sap.com/viewer/ba879a6e2ea04d9bb94c7ccd7cdac446/LATEST/en-US/49205531d0fc14cfe10000000a42189b.html) 

# 모범 사례 2.3 - 빌드 및 배포 관리 시스템 사용
<a name="best-practice-2-3"></a>

빌드 및 배포 관리 시스템을 사용합니다. ABAP 변경 및 전송 시스템(CTS), 웹 IDE 또는 SAP 도구와 같은 SAP 인증 빌드 및 배포 시스템을 사용 중인지 확인합니다. 이러한 시스템에서는 수동 프로세스에서 발생하는 오류와 변경 사항 배포를 위한 작업량을 줄일 수 있습니다.

 **제안 사항 2.3.1 - SAP 빌드 및 배포 시스템을 구현** 

 ABAP 변경 및 전송 시스템(CTS), 웹 IDE, SAP BTP 지속적 전달 서비스 또는 기타 SAP 도구와 같은 SAP 인증 빌드 및 배포 시스템을 구현합니다. 
+  AWS 동영상: [소프트웨어 개발을 위한 지속적 통합 모범 사례](https://www.youtube.com/watch?v=GEPJ7Lo346A&ref=wellarchitected) 
+  SAP on AWS 블로그: [SAP용 AWS DevOps 도구, 2부: SAP Fiori Apps](https://aws.amazon.com/blogs/awsforsap/aws-devops-tools-for-sap-part-2-sap-fiori-apps/) 
+  SAP 설명서: [고급 변경 및 전송 시스템(CTS\$1)](https://support.sap.com/en/tools/software-logistics-tools/enhanced-change-and-transport-system.html) 
+  SAP 설명서: [BTP에 애플리케이션 배포](https://help.sap.com/viewer/825270ffffe74d9f988a0f0066ad59f0/LATEST/en-US/4478283a220b46d9a46bb28d6a9140e8.html) 

# 모범 사례 2.4 - 다중 환경 사용
<a name="best-practice-2-4"></a>

여러 SAP 환경을 사용하여 워크로드를 실험, 개발 및 테스트합니다. 프로덕션 환경에 배포하는 단계에 가까워질수록 제어 수준을 높이면 배포되었을 때 워크로드가 의도한 대로 작동할 것이라는 신뢰성을 높일 수 있습니다. 일반적으로 SAP 환경에서는 최소한 개발, 테스트 및 프로덕션을 위한 3티어 환경이 필요합니다.

 **제안 사항 2.4.1 - 실험에 임시 환경을 사용** 

 기술 테스트 및 개발자 팀에 제어가 최소화된 샌드박스 또는 임시 환경을 제공하여 실험 및 위험 완화가 가능하도록 합니다. 
+  AWS 설명서: [AWS Launch Wizard for SAP](https://aws.amazon.com/launchwizard/) 
+  SAP on AWS 블로그: [코드형 인프라 예: Terraform 및 SAP on AWS](https://aws.amazon.com/blogs/awsforsap/terraform-your-sap-infrastructure-on-aws/) 

 **제안 사항 2.4.2 - 병렬 작업이 가능하고 민첩성을 개선할 수 있는 개발 환경을 제공** 

 병렬 작업이 가능하고 개발 및 테스트 민첩성을 제고할 수 있도록 비프로덕션 환경을 제공합니다. 개발자가 혁신을 위해 필요한 수단을 사용할 수 있도록 프로덕션 환경과 인접한 환경에서는 더욱 엄격한 제어 기능을 구현합니다. 일반적으로 SAP 환경에서는 최소한 개발, 테스트 및 프로덕션을 위한 3티어 환경이 필요합니다. 
+  AWS 설명서: [AWS Launch Wizard for SAP](https://aws.amazon.com/launchwizard/) 

 **제안 사항 2.4.3 - 릴리스 품질을 개선할 수 있도록 가능한 한 프로덕션과 근사한 통합 테스트 환경을 제공** 

 테스트 및 스테이징 환경은 릴리스 전에 아키텍처 및 코드 상호 작용 문제를 식별할 수 있도록 프로덕션 환경의 인터페이스, 보안, 복원력 및 성능 특성을 최대한 근사하게 미러링해야 합니다. 환경 비용 효율을 개선하기 위해 사용하지 않을 경우에는 클러스터의 보조 리소스를 종료하거나 이 환경의 애플리케이션 서버 성능을 수평적으로 또한 수직적으로 축소하는 것을 고려합니다. 
+  SAP on AWS 블로그: [AWS Systems Manager를 사용하여 분산 SAP HANA 시스템 자동 시작 또는 중지](https://aws.amazon.com/blogs/awsforsap/automate-start-or-stop-of-distributed-sap-hana-systems-using-aws-systems-manager/) 

 **제안 사항 2.4.4 - 코드형 인프라(IaC) 및 구성 관리 시스템을 사용하여 환경을 일관되게 배포** 

 코드형 인프라(IaC) 및 구성 관리 시스템을 사용하여 프로덕션 환경의 제어 기능과 일치하는 방식으로 구성된 환경을 배포합니다. 그러면 배포된 시스템이 정상적으로 작동합니다. 자동화 및 규정 준수에 사용할 수 있도록 태깅 및 리소스 그룹을 사용하여 환경 메타데이터에 레이블을 지정하고 향상시킵니다. 
+  SAP on AWS 블로그: [코드형 인프라 예: Terraform 및 SAP on AWS](https://aws.amazon.com/blogs/awsforsap/terraform-your-sap-infrastructure-on-aws/) 
+  SAP on AWS 블로그: [SAP on AWS 태깅 권장 사항](https://aws.amazon.com/blogs/awsforsap/tagging-recommendations-for-sap-on-aws/) 
+  AWS 설명서: [AWS Launch Wizard for SAP](https://aws.amazon.com/launchwizard/) 
+  AWS 설명서: [AWS 리소스 그룹이란 무엇입니까?](https://docs.aws.amazon.com/ARG/latest/userguide/welcome.html) 

 **제안 사항 2.4.5 - 사용하지 않을 경우 비프로덕션 환경 끄기** 

 사용되고 있지 않은 환경은 유휴 리소스 관련 비용이 발생하지 않도록 해제합니다. 예를 들어 개발 시스템은 야간 시간과 주말에 해제합니다. 
+  SAP on AWS 블로그: [AWS Systems Manager를 사용하여 분산 SAP HANA 시스템 자동 시작 또는 중지](https://aws.amazon.com/blogs/awsforsap/automate-start-or-stop-of-distributed-sap-hana-systems-using-aws-systems-manager/) 

# 모범 사례 2.5 - 변경 사항 테스트 및 확인
<a name="best-practice-2-5"></a>

개발, 테스트, 프로덕션 등의 모든 수명 주기 단계에서 변경 사항을 테스트하고 결과를 확인해야 합니다. 테스트 결과를 사용하여 새 기능을 확인하고 배포 실패의 위험과 영향을 완화합니다. 테스트 및 확인을 자동화하면 검토의 일관성을 보장하고, 수동 프로세스로 인해 발생하는 오류를 줄이고, 작업량을 줄일 수 있습니다.

 **제안 사항 2.5.1 - 모든 수명 주기 단계(예: 개발, 테스트, 프로덕션)에서 변경 사항을 테스트하고 결과를 확인** 

 **제안 사항 2.5.2 - 변경 사항 및 주요 프로젝트를 릴리스할 때 비교할 수 있도록 기능 테스트, 성능 및 복원력 전반에서 테스트 결과의 기준을 유지** 

 **제안 사항 2.5.3 - 각 변경 수준에 필요한 테스트 수준을 이해 예: 전체 테스트 vs 소규모 변경에 대한 타겟 회귀 테스트 프로덕션 환경으로 릴리스하는 데 필요한 테스트 정의 및 변경 사항 테스트 범위에 합의** 

 **제안 사항 2.5.4 - 가능한 경우 서드 파티 도구 및 테스트 하니스를 사용하여 테스트를 자동화 먼저 정기적인 변경 유형과 빈번한 릴리스에 중점을 둡니다.** 

# 모범 사례 2.6 - 소규모로 자주 발생하고 되돌릴 수 있는 소규모 변경 사항 적용
<a name="best-practice-2-6"></a>

되돌릴 수 있는 소규모 변경 작업을 자주 수행하면 변경의 영향과 범위가 감소합니다. 많은 SAP NetWeaver 솔루션이 ‘패치 포워드(patch forward)’ 접근 방식만 지원하지만 사용자 지정 개발에서 기능 토글을 사용하여 롤백을 허용하는 것을 고려합니다. 이렇게 하면 문제를 더 빠르고 쉽게 해결할 수 있으며 변경 사항 롤백 옵션을 사용할 수 있습니다.

 **제안 사항 2.6.1 - 가능한 경우 개발 및 릴리스를 자주 발생하는 소규모 변경 사항으로 분할** 

 **제안 사항 2.6.2 - 많은 SAP 솔루션이 ‘패치 포워드(patch forward)’ 접근 방식만 지원하고 복원 가능한 전송은 허용하지 않으므로 사용자 지정 개발에서 기능 토글을 사용하여 롤백/철회가 아닌 기능 비활성화를 허용하는 것을 고려** 

 **제안 사항 2.6.3 - 되돌릴 수 없는 SAP 변경 사항의 경우 전체 시스템 스냅샷, 데이터베이스 백업 및 복구 옵션 등 추가 롤백 옵션을 고려** 
+  AWS 설명서: [Amazon EBS 크래시 일관성 스냅샷](https://aws.amazon.com/blogs/storage/taking-crash-consistent-snapshots-across-multiple-amazon-ebs-volumes-on-an-amazon-ec2-instance/) 
+  AWS 설명서: [AWS Backint for SAP HANA](https://aws.amazon.com/backint-agent/) 

# 모범 사례 2.7 - 변경 사항의 테스트, 통합 및 배포 자동화
<a name="best-practice-2-7"></a>

워크로드 빌드, 배포 및 테스트를 자동화합니다. 이렇게 하면 수동 프로세스에서 발생하는 오류와 변경 사항 배포를 위한 작업을 줄일 수 있습니다.

 **제안 사항 2.7.1 - 코드 체크 인에서 빌드, 테스트, 배포 및 확인까지의 전체 통합 및 배포 파이프라인을 완전히 자동화** 

 **제안 사항 2.7.2 - SAP Solution Manager ChaRM, Focused Build 또는 서드 파티 변경 및 릴리스 관리 도구를 구현하여 빌드에서 배포 파이프라인까지 애플리케이션 변경을 위한 전체 프로세스를 조정** 
+  SAP 설명서: [SAP Solution Manager 변경 요청 관리](https://help.sap.com/viewer/8b923a2175be4939816f0981b73856c7/LATEST/en-US/4c3acb82b50843b4e10000000a42189e.html) 
+  SAP 설명서: [SAP Focused Build](https://support.sap.com/en/alm/focused-build.html) 
+  AWS Marketplace: [DevOps용 제품 및 도구](https://aws.amazon.com/marketplace/search/results?page=1&searchTerms=sap&category=45c68cc2-ccd6-426b-94bd-92a791004dc2) 
+  AWS Marketplace - [테스트용 제품 및 도구](https://aws.amazon.com/marketplace/search/results?page=1&searchTerms=sap&category=b1cf3403-729a-4df1-908d-51105b3574a3) 
+  SAP on AWS 블로그: [SAP용 AWS DevOps 도구, 1부: Cloud Foundry](https://aws.amazon.com/blogs/awsforsap/aws-devops-tools-for-sap-part-1-cloud-foundry-apps/) 