

# 변경 구현
<a name="implement-change"></a>

 새로운 기능을 배포하고 워크로드와 운영 환경에서 적절한 패치가 적용된 알려진 소프트웨어를 실행하려면 변경 제어가 필요합니다. 이러한 변경이 제어되지 않으면 변경의 영향을 예측하거나 변경으로 인해 발생하는 문제를 해결하는 것이 어려워집니다.

 **위험을 최소화하기 위한 추가 배포 패턴** 

 [기능 플래그(기능 토글이라고도 함)](https://martinfowler.com/articles/feature-toggles.html)는 애플리케이션의 구성 옵션입니다. 고객에게 특정 기능이 표시되지 않도록 기능을 해제한 상태로 소프트웨어를 배포할 수 있습니다. 그런 다음 카나리 배포에서와 같이 기능을 설정할 수도 있고, 변경 속도를 100%로 설정하여 효과를 표시할 수도 있습니다. 배포에 문제가 발생하더라도 롤백할 필요 없이 기능만 다시 해제하면 됩니다.

 [장애 격리 영역 배포](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/):AWS AWS에서 배포와 관련하여 설정한 가장 중요한 규칙 중 하나는 한 리전에서 여러 가용 영역에 동시에 연결하지 않는 것입니다. 가용성 계산에서 가용 영역의 독립성을 유지하려면 이 규칙을 준수해야 합니다. 실제 배포에서도 이와 유사한 고려 사항을 포함하는 것이 좋습니다.

 **운영 준비 상태 검토(ORR)** 

 AWS는 테스트의 완전성, 모니터링 기능 그리고 무엇보다도 애플리케이션 성능이 SLA를 충족하는지를 감사하고 서비스가 중단되거나 비정상적인 작업이 수행되는 경우 데이터를 제공하는 기능을 평가하는 운영 준비 검토를 수행하는 데 유용합니다. 공식 ORR은 초기 프로덕션 배포 전에 수행됩니다. AWS는 ORR을 주기적으로(매년 1회 또는 성능이 중요한 기간) 반복 수행하여 운영상의 기대치를 벗어난 경우(드리포트)가 없었는지를 확인합니다. 운영 준비 상태에 대한 자세한 내용은 [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/)의 [운영 우수성 원칙](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)을 참조하세요.

**Topics**
+ [REL08-BP01 배포와 같은 표준 활동에 런북 사용](rel_tracking_change_management_planned_changemgmt.md)
+ [REL08-BP02 배포의 일부로 기능 테스트 통합](rel_tracking_change_management_functional_testing.md)
+ [REL08-BP03 배포의 일부로 복원력 테스트 통합](rel_tracking_change_management_resiliency_testing.md)
+ [REL08-BP04 변경 불가능한 인프라를 사용하여 배포](rel_tracking_change_management_immutable_infrastructure.md)
+ [REL08-BP05 자동화를 통한 변경 사항 배포](rel_tracking_change_management_automated_changemgmt.md)