벽면 TV 로 보는 APM 설계 기준, 장애 상황을 벽면 TV에서 1초에 읽게 하는 법

책상 위 APM은 담당 운영자가 장애 원인을 찾는 화면이고, 벽 TV의 APM 월보드는 사무실 전체가 지금 상황을 1초 안에 읽는 화면이라 설계 기준이 다릅니다. 2분 34초 영상과 화면 8장으로 정리했습니다.

영상으로 먼저 보기: 책상 화면과 APM 월보드를 나눠 쓰는 이유

같은 APM 데이터를 보는 두 화면, 책상 위 OPENMARU APM 대시보드와 벽에 건 OPENMARU Wallboard(월보드)를 나란히 놓고 두 화면이 답하는 질문이 어떻게 다른지 설명하는 영상입니다.

영상에서 다루는 순서는 다음과 같습니다.

같은 데이터인데 화면은 왜 달라야 하는가 (0:00)
팔 거리에서 들여다보는 책상용 APM 대시보드 (0:09)
느린 요청에서 원인까지 내려가는 과정 (0:26)
같은 대시보드를 벽 TV에 띄웠을 때 (0:45)
‘왜’에서 ‘지금 무슨 일’로 바뀌는 질문 (1:01)
뉴스 화면처럼 설계한 APM 월보드 (1:18)
장애부터 회복까지 함께 보는 과정 (1:31)
지나가는 사람마다 다른 정보 (1:46)
숫자보다 색을 먼저 보여 주는 까닭 (2:03)
보는 화면과 고치는 화면의 분리 (2:14)

이 영상이 답하는 8가지 질문 정리

영상의 내용을 질문으로 바꾸면 여덟 가지이고, 아래 여덟 개 절이 이 순서대로 답합니다.

책상 위 APM 대시보드는 왜 지표를 한 화면에 빽빽하게 놓는가?
느린 요청의 원인은 어떤 순서로 찾아 들어가는가?
책상 화면이 끝내 답하는 질문은 무엇인가?
같은 대시보드를 벽 TV에 띄우면 무엇이 어긋나는가?
APM 월보드는 지금 벌어지는 일을 어떻게 보여 주는가?
장애가 풀려 가는 과정은 벽에서 어떻게 보이는가?
벽 앞을 지나는 사람마다 무엇을 가져가는가?
APM 월보드는 왜 숫자보다 색을 먼저 보여 주는가?

책상 위 APM이 지표를 한 화면에 빽빽하게 놓는 이유

책상 위 APM 대시보드는 담당 운영자 한 사람이 팔 거리에서 마우스를 쥐고 보는 화면입니다. 보는 사람이 가까이 있고 시간을 들여 읽을 수 있으므로, 화면은 들여다볼 지표를 최대한 많이 한 장에 담습니다.

APM(Application Performance Management, 애플리케이션 성능 관리)은 애플리케이션에서 도는 요청의 처리 상태를 계속 기록하는 도구입니다. 영상의 나레이션은 이 화면을 “응답시간과 처리량, 힙 메모리처럼 들여다볼 지표가 한 화면에 빽빽하게 놓”인다고 설명합니다.

책상용 APM 대시보드에는 TPS·평균 응답시간·JVM 힙·사용자 만족도 위젯이 한 화면에 빽빽하게 놓여 있다.

▲ 팔 거리에서 들여다보는 책상용 APM 대시보드 (영상 0:15)

화면에는 위젯이 열 개 가까이 놓여 있습니다. 위쪽은 지금 들어오는 요청을 인스턴스별로 보여 주는 요청 뷰어와 실시간 요청 모니터링이고, 가운데는 트랜잭션 히트맵(T-Map), 활성 사용자, TPS(Transactions Per Second, 초당 처리 건수), 사용자 만족도 그래프입니다. 아래쪽에는 JVM(Java Virtual Machine, 자바 가상 머신) 힙 사용량, 평균 응답시간, 오류율 그래프가 이어집니다. 오른쪽 정보 패널에는 사용자 만족도 75.0%, TPS 2.0, 평균 응답시간 2,244ms 같은 숫자가 작은 글씨로 찍혀 있습니다.

이 밀도는 결함이 아니라 목적에 맞춘 설계입니다. 운영자는 그래프 하나에서 이상한 봉우리를 보면 바로 옆 그래프와 시간대를 견주고, 의심 가는 구간을 마우스로 끌어 다음 화면으로 넘어갑니다. 지표가 여러 화면에 흩어져 있으면 이 비교가 끊깁니다. 책상 화면은 한 사람이 오래, 가까이서, 손을 움직이며 본다는 전제 위에 서 있습니다.

