알림 피로

알림 피로는 알림이 너무 자주 울려서 사람이 알림에 무뎌지는 고장입니다. 울린 알림 대부분은 손쓸 일 없이 끝납니다. 그러면 사람은 진짜 장애를 알리는 알림까지 늦게 보거나 놓칩니다.

쉽고 빠른 이해

알림 피로는 알림이 울려도 사람이 움직이지 않게 되는 상태입니다. 새벽마다 「서버 부하가 높다」 알림이 울립니다. 열어 보면 매번 값이 이미 내려와 있습니다. 이런 알림이 쌓인 끝에 생깁니다.

이 고장에 이름이 붙은 까닭은 알림 장치가 멀쩡한데도 장애를 놓치기 때문입니다. 알림은 제때 울렸습니다. 사람이 그 알림을 흘려보냈을 뿐입니다.

어떻게 도나:

1. 손쓸 일이 없는 알림이 자주 울립니다
2. 사람은 열어 볼 때마다 「이번에도 괜찮다」를 확인합니다
3. 알림을 늦게 열거나 건너뛰는 버릇이 생깁니다. 진짜 장애 알림도 같은 대접을 받습니다

그 대가로 장애를 알아채는 시간이 길어집니다. 당번을 서는 사람은 잠과 집중을 잃고 지칩니다.

상세

알림 피로의 본체는 사람이 알림 하나를 열 때마다 무엇을 배우느냐입니다. 이 편은 서비스를 운영하며 받는 알림을 다룹니다. 병원 의료 기기의 경보가 너무 잦을 때도 같은 이름을 씁니다.

불필요한 알림

알림은 서비스에 이상이 생겼다고 사람에게 알려 주는 메시지입니다. 사람이 대시보드를 계속 지켜보지 않아도 장애를 알아채게 하려고 둡니다. 알림은 모니터링 시스템이 지표나 로그를 보다가 보냅니다.

언제 보낼지는 미리 정해 둡니다. 이것을 알림 규칙이라고 부릅니다. 「오류 비율이 몇 분 동안 기준선을 넘으면 알린다」 같은 것이 알림 규칙입니다.

알림 가운데 사람을 곧바로 불러내는 것을 페이지라고 부릅니다. 전화나 앱 푸시로 와서 자는 사람도 깨웁니다. 페이지를 받는 사람은 온콜 당번입니다. 온콜은 장애를 곧바로 맡기로 미리 정해 둔 당번입니다.

이 편에서는 울렸지만 사람이 손쓸 일이 없었던 알림을 불필요한 알림이라고 부릅니다. 영어로는 non-actionable alert 입니다. 열어 보니 값이 이미 정상으로 돌아와 있었거나, 사용자에게는 아무 영향이 없던 경우입니다. 알림 피로는 이 불필요한 알림이 쌓여서 생깁니다.

장애가 없는데 울린 알림은 흔히 거짓 양성이라고 부릅니다. 불필요한 알림은 이보다 넓습니다. 장애가 아니라 알고만 있으면 되는 소식을 알리는 알림도 불필요한 알림에 듭니다.

사람이 알림에 무뎌지는 과정

알림을 받은 사람은 먼저 알림을 엽니다. 상황을 본 뒤 할 일이 있는지 판단합니다. 이 판단에는 시간과 집중이 듭니다. 한밤중이면 잠도 듭니다.

그런데 열어 볼 때마다 할 일이 없었다면 사람은 그 경험에서 배웁니다. 「이 알림은 대개 괜찮다」는 믿음이 생깁니다. 다음 알림은 조금 늦게 엽니다. 그다음 알림은 제목만 보고 넘깁니다.

flowchart TD
    A["알림이 울린다"] --> B["당번이 열어 본다"]
    B --> C{"손쓸 일이 있었나"}
    C -->|없었다 · 불필요한 알림| D["알림을 덜 믿게 된다"]
    D --> E["다음 알림을 늦게 열거나 건너뛴다"]
    E --> A
    C -->|있었다| F["장애에 대응한다"]

「없었다」 쪽으로 갈라져 다시 「알림이 울린다」로 돌아오는 고리가 알림 피로입니다. 불필요한 알림이 한 번 돌 때마다 사람이 알림을 여는 때가 조금씩 늦어집니다. 고리를 여러 번 돈 뒤에 진짜 장애 알림이 오면, 그 알림도 늦게 열리거나 건너뛰어집니다.

알림 장치 쪽에서 보면 망가진 곳이 없습니다. 알림은 제때 울렸습니다. 전달도 제대로 됐습니다. 끊긴 곳은 알림과 사람의 행동 사이입니다. 그래서 알림 시스템의 로그만 보면 알림 피로가 안 보입니다.

알림 피로가 생기는 세 요인

세 요인이 함께 서면 알림 피로가 생깁니다.

1. 울린 알림 가운데 불필요한 알림의 비율이 높습니다. 열 번 울리면 한두 번만 손쓸 일이 있는 식입니다
2. 한 사람이 받는 알림 수가 그 사람이 하나하나 살펴볼 수 있는 수를 넘습니다
3. 불필요한 알림이 나도 그 알림 규칙을 고치지 않습니다. 같은 규칙이 같은 불필요한 알림을 다시 울립니다

