COURSE MAP
흩어져 있던 것들을 하나의 흐름으로
로그 읽는 법은 터미널·서버 코스에, 락과 슬로우 쿼리는 DB 코스에, 나쁜 소식을 전하는 법은 협업·성장 코스에 있습니다. 이 코스는 그 도구들을 실제 장애 상황의 순서대로 꿰어 놓은 것입니다. 무엇부터 확인하고, 무엇을 남기고 복구하고, 무엇을 보고할지에 대한 판단을 다룹니다.
영향 파악, 증거 확보와 복구, 증상 분류, 진행 중 보고를 다룹니다.
로그, 스레드 덤프, 메모리, 자원 고갈을 Java 환경에서 진단합니다.
원인 규명 보고서, 조기 발견 체계, 반복 장애를 다룹니다.
전체 11개 파트가 모두 공개돼 있습니다.
트랙 A · 장애가 났을 때
장애가 났을 때
연락을 받은 순간부터 첫 보고까지, 원인을 찾기 전에 해야 할 판단과 절차를 다룹니다.
첫 15분에 할 일
원인을 찾기 전에 영향 범위부터 파악하고, 변경 이력을 확인하고, 첫 보고를 올리는 순서를 다룹니다.
복구가 먼저인가 원인이 먼저인가
재기동이 증거를 지운다는 점을 전제로, 30초 안에 증거를 확보하고 복구하는 방법과 롤백 판단을 다룹니다.
증상에서 원인 후보로 좁히기
느림·멈춤·오류·간헐 네 가지 증상 유형별로 의심 경로를 나누고, 계층을 갈라 범위를 줄이는 방법을 다룹니다.
진행 중 보고
원인을 모르는 상태에서 무엇을 어떻게 보고할지, 고객사 대응과 원인 미규명 종료 보고까지 다룹니다.
트랙 B · 원인을 찾는 기술
원인을 찾는 기술
로그, 스레드 덤프, 메모리, 자원 고갈을 Java 환경 기준으로 진단합니다.
여러 로그를 시간축으로 합치기
흩어진 로그의 시각을 맞추고, 첫 오류와 연쇄 오류를 가르고, 상관관계 착각을 피하는 방법을 다룹니다.
멈췄을 때: 스레드 덤프
스레드 덤프를 뜨고 상태별로 분류해 읽는 법, 3장을 비교하는 이유, 전형적인 네 가지 패턴을 다룹니다.
메모리 문제
OOM 종류별로 원인이 다르다는 점, 늘어나는 것과 새는 것의 구분, GC 로그와 힙 덤프 활용을 다룹니다.
자원 고갈
커넥션 풀, 스레드 풀, 파일 디스크립터처럼 애플리케이션이 스스로 정한 한계가 마를 때의 증상과 확인 방법을 다룹니다.
트랙 C · 장애 이후
장애 이후
원인 규명 보고서, 조기 발견 체계, 반복되는 장애를 다룹니다.
이 코스를 쓰는 방법
- 지금 장애 대응 중이라면 Part 1의 확인 순서부터 봅니다.
- Part 2의 증거 확보 스크립트는 평소에 서버에 배치해 둬야 의미가 있습니다.
- 고객사 시스템을 담당해 서버에 직접 못 붙는 상황을 전제로 썼습니다.
- 진단 도구의 사용법 자체는 터미널·서버 코스와 DB 코스에서 함께 봅니다.
REFERENCES
참고 자료
대응 절차는 조직마다 다릅니다. 아래 자료는 널리 쓰이는 공개 기준으로, 팀 규칙을 정할 때 출발점으로 참고합니다.
| 자료 | 내용 | 바로가기 |
|---|---|---|
| Google SRE Book · Postmortem Culture | 사람을 탓하지 않는 원인 규명 문화에 대한 공개 자료 | 바로가기 |
| OpenJDK 진단 도구 문서 | jcmd, 스레드 덤프, 힙 덤프 등 JDK 진단 도구 공식 안내 | 바로가기 |