何も分からない状態から始める

한 줄 요약

낯선 시스템 앞에서 첫 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 가 파는 것입니다.

정찰에서 무엇을 남기는가

정찰의 결과물은 머릿속이 아니라 문서여야 한다. 이유가 둘 있다. 첫째, 같은 시스템을 다음에 볼 때(또는 다른 사람이 볼 때) 30분을 다시 쓰지 않아도 된다. 둘째, 고객에게 "우리가 무엇을 파악했는지" 를 보이는 것 자체가 신뢰를 만든다. 첫날 아무것도 못 고쳤어도 지도 한 장이 나오면 그 시간은 낭비가 아니다.

환경 지도에 들어갈 것은 대체로 정해져 있다.

• 접속 경로와 권한 — 어떤 계정으로 어디에 들어가는지, 읽기인지 쓰기인지, 그리고 그 서버가 운영인지 아닌지.
• 무엇이 돌고 있는가 — 프로세스, 열린 포트, 그리고 그것들이 서로 어떻게 부르는지. 포트 목록만 있어도 의존 관계의 절반이 드러난다.
• 데이터가 어디에 있는가 — 로그, 데이터 디렉터리, 설정 파일. 각각의 크기와 형식.
• 자원 여유 — 용량과 inode 를 함께.
• 모르는 것 — 이 항목이 가장 중요하다. 확인하지 못한 것을 그대로 적어 두어야, 나중에 그 부분에서 가정을 세웠다는 사실을 잊지 않는다.

추측과 확인한 사실을 섞어 적지 않는 것이 이 문서의 유일한 규칙이다. "아마 nginx 가 앞단일 것" 과 "80 포트를 nginx 가 듣고 있다" 는 다른 문장이고, 며칠 뒤에는 둘을 구별할 수 없게 된다. 확인한 것에는 그것을 확인한 명령을 함께 적어 두면, 나중에 상태가 바뀌었는지 같은 명령으로 다시 볼 수 있다.

마지막으로 정찰에는 시간 상한을 둔다. 30분이든 한 시간이든 정해 놓고, 그 안에 다 못 그렸으면 못 그린 채로 다음 단계로 넘어간다. 완벽한 지도를 그리려다 정작 문제를 못 보는 것이, 지도 없이 뛰어드는 것 다음으로 흔한 실패입니다.

다음 실습에서 할 것

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