플랫폼은 자기 자신을 무엇으로 재는가

한 줄 요약

플랫폼 팀이 재야 할 것은 노드의 CPU 가 아니라 플랫폼이 사용자에게 한 약속입니다. 셀프서비스 요청이 성공하는 비율, 배포가 끝나기까지 걸리는 시간, 되돌려야 했던 배포의 비율이 그 약속입니다.

왜 자원 지표로는 모자라나

노드 지표만 보는 대시보드는 사고가 나도 초록불입니다. 셀프서비스 발급이 전부 실패해도 노드의 CPU 는 오히려 한가하기 때문입니다. 반대로 노드가 바빠도 사용자 입장에서는 아무 문제가 없을 수 있습니다.

그래서 플랫폼도 하나의 서비스로 놓고 봅니다. 사용자는 개발팀이고, 요청은 청구 생성이나 배포이며, 성공과 실패가 있고 소요 시간이 있습니다. 이렇게 놓으면 잴 것이 분명해집니다.

| 무엇을 재는가 | 왜 그것인가 |
| --- | --- |
| 발급 요청의 성공 비율 | 셀프서비스가 실제로 셀프서비스인지 |
| 요청부터 사용 가능까지의 시간 | 골든 패스가 실제로 빠른지 |
| 배포 빈도와 되돌린 비율 | 배포가 두려운 일인지 아닌지 |
| 사고 복구까지 걸린 시간 | 문제를 아는 데 걸리는 시간과 고치는 데 걸리는 시간 |

어떻게 동작하나

기록 규칙이 먼저이고 알림이 그다음입니다

비율을 알림 조건 안에서 매번 계산하면 같은 식이 여러 알림에 흩어집니다. 한 곳을 고치고 다른 곳을 잊는 사고가 여기서 납니다. 그래서 비율은 기록 규칙으로 한 번 정의하고, 알림은 그 이름을 참조합니다.

groups:  - name: platform-slo    rules:      - record: platform:provision_success:ratio5m        expr: |          sum(rate(platform_provision_total{result="success"}[5m]))          /          sum(rate(platform_provision_total[5m]))

이름에 5m 이 들어 있으면 식의 구간도 5분이어야 합니다. 이름과 내용이 어긋나면 그 지표를 쓰는 모든 사람이 틀린 전제로 판단하게 됩니다.

알림에는 for 와 runbook 이 있어야 합니다

for 가 없으면 순간의 튐이 사람을 깨웁니다. 한 번 그런 일을 겪으면 사람들은 그 알림을 무시하기 시작하고, 그때부터 그 알림은 없는 것과 같습니다.

runbook_url 이 없는 알림도 마찬가지입니다. 새벽 세 시에 받은 알림에 다음 행동이 적혀 있지 않으면 그것은 정보가 아니라 소음입니다. severity 라벨은 라우팅이 갈리는 기준이라, 없으면 모든 알림이 같은 경로로 갑니다.

검증한 것과 배포한 것이 같아야 합니다

규칙 파일은 promtool check rules 로 검증할 수 있습니다. 사람이 읽어서는 표현식의 괄호 하나를 못 잡습니다. 다만 검증한 파일과 클러스터에 올라간 PrometheusRule 이 다른 물건이면 그 검증은 아무것도 보장하지 않습니다. 그래서 파일에서 CR 을 만들고, 올린 뒤 그룹 이름이 같은지 대조합니다.

현장에서 만나는 모습

한 팀의 대시보드에 발급 성공률이 늘 100% 로 찍혀 있었습니다. 실패한 요청은 애초에 지표를 남기지 않고 있었기 때문입니다. 분모가 성공만 세고 있으면 비율은 언제나 1 입니다.

이런 종류의 오류는 지표를 보고서는 절대 안 보입니다. 무엇을 세고 있는지를 식에서 직접 읽어야 보입니다. 그래서 새 지표를 만들 때는 실패를 일부러 한 번 내 보고 그 값이 움직이는지 확인해야 합니다. 알림도 마찬가지입니다.

그다음 읽을 것

지표가 이상을 알려 준 다음, 그 이상을 무엇부터 세어 분류할지를 이어서 봅니다.