[DEVOPS-010][실무] 꼭 필요한 장애 알림과 당번 운영하기 > IT 기술 공유

• 목록

[이번 수업]
서비스 이상을 빠르게 알아채되 사람을 불필요하게 깨우지 않는 알림을 설계합니다. 즉시 대응하는 온콜 당번의 확인·전달·종료 흐름도 함께 배웁니다.

[선수지식]
로그·메트릭·트레이스와 SLI·SLO를 알아야 합니다. 온콜은 정해진 시간에 긴급 장애 알림을 받고 대응할 책임을 맡는 당번 제도입니다.

[학습목표]
- 사용자 영향이 있는 증상으로 알림을 만듭니다.
- 임계값과 지속 시간으로 순간 잡음을 줄입니다.
- 심각도별 채널, 담당자와 실행 안내서를 연결합니다.

[핵심개념]
좋은 알림은 사람이 지금 행동해야 하는 문제를 알려 줍니다. CPU 사용률 하나보다 성공률·지연 시간처럼 사용자가 겪는 증상을 우선합니다. 즉시 조치가 필요한 장애는 호출(page), 업무 시간에 처리해도 되는 문제는 티켓, 분석용 변화는 대시보드로 나눕니다. 모든 경고를 호출로 보내면 알림 피로 때문에 중요한 신호도 놓칩니다.

임계값은 경고를 켜는 기준이고 지속 시간은 그 상태가 얼마나 계속돼야 하는지입니다. 짧은 튐은 넘기되 실제 장애를 늦게 발견하지 않도록 과거 자료와 장애 훈련으로 조정합니다. 알림에는 서비스, 환경, 심각도 같은 라벨과 현상·영향·대시보드·실행 안내서(runbook)를 넣습니다. 같은 원인의 알림은 묶고, 상위 장애가 발생하면 파생 알림은 억제합니다. 점검 중 침묵은 종료 시각과 이유를 남깁니다.

온콜 흐름은 `수신 → 확인 → 초기 완화 → 필요 시 상향 전달 → 복구 확인 → 인계`입니다. 확인 응답 시간과 다음 담당자를 미리 정하고, 위험한 변경은 두 사람이 검토합니다. 당번 교대 때 진행 중인 장애, 적용한 완화책, 다음 판단 시점을 전달합니다. 장애 뒤에는 개인 탓 대신 감지와 대응 체계를 개선합니다.

[따라하기]
외부 알림을 보내지 않는 로컬 Python 실습입니다. alert_check.py로 저장하세요.

```python
samples = [0.01, 0.06, 0.07, 0.08]
threshold = 0.05
required = 3
recent = samples[-required:]
consecutive = sum(value >= threshold for value in recent)
firing = len(recent) == required and consecutive == required
state = "FIRING" if firing else "OK"
action = "page-oncall" if firing else "none"
print(f"latest={samples[-1]:.1%} consecutive={consecutive}")
print(f"state={state} action={action}")
```

macOS/Linux는 `python3 alert_check.py`, Windows PowerShell은 `py alert_check.py`로 실행합니다. 예상 결과입니다.

```text
latest=8.0% consecutive=3
state=FIRING action=page-oncall
```

오류율이 5% 이상인 표본이 세 번 연속이라 호출 상태입니다. 실제 시스템에서는 표본 간격, 누락 데이터 처리, 평가 지연을 명시합니다. Prometheus 규칙의 `for`는 조건이 일정 시간 유지된 뒤 firing 상태가 되도록 합니다. 먼저 시험용 수신처에서 정상·발생·복구 알림을 모두 확인하세요.

[흔한 실수]
원인 추정만 제목에 쓰거나, 소유자·실행 안내서·복구 알림을 빼먹기 쉽습니다. 한 임계값을 모든 시간대에 그대로 적용하거나 중복 알림을 여러 채널에 보내지 않습니다. 알림 개수보다 실제 행동으로 이어진 비율을 검토합니다.

[보안 주의]
알림 본문과 주소에 비밀번호, 토큰, 개인정보를 넣지 않습니다. 대시보드와 실행 안내서는 인증된 사용자만 열 수 있게 하고 알림 전송 비밀은 보안 저장소에 둡니다. 훈련은 본인 소유의 로컬·격리 환경과 시험 수신처에서만 하며 실제 당번을 호출하지 않습니다.

[직접 해볼 과제]
samples 마지막 값을 0.02로 바꿔 OK가 되는지 확인하세요. 이어서 WARNING은 티켓, CRITICAL은 호출이 되도록 심각도와 대응 표를 3줄로 작성하세요.

[확인문제]
1. 자원 사용률보다 사용자 증상 알림을 우선하는 이유는 무엇인가요?
2. 임계값에 지속 시간을 함께 두는 이유는 무엇인가요?
3. 알림에 실행 안내서와 상향 전달 경로가 필요한 이유는 무엇인가요?

[다음 학습]
SEC-010에서는 보안 테스트와 취약점 관리를 다룹니다. DEVOPS-011에서는 장애 대응·사후 분석·런북을 더 깊게 배웁니다.

[공식 참고 자료]
- Prometheus 알림 규칙: https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/
- Alertmanager 동작: https://prometheus.io/docs/alerting/latest/alertmanager/
- 실용적인 알림 설계: https://sre.google/sre-book/practical-alerting/
- SLO 기반 알림: https://sre.google/workbook/alerting-on-slos/