Computer System 실전 플레이북
3줄 요약
- 실전 플레이북은 CPU 급등, OOM, thread 고갈, file descriptor/socket 고갈 같은 장애를 빠르게 분류하는 절차다.
- 장애 대응은 증거 확보, 즉시 완화, 근본 원인 분석, 재발 방지 문서화로 나누어야 한다.
- 보고서는 OS/JVM/Application 지표를 시간축으로 연결하고 판단 근거와 남은 위험을 명확히 남겨야 한다.
핵심 정리
- CPU 급등은 top -H, thread dump, JFR, GC log로 계산, GC, busy loop, 암호화/직렬화 문제를 나눈다.
- Memory leak과 OOM은 heap, native memory, container limit, dump, GC after 사용량을 함께 본다.
- Thread 고갈과 응답 지연은 thread dump, executor queue, Tomcat busy thread, 하위 I/O 대기로 나눈다.
- File descriptor/socket 고갈은 lsof, ss, ulimit, accept queue, TIME_WAIT, connection leak를 함께 본다.
- 장애 보고서는 타임라인, 영향, 지표, 원인, 완화, 재발 방지, 미확인 리스크를 포함한다.
헷갈리는 지점
- 장애 중에는 바로 재시작하는 것이 최선이라고 보기 쉽다.
- 재시작은 완화가 될 수 있지만 원인 증거를 잃을 수 있다.
- 가능하면 짧은 dump와 주요 지표를 먼저 확보한다.
- 한 가지 지표가 원인을 증명한다고 생각하기 쉽다.
- CPU, memory, thread, I/O 지표는 서로 원인과 결과가 될 수 있다.
- 같은 시간축의 여러 증거가 필요하다.
- 보고서는 나중에 써도 된다고 생각하기 쉽다.
- 장애 중 판단 근거는 시간이 지나면 사라진다.
- 명령, 시각, 결과를 대응 중에 짧게 남겨야 한다.
확인 질문
- 장애 플레이북의 첫 단계는 무엇인가?
- 영향 범위와 시간대를 고정하고 최소 증거를 확보하는 것이다.
- Thread 고갈을 의심할 때 필요한 증거는 무엇인가?
- Thread dump, busy thread, executor queue, 하위 I/O latency, timeout 로그다.
- 장애 보고서에 반드시 남길 것은 무엇인가?
- 타임라인, 사용자 영향, 원인, 완화 조치, 재발 방지, 남은 리스크다.