아는 것이 없는 상태에서 시작하기

한 줄 요약

낯선 시스템 앞에서 첫 30분에 할 일은 문제를 고치는 것이 아니라, 무엇을 보지 않아도 되는지를 확정하는 것이다.

왜 이게 필요했나

자기 팀 서비스라면 장애 신고를 받는 순간 손이 먼저 움직입니다. 대시보드가 어디 있는지, 로그가 어느 디렉터리에 쌓이는지, 어제 누가 무엇을 배포했는지가 이미 머릿속에 있기 때문입니다. 고객사에서는 그 세 가지가 전부 없습니다. 모니터링이 무엇인지 모르고, 로그 위치를 모르고, 어제 무엇이 바뀌었는지 모르는 채로, 옆에서는 언제 고쳐지느냐고 묻습니다.

이 조건에서 경험 많은 사람과 그렇지 않은 사람을 가르는 것은 지식의 양이 아니라 순서입니다. 순서가 없으면 눈에 띄는 로그부터 열게 되고, 낯선 환경의 로그는 바다여서 두 시간 뒤에도 같은 자리에 있습니다.

그래서 첫 단계는 언제나 정찰입니다. 고칠 것을 찾는 게 아니라 지형을 그립니다.

어떻게 동작하나

정찰에서 확정할 것은 네 가지입니다.

첫째, 접속과 권한. 본능은 로그부터 열라고 하지만, 진단 도중에 권한이 없다는 것을 발견하면 그 요청과 승인에 걸리는 시간이 통째로 낭비됩니다. 더 나쁜 것은 권한 밖의 행동입니다. 고객 프로덕션에서 권한을 넘는 명령 하나는 장애보다 큰 신뢰 손실을 만듭니다. 지금 가진 것이 읽기인지 쓰기인지, 프로덕션인지 스테이징인지를 티켓 맨 위에 적고 시작합니다.

둘째, 시스템이 무엇 위에 서 있는가. 배포판, 커널, 실행 중인 프로세스, 열려 있는 포트. /etc/os-release 한 줄이 이후 모든 명령의 문법을 결정합니다. 로그 기본 경로만 해도 RHEL 계열은 /var/log/messages, 데비안 계열은 /var/log/syslog 로 다릅니다. 남의 문서를 그대로 옮겨 오면 가장 자주 깨지는 부분이 여기입니다.

셋째, 데이터가 어디에 얼마나 있는가. 어떤 파일이 가장 큰지, 로그가 몇 줄인지, 어떤 형식인지. 크기를 모르면 grep 하나가 몇 초에 끝날지 몇 분이 걸릴지 예측할 수 없고, 이미 부하가 걸린 시스템에서는 진단 명령 자체가 장애를 키웁니다.

넷째, 자원의 여유. 여기서 반드시 두 번 봐야 합니다. df -h 로 용량을, df -i 로 inode 를 따로 봅니다. 용량과 inode 는 완전히 다른 자원이기 때문입니다.

현장에서 만나는 모습

가장 자주 만나는 함정 하나를 미리 말해 둡니다. 애플리케이션이 "No space left on device" 로 죽었는데 df -h 는 여유가 30% 라고 합니다. 이때 범인은 셋 중 하나입니다. inode 가 고갈됐거나, 지워졌지만 아직 열려 있는 파일이 블록을 붙잡고 있거나, 그 경로가 실제로는 다른 파일시스템입니다.

리눅스에서 파일 이름은 실체가 아니라 실체를 가리키는 하나의 참조일 뿐이라서, 이름을 지워도 그 파일을 열어 둔 프로세스가 있으면 블록은 해제되지 않습니다. 그래서 로그 로테이션 후 프로세스가 파일을 다시 열지 않으면, 지운 로그가 계속 디스크를 먹습니다. df 와 du 의 값이 크게 다르다면 거의 항상 이 이야기입니다.

이 하나만 알아도 "디스크가 찼다" 는 신고에서 남들보다 20분을 아낍니다. 그리고 그 20분이 FDE 가 파는 것입니다.

다음 실습에서 할 것

고객사 서버라고 가정한 파드에 들어가, 배포판을 확인하고 데이터 인벤토리를 만들고 용량과 inode 를 함께 기록해 환경 지도 한 장을 남깁니다. 아무것도 고치지 않습니다. 그리는 것만 합니다.