초보 운영자를 위한 리눅스 서버 장애 대응 순서 총정리

초보 운영자를 위한 리눅스 서버 장애 대응 순서 총정리로 현상 확인, 최근 변경 사항 확인, 리소스 확인, 서비스 상태 확인, 로그 확인, 네트워크 확인, 조치 판단과 재확인 흐름을 설명하는 대표 이미지

리눅스 서버를 운영하다 보면 어느 날 갑자기 이런 말을 듣게 됩니다.

서버가 느립니다.
접속이 안 됩니다.
서비스가 안 뜹니다.
디스크가 가득 찼습니다.
로그가 계속 쌓입니다.
재기동하면 될까요?

 

처음에는 마음이 급해집니다.

서버 화면을 열고, top을 보고, df -h를 보고, 로그를 열어보다가 어느 순간 이런 생각이 듭니다.

뭘 먼저 봐야 하지?
이거 바로 재기동해도 되나?
파일 하나 지워도 괜찮은 건가?

 

초보 운영자에게 가장 어려운 부분은 명령어 자체보다 순서입니다.

명령어를 하나씩 아는 것도 중요하지만, 운영 서버에서는 어떤 순서로 확인하고 어느 시점에서 조치할지 판단하는 것이 더 중요합니다.

순서를 잘못 잡으면 장애를 해결하기보다 원인 단서를 먼저 지워버릴 수 있습니다.
로그를 지우거나, 프로세스를 종료하거나, 서버를 재기동한 뒤에는 처음 상태를 다시 확인하기 어려워지는 경우도 있습니다.

이 글은 리눅스 서버에서 문제가 생겼을 때 초보 운영자가 어떤 흐름으로 확인하면 좋은지 정리한 글입니다.
세부 명령어 하나하나를 깊게 설명하기보다는, 장애 상황에서 길을 잃지 않기 위한 전체 점검 순서에 가깝습니다.

서버 장애 대응의 기본 흐름

리눅스 서버 문제가 생겼을 때는 아래 순서로 보는 것이 좋습니다.

1. 현상 확인
2. 영향 범위 확인
3. 최근 변경 사항 확인
4. 서버 리소스 확인
5. 서비스 상태 확인
6. 로그 확인
7. 네트워크 확인
8. 원인 범위 좁히기
9. 조치 전 영향도 확인
10. 조치 후 재확인
11. 보고 정리

 

처음부터 완벽하게 할 필요는 없습니다.

다만 이 흐름 하나는 기억해두면 좋습니다.

확인 → 판단 → 조치 → 재확인

 

운영 서버에서 가장 위험한 흐름은 반대입니다.

조치 → 확인 → 당황 → 추가 조치

 

예를 들어 서버가 느리다고 바로 재기동하고, 디스크가 찼다고 바로 삭제하고, 프로세스가 높다고 바로 kill 하는 식입니다.

이렇게 하면 당장은 뭔가 한 것처럼 보이지만, 실제 원인을 놓칠 수 있습니다.

1. 먼저 “안 된다”를 구체적으로 나눕니다

장애 대응의 시작은 명령어가 아니라 현상 정리입니다.

“서버가 안 됩니다”라는 말은 너무 넓습니다.

아래처럼 나눠서 봐야 합니다.

서버 SSH 접속이 안 되는지
웹 서비스만 안 되는지
특정 URL만 안 되는지
전체 사용자가 느린지
일부 사용자만 느린지
내부망에서만 안 되는지
외부망에서도 안 되는지
특정 시간대에만 발생하는지

 

예를 들어 “접속이 안 된다”는 말도 여러 가지입니다.

ping 자체가 안 됨
포트가 닫혀 있음
포트는 열려 있는데 HTTP 응답이 이상함
도메인이 잘못된 IP를 바라봄
서비스 프로세스가 내려가 있음
중간 네트워크 구간에서 막힘

 

처음부터 원인을 단정하면 위험합니다.

ping 안 됨 = 방화벽 문제
CPU 낮음 = 서버 정상
디스크 90% = 파일 삭제
서비스 안 뜸 = 재기동

 

이런 식으로 바로 결론을 내리면 실제 원인을 놓치기 쉽습니다.

먼저 아래 정도만 정리해도 좋습니다.

현상:
웹 서비스 접속 시 응답 지연 발생

영향 범위:
일부 사용자에게서만 지연 문의 발생

발생 시점:
오전 10시 이후 문의 접수

우선 확인:
서버 리소스, 서비스 상태, 로그, 네트워크, 최근 변경 사항

 

이렇게 적어두면 이후 확인 과정이 훨씬 덜 흔들립니다.

2. 최근 변경 사항을 먼저 확인합니다

초보 운영자는 서버 상태부터 보는 경우가 많습니다.

물론 top, df -h, systemctl status 같은 명령어도 중요합니다.
하지만 그 전에 꼭 확인해야 할 것이 있습니다.

바로 최근 변경 사항입니다.

배포가 있었는지
설정 파일 변경이 있었는지
인증서 교체가 있었는지
방화벽 정책 변경이 있었는지
DNS 변경이 있었는지
LB나 Ingress 설정 변경이 있었는지
크론, 백업, 배치 시간이 겹치는지
패키지 업데이트가 있었는지

 

장애는 갑자기 생긴 것처럼 보이지만, 실제로는 변경 작업 이후에 드러나는 경우가 많습니다.

이럴 때는 아래 질문이 도움이 됩니다.

언제부터 발생했는가?
그 직전에 무엇이 바뀌었는가?
전체 서비스가 안 되는가, 일부만 안 되는가?
다른 서버도 같은 증상인가?
재기동, 배포, 설정 변경 이력이 있는가?

 

명령어 결과만 보면 서버 내부만 보게 됩니다.
하지만 운영 장애는 서버 밖에서 시작되는 경우도 많습니다.

DNS, 방화벽, 로드밸런서, 인증서, 배포 작업, 스토리지, 네트워크까지 같이 봐야 할 때가 있습니다.

3. 서버가 느릴 때는 CPU만 보지 않습니다

서버가 느리면 가장 먼저 CPU를 보게 됩니다.

 

top

 

CPU 사용률이 높다면 어떤 프로세스가 CPU를 많이 쓰는지 확인해야 합니다.

 

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head

 

하지만 CPU가 낮다고 해서 서버가 정상이라고 바로 판단하면 안 됩니다.

서버가 느린데 CPU 사용률은 낮은 경우도 있습니다.

이럴 때는 Load Average를 같이 봐야 합니다.

 

uptime

 

예를 들어 이런 상태라면 다시 봐야 합니다.

CPU 사용률은 낮음
Load Average는 높음
서버 응답은 느림

 

Load Average는 단순 CPU 사용률이 아니라, 실행 중이거나 대기 중인 작업의 흐름을 보는 데 도움이 됩니다.

CPU가 낮은데 서버가 느릴 때 Load Average를 어떻게 봐야 하는지는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/41

리눅스 서버 CPU 낮다고 정상이라 하지 말고 Load Average까지 확인하는 법

 

또 하나 봐야 할 값이 있습니다.

top에서 보이는 wa입니다.

%Cpu(s):  3.0 us,  2.0 sy, 70.0 id, 25.0 wa

 

wa는 I/O wait입니다.

쉽게 말하면 CPU가 디스크나 스토리지 응답을 기다리는 시간입니다.

CPU가 낮아 보여도 wa가 높다면 디스크 I/O 대기 때문에 서버가 느릴 수 있습니다.

top에서 wa 값을 확인하는 흐름은 아래 글과 이어집니다.

https://opsnote.tistory.com/42

리눅스 서버 CPU 낮다고 정상이라 하지 말고 top wa 값까지 확인하는 법

 

서버 느림 상황을 보고할 때 CPU, 메모리, 디스크 상태를 어떻게 정리하면 좋은지도 따로 정리했습니다.

https://opsnote.tistory.com/47

리눅스 서버 느림 보고할 때 CPU, 메모리, 디스크 상태 정리하는 방법

 

4. 메모리는 used만 보고 판단하지 않습니다

메모리 사용률이 높다고 바로 장애라고 보면 안 됩니다.

리눅스는 사용하지 않는 메모리를 캐시로 활용합니다.
그래서 used가 높아 보여도 실제로는 여유가 있을 수 있습니다.

기본 확인 명령어는 아래입니다.

 

free -m

 

여기서 초보 운영자가 꼭 봐야 할 값은 available입니다.

used
free
buff/cache
available

 

used만 보고 “메모리가 부족하다”고 판단하면 잘못 볼 수 있습니다.

메모리 상태는 아래처럼 보는 것이 좋습니다.

available이 충분한지
Swap이 계속 증가하는지
OOM 관련 로그가 있는지
특정 프로세스가 메모리를 과도하게 쓰는지
서비스 영향이 실제로 있는지

 

메모리 used와 available을 구분하는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/44

리눅스 서버 메모리 used만 보면 판단이 틀리는 이유와 available 확인법

 

Swap도 마찬가지입니다.

Swap 사용량이 올라갔다고 바로 재기동할 필요는 없습니다.

 

free -m
swapon --show

 

Swap이 언제부터 올라갔는지, 계속 증가하는지, 서비스 응답에 영향이 있는지를 같이 봐야 합니다.

https://opsnote.tistory.com/43

리눅스 서버 Swap 올라갔다고 바로 재기동하지 말고 확인하는 순서

 

5. 디스크가 찼을 때는 바로 삭제하지 않습니다

디스크 용량 알림은 초보 운영자를 가장 긴장하게 만드는 알림 중 하나입니다.

/ 사용률 90%
/var 사용률 95%
No space left on device
파일 생성 실패
로그 기록 실패

 

이때 바로 큰 파일을 찾아서 삭제하고 싶어질 수 있습니다.

하지만 운영 서버에서는 바로 삭제하면 안 됩니다.

먼저 어느 파일시스템이 찼는지 확인해야 합니다.

 

df -h

 

df -h에서는 Use%만 보면 안 됩니다.

아래 항목을 같이 봐야 합니다.

Filesystem
Size
Used
Avail
Use%
Mounted on

 

특히 Mounted on이 중요합니다.

/가 찼는지, /var가 찼는지, /tmp가 찼는지, /data가 찼는지에 따라 확인 순서가 달라집니다.

디스크 사용률 90%를 넘겼을 때 처음 확인하는 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/1

리눅스 서버 디스크 용량 90% 넘었을 때 바로 삭제하지 말고 확인하는 법

 

df -h 결과에서 Use%만 보면 안 되는 이유는 아래 글과 함께 보면 좋습니다.

https://opsnote.tistory.com/2

리눅스 서버 df -h 결과, Use%만 보면 안 되는 이유와 확인 순서

 

용량은 남아 있는데 파일 생성이 안 되는 경우도 있습니다.
이때는 inode 문제일 수 있습니다.

df -i

 

inode 문제는 초보 운영자가 놓치기 쉬운 부분입니다.

https://opsnote.tistory.com/66

리눅스 서버 용량은 남았는데 파일 생성이 안 될 때 df -i로 inode 확인하는 법

 

/tmp가 찼을 때도 바로 삭제하면 안 됩니다.
임시 파일처럼 보여도 현재 서비스나 배치 작업이 사용 중일 수 있습니다.

https://opsnote.tistory.com/67

리눅스 서버 /tmp 용량이 찼을 때 바로 삭제하지 말고 확인하는 법

 

/var가 찼을 때는 더 조심해야 합니다.
로그, 캐시, spool, 서비스 데이터가 섞여 있을 수 있습니다.

https://opsnote.tistory.com/68

리눅스 서버 /var 용량이 찼을 때 위험한 이유와 안전한 확인 순서

 

6. df와 du 결과가 다르면 deleted 파일을 의심합니다

디스크 문제를 확인하다 보면 이런 상황이 있습니다.

df -h에서는 사용량이 높음
du -sh로 보면 큰 파일이 안 보임
파일을 삭제했는데 용량이 줄지 않음

 

이럴 때는 삭제된 파일을 프로세스가 계속 잡고 있을 수 있습니다.

확인 명령어는 아래입니다.

lsof | grep deleted

 

환경에 따라 아래 명령어도 사용할 수 있습니다.

lsof +L1

 

이 상황에서 서버를 재기동하면 용량이 줄어들 수는 있습니다.

하지만 어떤 프로세스가 어떤 파일을 잡고 있었는지 확인하지 못하고 넘어가게 됩니다.

운영에서는 “재기동하면 해결된다”보다 “왜 용량이 안 줄었는지 확인했다”가 더 중요합니다.

df와 du 결과가 다르게 보일 때 확인하는 흐름은 아래 글과 이어집니다.

https://opsnote.tistory.com/65

리눅스 서버 df와 du 결과가 다르게 보일 때 deleted 파일부터 확인하는 법

 

7. 로그가 커질 때는 비우기 전에 원인을 봅니다

로그 파일이 계속 커지면 디스크 문제가 생길 수 있습니다.

 

du -sh /var/log/*

 

큰 로그 파일은 아래처럼 찾을 수 있습니다.

 

find /var/log -type f -size +100M -exec ls -lh {} \;

 

하지만 로그가 크다고 바로 비우면 안 됩니다.

로그는 단순한 파일이 아니라 장애 원인을 알려주는 흔적입니다.
비유하자면, 바닥에 찍힌 발자국을 지우기 전에 어디서 왔는지 먼저 봐야 합니다.

먼저 아래를 확인합니다.

어떤 서비스 로그인지
현재도 계속 쓰고 있는지
오류가 반복되고 있는지
logrotate 대상인지
장애 분석에 필요한 로그인지
보관 정책이 있는지

 

로그 파일이 계속 커질 때 확인하는 순서는 아래 글에 정리했습니다.

https://opsnote.tistory.com/7

리눅스 서버 로그 파일이 계속 커질 때 바로 비우지 말고 확인하는 법

 

8. 서비스가 안 뜰 때는 status부터 봅니다

서비스가 안 뜨거나 접속이 안 될 때 바로 restart부터 누르면 안 됩니다.

먼저 상태를 봐야 합니다.

 

systemctl status nginx --no-pager

 

서비스 이름은 환경마다 다릅니다.

 

systemctl status httpd --no-pager
systemctl status mariadb --no-pager
systemctl status docker --no-pager

 

systemctl status에서는 아래를 봅니다.

Active 상태
Main PID
최근 에러 메시지
실패 코드
마지막 실행 로그

 

서비스가 안 뜰 때 systemctl status를 먼저 봐야 하는 이유는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/27

리눅스 서버 서비스가 안 뜰 때 재기동부터 하지 말고 systemctl status 먼저 확인하는 법

 

실패한 서비스를 한 번에 확인하려면 아래 명령어도 사용할 수 있습니다.

systemctl --failed

 

https://opsnote.tistory.com/32

리눅스 서버에서 실패한 서비스 한 번에 확인하는 systemctl --failed 사용법

 

서비스를 재기동해야 한다면 start, stop, restart 차이를 알고 있어야 합니다.

https://opsnote.tistory.com/28

리눅스 서버 systemctl start stop restart 차이와 restart 바로 누르면 안 되는 이유

 

재기동 후에는 정상 기동 여부도 반드시 확인해야 합니다.

https://opsnote.tistory.com/29

리눅스 서버 systemctl restart 후 정상 기동 확인하는 법, 명령어만 치고 끝내지 마세요

 

서버 재기동 후 서비스가 자동으로 안 뜨는 문제는 enable 설정과 관련될 수 있습니다.

https://opsnote.tistory.com/30

리눅스 서버 재기동 후 서비스가 자동으로 안 뜰 때 systemctl enable disable 차이 확인하는 법

 

9. 로그 확인은 tail, less, journalctl을 나눠서 봅니다

서비스 상태를 봤다면 로그를 확인합니다.

최근 로그만 빠르게 볼 때는 tail을 사용합니다.

 

tail -n 100 /var/log/nginx/error.log

 

큰 로그 파일을 열 때는 less가 더 안전합니다.

 

less /var/log/nginx/error.log

 

실시간으로 로그를 따라갈 때는 tail -f를 사용할 수 있습니다.

 

tail -f /var/log/nginx/error.log

 

다만 처음부터 tail -f만 보고 있으면 전체 흐름을 놓칠 수 있습니다.

먼저 최근 에러를 보고, 필요한 경우 실시간으로 따라가는 것이 좋습니다.

tail과 less 사용 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/20

리눅스 서버 로그 확인할 때 cat부터 치지 말고 tail과 less로 안전하게 보는 법

 

실시간 로그 확인은 아래 글과 이어서 보면 좋습니다.

https://opsnote.tistory.com/21

리눅스 서버 장애 났을 때 tail -f로 실시간 로그 확인하는 법

 

systemd 서비스 로그는 journalctl로 확인합니다.

 

journalctl -u nginx -n 100 --no-pager

 

커널 메시지는 아래처럼 볼 수 있습니다.

 

journalctl -k -n 100 --no-pager

 

journalctl 확인 흐름은 아래 글에 정리했습니다.

https://opsnote.tistory.com/33

리눅스 서버 systemctl status만 보지 말고 journalctl로 서비스 로그 확인하는 법

 

10. 로그가 많을 때는 grep으로 좁혀봅니다

로그가 많을 때는 필요한 키워드부터 찾습니다.

 

grep -i "error" /var/log/nginx/error.log

 

타임아웃 관련 로그를 찾을 수도 있습니다.

 

grep -i "timeout" /var/log/nginx/error.log

 

에러 앞뒤 흐름을 같이 보려면 -C 옵션이 유용합니다.

 

grep -C 5 -i "error" /var/log/nginx/error.log

 

불필요한 로그를 제외하고 보고 싶을 때는 grep -v를 사용할 수 있습니다.

 

grep -v "healthcheck" /var/log/nginx/access.log

 

로그에서 에러를 찾는 기본 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/24

리눅스 서버 로그에서 에러 찾을 때 grep만 믿지 말고 앞뒤 흐름까지 확인하는 법

 

에러 앞뒤 로그를 같이 보는 방법은 아래 글과 이어집니다.

https://opsnote.tistory.com/25

리눅스 서버 로그에서 에러 한 줄만 보지 말고 grep -C로 앞뒤 흐름 확인하는 법

 

불필요한 로그를 제외하는 방법은 아래 글에 정리했습니다.

https://opsnote.tistory.com/26

리눅스 서버 로그에서 정상 로그가 너무 많을 때 grep -v로 제외하고 확인하는 법

 

11. 접속 장애는 ping 하나로 판단하지 않습니다

서버 접속이 안 될 때 ping부터 확인하는 경우가 많습니다.

 

ping 192.0.2.10

 

하지만 ping은 ICMP 응답을 보는 도구입니다.
웹 서비스나 애플리케이션 포트가 정상인지까지 알려주지는 않습니다.

예를 들어 ping은 되는데 웹 서비스가 안 될 수 있습니다.

이때는 포트를 확인해야 합니다.

 

nc -vz 192.0.2.10 443

 

HTTP 응답을 확인하려면 curl을 사용합니다.

 

curl -I https://example.com

 

ping은 되는데 서비스 접속이 안 될 때 확인하는 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/34

리눅스 서버 ping 된다고 정상이라 하지 말고 포트와 curl까지 확인하는 법

 

ping이 안 될 때도 바로 방화벽 문제로 단정하면 안 됩니다.

https://opsnote.tistory.com/35

리눅스 서버 ping 안 된다고 방화벽 문제라 하지 말고 포트와 curl까지 확인하는 법

 

포트가 열려 있는지 확인하는 nc 명령어는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/36

리눅스 서버 포트 열렸는지 nc로 확인할 때 ping만 보지 말고 TCP 접속까지 확인하는 법

 

curl과 nc는 역할이 다릅니다.
포트 확인과 HTTP 응답 확인을 구분해야 합니다.

https://opsnote.tistory.com/38

리눅스 서버 접속 확인할 때 curl과 nc 차이, 포트와 HTTP 응답을 구분하는 법

 

12. 네트워크 경로와 DNS도 확인합니다

서비스 접속 장애는 서버 내부 문제가 아닐 수도 있습니다.

중간 네트워크 구간에서 막히는지 확인하려면 traceroute 또는 tracepath를 사용할 수 있습니다.

 

traceroute example.com

 

환경에 따라 아래 명령어를 사용할 수도 있습니다.

 

tracepath example.com

 

traceroute 결과는 단독으로 판단하면 안 됩니다.
중간 장비가 ICMP 응답을 제한할 수 있기 때문입니다.

그래서 ping, nc, curl 결과와 함께 봐야 합니다.

https://opsnote.tistory.com/37

리눅스 서버 접속 안 될 때 traceroute로 어느 구간에서 막히는지 확인하는 법

 

도메인 문제도 자주 헷갈리는 부분입니다.

도메인이 어떤 IP를 바라보는지 확인하려면 nslookup을 사용할 수 있습니다.

 

nslookup example.com

 

DNS 응답을 더 자세히 보고 싶다면 dig를 사용합니다.

 

dig example.com
dig A example.com
dig CNAME example.com

 

DNS 문제는 서버 애플리케이션이 정상이어도 장애처럼 보일 수 있습니다.

아래처럼 나눠서 봐야 합니다.

도메인이 IP를 못 찾는지
잘못된 IP를 바라보는지
내부 DNS와 외부 DNS 응답이 다른지
TTL 때문에 변경 반영이 늦는지
LB나 Ingress 앞단 주소가 맞는지

 

nslookup 확인 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/39

리눅스 서버 도메인 안 된다고 서버부터 보지 말고 nslookup으로 DNS부터 확인하는 법

 

dig로 DNS 응답을 자세히 확인하는 방법은 아래 글과 이어집니다.

https://opsnote.tistory.com/40

리눅스 서버 nslookup만 보지 말고 dig로 DNS 응답까지 확인하는 법

 

13. 재기동은 마지막에 가까운 카드입니다

운영 서버에서 재기동은 쉬운 버튼처럼 보입니다.

하지만 실제로는 꽤 큰 조치입니다.

재기동 전에 최소한 아래는 확인해야 합니다.

현재 접속자 영향
서비스 이중화 여부
서비스 재기동인지 서버 전체 재기동인지
최근 로그 확보 여부
디스크, 메모리, CPU 상태
재기동 후 자동 기동 여부
담당자 또는 고객 공지 필요 여부
롤백 가능 여부

 

서비스만 재기동할지, 서버 전체를 재기동할지도 구분해야 합니다.

 

systemctl restart nginx

 

서버 전체 재기동은 더 신중해야 합니다.

 

reboot

 

서버 재기동 전 확인해야 할 체크리스트는 아래 글에 정리했습니다.

https://opsnote.tistory.com/19

리눅스 서버 재기동 전 바로 껐다 켜지 말고 확인해야 할 체크리스트

 

운영에서는 “재기동했습니다”보다 “재기동 전 원인 단서를 확인했고, 재기동 후 정상 확인했습니다”가 더 중요합니다.

14. 조치 전에는 영향도를 먼저 생각합니다

원인이 어느 정도 보이더라도 바로 조치하면 안 됩니다.

아래 작업들은 모두 운영 영향이 있을 수 있습니다.

서비스 재기동
서버 재기동
프로세스 kill
로그 삭제
권한 변경
설정 파일 수정
방화벽 정책 변경
DNS 변경
패키지 설치

 

조치 전에는 최소한 아래를 생각해야 합니다.

이 조치가 서비스에 영향을 주는가?
되돌릴 수 있는가?
작업 전 백업이 필요한가?
공지나 승인 절차가 필요한가?
장애 원인 로그를 먼저 확보했는가?

 

설정 파일을 수정해야 한다면 원본을 먼저 백업하는 습관이 필요합니다.

 

cp nginx.conf nginx.conf.bak_$(date +%Y%m%d_%H%M%S)

 

작은 습관 하나가 큰 사고를 막아줍니다.

15. 조치 후에는 반드시 재확인합니다

조치를 했다고 끝난 것이 아닙니다.

반드시 다시 확인해야 합니다.

 

systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager
curl -I https://example.com
df -h
free -m
uptime

 

확인할 내용은 아래와 같습니다.

서비스가 정상 기동됐는지
에러 로그가 계속 발생하는지
접속이 정상인지
디스크 사용률이 내려갔는지
CPU, 메모리, Load Average가 안정됐는지
사용자 영향이 해소됐는지

 

운영에서는 “조치했습니다”보다 “조치 후 정상 확인했습니다”가 더 중요합니다.

16. 보고는 짧고 정확하게 정리합니다

장애 상황에서는 보고도 중요합니다.

처음부터 길게 쓰려고 하면 오히려 헷갈립니다.

아래 흐름으로 정리하면 좋습니다.

현상:
확인 내용:
원인 추정:
조치 내용:
현재 상태:
추가 확인 필요:

 

예를 들어 서버가 느린 상황이라면 이렇게 쓸 수 있습니다.

현상:
웹 서비스 응답 지연 문의가 접수되었습니다.

확인 내용:
서버 접속은 가능하며, CPU 사용률은 높지 않으나 Load Average와 wa 값이 함께 높게 확인되었습니다.
디스크 I/O 대기 가능성이 있어 관련 프로세스와 로그를 확인했습니다.

원인 추정:
백업 작업 시간대와 증상 발생 시간이 일부 겹치는 것으로 확인됩니다.

조치 내용:
현재 백업 작업 종료 여부 및 서비스 로그를 추가 확인 중입니다.

현재 상태:
서비스는 응답 중이나 일부 요청에서 지연이 확인됩니다.

추가 확인 필요:
스토리지 응답 지연 여부와 백업 작업 영향도를 추가 확인하겠습니다.

 

이렇게 정리하면 “서버 느립니다”보다 훨씬 실무적으로 보입니다.

장애 상황별 빠른 확인 순서

마지막으로 상황별 확인 순서를 짧게 정리해보겠습니다.

서버가 느릴 때

uptime
top
free -m
df -h
ps -eo pid,stat,cmd | head
journalctl -xe --no-pager

 

확인할 것:

Load Average
CPU 사용률
wa 값
메모리 available
Swap
디스크 사용률
D 상태 프로세스
서비스 로그

 

디스크가 찼을 때

df -h
df -i
du -sh /*
du -sh /var/log/*
lsof | grep deleted

 

확인할 것:

어느 파일시스템이 찼는지
inode가 부족한지
큰 파일이 어디에 있는지
삭제된 파일을 프로세스가 잡고 있는지
로그가 비정상적으로 증가하는지

 

서비스가 안 뜰 때

systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager
systemctl --failed

 

확인할 것:

Active 상태
실패 코드
최근 에러 로그
설정 변경 여부
포트 충돌 여부
권한 문제 여부

 

접속이 안 될 때

ping 192.0.2.10
nc -vz 192.0.2.10 443
curl -I https://example.com
traceroute example.com
nslookup example.com
dig example.com

 

확인할 것:

서버 접근 가능 여부
포트 오픈 여부
HTTP 응답 여부
네트워크 경로
DNS 응답
도메인이 바라보는 IP

 

장애 상황별 실제 점검 사례

기본적인 장애 대응 순서를 익혔다면 실제 상황에서는 어떻게 적용하는지도 살펴볼 필요가 있습니다.

서버 장애는 비슷한 증상으로 시작하더라도 원인은 다를 수 있습니다. 그래서 상황별로 어떤 부분부터 확인하면 좋은지 따로 정리했습니다.

디스크 용량이 90%를 넘었을 때

사용률이 높은 파일시스템을 확인하고, 로그 증가나 삭제된 파일, inode 문제 등을 구분해 점검하는 과정입니다.

https://opsnote.tistory.com/72

리눅스 서버 디스크 용량 90% 알림을 받았을 때 실제 점검 흐름 정리

 

서비스가 갑자기 실행되지 않을 때

systemctl status와 journalctl로 서비스 상태와 오류 기록을 확인하고 원인을 좁혀가는 과정입니다.

https://opsnote.tistory.com/73

리눅스 서버 서비스가 안 뜰 때 systemctl status와 journalctl로 원인 좁히는 과정

 

ping은 되는데 사이트가 열리지 않을 때

ping 응답만으로 정상이라고 판단하지 않고 포트 연결과 HTTP 응답을 확인하는 방법입니다.

https://opsnote.tistory.com/74

ping은 되는데 사이트가 안 열릴 때 nc와 curl로 확인하는 실제 점검 흐름

 

서버가 느린데 CPU 사용률은 낮을 때

CPU 사용률 외에도 Load Average와 I/O wait를 함께 확인해야 하는 이유를 정리했습니다.

https://opsnote.tistory.com/75

리눅스 서버가 느린데 CPU는 낮을 때 Load Average와 wa로 확인하는 실제 점검 흐름

 

OOM으로 서비스가 종료됐는지 확인할 때

커널 OOM 로그와 종료된 프로세스, 서비스 중단 시각을 비교해 원인을 판단하는 과정입니다.

https://opsnote.tistory.com/76

리눅스 서버에서 OOM으로 서비스가 죽었는지 확인하는 실제 점검 흐름

 

장애 대응에서는 모든 명령어를 외우는 것보다 현재 상황에서 어떤 정보를 먼저 확인해야 하는지 판단하는 것이 중요합니다.

저도 운영 중 문제가 발생하면 확인 → 판단 → 조치 → 재확인 순서로 접근하려고 합니다.

무엇보다 서비스에 영향을 줄 수 있는 조치부터 실행하지 않고, 현재 상태와 로그를 먼저 확보하는 습관이 중요합니다.

정리하면

리눅스 서버 장애 대응에서 중요한 것은 명령어를 많이 외우는 것이 아닙니다.

문제가 생겼을 때 어떤 순서로 확인하고, 어디서 멈춰서 판단할지 아는 것이 더 중요합니다.

초보 운영자라면 아래 순서를 먼저 기억해도 충분합니다.

현상 확인
최근 변경 사항 확인
리소스 확인
서비스 상태 확인
로그 확인
네트워크 확인
조치 전 영향도 확인
조치 후 재확인
보고 정리

 

그리고 가장 중요한 문장은 이것입니다.

운영 서버에서는 바로 조치하지 말고, 확인 → 판단 → 조치 → 재확인 순서로 움직여야 합니다.

이 블로그에서는 리눅스 서버 운영 중 자주 만나는 상황을 하나씩 나눠서 정리하고 있습니다.

리눅스 서버 장애 대응은 한 번에 외우기보다, 상황별로 확인 순서를 나눠서 보는 것이 좋습니다.
전체 흐름은 이 글에서 잡고, 디스크 용량 문제와 접속 장애처럼 자주 만나는 상황은 아래 글에서 따로 확인하면 됩니다.

디스크 용량 문제가 생겼을 때 df -h, du, df -i, lsof deleted 확인 순서를 보고 싶다면 아래 글을 함께 보면 좋습니다.
https://opsnote.tistory.com/70

리눅스 서버 디스크 용량 문제 확인 순서 총정리

접속 장애 상황에서 ping, nc, curl, DNS 확인 순서를 보고 싶다면 아래 글을 참고하면 됩니다.
https://opsnote.tistory.com/71

리눅스 서버 접속 장애 확인 순서 총정리