경보
고친 사람 github-actions[bot]
경보는 지켜보던 값이 미리 그어 둔 선을 넘었을 때 사람을 불러 손을 쓰게 하는 것입니다. 사람이 화면을 계속 들여다보지 않아도 고장을 제때 알게 됩니다. 선을 어디에 긋느냐에 따라 헛걸음이 잦아지기도 하고, 나서야 할 때를 놓치기도 합니다.
쉽고 빠른 이해
경보는 지켜보던 값이 선을 넘으면 사람을 부르는 것입니다. 저장 공간이 차 가는 서버가 한밤중에 담당자를 깨우는 것이 그런 경우입니다.
화면 앞에 사람을 붙여 둘 수는 없습니다. 지켜보는 일은 기계에 맡기고, 사람은 불렸을 때만 나서게 하려는 것입니다.
도는 모양은 셋입니다.
- 무엇을 볼지 값을 하나 고릅니다
- 그 값이 어떤 상태면 문제인지 조건으로 적어 둡니다
- 조건이 참이 되면 경보를 세우고 그 사실을 사람에게 보냅니다
대가가 있습니다. 조건을 촘촘히 걸수록 헛걸음이 늘고, 헛걸음이 잦으면 사람이 경보를 흘려보게 됩니다. 그러면 진짜 고장도 같이 묻힙니다.
상세
아이가 열이 날 때 몇 도부터 병원에 갈지 미리 정해 두는 일을 떠올려 봅니다. 선을 37.5도에 그으면 한밤중에 둘러업고 나갔다가 아침에는 멀쩡한 날이 늘고, 39도에 그으면 진작 갔어야 할 밤을 그냥 넘깁니다. 어느 눈금에 두어도 빗나가고, 정할 수 있는 것은 어느 쪽으로 더 자주 빗나갈지뿐입니다.
경보는 감시하는 값이 미리 정해 둔 조건을 벗어났다고 판정하고, 그 판정을 사람 쪽으로 내보내는 것입니다. 판정하는 쪽은 값을 재고 있는 모니터링 체계이고, 받는 쪽은 그 시스템을 맡은 사람입니다.
고장은 사람이 보지 않는 동안에도 납니다. 그렇다고 화면 앞에 사람을 앉혀 둘 수는 없습니다. 지켜보는 일은 지치지 않는 기계에 맡기고, 사람은 손을 써야 할 때만 나서게 하려고 경보를 겁니다.
부르는 낱말이 갈립니다. 영어권 도구는 조건이 깨졌다는 판정을 alert, 그 판정을 사람에게 보내는 일을 notification 으로 갈라 씁니다. 한국어에서는 둘 다 경보로도 알림으로도 옮겨져 자주 뭉개집니다. 아래에서는 앞쪽인 판정과 그 상태를 봅니다.
경보 규칙에 적는 것
경보 하나는 규칙 하나에서 나옵니다. 규칙에 들어가는 것은 셋입니다. 어떤 값을 볼지, 그 값이 어떤 상태면 문제인지, 그리고 누구에게 보낼지입니다.
첫째는 볼 값입니다. 응답 시간, 오류 비율, 남은 저장 공간처럼 숫자로 나오는 것이어야 조건과 견줄 수 있습니다. 시스템의 상태를 이렇게 숫자로 나타낸 것을 지표라고 부릅니다.
둘째는 조건입니다. 값 하나만 보고 판정하지는 않습니다. 값은 잠깐씩 튀기 때문입니다. 그래서 대개 "정해 둔 시간 동안 이어질 때"라는 단서를 함께 답니다.
조건을 적는 꼴은 대개 셋으로 갈립니다.
| 조건 꼴 | 무엇을 잡나 | 놓치는 것 |
|---|---|---|
| 값이 선 위로 올라간다 | 응답 시간이 길어지는 것처럼 나빠진 상태 | 선 바로 아래에서 오래 버티는 상태 |
| 값이 선 밑으로 떨어진다 | 요청이 아예 안 들어오는 것처럼 멎은 상태 | 줄긴 했어도 남아 있는 상태 |
| 값이 앞 구간과 크게 달라진다 | 평소와 다른 흐름 | 평소부터 어긋나 있던 흐름 |
셋을 섞어 거는 일이 흔합니다. 오른쪽 칸이 보여 주듯 한 꼴만으로는 못 잡는 상태가 언제나 남기 때문입니다.
셋째는 받을 사람입니다. 누구에게 어떤 경로로 보낼지 정해 두지 않으면 경보는 아무 데도 가 닿지 않습니다. 알림이 그 몫을 받습니다.
발생과 해소
경보는 한 번 울리고 끝나는 사건이 아닙니다. 조건이 깨져 있는 동안 이어지는 상태입니다.
stateDiagram-v2
[*] --> 평온
평온 --> 지켜봄: 조건이 깨짐
지켜봄 --> 평온: 곧 되돌아옴
지켜봄 --> 발생: 정해 둔 시간 동안 이어짐
발생 --> 해소: 조건이 풀림
해소 --> [*]
가운데 칸이 잠깐 튄 값을 걸러 냅니다. 조건이 깨지자마자 부르지 않고, 정해 둔 시간 동안 이어질 때만 발생으로 넘어갑니다.
발생한 뒤로는 같은 조건이 몇 번 더 참이 되어도 경보는 하나입니다. 재는 간격마다 새 경보를 세우면 고장 하나가 수백 건으로 불어납니다.
해소도 알려야 합니다. 알려 주지 않으면 사람은 자기가 고친 것이 맞는지 직접 확인해야 합니다. 발생만 보내고 해소를 안 보내는 체계에서는 이미 끝난 경보가 목록에 남아 쌓입니다.
헛 경보와 놓친 경보
빗나감은 두 방향입니다. 아무 일 없는데 부르는 것과, 일이 났는데 안 부르는 것입니다.
| 빗나감 | 언제 나나 | 무엇이 뒤따르나 |
|---|---|---|
| 헛 경보 | 조건이 너무 민감할 때 | 사람이 헛걸음하고, 경보를 덜 믿게 됩니다 |
| 놓친 경보 | 조건이 너무 둔할 때 | 고장을 사용자가 먼저 겪습니다 |
두 빗나감은 손잡이 하나의 양쪽 끝입니다. 조건을 민감하게 당기면 헛 경보가 늘고, 둔하게 밀면 놓친 경보가 늘어납니다. 한쪽만 줄이는 설정은 없습니다.
헛 경보가 쌓이면 사람은 경보를 열어 보지 않게 됩니다. 이 상태를 경보 피로라고 부릅니다. 경보를 늘리는 것만으로 시스템이 더 안전해지지 않는 까닭입니다.
증상에 걸까 원인에 걸까
무엇에 조건을 걸지도 갈립니다. 사용자가 겪는 증상에 걸 수도 있고, 그 증상을 낳는 원인 후보에 걸 수도 있습니다.
증상은 "응답이 오래 걸린다", "요청이 오류로 끝난다"처럼 밖에서 보이는 것입니다. 원인 후보는 "저장 공간이 차 간다", "대기 큐가 밀린다"처럼 안에서 보이는 것입니다.
| 경보 수 | 처음 보는 원인 | 부른 뒤 | |
|---|---|---|---|
| 증상에 건다 | 적습니다 | 원인이 무엇이든 잡힙니다 | 어디서 났는지 따로 찾아야 합니다 |
| 원인에 건다 | 원인 수만큼 늘어납니다 | 미리 적어 둔 것만 잡힙니다 | 무엇을 볼지 이미 정해져 있습니다 |
둘을 같이 걸면 고장 하나에서 양쪽이 함께 울립니다. 그래서 증상 쪽을 사람을 깨우는 경보로 두고, 원인 쪽은 대시보드에 남기거나 심각도를 낮춰 두는 식으로 가릅니다.
증상 쪽 경보는 무엇이 잘못됐다는 것까지만 말해 줍니다. 그래서 불려 나온 사람이 무엇부터 볼지 적어 둔 문서를 경보에 같이 답니다. 그 문서를 런북이라고 부릅니다.
쏟아질 때 줄이는 손잡이
고장 하나가 경보 하나로 끝나지 않습니다. 데이터베이스 한 대가 멎으면 거기에 기대던 서비스마다 조건이 같이 깨집니다.
| 손잡이 | 하는 일 |
|---|---|
| 묶음 | 같은 원인으로 보이는 경보를 한 건으로 묶어 보냅니다 |
| 억제 | 상위 고장이 발생해 있는 동안 그 아래 경보를 보내지 않습니다 |
| 무음 | 정비처럼 미리 아는 기간에는 보내지 않습니다 |
| 심각도 | 지금 깨울 것과 아침에 볼 것을 갈라 둡니다 |
네 손잡이는 사람에게 닿는 건수를 줄입니다. 고장 자체를 줄이지는 않습니다. 묶고 눌러 둔 뒤에도 원래 조건은 깨져 있습니다.
억제와 무음에는 반대쪽 대가가 붙습니다. 눌러 둔 동안 새 고장이 나도 같이 묻힙니다. 그래서 무음은 기간을 정해 걸고, 그 기간이 지나면 저절로 풀리게 둡니다.
건수를 줄이는 마지막 방법은 조건을 아예 안 거는 것입니다. 사람이 손 쓸 것이 없는 조건은 경보로 만들지 않습니다. 재시도 몇 번으로 풀리는 실패가 그렇습니다. 불려 나온 사람이 할 일이 기다리는 것뿐이라면, 그 조건은 대시보드에 남길 것이지 사람을 깨울 것이 아닙니다.
관련 항목
경보를 만들어 내는 감시 체계
모니터링 · 관측성 · 대시보드 · 화이트박스 모니터링 · 블랙박스 모니터링 · 상태 점검 · 하트비트 · 로그
경보 조건에 올리는 지표
서비스 수준 지표 · 서비스 수준 목표 · 오류 예산 · 골든 시그널 · 오류율 · 지연 · 가용성 · 백분위수 · 집계 구간 · 임계값
경보를 사람에게 보내는 수단
경보를 받고 나서 밟는 단계
런북 · 사고 지휘 체계 · 사후 분석 · 평균 복구 시간
경보가 빗나가는 방식
거짓 양성 · 거짓 음성 · 경보 피로 · 경보 폭풍