운영에서 가장 아픈 순간은 장애 자체가 아닙니다. 고객이 먼저 알려 줄 때입니다. “사이트가 안 열리는데요” 라는 연락을 받는 순간, 이미 그 앞의 몇 시간 동안 다른 방문자들도 같은 화면을 봤다는 뜻이기 때문입니다.
이 문제는 기술적으로 어렵지 않습니다. 밖에서 주기적으로 사이트를 열어 보고, 안 열리면 알려 주는 장치를 두면 됩니다. 중요한 것은 무엇을 열어 보게 할지와 알림을 어디로 받을지입니다.
감시는 반드시 밖에서 합니다
서버 안에 설치하는 감시 도구는 서버가 살아 있을 때만 동작합니다. 정작 서버가 멈추면 알림을 보낼 주체도 함께 멈춥니다. 그래서 감시는 사이트 밖에 있어야 합니다 — 외부 서비스가 우리 사이트를 방문자처럼 열어 보는 방식입니다.
같은 이유로 알림도 사이트와 무관한 경로로 받아야 합니다. 사이트에서 보내는 메일로 알림을 받도록 해 두면, 메일 발송이 사이트와 같은 서버에 묶여 있을 때 장애와 함께 알림도 사라집니다.
무엇을 감시할 것인가
홈 화면 하나만 보는 것으로는 부족합니다. 홈이 캐시된 상태로 남아 있으면 워드프레스가 죽었는데도 홈은 정상으로 보입니다. 감시 대상을 성격별로 나눠 두면 이런 착시가 사라집니다.
동적 화면은 검색 결과 페이지나 로그인 화면처럼 캐시에 가려지지 않는 주소를 하나 고르면 됩니다. 이 화면이 열린다는 것은 워드프레스와 데이터베이스가 함께 살아 있다는 뜻입니다.
인증서와 도메인 만료는 장애 중에서 가장 억울한 종류입니다. 기술적 결함이 아니라 갱신을 잊은 것이고, 하루 전에만 알았어도 아무 일도 아니었을 사고입니다. 달력에 넣어 두는 것만으로도 대비가 됩니다.
알림이 신뢰를 잃지 않게
감시를 붙이고 나면 새로운 문제가 생깁니다 — 거짓 알림입니다. 순간적인 네트워크 흔들림으로 한 번 실패했을 뿐인데 알림이 오면, 몇 번 반복된 뒤에는 알림을 무시하게 됩니다. 그러면 감시가 없는 것과 같아집니다.
복구 알림을 빠뜨리지 마세요. 장애 알림만 오고 복구 알림이 없으면, 이미 복구된 상황에서도 계속 확인하러 들어가게 됩니다.
알고 난 다음에 할 일도 정해 둡니다
알림을 받았을 때 무엇을 볼지 순서를 적어 두세요. 다른 사이트도 안 열리는지(내 인터넷 문제인지), 호스팅 업체의 공지가 있는지, 최근에 무엇을 바꿨는지. 이 세 줄만 있어도 급한 순간의 판단이 빨라집니다.
서버 운영과 장애 대응에 관한 글은 서버 · 인프라 아카이브에 모여 있고, 감시와 대응을 맡겨 두고 싶다면 InfraGuard 지속 관제가 그 역할을 합니다.
다음 회차
다음 회차는 조용히 자라는 쪽입니다. 장애처럼 눈에 띄지 않지만 시간이 지날수록 무거워지는 것 — 데이터베이스가 커지면 무슨 일이 생기는지 다룹니다.