모니터링·백업·장애 런북 — “만든 뒤 방치” 방지

서비스 오픈 직후에는 모두가 화면을 봅니다. 몇 달이 지나면 관심은 신규 기능·마케팅으로 이동하고, 인프라는 “아직 안 죽었다”는 사실만으로 안심 상태가 됩니다. 그 사이 실제로 일어나는 일은 다음과 같습니다.

디스크가 차올라 업로드·기록이 멈춥니다. 보안 인증서가 만료되어 브라우저 경고가 뜹니다. 결제·문자·로그인 외부 키가 만료되거나 한도를 넘깁니다. 백업 파일은 있긴 한데 한 번도 복원해 본 적이 없습니다. 장애가 나도 누가 1차로 받는지, 어디까지 스스로 조치하는지 모릅니다.

모니터링·백업·장애 때 볼 짧은 절차서(런북)는 대기업 전유물이 아닙니다. 규모에 맞게 최소 세트를 두지 않으면, “만든 뒤 방치”가 곧 영업·신뢰 리스크가 됩니다.

왜 세 가지를 한 세트로 보나요?

도구를 많이 사는 것보다, 인지 → 판단 → 조치 → 기록 루프가 조직에 존재하는지가 핵심입니다.

모니터링: “살아 있음”과 “정상 업무”를 나눕니다

주소가 응답해도 결제가 실패 중일 수 있습니다. 최소 관측 포인트를 나눕니다.

1. 인프라: 처리량, 메모리, 디스크, 인증서 만료일, 프로세스 생존
2. 애플리케이션: 서버 오류 비율, 응답 시간, 대기 작업 적체, 백그라운드 실패
3. 비즈니스 경로: 로그인 → 핵심 목록 → (해당 시) 장바구니·예약 진입처럼 사용자 여정의 일부를 주기적으로 확인
4. 외부 의존성: 결제, 문자, 본인인증, 지도, 파일 저장 오류율·지연

알림 원칙도 같이 정합니다.

• 야간·주말에 깨울 알림과 업무시간 티켓을 등급으로 분리한다
• 같은 장애로 알림이 폭주하지 않게 중복을 줄인다
• 알림 채널이 개인 휴대폰 하나에만 의존하지 않게 한다 (조직 채널 + 대체 담당)

백업: 파일이 있는 것과 복구 가능한 것은 다릅니다

백업 정책을 문장으로 고정합니다.

• 복구 시점 목표: 최대 얼마치 데이터 손실을 감내하는가 (예: 24시간, 1시간)
• 복구 시간 목표: 장애 인지 후 서비스 재개까지 목표 시간
• 범위: 데이터베이스만인지, 업로드 파일·설정·접속 정보까지인지
• 보관: 일·주·월 세대, 암호화, 접근 권한
• 위치: 운영 서버와 같은 디스크만 백업이면 디스크 장애에 함께 소실됩니다

필수 습관입니다.

• 정기 복원 연습 (분기 1회라도): 시험 환경에 올려 애플리케이션이 기동되는지 확인
• 백업 실패 자체를 모니터링 (조용히 실패하는 경우가 흔함)
• 삭제·랜섬·실수에 대비한 분리 보관 검토

장애 런북: 새벽에도 따라 할 수 있는 짧은 절차

런북은 두꺼운 매뉴얼이 아닙니다. 서비스별로 1~3페이지면 충분할 수 있습니다.

권장 구성입니다.

1. 증상 (사용자 관점 한 줄)
2. 심각도 정의 (전체 불능 / 결제만 / 관리자만 등)
3. 1차 확인 화면·링크 (계정 없이 못 보면 무용)
4. 완화 조치 (되돌리기, 점검 페이지, 일부 기능 끄기)
5. 근본 조치 후보와 하지 말 것 (운영 데이터를 급히 손으로 지우기 등)
6. 외부 벤더 연락처·티켓 경로
7. 사후 기록 틀 (타임라인, 영향 범위, 재발 방지)

런북이 저장소에만 있고, 장애 시 권한이 없는 사람만 대기 중이면 실패합니다. 당직·대체 담당이 실제로 접근 가능한지를 점검 항목에 넣습니다.

중소 규모 서비스의 최소 운영 세트 예시

완벽주의 대신 단계적으로 올려도 됩니다.

제작 계약에 “오픈 후 1개월 안정화 + 최소 세트 구축”을 넣으면 방치를 줄일 수 있습니다.

급할수록 권한을 함부로 넓히지 마세요

장애 대응 중 가장 위험한 순간은 “급하니까 임시로” 권한·키를 넓히는 때입니다.

• 개인 계정에 운영 키를 두지 않는다
• 퇴사자 접근은 즉시 회수한다
• 런북에 필요한 최소 권한만 당직 역할에 부여한다
• 관리자 화면 권한과 모니터링 접근을 함께 검토한다

자주 하는 선택이 만드는 결과

• 고객 신고로만 장애를 알면, 이미 결제가 실패한 뒤 환불·클레임 비용이 납니다
• 백업을 검증하지 않으면, 복구 시도 중 손상·버전 불일치를 발견해 골든타임을 씁니다
• 런북이 없으면 숙련자 개인 기억에 의존하고, 휴가·퇴사 시 같은 장애가 길어집니다
• 알림이 과하면 진짜 장애를 무시하게 됩니다
• 운영 서버에만 백업하면 랜섬·디스크 장애 시 백업까지 같이 잃을 수 있습니다

이렇게 준비하면 좋아요

• □ 접속 여부 외에 오류·디스크·인증서 만료 알림이 있는가
• □ 결제·로그인 등 핵심 경로를 업무시간 외에도 감지할 수단이 있는가
• □ 백업 주기·보관·복구 목표가 문서에 있는가
• □ 최근 1회 이상 복원 연습 기록이 있는가
• □ 백업 실패 알림이 켜져 있는가
• □ 장애 심각도·1차 연락·대체 담당이 정의되어 있는가
• □ 되돌리기·점검 페이지 등 완화 조치가 런북에 있는가
• □ 외부 결제·문자 장애 시 벤더 연락 경로가 있는가
• □ 당직자가 모니터링·배포·런북 문서에 실제 접근 가능한가
• □ 장애 후 타임라인 기록 습관이 있는가

LB Contents는 앱·홈페이지·쇼핑몰을 납품할 때 화면 검수만으로 끝내지 않고, 오픈 후 인지·백업·대응이 가능한 최소 운영 구조를 유지보수 설계와 함께 제안합니다. “만든 뒤 방치”가 걱정된다면 현재 관측·복구 상태부터 점검 상담이 가능합니다.