느린 요청에서 호출 흐름을 따라 내려가는 방식

원인 찾기는 느린 요청만 골라 목록을 여는 데서 시작합니다. 나레이션은 “느린 요청만 골라 목록을 열고, 호출 흐름을 따라 내려가면 원인이 나온다”고 말합니다. 트랜잭션 히트맵에서 위쪽에 찍힌 느린 점들을 마우스로 끌어 고르면, 그 점에 해당하는 트랜잭션 목록이 열립니다.

목록에서 한 줄을 고르면 호출 흐름 탭이 그 요청 안에서 어떤 메서드가 어떤 순서로 불렸고 각각 얼마나 걸렸는지를 나무 모양으로 펼칩니다.

호출 흐름에서 HttpClient.executeMethod 외부 호출 하나가 응답시간 24.71초를 전부 차지한다.

▲ 호출 흐름을 따라 내려가 찾은 24.71초짜리 외부 호출 (영상 0:32)

화면의 요청은 /http/httpclient3이고 응답시간은 24.71초입니다. 나무를 따라 내려가면 웹 필터, 스프링 디스패처, 컨트롤러를 지나 맨 아래 HttpClient.executeMethod()에 닿습니다. 위의 모든 단계가 똑같이 24.71초로 찍혀 있다는 것은 그 시간이 전부 맨 아래 외부 호출 하나에서 나왔다는 뜻입니다. 나레이션이 “외부 호출 하나에 이십오 초 가까이 걸렸다”고 말한 대목입니다.

같은 줄의 CPU 시간이 3ms라는 점도 함께 읽어야 합니다. 24.71초 가운데 실제로 계산에 쓴 시간은 거의 없고, 나머지는 무언가를 기다린 시간입니다. 서버가 바빠서 느린 것이 아니라 바깥의 응답을 기다리다 느려졌다는 판단이 여기서 나옵니다. 이 판단은 마우스로 탭을 넘기고 나무를 펼치며 한 줄씩 읽어야 얻을 수 있습니다.

책상 화면이 ‘왜’에 답하는 구조

호출 흐름 다음의 성능 분석 탭이 기다린 까닭을 확정합니다. 영상의 결론은 “그 원인은 데이터베이스 연결 실패였습니다”입니다. 책상 화면이 운영자에게 주는 답은 결국 왜 이런 일이 벌어졌는가에 대한 답입니다.

성능 분석 탭은 이 요청의 원인을 MS SQL Server 연결이 거부된 DB 연결 실패로 확정한다.

▲ 성능 분석이 짚은 원인, DB 연결 실패 (영상 0:40)

분석 결과는 세 덩어리로 나뉩니다. 맨 위 ‘문제 감지’는 DB 연결 실패를 ‘확정’으로 표시하고, JDBC 드라이버가 MS SQL Server이며 오류가 java.net.ConnectException: Connection refused라고 적습니다. 그 아래에는 가능한 원인 네 가지(DB 서버 다운, 네트워크나 방화벽 차단, 잘못된 JDBC 주소, 커넥션 풀의 검증 설정)와 “DB 서버 가용성을 가장 먼저 확인하라”는 안내가 붙습니다.

이어지는 ‘누적 핫스팟’과 ‘느린 외부 호출’은 같은 사실을 다른 각도에서 보여 줍니다. 24.71초가 걸린 외부 호출은 코드 조회 API를 부른 것이었고, 그 호출 끝에 연결 거부 오류가 찍혀 있습니다. 즉 애플리케이션이 데이터베이스에 붙지 못한 채 응답을 기다리다가 사용자 요청 전체가 늦어진 것입니다.

이 화면이 하는 일은 원인을 좁히는 것입니다. 여러 줄의 코드 경로, 예외 이름, 원인 후보, 확인 순서가 한 화면에 있고, 이것을 읽고 다음 행동을 정하는 사람은 담당 운영자입니다. 몇 분이 걸려도 괜찮고, 화면은 그 몇 분 동안 필요한 단서를 빠짐없이 내놓아야 합니다.

같은 대시보드를 벽면 TV에 띄우면 안 되는 이유

책상 화면을 그대로 벽 TV에 띄우면 설계의 전제가 전부 어긋납니다. 나레이션은 “설계는 오십 센티미터 거리인데, 벽은 삼 미터에서 십 미터 떨어져 있다”고 말합니다. 그리고 “확대해도 글자만 커질 뿐, 무엇을 먼저 볼지는 그대로”라고 덧붙입니다.