하나만 빠져도 고리가 약해집니다. 불필요한 알림이 드물면 사람은 알림을 계속 믿습니다. 알림이 드물면 불필요한 알림이어도 하나하나 살펴볼 여유가 있습니다.

규칙을 고치지 않는 요인이 빠지면 고리가 끊깁니다. 불필요한 알림이 날 때마다 규칙을 손보면 같은 알림은 다시 안 옵니다. 그래서 규칙을 그대로 두는 것이 이 고장을 오래 끌고 가는 요인입니다.

불필요한 알림을 만드는 알림 규칙

불필요한 알림은 대개 알림 규칙을 거는 방식에서 나옵니다. 흔히 보는 꼴은 넷입니다. 그 가운데 첫 꼴을 보려면 「원인」과 「증상」이라는 짝말부터 알아야 합니다.

증상은 사용자가 겪는 일입니다. 응답이 느려지거나 오류가 나는 것이 증상입니다. 원인은 그 증상을 부를 수도 있는 속사정입니다. CPU(Central Processing Unit, 중앙처리장치) 사용률이 높은 것이 원인의 한 예입니다.

원인이 있어도 증상이 없는 때가 많습니다. CPU 사용률이 높아도 응답은 멀쩡할 수 있습니다. 그래서 원인에 건 알림이 불필요한 알림을 많이 냅니다. 아래 표는 네 꼴마다 왜 사람이 할 일 없이 불려 나오는지를 적었습니다.

잠깐 튀는 값에 건 알림은 값이 선을 넘었다 돌아오기를 되풀이하면 켜졌다 꺼졌다 합니다. 이렇게 알림이 깜빡이는 것을 플래핑이라고 부릅니다.

한 장애에 여러 알림이 걸려 있으면 알림이 한꺼번에 쏟아집니다. 이것은 알림 폭풍이라고 부릅니다.

정밀도와 놓침 사이

알림이 얼마나 불필요한 알림 없이 울리는지는 정밀도로 잽니다. 알림의 정밀도는 울린 알림 가운데 사람이 손을 써야 했던 것의 비율입니다. 불필요한 알림이 많을수록 이 값이 낮습니다.

반대쪽 잣대는 재현율입니다. 실제로 난 장애 가운데 알림이 울린 것의 비율입니다. 이 값이 낮으면 장애가 나도 알림이 안 옵니다.

둘은 한쪽을 올리면 다른 쪽이 내려가기 쉽습니다. 알림이 울리는 기준선인 임계값을 높이면 불필요한 알림이 줄어 정밀도가 오릅니다. 대신 작게 시작한 장애는 선을 못 넘어 놓칩니다. 그만큼 재현율이 내려갑니다.

알림 피로는 정밀도가 오래 낮게 머문 끝에 옵니다. 재현율만 높이려고 알림을 계속 더하면 이 고장으로 갑니다. 사람이 알림을 흘려보내기 시작하면 높던 재현율도 쓸모를 잃습니다. 알림이 울려도 아무도 안 움직이기 때문입니다.

알아채는 신호

알림 피로는 사람 쪽에서 나는 고장이라 알림 시스템의 오류 수로는 안 보입니다. 대신 알림과 사람의 반응을 함께 세면 드러납니다.

당번은 알림을 보면 봤다고 시스템에 표시합니다. 이 동작을 영어로 acknowledge, 줄여서 ack 라고 부릅니다. 알림을 받고 ack 하기까지 걸린 시간이 사람의 반응을 재는 값이 됩니다.

이 가운데 ack 까지 걸린 시간이 길어지는 것이 가장 먼저 드러나는 신호입니다.

고리를 끊는 방향

고치는 길은 대개 불필요한 알림을 줄이는 것입니다. 당번을 더 세우면 한 사람이 받는 수는 줄지만 불필요한 알림의 비율은 그대로입니다. 그래서 알림 규칙 쪽을 손봅니다.

급하지 않은 알림은 페이지 대신 티켓으로 돌리기도 합니다. 티켓은 사람을 깨우지 않고 할 일 목록에 쌓아 두는 알림입니다. 다음 업무 시간에 처리합니다.

어느 수단이든 재는 잣대는 같습니다. 당번 한 번 동안 받은 알림 가운데 조치로 이어진 비율이 오르는지를 봅니다.

관련 항목

알림 피로를 낳는 알림 체계

알림 · 알림 규칙 · 페이지 · 티켓 · 경보 · 모니터링 · 알림 라우팅 · 에스컬레이션 · 심각도

알림 피로를 떠안는 당번과 사고 대응

온콜 · 당번표 · 사고 대응 · 런북 · 사후 분석 · 번아웃

알림 피로를 부르는 불필요한 알림의 갈래

잡음 · 플래핑 · 알림 폭풍 · 거짓 양성 · 원인 기반 알림

알림의 품질을 재는 잣대

정밀도 · 재현율 · 임계값 · 탐지 시간 · 거짓 음성 · 혼동 행렬

알림 피로를 줄이는 알림 설계 수단

증상 기반 알림 · 알림 그룹핑 · 알림 억제 · 서비스 수준 목표 · 오류 예산 · 골든 시그널

알림이 기대는 관측 수단

관측성 · 지표 · 로그 · 대시보드 · 분산 추적 · 헬스 체크