기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 4단계: 운영
[3단계: 평가 및 테스트](stage-3.md)를 완료하면 애플리케이션을 프로덕션에 배포할 준비가 된 것입니다. *운영* 단계에서는 애플리케이션을 프로덕션에 배포하고 고객 경험을 관리합니다. 애플리케이션의 설계 및 구현에 따라 많은 복원력 결과가 결정되지만,이 단계에서는 시스템이 복원력을 유지하고 개선하는 데 사용하는 운영 사례에 중점을 둡니다. 운영 우수성 문화를 구축하면 이러한 사례에서 표준과 일관성을 만드는 데 도움이 됩니다.
## 관찰성
고객 경험을 이해하는 데 가장 중요한 부분은 모니터링과 경보를 사용하는 것입니다. 애플리케이션을 계측하여 상태를 이해해야 하며 다양한 관점이 필요합니다. 즉, 일반적으로 카나리를 사용하여 서버 측과 클라이언트 측 모두에서 측정해야 합니다. 지표에는 애플리케이션의 종속성 및 [장애 격리 경계에 맞는 차원](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/multi-az-observability.html)과의 상호 작용에 대한 데이터가 포함되어야 합니다. 또한 애플리케이션에서 수행하는 모든 작업 단위에 대한 추가 세부 정보를 제공하는 로그를 생성해야 합니다. [Amazon CloudWatch 임베디드 지표 형식](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html)과 같은 솔루션을 사용하여 지표와 로그를 결합하는 방법을 고려할 수 있습니다. 항상 더 많은 관찰성을 원할 수 있으므로 원하는 수준의 계측을 구현하는 데 필요한 비용, 노력 및 복잡성의 절충 효과를 고려합니다.
다음 링크는 애플리케이션을 계측하고 경보를 생성하기 위한 모범 사례를 제공합니다.
+ [Monitoring production services at Amazon](https://youtu.be/hnPcf_Czbvw)(AWS re:Invent 2020 프레젠테이션)
+ [Amazon Builders' Library: Operational Excellence at Amazon](https://youtu.be/7MrD4VSLC_w)(AWS re:Invent 2021 프레젠테이션)
+ [Observability best practices at Amazon](https://youtu.be/zZPzXEBW4P8)(AWS re:Invent 2022 프레젠테이션)
+ [Instrumenting distributed systems for operational visibility](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)(Amazon Builders' Library 문서)
+ [Building dashboards for operational visibility](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)(Amazon Builders' Library 문서)
## 이벤트 관리
경보나 고객 측(상황이 더 좋지 않음)에서 문제가 발생했음을 알리는 경우 장애를 처리하기 위한 이벤트 관리 프로세스가 마련되어 있어야 합니다. 이 프로세스에는 통화 중인 운영자 참여, 문제 에스컬레이션, 인적 오류를 제거하는 데 도움이 되는 문제 해결에 대한 일관된 접근 방식을 위한 런북 수립이 포함되어야 합니다. 그러나 장애는 일반적으로 단독으로 발생하지 않습니다. 단일 애플리케이션은 장애에 종속되는 다른 여러 애플리케이션에 영향을 미칠 수 있습니다. 영향을 받는 모든 애플리케이션을 이해하고 한 번의 컨퍼런스 통화로 여러 팀의 운영자를 한데 모아 문제를 신속하게 해결할 수 있습니다. 그러나 조직의 규모와 구조에 따라 이 프로세스에 중앙 집중식 운영 팀이 필요할 수 있습니다.
이벤트 관리 프로세스를 설정하는 것 외에도 대시보드를 통해 지표를 정기적으로 검토해야 합니다. 정기 검토는 애플리케이션 성능의 고객 경험과 장기 추세를 이해하는 데 도움이 됩니다. 이를 통해 프로덕션에 상당한 영향을 미치기 전에 문제와 병목 현상을 식별할 수 있습니다. 일관되고 표준화된 방식으로 지표를 검토하면 상당한 이점을 얻을 수 있지만 하향식 동의와 시간 투자가 필요합니다.
다음 링크는 대시보드 빌드 및 운영 지표 검토에 대한 모범 사례를 제공합니다.
+ [Building dashboards for operational visibility](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)(Amazon Builders' Library 문서)
+ [Amazon's approach to failing successfully](https://youtu.be/yQiRli2ZPxU)(AWS re:Invent 2019 프레젠테이션)
## 지속적 복원력
[2단계: 설계 및 구현](stage-2.md) 및 [3단계: 평가 및 테스트](stage-3.md) 중에 애플리케이션을 프로덕션에 배포하기 전에 검토 및 테스트 활동을 시작했습니다. *운영* 단계에서는 프로덕션 환경에서 이러한 활동을 계속 반복해야 합니다. [AWS Well-Architected Framework 검토](https://aws.amazon.com/architecture/well-architected/), [운영 준비 상태 검토(ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 및 [복원력 분석 프레임워크](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html)를 통해 애플리케이션의 복원력 상태를 주기적으로 검토해야 합니다. 이렇게 하면 애플리케이션이 설정된 기준 및 표준에서 드리프트되지 않도록 하고 새 지침 또는 업데이트된 지침을 최신 상태로 유지할 수 있습니다. 이러한 지속적인 복원력 활동은 이전에 예상치 못한 중단을 찾아내고 새로운 완화 조치를 마련하는 데 도움이 됩니다.
사전 프로덕션 환경에서 성공적으로 실행한 후 프로덕션 환경에서 [게임 데이](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.gameday.en.html) 및 [카오스 엔지니어링](https://aws.amazon.com/blogs/architecture/chaos-engineering-in-the-cloud/) 실험을 실행하는 방법도 고려해 볼 수 있습니다. 게임 데이는 완화를 위해 복원력 메커니즘을 빌드한 알려진 이벤트를 시뮬레이션합니다. 예를 들어 게임 데이는 AWS 리전 서비스 장애를 시뮬레이션하고 다중 리전 장애 조치를 구현할 수 있습니다. 이러한 활동을 구현하려면 상당한 노력이 필요할 수 있지만 두 가지 방법 모두 시스템이 견딜 수 있도록 설계한 장애 모드에 복원력이 있다는 확신을 쌓는 데 도움이 됩니다.
애플리케이션을 운영하고, 운영 이벤트에 직면하며, 지표를 검토하고, 애플리케이션을 테스트하면 대응하고 배울 수 있는 많은 기회가 생깁니다.