영상은 두 화면의 차이를 표 하나로 정리합니다.

책상 모니터는 50~70cm 거리에서 분 단위로 탐색하는 문제 해결 도구이고, 벽 TV 는 3~10m 거리에서 0.5~1초에 읽히는 관제 매체다.

▲ 책상 화면과 벽 화면은 답하는 질문이 다르다 (영상 1:14)

구분	책상 위 모니터	벽에 건 TV
성격	문제 해결 도구	관제 매체
보는 거리	50~70cm, 팔 거리	3~10m, 방 건너편
조작	마우스·키보드로 파고듦	조작 없이 판독
판독 시간	분 단위 능동 탐색	0.5~1초
보는 사람	담당 운영자	지나가며 보는 사람 전원
질문	왜 이런 일이 벌어졌는가	지금 무슨 일이 벌어지고 있는가

표에서 가장 큰 차이는 조작과 판독 시간입니다. APM 월보드 앞에는 마우스도 키보드도 없고, 지나가는 사람에게 남는 시간은 1초 남짓입니다. 책상 화면의 강점이던 ‘파고들기’가 벽 앞에서는 아예 불가능합니다. 위젯 열 개를 확대해 봐야 3m 밖에서 읽히는 것은 몇 개의 큰 숫자뿐이고, 그중 무엇이 지금 중요한지는 화면이 알려 주지 않습니다.

APM이 다루는 지표는 트랜잭션, 응답시간, JVM 힙, 가비지 컬렉션, 오류율, 외부 연동 상태처럼 여러 층에 걸쳐 있고, 이것을 다 펼치면 한 화면에 담긴 시계열이 100개를 넘습니다. 화면을 키운다고 사람이 멀리서 가려낼 수 있는 정보의 양까지 늘어나지는 않습니다. 거리가 멀어질수록 눈이 구분할 수 있는 최소 크기는 커지고, 그보다 작게 그려진 요소는 아무리 확대해도 방 건너편에서는 읽히지 않습니다.

그래서 질문 자체가 바뀝니다. 나레이션의 표현으로는 “왜가 아니라, 지금 무슨 일이 벌어지고 있는가”입니다. APM 월보드는 원인 찾기를 돕는 화면이 아니라, 지금 문제가 있는지와 어디에 있는지를 한눈에 알리는 화면이어야 합니다.

APM 월보드가 느려진 서비스만 붉게 바꾸는 방식

OPENMARU Wallboard는 뉴스 화면처럼 설계했다는 것이 영상의 설명입니다. 화면은 서비스 여덟 칸으로 나뉘고, 그 가운데 느려진 서비스만 붉게 바뀝니다. 아래 알림 띠에는 방금 일어난 일이 차례로 지나갑니다.

월보드 여덟 칸 가운데 지연이 쌓인 delivery 와 shoppingmall 만 붉고 주황으로 바뀌고 나머지는 초록이다.

▲ 느려진 서비스만 색이 바뀌는 월보드 여덟 칸 (영상 1:22)

여덟 칸은 order, payment, shoppingmall, member, search, delivery, settlement, notification입니다. 칸마다 가운데의 큰 숫자는 지연 건수이고, 그 아래 작은 글씨로 진행 중인 건수, 사용자 수, 만족도, TPS, 오류율이 붙습니다. 화면의 순간에 delivery는 지연 56건으로 숫자와 고리가 붉고, shoppingmall은 35건으로 주황입니다. 나머지 여섯 칸은 지연이 0~3건이고 고리가 초록입니다.

3m 밖에서 APM 월보드를 보면 작은 글씨는 읽히지 않지만, 붉은 칸 하나와 주황 칸 하나는 바로 눈에 들어옵니다. 지금 문제가 있는지, 있다면 어느 서비스인지가 1초 안에 전달됩니다. 책상 화면이 열 개의 위젯으로 답하던 질문을 APM 월보드는 여덟 칸의 색으로 줄여서 답합니다.

칸 가운데의 가장 큰 숫자가 지연 건수라는 것도 설계의 결정입니다. 벽에서 가장 먼저 읽히는 자리는 하나뿐이고, OPENMARU Wallboard는 그 자리를 ‘지금 밀리고 있는가’라는 질문에 내주었습니다. 만족도, 사용자 수, 오류율은 사라진 것이 아니라 그 아래 작은 글씨로 내려가 있습니다. 관제 화면을 고를 때 먼저 던질 질문이 ‘이 화면에서 가장 큰 글자는 무엇인가’인 까닭입니다.

