초록이면 괜찮다는 말이 사실이려면

한 줄 요약

"초록이면 괜찮다" 는 약속은 그 초록이 무엇을 뜻하는지 말할 수 있을 때만 사실이다. 근거 없는 문턱은 아무 말도 하지 않으면서 모두를 안심시킨다.

왜 이게 필요했나

Grafana 에서 패널을 만들면 문턱이 이미 들어 있다. [공식 문서](https://grafana.com/docs/grafana/latest/visualizations/panels-visualizations/configure-thresholds/)가 적어 둔 기본값은 이렇다 — 기준선(Base)은 초록, 80 부터 빨강, 방식은 절대값. 이 80 은 어디서 왔을까. 아무 데서도 오지 않았다. CPU 사용률처럼 0 에서 100 사이인 값을 쓰는 사람이 많아서 정해 둔 편의값이다.

문제는 그 편의값이 우리 지표에 그대로 남는다는 것이다. PromQL 로 만든 오류 비율은 0 과 1 사이로 나온다. 그 패널에 80 짜리 빨강 문턱이 붙어 있으면, 서비스가 요청을 100% 실패시켜도 값은 1 이라 문턱을 넘지 못한다. 그 패널은 영원히 초록이다. 화면은 매일 "괜찮다" 고 말하고 있었고, 아무도 그 말이 무슨 뜻인지 물어본 적이 없었을 뿐이다.

반대 방향도 흔하다. 누군가 "빨간 게 너무 자주 뜬다" 며 문턱을 슬쩍 올린다. 근거가 없으니 내리는 것도 근거가 없다. 문턱이 한 번 감정의 손잡이가 되면 그다음부터는 화면이 사람을 길들인다.

어떻게 동작하나

문턱은 그림이 아니라 대시보드 모델에 있다. fieldConfig.defaults.thresholds 아래에 방식(mode)과 단계 목록(steps)이 들어 있고, 각 단계는 색과 값을 갖는다. 맨 앞 단계의 값은 비어 있는데, 그것이 문서가 말하는 기준선 — 마이너스 무한대다. Grafana 는 단계를 값 순으로 정렬한 뒤, 값이 그 단계 이상인 마지막 단계의 색을 고른다. 경계는 포함이다. 문턱이 0.005 라면 0.005 는 이미 그 색이고 0.00499 는 앞 색이다.

여기서 나오는 규칙이 두 개 있다. 첫째, 단계는 "낮을수록 좋다" 를 전제로 쓰인다 — 값이 커질수록 나쁜 색으로 간다. 그래서 남은 디스크나 성공률처럼 클수록 좋은 지표에는 순서를 뒤집어야 한다. 기준선을 빨강으로 두고 위로 갈수록 초록이 되게. 이걸 뒤집지 않으면 디스크가 텅 빈 상태가 초록으로 보인다. 둘째, 단계 사이에는 빈 곳이 없다. 어떤 값이든 반드시 한 색을 갖는다.

방식은 두 가지다. 절대값은 값 자체를 문턱과 비교한다. 백분율은 값이 최솟값과 최댓값 사이에서 몇 퍼센트 위치인지를 비교한다. 그래서 백분율 문턱은 [표준 옵션의 Min·Max](https://grafana.com/docs/grafana/latest/visualizations/panels-visualizations/configure-standard-options/) 없이는 뜻을 갖지 못한다 — 문서가 Min 과 Max 를 "백분율 문턱 계산에 쓰는 값" 이라고 적어 둔 이유다. 남은 디스크를 백분율로 색칠하려면 볼륨 전체 크기를 최댓값으로 적어 주어야 하고, 그 숫자를 적지 않으면 Grafana 는 지금 화면에 있는 데이터에서 최댓값을 짐작한다. 그러면 같은 패널이 시간 범위를 바꿀 때마다 다른 색이 된다.

문턱을 정할 때 유일하게 설명 가능한 근거는 우리가 사용자에게 약속한 것이다. 30일 가용성 목표가 99.5% 라면 오류 예산은 0.5% 이고, 오류 비율이 0.5% 를 넘는 동안은 예산을 정확히 예산 속도보다 빨리 태우고 있는 것이다. 그러면 경고는 0.005 에, 그 두 배인 0.01 에 빨강을 두는 식으로 문턱이 계산된다. 이렇게 만든 문턱은 회의에서 방어할 수 있고, 목표가 바뀌면 같이 바뀐다.

색만으로 말하는 화면은 또 다른 문제를 만든다. 색각 이상이 있는 사람에게 빨강과 초록은 구별되지 않고, 흑백으로 인쇄된 회고 자료에서도 마찬가지이며, 알림 캡처가 흑백으로 저장되는 도구도 있다. 그래서 색은 덧붙이는 신호여야 하고 값과 글자가 먼저 있어야 한다. Grafana 에서는 [값 매핑](https://grafana.com/docs/grafana/latest/visualizations/panels-visualizations/configure-value-mappings/)의 Range 규칙으로 구간마다 글자를 붙일 수 있다. 0 에서 0.005 까지는 "정상", 그 위는 "예산 소진 중" 처럼. 매핑은 위에서부터 훑어 처음 걸리는 규칙이 이기고 양 끝을 모두 포함하므로, 경계값이 겹치면 앞의 규칙이 가져간다.

마지막은 화면과 호출기의 어긋남이다. 패널의 빨강이 0.01 인데 알림 규칙은 0.02 에서 울린다면, 오류 비율 0.015 인 시간 동안 대시보드는 새빨갛고 아무도 호출되지 않는다. 사고 회고에서 "왜 아무도 몰랐나" 를 물으면 두 숫자가 서로 다른 파일에 손으로 적혀 있었다는 답이 나온다. 고치는 방법은 둘을 한 곳에서 끌어오는 것이다. 목표 파일에 숫자를 한 번 적고, 패널과 규칙을 거기서 만들어 내면 어긋날 자리가 사라진다.

이 환경이 판정할 수 없는 것도 분명히 해 두자 — 실제로 칠해진 색이다. 이 파드의 Grafana 에는 이미지 렌더러 플러그인이 없어서 패널을 그림으로 뽑을 수 없다. 그래서 채점기는 문턱 모델과 쿼리 결과만 본다. 어떤 값이 어떤 색이 되는지는 Grafana 가 쓰는 규칙을 그대로 계산해 확인할 수 있지만, 그 빨강이 화면에서 눈에 띄는지, 옆 패널의 초록과 헷갈리지 않는지는 확인할 수 없다. 그건 웹 미리보기로 3000번 포트를 열어 사람이 봐야 한다.

현장에서 만나는 모습

한 팀의 결제 대시보드는 여섯 달 동안 한 번도 빨개진 적이 없었다. 신뢰의 근거로 그 사실이 자주 인용됐다. 어느 날 누가 패널 JSON 을 열어 보고 문턱이 80 인 것을 발견했다. 그 패널의 값은 0 과 1 사이였다. 여섯 달 동안 그 초록은 "괜찮다" 가 아니라 "아무 말도 하지 않는다" 였다.

다른 팀에서는 디스크 게이지가 빨강으로 시작해 초록으로 끝나는 대신 반대로 붙어 있었다. 남은 용량이 90% 일 때 빨강, 5% 일 때 초록이었다. 아무도 이상하다고 말하지 않은 이유는, 그 패널이 늘 초록이었기 때문이다.

다음 실습에서 할 것

Grafana 를 띄우고 기본 문턱 그대로인 패널을 하나 만들어, 그 문턱이 우리 지표에서 도달 가능한 값인지 직접 계산해 본다. 그다음 목표 파일에서 오류 예산을 꺼내 문턱을 계산해 넣고, 지금 값이 어느 색인지 Grafana 의 규칙으로 확인한다. 절대값 문턱과 백분율 문턱을 갈라 쓰면서 최솟값·최댓값이 왜 필요한지 보고, 값 매핑으로 색 말고 글자도 함께 말하게 만든다. 경계값 여섯 개로 문턱의 순서와 포함 규칙을 확인하는 작은 도구를 만들고, 이미 운영에 올라가 있는 알림 규칙의 임계값과 패널 문턱을 한 값에서 끌어오게 고친다. 마지막으로 문턱 결함 네 개가 든 운영 대시보드를 받아 전부 고쳐 제출한다.