기술 기반 워크스트림 - AWS 권장 가이드
검색 및 로드맵설계빌드테스트배포PGLS(Post Go-Live Support)

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

기술 기반 워크스트림

이 워크스트림에는 변경 시 상당한 재작업이 필요한 의사결정이 포함되므로 워크스트림에서는 DevOps 프로세스 및 테스트에 대한 신중한 설계, 광범위한 상담, 초기 투자를 강조합니다.

기술 기반 워크스트림은 검색 및 로드맵, 설계, 구축, 테스트, 배포, 가동 후 지원의 5단계로 구성됩니다.

콜 센터 마이그레이션의 기술 기반 워크스트림

검색 및 로드맵

이 단계에서는 다음과 같은 정보를 수집하고 워크숍 일정을 잡습니다.

  • 현재 매핑 – 시스템과 기능을 조사하고, 데이터를 수집하고, SME와 만나 콜 센터의 현재 상태를 파악합니다.

  • 예정 설계 및 격차 평가 - 모든 콜 센터 담당자와 고객이 프로젝트 범위를 정할 수 있는 이상적인 경험을 결정합니다.

  • 격차 해소 계획 - 콜 센터의 미래 상태를 구축하고 배포하기 위한 로드맵을 개략적으로 설명합니다.

워크숍 참석자:

  • 프로젝트 관리자

  • 비즈니스, 솔루션, 기술 및 보안 아키텍트

  • 인프라 플랫폼 소유자

설계

이 단계에서는 설계 문서를 생성합니다. 설계 아티팩트를 생성하기 위한 고유한 규칙이나 프로세스가 있을 수 있습니다. 설계 문서에는 Amazon Connect 구성, 네트워킹 및 보안이라는 최소 3개의 섹션을 포함하는 것이 좋습니다. 각 섹션에는 효과적인 검토 및 승인을 보장하기 위해 서로 다른 전문 이해관계자 그룹이 있을 가능성이 높으므로 이 세 영역에 대해 별도의 문서를 작성하는 것이 더 실용적일 수 있습니다. 이해관계자에는 아키텍트, 보안 및 규정 준수 팀, 플랫폼 소유자가 포함되어야 합니다.

빌드

이 단계에서는 DevOps 도구로 안정적인 릴리스를 표준화하고 관리하여 코드형 인프라(IaC) 원칙을 따릅니다. 더 빨리 시작하는 데 도움이 되더라도 수동 빌드 프로세스를 채택하지 마세요. 빌드가 더 복잡해지고 테스트 및 프로덕션 환경으로 승격될 때 안정성에 대한 위험과 버그 수가 증가할 수 있기 때문입니다. 자체 DevOps 도구가 없는 경우 빠르게 켤 수 AWS CodeBuild있는 AWS CodePipeline 및와 같은 AWS 도구를 사용하는 것이 좋습니다. 프로젝트 범위에 이러한 도구를 설정하는 데 드는 노력을 포함합니다. 이러한 도구를 사용하면 장기적으로 유용하며 DevOps 원칙을 준수할 수 있습니다. 개발, 테스트 및 프로덕션을 위해 최소 3개의 개별 AWS 계정을 구축하는 것이 좋습니다. DevOps 도구와 자동화는 이러한 환경에서 코드를 이동하는 데 도움이 될 수 있습니다.

테스트

테스트 단계는 3개의 순차적 하위 단계로 구성됩니다.

  1. 단위 테스트 – 개별 인프라 구성 요소가 정확하고 설계 사양 내에 있는지 테스트합니다. 수행자: 개발자

  2. 통합 테스트 - Microsoft Active Directory(AD) ID 관리 서비스와 같이 통합 경계를 형성하는 항목을 테스트합니다. 수행자: 개발자

  3. 제품 테스트 - 인프라 전반의 기능 여정을 종합적으로 테스트합니다. 예를 들어, 각 에이전트 이벤트가 보안 모니터링 도구에 로깅되고, 통화가 접수되고, 통화 녹음이 올바른 Amazon Simple Storage Service(S3) 버킷에 있는지 테스트합니다. 수행자: 기능 테스트 팀

배포

사용자 여정 가동이 예정되어 있을 때 인프라가 실시간 트래픽을 처리할 준비가 되어 있어야 합니다. 배포 단계에서는 AWS 서비스 할당량이 예상 통화 볼륨과 동시 에이전트 수, 번호 포팅 또는 수신자 부담 번호 서비스(TFNS) 리포지토리를 충족하고 실시간 트래픽 볼륨이 증가함에 따라 백엔드 시스템의 상태를 모니터링하는 데 중점을 둡니다. 또한 보안 및 규정 준수 팀은 자체 관점에서 플랫폼이 실시간 트래픽을 처리할 준비가 되었는지 확인해야 합니다.

PGLS(Post Go-Live Support)

새로운 콜 센터가 가동된 후 처음 몇 주 동안 프로젝트 팀은 BAU(Business As Usual) 지원 팀 및 최종 사용자와 계속 소통합니다. 프로젝트 팀은 사용자의 새 시스템 시작을 돕고, BAU 지원 팀과 함께 문제 해결에 참여하고, 피드백을 바탕으로 지원 설명서를 개선할 수 있습니다.