여덟 칸이라는 분할 수도 벽이 답할 질문에서 나옵니다. 어디가 문제인지만 빠르게 가리키면 되는 벽이면 여덟 칸으로 나누고, 서비스 넷을 나란히 견줘야 하면 네 칸, 한 서비스를 깊게 봐야 하면 한 칸으로 둡니다. 여덟 칸 화면에서는 값을 하나도 읽지 않아도 숫자가 큰 칸과 색이 바뀐 칸이 먼저 눈에 들어오므로, 그 칸을 확인한 사람이 책상 화면으로 옮겨 가는 흐름이 자연스럽게 생깁니다.

화면 아래 알림 띠는 뉴스 자막과 같은 역할을 합니다. ‘위험’ 꼬리표와 함께 “17:03 shoppingmall · was03 WAS 에이전트 정지”가 흘러가고, 다른 순간에는 ‘주의’ 꼬리표로 평균 응답시간이 임계 4,000ms를 넘어 4,200ms가 된 사건이 지나갑니다. 칸의 색이 지금 상태를 말한다면, 알림 띠는 그 상태가 어떤 사건에서 시작됐는지를 순서대로 남깁니다.

장애에서 회복까지를 사무실 전체가 함께 보는 과정

APM 월보드의 두 번째 역할은 문제가 풀려 가는 과정을 보여 주는 것입니다. 나레이션은 “장애가 생기고, 담당자가 붙고, 지연 건수가 줄어 색이 다시 돌아오는 과정을 사무실 전체가 같은 화면으로 함께 지켜본다”고 말합니다.

몇 분 뒤 delivery 의 지연 건수는 56건에서 30건으로, shoppingmall 은 20건으로 줄고 링 색이 돌아오고 있다.

▲ 지연 건수가 줄며 색이 돌아오는 과정 (영상 1:38)

앞의 화면과 비교하면 변화가 분명합니다. delivery의 지연 건수는 56건에서 30건으로 줄었고, 붉던 큰 숫자가 다른 칸과 같은 파란색으로 돌아왔습니다. 만족도는 69.2에서 75.1로 올랐습니다. shoppingmall도 35건에서 20건으로 줄었습니다. 다만 delivery의 고리에는 아직 붉은 구간이 남아 있어서, 숫자는 내려왔지만 완전히 정상으로 돌아온 것은 아니라는 점도 함께 읽힙니다.

이 변화가 APM 월보드에 있다는 것이 중요합니다. 장애가 나면 담당자 주변에는 “지금 어떻게 됐어요?”라는 질문이 몰리고, 담당자는 원인을 찾는 대신 상황을 설명하는 데 시간을 씁니다. 영상의 표현으로는 벽 화면이 있으면 “따로 묻지 않아도 상황이 공유”됩니다. 담당자는 책상 화면에서 원인을 찾고, 나머지 사람들은 APM 월보드에서 진행 상황을 봅니다. 두 화면이 나뉘어 있기 때문에 담당자의 집중과 조직의 공유가 동시에 가능합니다.

지나가는 사람마다 다른 정보를 가져가는 구조

벽 앞을 지나는 사람은 한 부류가 아니고, 사람마다 가져가는 정보가 다릅니다. 영상은 세 사람을 예로 듭니다. 임원은 1~2초 동안 전체가 괜찮은지를, 운영자는 어느 칸이 이상한지를, 다른 직원은 색 하나를 봅니다.

임원은 벽 앞을 지나는 1~2초 동안 전체가 괜찮은지를 신호 하나로 읽는다.

▲ 임원은 1~2초, 신호 하나를 가져간다 (영상 1:50)

세 사람이 읽는 깊이를 나란히 놓으면 다음과 같습니다.

보는 사람	머무는 시간	가져가는 정보
임원	1~2초, 스치는 정도	전체가 괜찮은가, 신호 1개
운영자	몇 초	어느 칸이 이상한가
다른 직원	한순간	색 하나

한 화면이 세 사람을 모두 만족시키려면 정보에 층이 있어야 합니다. 가장 바깥층은 화면 전체의 색으로, 임원이 스치며 “붉은 칸이 있다, 없다”를 읽습니다. 그다음 층은 칸의 위치와 이름으로, 운영자가 “delivery가 문제다”를 읽습니다. 가장 안쪽 층은 칸 안의 작은 숫자로, 가까이 다가온 사람만 읽습니다.

