“사이트가 안 열려요” 라는 연락을 받으면 가장 먼저 하고 싶어지는 일은 원인을 찾는 것입니다. 그런데 원인부터 찾는 것이 첫 5분에 저지르는 가장 비싼 실수입니다. 범위를 모르는 상태에서는 어떤 로그를 열어야 하는지조차 정할 수 없기 때문입니다.
순서를 미리 정해 두는 이유가 여기 있습니다. 장애는 판단력이 가장 떨어지는 순간에 찾아오고, 그때 필요한 것은 영리한 추론이 아니라 외워 둔 순서입니다.
1분 — 범위를 확정하는 세 질문
순서대로 답합니다. 세 질문의 답이 곧 원인 후보 목록입니다.
- 사이트 전체입니까, 페이지 하나입니까. 전체가 죽었다면 서버 · DB · 인증서 · DNS 쪽이고, 한 페이지만이라면 그 페이지가 쓰는 기능 · 쿼리 · 템플릿 쪽입니다.
- 모두에게입니까, 나에게만입니까. 다른 회선(휴대폰 데이터)이나 외부 점검 서비스로 한 번 더 확인합니다. 나만이라면 캐시 · 쿠키 · 차단된 IP 를 먼저 봅니다.
- 최근에 무엇이 바뀌었습니까. 장애의 압도적 다수는 방금 바뀐 것 때문에 납니다.
확인은 반드시 밖에서 합니다. 브라우저 새로고침은 캐시를 물고 오고, 관리자 로그인 상태에서는 캐시를 우회하므로 방문자와 다른 화면을 봅니다. 상태 코드 하나만 보면 충분합니다.
curl -s -o /dev/null -w "%{http_code} %{time_total}sn" https://example.com/200 이 돌아오는데 화면이 비어 있다면 서버는 살아 있고 애플리케이션이 답을 만들지 못한 것입니다. 502 · 504 라면 애플리케이션이 아예 대답하지 않았다는 뜻이고, 응답 자체가 없다면 DNS · 방화벽 · 네트워크 쪽입니다.
2분 — “무엇이 바뀌었나” 는 로그보다 배포 기록이 빠릅니다
로그를 뒤지기 전에 변경 목록을 봅니다. 이 순서가 뒤집히면 수백 줄을 읽고 나서야 “아, 어제 플러그인 업데이트했지” 를 떠올리게 됩니다.
볼 곳은 정해져 있습니다. 배포 이력(커밋 · 배포 로그), 워드프레스의 업데이트 기록, 서버 패키지 업데이트, DNS · 인증서 변경, 그리고 호스팅 업체의 공지입니다. 자동 업데이트를 켜 두었다면 내가 아무것도 안 했는데 바뀐 경우가 있으므로 여기를 반드시 봅니다.
5분이 지나면 — 알리고 기록을 시작합니다
원인을 못 찾았더라도 5분이 지나면 두 가지를 합니다. 첫째, 알립니다. 문의를 받는 사이트라면 안내가 없는 5분보다 “확인 중입니다” 한 줄이 훨씬 낫습니다. 둘째, 시각과 함께 기록합니다. 무엇을 몇 시에 확인했고 무엇을 바꿨는지 한 줄씩 적어 둡니다.
이 기록은 나중을 위한 것이 아닙니다. 지금 필요한 것입니다 — 30분쯤 지나면 자기가 무엇을 이미 시도했는지 헷갈리기 시작하고, 같은 조치를 두 번 하다가 상태를 더 망칩니다. 마지막 회차의 사후 기록도 이 메모에서 만들어집니다.
서버 계층의 구조를 더 알고 싶다면 서버 · 인프라 아카이브가 있고, 지금 상태를 밖에서 한 번 훑어 보고 싶다면 무료 도구의 사이트 진단으로 응답 · 헤더 · 인증서를 함께 확인할 수 있습니다.
다음 회차
증상 중 가장 당황스러운 것이 아무것도 없는 흰 화면입니다. 다음 회차는 그 화면에서 에러 메시지를 되찾는 방법입니다 — 화면이 아니라 로그로 되찾습니다.