시스템 결함, 사용자 경험 중심으로 감지하라!

게시글은 전통적인 경고 설정 방식이 시스템의 모든 실패 시나리오를 예측하는 데 실패하며, 과도한 알림으로 엔지니어의 피로도를 높인다고 지적한다. 특히, 컨테이너 CPU 사용량 임계치 초과와 같은 낮은 수준의 지표(Low-level Metrics)에 기반한 경고는 시스템 변화에 취약하며, 오탐(False Positive)을 유발하여 신뢰도를 저하시킨다. 또한, 사후 분석(Postmortem) 과정에서 놓친 지표에 대한 경고를 추가하는 것은 또 다른 함정이라고 경고한다.

저자는 시스템의 핵심 사용자 여정(User Journey)을 정의하고, 해당 여정의 실패를 감지하는 방식으로 알림 설정을 개선할 것을 제안한다. 예를 들어, Spotify의 '노래 재생'과 같은 핵심 기능을 모니터링하여, API 오류 발생 시 알림을 발생시키는 것이다. 이러한 접근 방식은 시스템 구현 세부 사항에 덜 의존적이며, 예측 불가능한 하위 수준의 실패를 감지하는 데 효과적이다. 사용자 경험(User Experience)에 직접적인 영향을 미치는 지표를 중심으로 알림을 설정함으로써, 엔지니어는 시스템의 실제 문제에 더 빠르게 대응할 수 있다.

게시글은 서비스 수준 지표(SLI)를 통해 서비스의 현재 수준을 측정하고, 서비스 수준 목표(SLO)를 설정하여 문제의 심각성을 판단하는 방법을 제시한다. 예를 들어, 노래 재생 API의 성공률을 SLI로 측정하고, 99.9%의 성공률을 SLO로 설정하는 것이다. 이를 통해 오류 예산(Error Budget)과 소진율(Burn Rate)을 계산하여, 문제 발생 시 엔지니어가 얼마나 빠르게 대응해야 하는지 판단할 수 있다. 특히, 소진율(Burn Rate) 기반의 알림은 시스템의 전반적인 상태를 파악하는 데 유용하며, 유지 보수 부담을 줄일 수 있다.

게시글은 디스크 용량 부족, 데이터베이스 연결 제한 등 임박한 한계점(Impending Limit)에 대한 알림 설정을 권장한다. 이러한 알림은 문제 발생 전에 엔지니어에게 사전 경고를 제공하여, 시스템의 안정적인 운영을 유지하는 데 기여한다. 저자는 이러한 유형의 알림은 전통적인 방식이 적합하며, 자동화를 통해 관리하는 것이 이상적이라고 언급한다. 하지만, 모든 리소스 제한을 자동화하는 것이 불가능하므로, 수동적인 알림 설정도 필요하다는 점을 강조한다.