임원에게 신호를 둘 이상 보여 주면 그중 무엇을 먼저 볼지 판단하는 부담이 새로 생깁니다. 바깥층의 신호를 하나로 좁히는 것은 정보를 숨기는 일이 아니라, 그 사람이 벽 앞에서 실제로 쓸 수 있는 1~2초에 화면을 맞추는 일입니다.

책상 화면에는 이런 층이 없습니다. 모든 지표가 같은 크기로 놓이고 무엇을 먼저 볼지는 보는 사람이 정합니다. 담당 운영자 한 사람에게는 그것이 맞는 설계지만, 지나가는 여러 사람에게는 맞지 않습니다.

APM 월보드가 숫자보다 색을 먼저 보여 주는 이유

APM 월보드는 숫자보다 색을 먼저 보여 줍니다. 나레이션의 이유는 짧습니다. “멀어질수록 숫자는 먼저 사라지고, 색은 끝까지 남기 때문”입니다.

1m 에서는 숫자까지 읽히고, 5m 에서는 큰 숫자와 색이, 10m 에서는 색만 남는다.

▲ 멀어질수록 숫자는 사라지고 색은 남는다 (영상 2:09)

영상은 같은 APM 월보드를 거리별로 흐리게 처리해 이 차이를 보여 줍니다. 1m에서는 칸 안의 작은 숫자까지 읽힙니다. 5m에서는 큰 숫자와 색만 남습니다. 10m에서는 숫자가 모두 뭉개지고 붉은 칸과 주황 칸의 색만 남습니다.

APM 월보드를 보는 거리가 3~10m라는 앞의 표와 이 그림을 겹쳐 보면 결론이 나옵니다. 방 건너편에서 확실히 전달되는 정보는 색뿐이므로, 가장 중요한 신호인 “어디가 이상한가”는 색으로 실어야 합니다. 숫자는 가까이 온 사람을 위한 다음 층입니다.

칸 하나가 같은 상태를 색, 큰 숫자, 고리의 길이로 겹쳐 그리는 것도 같은 까닭입니다. 거리가 한 겹을 지워도 다른 겹이 남습니다. 소수점과 단위가 뭉개지는 거리에서도 덩어리진 색과 큰 글자의 윤곽은 끝까지 버팁니다.

영상은 마지막으로 “한 화면에 두 역할을 맡기면 둘 다 어중간해진다”고 정리합니다. 책상 화면을 벽에 맞게 단순하게 만들면 원인을 찾는 데 필요한 단서가 사라지고, 벽 화면을 책상처럼 빽빽하게 만들면 멀리서 아무것도 읽히지 않습니다. 보는 화면과 고치는 화면은 따로 있어야 한다는 것이 영상의 결론입니다.

영상 밖의 보충: APM 월보드 같은 관제 화면을 설계할 때 따르는 기준

벽에 거는 화면은 애자일 개발에서 오래전부터 다뤄 온 주제입니다. 앨리스터 코번이 이름 붙인 정보 라디에이터는 팀이 일하는 공간의 눈에 잘 띄는 자리에 걸어 두고, 지나가는 사람이 따로 묻지 않아도 상태를 알 수 있게 하는 화면을 말합니다. 좋은 정보 라디에이터는 멀리서 한눈에 읽히고, 항상 최신 상태로 바뀝니다. 영상의 비교 표가 출처로 이 개념을 든 것도 같은 맥락입니다.

색이 숫자보다 먼저 읽히는 데에도 근거가 있습니다. 사람의 눈은 색, 크기, 방향처럼 몇 가지 시각 속성을 의식적으로 찾기 전에 먼저 알아챕니다. 닐슨 노먼 그룹은 대시보드 설계 글에서 이런 속성을 이용하면 중요한 값이 따로 찾지 않아도 눈에 띈다고 설명합니다. 여덟 칸 가운데 한 칸만 붉으면 그 칸은 찾는 과정 없이 보입니다.

다만 색 하나에만 의존해서는 안 됩니다. 웹 접근성 지침 WCAG는 색만으로 정보를 전달하지 말라고 권합니다. 색을 구분하기 어려운 사람도 있기 때문입니다. APM 월보드의 칸이 색과 함께 큰 숫자, 서비스 이름, 고리의 길이를 같이 보여 주는 것은 이 권고와도 맞습니다. APM 월보드 같은 관제 화면을 직접 만든다면 배경과 글자의 명도 대비도 함께 점검해야 합니다. 어두운 관제실에서는 대비가 낮은 글자가 거리보다 먼저 사라집니다.

