무엇을 지표로 둘까, 사용자 체감부터 거슬러 오르기

사용자가 겪는 것부터 지표로 만듭니다

지표를 자원 쪽에서 시작하면 숫자는 많고 판단은 어려워집니다. 프로세서 사용률이 70퍼센트일 때 좋은지 나쁜지 그 숫자만으로는 알 수 없습니다. 그래서 사용자가 겪는 것에서 시작합니다. 가장 위층은 사용자 체감 지표입니다. 요청이 성공했는지와 얼마나 기다렸는지 두 가지입니다. 그 아래가 서비스 지표입니다. 주요 기능별 성공률과 응답 시간입니다. 그 아래가 자원 지표이고, 가장 아래가 외부 의존성 지표입니다. 이 순서로 만들면 위층이 나빠질 때 아래층을 따라 내려가며 원인을 찾을 수 있습니다. 반대 방향으로는 그 추적이 되지 않습니다.

경보는 위층 두 개에만 붙입니다

지표를 많이 만드는 것과 경보를 많이 거는 것은 다릅니다. 지표는 조사용으로 많아도 되지만, 경보는 사람을 부르는 장치이므로 적어야 합니다. 그래서 경보는 사용자 체감 지표와 서비스 지표에만 붙입니다. 자원 지표는 조사할 때 보는 값으로 두고 경보를 걸지 않습니다. 프로세서 사용률이 높아도 응답이 정상이면 부를 일이 없기 때문입니다. 예외는 되돌릴 수 없는 한계에 가까워지는 지표입니다. 디스크 남은 공간처럼 소진되면 복구가 어려운 값은 자원 지표라도 경보를 걸고, 소진까지 남은 시간을 기준으로 임계값을 정합니다.

지표 수와 경보 수를 세어 봅니다

학습용 가정으로 계산합니다. 가정값은 사용자 체감 지표 1개, 서비스 지표 3개, 자원 지표 6개, 외부 의존성 지표 2개를 둔다고 하겠습니다. 전체 지표는 12개입니다. 경보는 위층 두 개에만 붙이므로 1 더하기 3으로 4개입니다. 중간 계산값으로 경보 없는 조사용 지표는 8개입니다. 최종 판단은 당직 부담으로 합니다. 경보 4개는 각각 울릴 때 할 일이 명확해야 하고, 그 절차를 적을 수 있는 수준이어야 합니다. 절차를 적을 수 없는 경보가 있다면 그것은 아직 경보가 아니라 조사용 지표입니다.

체감 지표를 만들 수 없는 경우

결론을 뒤집는 조건은 측정 지점입니다. 사용자 체감을 서버 쪽에서만 재면 네트워크와 브라우저 구간이 빠져 실제 체감과 차이가 생깁니다. 그래서 가능하면 브라우저에서 수집한 값을 함께 봅니다. 수집 수단이 없으면 서버 쪽 값으로 시작하되 '서버 응답까지만 측정했다'고 지표 설명에 적습니다. 두 번째 조건은 트래픽이 적은 서비스입니다. 요청이 시간당 몇 건뿐이면 성공률이 한 건에 크게 흔들려 경보가 불안정해집니다. 이때는 비율 대신 실패 건수로 경보를 걸고, 평가 기간을 길게 둡니다. 지표 설명에는 이 선택의 이유를 적습니다.

서버 운영 실행 전 점검표

• 사용자 체감·서비스·자원·외부 의존성 네 층으로 지표를 나눴다
• 경보는 위층 두 개에만 붙였다
• 소진되면 복구가 어려운 자원 지표에만 예외로 경보를 걸었다
• 경보마다 울릴 때 할 일을 적었다