퀴즈: 알람 설계

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. CPU 사용률에 페이지 알림을 걸면 안 되는 이유로 가장 정확한 것은?

   1. CPU 메트릭은 카디널리티가 높아서
   2. CPU 90% 인데 응답이 정상이면 아무 일도 없는 것이고, CPU 40% 인데 응답이 5초면 심각한 사고이므로 두 경우 모두 틀리기 때문
   3. CPU 는 게이지 타입이라 rate 함수를 걸 수 없어 알림을 만들 수 없기 때문에
   4. CPU 는 클라우드에서 자동으로 조정되므로

2. '오탐이 많으니 for 를 30분으로 늘리자'가 안티패턴인 이유는?

   1. 프로메테우스가 30분 이상의 for 를 지원하지 않아서
   2. 메모리 사용량이 늘어서
   3. 탐지가 30분 늦어지고, 사고가 25분 만에 끝나면 알림이 아예 울리지 않기 때문
   4. for 는 표현식이 참인 총 시간을 세므로 의미가 없어서

3. 하루 400건의 알림 중 실제 조치로 이어진 것이 4건일 때 가장 큰 위험은?

   1. 알림 기록이 쌓여 스토리지 비용이 커진다
   2. 양이 많아 알림 전송이 지연된다
   3. '일단 무시하고 나중에 확인'이 합리적인 전략이 되어 버린다
   4. 규칙이 많아 평가가 느려진다

4. Alertmanager 의 `group_by` 에 instance 를 넣으면?

   1. 파드 수만큼 알림이 온다
   2. 알림이 전혀 오지 않는다
   3. 억제 규칙이 동작하지 않는다
   4. repeat_interval 이 무시된다

5. 알림 라우팅에서 '일단 슬랙 채널에만 보내자'는 절충안이 최악인 이유는?

   1. 슬랙 API 요금이 비싸서
   2. 슬랙은 억제 규칙을 지원하지 않아서
   3. 아무도 책임지지 않고 아무도 끄지 않는 4단계가 생기기 때문
   4. 슬랙 메시지는 감사 로그에 남지 않아서

6. 사일런스가 30일 이상 유지된 알림은 어떻게 해야 하는가?

   1. 사일런스를 90일로 연장한다
   2. 심각도를 page 로 올려 주의를 끈다
   3. 임계값을 두 배로 올린다
   4. 삭제한다 — 사일런스는 알림이 틀렸다는 가장 정직한 신호이기 때문