무엇을 벽에 올릴지는 구글의 SRE 책이 실마리를 줍니다. 이 책은 사용자 쪽에서 본 서비스 상태를 지연, 트래픽, 오류, 포화도 네 가지 신호로 보라고 권하고, 대시보드는 서비스에 대한 기본 질문에 답해야 한다고 설명합니다. APM 월보드의 칸이 지연 건수를 큰 숫자로 두고 TPS와 오류율을 작은 글씨로 붙인 구성은 이 네 신호 가운데 사용자가 가장 먼저 느끼는 지연을 앞에 세운 배치입니다.

장애 상황 공유의 중요성은 장애 대응 실무에서도 강조됩니다. 아틀라시안의 장애 커뮤니케이션 안내는 장애 대응 중에 관계자에게 상태를 자주, 한 곳에서 알리라고 권합니다. APM 월보드는 이 ‘한 곳’을 사무실 안에 물리적으로 만드는 방법입니다.

핵심 정리: 책상 화면과 APM 월보드를 나눠 쓰는 기준

책상 화면은 원인을 찾는 화면이고, APM 월보드는 상황을 함께 보는 화면입니다. 두 화면의 설계 기준을 한 표로 모으면 다음과 같습니다.

기준	책상 위 APM 대시보드	벽 TV의 APM 월보드	영상 시각
답하는 질문	왜 이런 일이 벌어졌는가	지금 무슨 일이 벌어지고 있는가	1:01
보는 사람	담당 운영자 한 사람	지나가는 사람 전원	1:46
거리와 시간	50~70cm, 분 단위	3~10m, 1초 남짓	0:45
조작	마우스로 목록과 호출 흐름을 따라감	조작 없음	0:26
먼저 보여 줄 것	촘촘한 지표와 원인 후보	느려진 서비스의 색	2:03
장애 때 하는 일	DB 연결 실패 같은 원인 확정	장애부터 회복까지 진행 공유	1:31

관제실 벽에 APM 월보드를 걸기 전에 먼저 정할 것은 그 화면이 답할 질문입니다. “왜”에 답하는 화면은 이미 책상 위에 있습니다. 벽에는 “지금 괜찮은가, 아니라면 어디인가”에 1초 안에 답하는 APM 월보드를 따로 두어야 담당자도, 지나가는 사람도 각자 필요한 것을 가져갑니다.

자주 묻는 질문

APM 월보드는 무엇인가요?

APM 월보드는 APM이 모은 데이터를 관제실이나 사무실 벽의 큰 화면에 띄워 여러 사람이 함께 보도록 만든 화면입니다. OPENMARU Wallboard는 서비스마다 칸 하나를 두고 가운데에 지연 건수를 크게 표시하며, 느려진 서비스의 칸만 붉게 바꿉니다. 아래 알림 띠에는 방금 일어난 사건이 차례로 지나갑니다.

기존 APM 대시보드를 벽면 TV에 그대로 띄우면 안 되나요?

띄울 수는 있지만 벽에서는 제 역할을 하지 못합니다. 책상 화면은 50~70cm 거리에서 마우스로 파고들도록 설계되어 있고, 벽은 3~10m 떨어져 있으며 조작 수단도 없습니다. 확대해도 글자만 커질 뿐 무엇을 먼저 볼지는 그대로라서, 지나가는 사람이 1초 안에 상황을 읽기 어렵습니다.

책상 위 APM 화면은 장애 때 어떤 역할을 하나요?

담당 운영자가 장애의 원인을 찾는 역할을 합니다. 영상에서는 느린 요청을 골라 호출 흐름을 따라 내려가 24.71초가 걸린 외부 호출을 찾고, 성능 분석 탭에서 그 원인을 DB 연결 실패로 확정했습니다. 책상 화면이 답하는 질문은 왜 이런 일이 벌어졌는가입니다.

APM 월보드는 왜 숫자보다 색을 먼저 보여 주나요?

멀어질수록 숫자는 먼저 사라지고 색은 끝까지 남기 때문입니다. 영상은 같은 APM 월보드를 거리별로 보여 주며 1m에서는 숫자까지, 5m에서는 큰 숫자와 색이, 10m에서는 색만 남는다는 점을 보여 줍니다. 그래서 가장 중요한 신호인 어디가 이상한가를 색으로 싣습니다.