시나리오새벽 3시 15분, 온콜 알람이 울립니다. Slack에는 "사이트 안 열려요"가 쌓이고 노트북을 열었는데 무엇부터 봐야 할지 막막합니다. 직감으로 "아마 앱 버그겠지"라며 kill -9부터 치면 증거는 사라지고 30분 뒤 같은 장애가 반복됩니다. 트리아지는 가장 낮은 계층(IP 연결)부터 올라가며 가설을 좁히는 것입니다 — 그 첫 5분이 사후 원인 분석 전체를 결정합니다.서버 장애 초동 대응 — 5분 트리아지이번 챕터에서 배울 것1장애 계층(L3 IP → L4 포트 → L7 앱) 순서에 따라 원인을 좁혀갈 수 있다2ping → ss → curl → journalctl → strace 5단계를 손에 익혀 실행할 수 있다3죽이기 전에 strace·코어덤프·로그로 증거를 수집하는 원칙을 적용할 수 있다..

시나리오신규 입사 3일차, 팀장이 슬랙으로 메시지를 보냅니다. "스테이징 서버에 배포 권한 줬는데 접속이 안 된다고 하던데?" 새로 합류한 백엔드 개발자가 비밀번호 인증을 시도하다 fail2ban에 차단됐고, 정작 배포용 키는 아직 서버에 등록도 안 된 상태입니다. SSH 키 배포부터 다중 서버 접속 설정, 보안 하드닝까지 — 팀에 새 인원이 들어올 때마다 반복되는 이 과정을 한 번에 정리해 둘 필요가 있습니다.SSH 고급 & 보안 하드닝이번 챕터에서 배울 것1공개키/개인키 비대칭키 암호화 원리와 SSH 인증 흐름을 설명할 수 있다2ssh-keygen으로 ed25519 키 쌍을 생성하고 알고리즘을 선택할 수 있다3ssh-copy-id로 공개키를 배포하고 authorized_keys 권한 문제를 진단할 수..

시나리오개발자가 슬랙에 메시지를 보냅니다. "DB 접속이 안 돼요." 서버에서 telnet db-host 5432를 쳐보면 Connection refused. 애플리케이션 로그에는 "connection refused"만 찍혀 있습니다. DB 서버가 죽었는지, 포트가 다른지, 방화벽인지 — 소켓 상태를 읽을 줄 알면 1분 안에 좁힐 수 있습니다.ss -tulnp | grep 5432 — 이 한 줄이 시작입니다.포트 & 네트워크 진단이번 챕터에서 배울 것1TCP 3-Way Handshake와 소켓 상태(LISTEN/ESTABLISHED/TIME_WAIT)를 설명할 수 있다2ss와 netstat으로 LISTEN 포트와 활성 연결을 확인할 수 있다3nc/telnet으로 원격 포트 연결 가능 여부를 테스트할 수 ..

시나리오서버에 배포 직후 ping 93.184.216.34는 응답이 옵니다. 그런데 curl https://api.example.com을 실행하면 Could not resolve host: api.example.com이 뜨고 바로 실패합니다. 네트워크 자체는 정상인데 이름 해석이 안 되는 것입니다. /etc/resolv.conf를 열어보면 심볼릭 링크입니다.DNS 해석이 실제로 어느 경로를 거치는지 알고 있으면, 어느 단계에서 끊겼는지 5분 안에 특정할 수 있습니다.DNS & 이름 해석 트러블슈팅이번 챕터에서 배울 것1Linux DNS 해석 경로(/etc/hosts → nsswitch.conf → systemd-resolved → upstream)를 설명할 수 있다2Ubuntu와 RHEL의 DNS 설정 ..

시나리오배포한 서버에 갑자기 접속이 안 됩니다. 로그를 봐도 애플리케이션은 정상입니다. "어디서부터 확인해야 하나." IP가 잘못 설정된 건지, 포트가 닫힌 건지, DNS 문제인지 — 체계 없이 방화벽만 한참 뒤지다 결국 DNS 설정 오류였다는 결론에 도달하기도 합니다.OSI 계층 순서대로 ping → ss → dig → curl을 돌리면 대부분의 네트워크 장애를 스스로 추적할 수 있습니다.네트워킹 기초 (Networking Basics)이번 챕터에서 배울 것1OSI 7계층 모델과 Linux 명령어를 매핑하고 계층별로 장애를 좁힐 수 있다2ip 명령어로 인터페이스·IP 주소·라우팅 테이블을 조회하고 설정할 수 있다3ss/netstat으로 LISTEN 중인 포트와 소켓 상태를 확인할 수 있다4tcpdump..

