4단계: 운영

복원력이 뛰어난 애플리케이션을 빌드하고 테스트했습니다. 이제 일상적인 현실이 계속 실행되고 있습니다. 그러나 시작 시 모든 작업을 볼 수 없으며 시도해서는 안 됩니다. 핵심은 지표를 너무 많이 제공하거나 팀을 과도하게 부담하지 않고 중요한 사항에 주의를 기울이는 것입니다.

고객 관점에서 시작합니다. Amazon CloudWatch Synthetics canary는 자동화된 고객 역할을 합니다. 중요한 사용자 여정을 지속적으로 테스트합니다. 특히 바쁜 시간에 로그인하거나, 테스트 계정을 사용하여 구매를 시뮬레이션하거나, 주요 기능에 액세스하도록 합니다. 이를 통해 고객 경험을 이해하고 실제 사용자가 문제를 해결하기 전에 문제를 포착할 수 있습니다. canary가 실패하면 고객의 관점에서 문제가 있음을 즉시 알 수 있습니다.

지원 인프라를 집중적으로 모니터링하여이 기반을 구축합니다. 문제가 있음을 알려주는 신호는 무엇입니까? Amazon CloudWatch를 사용하면 이러한 징후를 추적하는 대시보드를 구축할 수 있습니다. 기술 지표만 모니터링하지 말고 비즈니스에 미치는 영향과 연결하세요. 예를 들어 CPU 사용량이 높을수록 카나리아로 추적하는 고객 경험이 저하될 수 있기 때문입니다.

실용적인 접근 방식으로 모니터링을 고객 여정에 매핑합니다. 서비스형 소프트웨어(SaaS) 플랫폼을 실행하는 경우 API 응답 시간, 인증 성공률 및 핵심 기능 가용성에 신경을 쓸 것입니다. 이러한 지표가 드리프트되는 시기를 알려주는 알림을 설정합니다. 그러나 선택 사항이어야 합니다. 모든 알림에는 조치가 필요합니다. “아마도 아무것도 아니기 때문에” 팀이 알림을 무시하기 시작하는 경우 너무 많이 설정했거나 잘못된 지표를 추적하고 있는 것입니다.

팀이 이미 사용하는 도구를 통해 이러한 알림을 라우팅합니다. 엔지니어가 특정 메시징 애플리케이션에 거주하는 경우 여기에 알림을 보냅니다. 목표는 새 프로세스를 생성하지 않고 빠르게 인식하는 것입니다. 알림이 실행되면 팀은 알림의 의미와 이에 대해 수행할 작업을 정확히 알아야 합니다.

운영 설명서를 간결하고 실용적으로 유지하세요. 런북을 코드와 함께 버전 관리에 저장하되, 소설이 아님을 기억하세요. 문제가 발생하면 팀에 명확하고 실행 가능한 단계가 필요합니다. 각 알림은 해당 실행서에 연결되어야 하며, 각 실행서는 다음 세 가지 질문에 답해야 합니다.

간단한 인시던트 관리 프로세스를 구현합니다. 복잡한 프레임워크가 필요하지 않습니다. 인시던트를 구성하는 항목과 상황이 에스컬레이션될 때 호출할 대상에 대한 명확한 정의만 있으면 됩니다. 인시던트 로그는 애플리케이션의 복원력을 개선하는 데 도움이 되므로 보관합니다.

핵심은 경계와 오버헤드 사이의 스위트 스팟을 찾는 것입니다. AWS 도구를 사용하여 할 수 있는 일을 자동화하고, 고객에게 영향을 미치는 지표를 모니터링하는 데 집중하고, 성장에 따라 프로세스를 충분히 가볍게 발전시킬 수 있습니다.

다음 장에서는 스타트업을 특별하게 만드는 속도와 혁신을 희생하지 않고 복원력 사고방식을 조성하는 방법을 살펴봅니다. 결국 복원력은 기술에 관한 것만큼이나 사람에 대한 것입니다.