OPS10-BP05 중단에 대한 고객 커뮤니케이션 계획 정의
중단 중에 고객과 이해 관계자에게 지속적으로 정보를 제공하는 데 사용할 수 있는 시스템 중단에 대한 커뮤니케이션 계획을 정의하고 테스트합니다. 사용자가 이용하는 서비스가 영향을 받거나 서비스가 정상으로 돌아올 때 모두 사용자와 직접 커뮤니케이션합니다.
원하는 결과:
-
예약된 유지 보수부터 재해 복구 계획 호출을 비롯한 예기치 않은 대규모 장애에 이르는 다양한 상황에 대한 커뮤니케이션 계획이 있습니다.
-
커뮤니케이션에서 시스템 문제에 대한 정보를 명확하고 투명하게 제공하여 고객이 시스템 성능을 추측하지 않도록 돕습니다.
-
사용자 지정 오류 메시지 및 상태 페이지를 사용하여 급격하게 늘어나는 헬프데스크 요청을 줄이고 사용자에게 정보를 제공합니다.
-
커뮤니케이션 계획은 실제 중단이 발생할 때 의도한 대로 수행되는지 확인하기 위해 정기적으로 테스트됩니다.
일반적인 안티 패턴:
-
워크로드 중단이 발생했지만 커뮤니케이션 계획이 없습니다. 사용자는 중단에 대한 정보가 없기 때문에 문제 티켓 시스템에 요청이 폭주합니다.
-
중단 중에 사용자에게 이메일 알림을 보냅니다. 여기에는 서비스 복원 일정이 포함되어 있지 않으므로 사용자는 중단과 관련된 계획을 세울 수 없습니다.
-
중단에 대한 커뮤니케이션 계획이 있지만 테스트를 진행한 적이 없습니다. 중단이 발생하고 테스트 진행 중에 발견할 수 있는 중요한 단계를 놓쳤기 때문에 커뮤니케이션 계획이 실패합니다.
-
중단 중에 AWS NDA에 해당하는 기술 세부 사항 및 정보가 너무 많이 담긴 알림을 사용자에게 보냅니다.
이 모범 사례 확립의 이점:
-
중단 중에 커뮤니케이션을 계속 주고받으면 고객이 문제 진행 상황과 예상 해결 시간을 확인할 수 있습니다.
-
잘 정의된 커뮤니케이션 계획을 개발하면 고객과 최종 사용자가 중단의 영향을 완화하기 위해 필요한 추가 단계를 수행할 수 있도록 충분한 정보를 얻었는지 확인할 수 있습니다.
-
적절한 커뮤니케이션과 계획된 중단 및 계획되지 않은 가동 중단에 대한 인식 개선을 통해 고객 만족도를 높이고 의도하지 않은 반응을 제한하며 고객 유지를 촉진할 수 있습니다.
-
투명하고 시의적절한 시스템 중단 커뮤니케이션은 확신을 주고 고객과의 관계를 유지하는 데 필요한 신뢰를 형성합니다.
-
중단 또는 위기 동안 입증된 커뮤니케이션 전략은 복구 능력을 방해할 수 있는 추측과 소문을 줄입니다.
이 모범 사례를 따르지 않을 경우 노출 위험도: 중간
구현 가이드
중단 중에 고객에게 계속 정보를 제공하는 커뮤니케이션 계획은 종합적이며, 고객에게 표시되는 오류 페이지, 사용자 지정 API 오류 메시지, 시스템 상태 배너 및 상태 페이지를 비롯한 여러 인터페이스를 포함합니다. 시스템에 등록된 사용자가 포함된 경우 이메일, SMS 또는 푸시 알림과 같은 메시징 채널을 통해 통신하여 개인화된 메시지 콘텐츠를 고객에게 보낼 수 있습니다.
고객 커뮤니케이션 도구
1차 방어선으로 웹 및 모바일 애플리케이션은 중단 시 친근하고 유용한 정보가 담긴 오류 메시지를 제공하고, 트래픽을 상태 페이지로 리디렉션할 수 있어야 합니다. Amazon CloudFront
사용자 지정 API 오류 메시지는 중단이 개별 서비스로 분리될 때 영향을 감지하고 줄이는 데 도움이 될 수 있습니다.Amazon API Gateway
다이렉트 메시징은 가장 개인화된 고객 메시징 유형입니다. Amazon Pinpoint
고객 사례
워크로드가 손상되면 AnyCompany Retail은 사용자에게 이메일 알림을 보냅니다. 이메일은 어떤 비즈니스 기능이 손상되었는지 설명하고 서비스가 복원될 시기에 대한 현실적인 추정치를 제공합니다. 또한 워크로드 상태에 대한 실시간 정보를 보여주는 상태 페이지가 있습니다. 커뮤니케이션 계획은 효과적인지 확인하기 위해 1년에 두 번 개발 환경에서 테스트됩니다.
구현 단계
-
메시징 전략을 시행할 커뮤니케이션 채널을 결정합니다. 애플리케이션의 아키텍처 측면을 고려하고 고객에게 피드백을 제공하기 위한 최상의 전략을 결정합니다. 여기에는 오류 및 상태 페이지, 사용자 지정 API 오류 응답 또는 다이렉트 메시징을 포함하여 설명된 하나 이상의 지침 전략이 포함될 수 있습니다.
-
애플리케이션의 상태 페이지를 설계합니다. 상태 또는 사용자 정의 오류 페이지가 고객에게 적합하다고 판단되면 해당 페이지에 대한 콘텐츠 및 메시지를 설계해야 합니다. 오류 페이지에서는 사용자에게 애플리케이션을 사용할 수 없는 이유, 다시 사용할 수 있는 시기, 그 동안 할 수 있는 작업을 설명합니다. 애플리케이션에서 Amazon CloudFront를 사용하는 경우 사용자 지정 오류 응답을 제공하거나 엣지에서 Lambda를 사용하여 오류를 변환하고 페이지 콘텐츠를 다시 작성할 수 있습니다. 또한 CloudFront를 사용하면 애플리케이션 콘텐츠에서 유지 보수 또는 중단 상태 페이지가 포함된 정적 Amazon S3
콘텐츠 오리진으로 대상을 바꿀 수 있습니다. -
서비스에 대한 올바른 API 오류 상태 집합을 설계합니다. 백엔드 서비스에 도달할 수 없을 때 API Gateway에서 생성되는 오류 메시지와 서비스 계층 예외에는 최종 사용자에게 표시하기에 적합한 친숙한 메시지가 포함되어 있지 않을 수 있습니다. 백엔드 서비스의 코드를 변경하지 않고도 HTTP 응답 코드를 선별된 API 오류 메시지에 매핑하도록 API Gateway 사용자 지정 오류 응답을 구성할 수 있습니다.
-
시스템의 최종 사용자와 관련이 있고 기술적 세부 사항을 포함하지 않도록 비즈니스 관점에서 메시징을 디자인합니다. 대상을 고려하고 메시지를 조정합니다. 예를 들어 내부 사용자에게 대체 시스템을 활용하는 해결 방법이나 수동 프로세스로 안내할 수 있습니다. 외부 사용자는 시스템이 복원될 때까지 기다리거나 업데이트를 구독하여 시스템이 복원된 후 알림을 받도록 요청받을 수 있습니다. 예기치 않은 중단, 계획된 유지 보수, 특정 기능이 저하되거나 사용할 수 없는 부분적인 시스템 오류를 비롯한 여러 시나리오에 대해 승인된 메시징을 정의합니다.
-
고객 메시징을 템플릿화하고 자동화합니다. 메시지 콘텐츠를 설정한 후에는 Amazon Pinpoint 또는 기타 도구를 사용하여 메시징 캠페인을 자동화할 수 있습니다. Amazon Pinpoint를 사용하면 영향을 받는 특정 사용자에 대한 고객 대상 세그먼트를 생성하고 메시지를 템플릿으로 변환할 수 있습니다. 메시징 캠페인 설정 방법을 이해하려면 Amazon Pinpoint 자습서를 검토합니다.
-
메시징 기능을 고객용 시스템에 밀결합하지 않도록 합니다. 중단이 발생할 때 성공적으로 메시지를 보낼 수 있는지 확인하기 위해 메시징 전략이 시스템 데이터 스토어 또는 서비스에 크게 의존해서는 안 됩니다. 메시징 가용성을 위해 둘 이상의 가용 영역 또는 리전에서 메시지를 보내는 기능을 구축하는 것을 고려합니다. AWS 서비스를 사용하여 메시지를 보내는 경우 컨트롤 플레인 작업보다 데이터 영역 작업을 활용하여 메시징을 호출합니다.
구현 계획의 작업 수준: 높음. 커뮤니케이션 계획과 이를 전송하는 메커니즘을 개발하려면 상당한 노력이 필요할 수 있습니다.
리소스
관련 모범 사례:
-
OPS07-BP03 런북을 사용한 절차 수행 - 커뮤니케이션 계획에는 담당자가 대응 방법을 알 수 있도록 이와 관련된 런북이 있어야 합니다.
-
OPS11-BP02 인시던트 사후 분석 수행 - 중단 후에는 사고 후 분석을 수행하여 또 다른 중단을 방지하기 위한 메커니즘을 식별합니다.
관련 문서:
-
Error Handling Patterns in Amazon API Gateway and AWS Lambda
(Amazon API Gateway 및 AWS Lambda의 오류 처리 패턴) -
Amazon API Gateway responses(Amazon API Gateway 응답)
관련 예시:
-
Summary of the AWS Service Event in the Northern Virginia (US-EAST-1) Region
(버지니아 북부(US-EAST-1) 리전의 AWS 서비스 이벤트 요약)
관련 서비스:
