[DEVOPS-011][실무] 장애를 차분하게 해결하고 기록하기 > IT 기술 공유

• 목록

[이번 수업]
서비스 장애가 나면 원인 추측보다 사용자 영향 축소, 역할 분담, 시간순 기록이 먼저입니다. 이번에는 장애를 선언하고 복구한 뒤 사후 분석으로 재발 가능성을 낮추는 흐름과, 당황한 상황에서도 따라 할 런북(runbook)을 만듭니다. 런북은 반복 작업을 순서와 판단 기준으로 적은 운영 안내서입니다.

[선수지식]
DEVOPS-008~010의 로그·메트릭·트레이스, SLI·SLO, 알림과 온콜 개념을 알고 HTTP 상태 코드와 Python 실행 방법을 이해해야 합니다.

[학습목표]
1. 장애 대응의 역할과 우선순위를 설명한다.
2. 확인·완화·복구·종료 절차가 있는 런북을 작성한다.
3. 비난 없는 사후 분석에서 실행 가능한 개선 항목을 만든다.

[핵심개념]
장애 대응은 감지, 영향 확인, 장애 선언, 완화, 복구 확인, 종료 순으로 진행합니다. 심각도는 원인이 아니라 영향 범위와 지속 시간으로 정합니다. 규모가 커지면 지휘 담당은 우선순위와 역할을 조정하고, 작업 담당은 진단과 완화를 수행하며, 소통 담당은 확인된 사실과 다음 갱신 시각을 알립니다. 한 사람이 여러 역할을 맡더라도 역할 이름은 분명히 합니다.

복구 중에는 완벽한 원인 규명보다 안전하게 영향을 줄이는 조치가 우선일 수 있습니다. 최근 배포 중단, 이전 버전 복원, 트래픽 제한처럼 되돌릴 수 있는 조치를 선택하고 시작·결과·판단 근거를 시간순으로 남깁니다. 서비스가 회복되면 핵심 지표와 사용자 경로를 확인한 뒤 종료합니다.

사후 분석은 사람을 탓하는 문서가 아닙니다. 영향, 타임라인, 감지와 대응에서 잘된 점, 기여 요인, 배운 점을 증거로 정리합니다. 개선 항목에는 담당자, 완료 조건, 기한과 우선순위를 붙입니다. ‘주의한다’보다 ‘배포 뒤 오류율을 자동 확인하고 임계값을 넘으면 중단한다’처럼 검증 가능한 문장이 좋습니다.

[따라하기]
빈 폴더에 health_check.py를 만듭니다. 이 코드는 본인 컴퓨터의 로컬 웹서버만 확인합니다.
```python
import json, sys, time
from urllib.error import URLError
from urllib.request import urlopen

url = "http://127.0.0.1:8000/"
started = time.monotonic()
try:
    with urlopen(url, timeout=2) as response:
        status = response.status
        healthy = 200 <= status < 300
except URLError:
    status = "unreachable"
    healthy = False

print(json.dumps({
    "url": url,
    "status": status,
    "healthy": healthy,
    "elapsed_ms": round((time.monotonic() - started) * 1000),
}))
sys.exit(0 if healthy else 1)
```
첫 터미널에서 macOS·Linux는 `python3 -m http.server 8000`, Windows는 `py -m http.server 8000`을 실행합니다. 둘째 터미널에서 같은 실행기 이름으로 health_check.py를 실행하세요. `status: 200`과 `healthy: true`가 나오면 정상입니다. 첫 서버를 중지하고 다시 실행하면 `unreachable`과 `false`가 나오며 종료 코드는 1입니다. 이 두 결과를 런북의 정상·장애 판정 예시로 기록하세요.

[흔한 실수]
여러 사람이 조정 없이 같은 설정을 바꾸거나, 원인 가설을 확인된 사실처럼 알리지 마세요. 복구 확인 없이 알림이 사라진 것만 보고 종료해서도 안 됩니다. 사후 분석을 작성하고도 담당자와 기한 없는 개선 목록만 남기면 같은 문제가 반복됩니다.

[보안 주의]
장애 채널과 문서에 토큰, 쿠키, 개인정보, 내부 접속 주소를 붙이지 마세요. 보안 침해가 의심되면 증거가 될 로그와 시간을 보존하고 승인된 보안 담당 절차로 전환합니다. 임의로 로그를 지우거나 타인 시스템을 점검하지 말고, 실습은 본인 소유의 로컬·격리 환경에서만 진행합니다.

[직접 해볼 과제]
로컬 서버 장애용 런북을 작성하세요. 감지 조건, 심각도, 담당 역할, 위 명령, 예상 결과, 완화와 복구 확인, 중단 기준, 연락 경로를 넣습니다. 서버를 켰다 끄며 5분 모의훈련을 하고 타임라인 5줄과 개선 항목 2개를 작성합니다.

[확인문제]
1. 장애 심각도를 원인보다 사용자 영향으로 정하는 이유는 무엇인가요?
2. 복구 중 역할과 시간순 기록을 분리하는 목적은 무엇인가요?
3. 좋은 사후 분석 개선 항목에 필요한 네 가지 정보는 무엇인가요?

[다음 학습]
DEVOPS-012에서 코드 변경부터 빌드·테스트·배포·모니터링·롤백까지 이어지는 전체 배포 파이프라인을 설계합니다.

[공식 참고 자료]
https://csrc.nist.gov/pubs/sp/800/61/r3/final
https://doi.org/10.6028/NIST.SP.800-61r3
https://sre.google/workbook/incident-response/
https://sre.google/sre-book/postmortem-culture/
https://docs.python.org/3/library/urllib.request.html
https://docs.python.org/3/library/urllib.error.html
https://docs.python.org/3/library/http.server.html