장애를 고객에게서 먼저 듣는 순간은 운영자가 가장 피하고 싶은 상황입니다. “사이트가 안 열려요” 라는 연락을 받고 나서야 확인을 시작하면, 이미 얼마나 오래 그 상태였는지조차 알 수 없습니다. 가동 감시는 그 순서를 뒤집기 위한 장치입니다.
그런데 감시를 붙여 두고도 놓치는 일이 생깁니다. 원인은 대체로 하나입니다 — 확인하는 페이지를 잘못 골랐기 때문입니다.
홈은 가장 늦게 무너지는 페이지입니다
워드프레스 사이트에서 홈은 대체로 캐시가 가장 잘 걸린 화면입니다. 앞에 페이지 캐시나 CDN 이 있으면 홈 요청은 PHP 도 데이터베이스도 거치지 않고 저장된 HTML 을 그대로 돌려줍니다. 빠르고 안정적인 것은 좋은 일입니다. 다만 감시 대상으로는 최악의 선택입니다.
데이터베이스가 응답하지 않아도 캐시가 살아 있는 동안 홈은 계속 정상 응답을 냅니다. 로그인이 막혀도, 문의 폼이 오류를 뱉어도, 결제 단계가 멈춰도 홈은 멀쩡합니다. 감시 대시보드는 계속 초록색이고, 그동안 실제로 매출이 되는 경로만 조용히 멈춰 있습니다.
데이터베이스를 실제로 거치는 주소를 고릅니다
감시 대상은 요청할 때마다 새로 만들어지는 페이지여야 합니다. 글 목록, 검색 결과, 로그인 화면, 문의 폼 페이지처럼 캐시를 우회하거나 매번 쿼리를 도는 주소가 좋은 후보입니다. 사이트에 주문이나 예약이 있다면 그 흐름의 첫 화면이 가장 정확한 지표가 됩니다.
확인은 상태 코드만으로 끝내지 않습니다. 200 을 돌려주면서도 화면에는 오류 문구만 그려져 있는 경우가 실제로 있습니다. 그래서 응답 본문에 반드시 있어야 하는 문자열을 하나 정해 두고 그것까지 확인하게 합니다 — 회사명, 푸터의 고정 문구, 폼의 버튼 라벨 같은 것이면 충분합니다.
한 걸음 더 나아가면 감시 전용 주소를 하나 만드는 방법도 있습니다. 가벼운 쿼리를 한 번 돌리고 정해진 한 단어만 돌려주는 경로인데, 캐시에서 제외해 두면 매번 데이터베이스까지 살아 있는지를 가장 싸게 확인할 수 있습니다.
간격 · 위치 · 재확인
세 가지만 정하면 됩니다. 간격은 1분에서 5분 사이면 충분합니다. 더 짧게 잡는다고 복구가 빨라지지는 않고, 남의 서버에 보내는 요청 수만 늘어납니다.
위치는 가능하면 두 곳 이상에서 봅니다. 한 곳에서만 재면 그 감시 서버와 우리 서버 사이의 일시적인 네트워크 문제를 장애로 오인하게 됩니다.
재확인은 알림의 품질을 결정합니다. 한 번 실패했다고 곧바로 알리면 순간적인 끊김에도 전화가 울립니다. 짧은 간격을 두고 두세 번 연속 실패했을 때만 알리도록 하면, 울렸다는 사실 자체가 정보가 됩니다.
서버 구성과 캐시 계층이 응답에 어떻게 관여하는지는 서버 · 인프라 아카이브에 더 정리돼 있습니다. 당직을 설 사람이 없어 새벽에 울린 알림을 아무도 받지 못하는 구조라면, 감시와 대응을 함께 맡기는 InfraGuard 지속 관제가 그 자리를 대신합니다.
다음 회차
가동 여부를 보게 됐다면 다음은 항목을 늘릴 차례입니다. 다음 회차에서는 무엇을 감시해야 하는지를 쓸모 있는 순서대로 다섯 개만 고릅니다 — 그중 하나는 대부분의 운영자가 감시 항목으로 생각하지 않는 것입니다.