시나리오새벽 2시, 모니터링 알림이 울립니다. "디스크 사용량 95% 초과." SSH로 접속해 df -h를 확인하니 용량이 꽉 찼습니다. rm으로 30GB짜리 로그 파일을 삭제했는데 df -h가 여전히 100%. du -sh /*로 뒤져봐도 범인을 찾기 어렵습니다. Nginx 프로세스가 삭제된 파일의 핸들을 잡고 있어서 블록이 해제되지 않은 것이었습니다.lsof | grep deleted — 이 한 줄로 '고스트 파일'을 찾을 수 있습니다.디스크 트러블슈팅 심화이번 챕터에서 배울 것1df와 du 조합으로 디스크 사용량을 계층적으로 분석할 수 있다2inode 고갈 원인을 df -i로 진단하고 소형 파일 폭증을 해결할 수 있다3lsof | grep deleted로 고스트 파일을 탐지하고 블록 공간을 회수할 ..

시나리오새벽 3시, PagerDuty 알림이 울립니다. /var/lib/mysql 파티션 사용률이 93%입니다. df -h로 확인하니 20GB 파티션이 꽉 찼습니다. 전통 파티션 방식이라면 MySQL을 멈추고, 데이터를 임시 디스크에 옮기고, 파티션을 지웠다 새로 만들고, 다시 복원해야 합니다. 예상 다운타임 2~3시간, 새벽에 서비스 중단 공지를 써야 하는 상황.같은 서버가 LVM으로 구성되어 있었다면 lvextend -L +20G -r /dev/vg_data/lv_mysql 한 줄, 3분 안에 끝납니다.LVM & 볼륨 관리이번 챕터에서 배울 것1전통 파티션의 한계와 LVM이 온라인 볼륨 확장으로 해결하는 문제를 설명할 수 있다2PV·VG·LV 3계층 구조를 이해하고 각 계층의 명령어를 구분할 수 있다..

시나리오새벽 2시, 슬랙 알림이 울립니다. "No space left on device — 서비스 쓰기 실패." df -h를 치니 루트 파티션이 100%입니다. du -sh /*로 큰 디렉토리를 찾아가다가 /var/log에 30GB짜리 로그가 쌓여 있습니다. 지웠는데 df -h가 여전히 100%. 알고 보니 삭제한 파일을 nginx 프로세스가 계속 열고 있어서 공간이 실제로 반환되지 않은 것이었습니다. lsof | grep deleted를 치고서야 원인을 찾았습니다.df → du → lsof, 이 세 명령의 순서가 디스크 장애 진단의 기본입니다.디스크와 스토리지 관리이번 챕터에서 배울 것1물리 디스크 → 파티션 → 파일시스템 → 마운트 포인트의 계층 구조를 설명할 수 있다2df, du, lsblk, ls..

시나리오새벽 3시, 로그 디렉토리가 꽉 찼다는 알림이 옵니다. 접속해보니 30일 넘은 로그 파일이 수백 개 쌓여 있습니다. 그날 밤은 손으로 지웠지만, 다음 달에 또 같은 일이 생겼습니다. 명령어 서너 줄을 파일에 저장해 cron에 등록하는 것만으로 이 상황은 영구히 해결됩니다. Bash 스크립트는 반복 작업을 없애는 가장 직접적인 도구입니다.Bash 스크립팅 기초이번 챕터에서 배울 것1Shebang(#!/bin/bash)과 chmod +x로 실행 가능한 스크립트를 만들 수 있다2변수·특수변수($?, $#, $@)와 조건문(if/elif/else, [[ ]])을 작성할 수 있다3for, while, until 반복문으로 서버 관리 작업을 자동화할 수 있다4파이프(|)와 리다이렉션(>, 2>&1)으로 출력..

시나리오새벽 2시, 모니터링 대시보드에 빨간 알림이 켜집니다. "nginx 500 에러율 급등 — 결제 API 영향 가능." Slack에는 "지금 얼마나 심각해요?"라는 메시지가 쌓이고 있습니다. /var/log/nginx/access.log를 열었더니 수백만 줄. 눈으로 읽는 건 불가능합니다.grep, awk, sed를 파이프로 엮는 법을 알면 30초 안에 "203.0.113.42에서 분당 500 에러 47건, /api/payment 집중"이라는 답이 나옵니다.텍스트 처리 (grep/awk/sed)프로덕션 서버에서 장애가 발생했습니다. /var/log/nginx/access.log에는 수백만 줄의 로그가 쌓여 있고, 상사는 "지금 HTTP 500 에러가 얼마나 나고 있어?" 라고 묻습니다. 이때 필요한..