유지보수 SLA 확인법: 첫 응답·임시 복구·정상화의 차이

응답 시간이 짧으면 그 안에 복구되는 건가요?

장애 접수에 대한 첫 응답과 서비스 복구는 다른 단계입니다. 유지보수 계약에서 SLA를 검토할 때는 담당자가 상황을 확인하는 시점, 임시 조치로 업무를 이어가는 시점, 정상 동작을 검증하는 시점을 나누세요. ‘신속 대응’이라는 표현만으로는 언제 누구에게 연락이 오고 무엇을 완료해야 하는지 비교하기 어렵습니다.

AWS Support 공식 문서도 지원 요청의 심각도에 따른 시간을 ‘최초 응답’으로 안내합니다. 이를 특정 유지보수 업체의 복구 보장으로 해석해서는 안 됩니다. 각 업체의 계약에서는 제공하는 지원 시간과 적용 조건을 직접 확인하세요.

• AWS Support의 최초 응답 시간 설명

야간·주말 지원은 접수 창구와 별도로 확인하세요

온라인으로 언제든 요청을 등록할 수 있다는 설명과 야간에 사람이 대응한다는 약속은 구분해야 합니다. 평일 지원 시간, 휴일 적용, 긴급 연락 경로, 부재 시 대체 담당자를 적어두세요. 고객 신고와 자동 경보 중 무엇을 기준으로 시간을 재는지, 자료나 승인을 기다리는 동안은 어떻게 기록하는지도 정해야 비교가 가능합니다.

오류 수보다 업무 영향을 기준으로 우선순위를 정하세요

주문 전체가 멈춘 상황과 일부 통계의 표시가 늦는 상황은 업무 영향이 다릅니다. 우회 가능한지, 영향받는 사용자와 사업장이 얼마나 되는지, 데이터 손실 우려가 있는지를 기준으로 등급을 정하세요. 아래 구분은 협의를 위한 예시이며 특정 업체의 제공 등급이나 대응 시간을 뜻하지 않습니다.

외부 API·클라우드 장애의 담당도 정하세요

유지보수 업체가 오류를 확인하더라도 결제사나 클라우드의 내부 장애를 직접 수정할 수 있는 것은 아닙니다. 외부 문의를 누가 접수하고, 고객에게 누가 진행을 알리며, 재시도나 수동 처리 여부를 누가 승인할지 정하세요. 서버가 정상으로 돌아온 뒤에도 실패한 주문과 중복 결제, 누락 데이터가 남았는지 별도로 확인해야 할 수 있습니다.

복구 목표를 정할 때는 운영 접근 권한, 사용할 수 있는 백업, 외부 제공자의 지원 조건을 함께 확인합니다. 계약 전에는 가능한 조치와 확인되지 않은 제약을 구분하고, 운영을 시작한 뒤 모의 복구나 실제 작업 결과를 바탕으로 절차를 보완하세요.

신고부터 복구 검수까지 같은 기록을 이어가세요

먼저 발생 시각, 영향을 받는 화면·업무와 최근 변경을 전달합니다. 담당자는 확인된 사실과 미확인 원인을 나눠 기록하고, 조치 전 영향과 복귀 방법을 확인합니다. 임시 복구 후에는 고객사의 업무 담당자가 핵심 거래나 데이터를 검수하고, 남은 문제를 후속 작업으로 분리합니다. 비밀번호나 고객의 민감한 원문은 일반 요청 글에 넣지 않도록 공유 경로를 정하세요.

• 장애 기록: 발생·접수·응답·조치·복구 확인 시각
• 판단 근거: 업무 영향·재현 조건·관련 로그·최근 변경
• 복구 자료: 적용 버전·우회 방법·검수 결과·데이터 대조
• 후속 보고: 확인된 원인·남은 위험·개선 작업과 담당자

• 유지보수 서비스의 대응 범위 확인
• 지원 조건과 유지보수 비용 비교
• 장애·배포·복구 범위의 가상 예시