서비스 유지보수, 장애가 나기 전에 개발사와 정할 기준은?

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.

오늘의 인사이트 요약

• 서버 상태와 함께 고객의 신청·결제가 끝까지 처리되는지 확인합니다.

• 장애 접수, 조사 시작, 복구 확인의 담당자와 완료 조건을 정합니다.

• 인수인계는 다음 담당자가 실제로 접근하고 운영해 보는 데까지 이어갑니다.

사이트는 열리는데 고객의 신청 내역이 관리자 화면에 들어오지 않는 상황을 가정해 보겠습니다. 서버는 정상으로 표시돼도 고객은 답변을 기다리고, 담당자는 신청이 들어왔다는 사실조차 모릅니다. 이런 문제를 누가 발견하고 어디로 알릴지 정해두지 않았다면 대응을 시작하는 데부터 시간이 걸리게 되는데요.

서비스 유지보수 사항을 협의할 때 수정 가능한 기능과 월 작업량만 확인하기 쉬운 이유도 여기에 있습니다. 평소에는 문제가 없어 보이기 때문입니다. 계약이나 운영 문서를 검토할 때는 고객이 막히는 순간을 하나 떠올려 보면 발견부터 복구 확인까지 누가 무엇을 맡는지 따라가면 빠진 일을 찾기 수월합니다.

1. 고객이 끝내야 할 일을 기준으로 점검해야 합니다.

먼저 서비스에서 반드시 완료돼야 하는 일을 적습니다.

로그인, 결제, 신청서 제출처럼 고객이 자주 이용하거나 실패했을 때 영향이 큰 기능이 대상입니다. 버튼을 누를 수 있는지만 보지 말고, 이후 처리까지 어디를 확인해야 완료인지 정합니다.

신청 기능을 예로 들면 완료 화면이 뜨는지, 신청 정보가 저장되는지, 담당자가 해당 내역을 조회할 수 있는지가 각각 점검 대상이 될 수 있습니다. 서비스에 따라 알림 전달까지 확인해야 할 수도 있습니다. 똑똑한개발자팀은 고객의 신청이 운영자의 처리로 이어지는 데까지 확인해야 점검을 마쳤다고 생각합니다. 고객 화면에 완료 표시가 떠도 내부에서 처리할 수 없다면 업무는 끝나지 않은 셈이니까요.

서버의 상태를 보는 점검도 필요합니다.

다만 서버가 살아 있다는 사실만으로 모든 기능이 정상이라고 판단하지는 않습니다. 유지보수를 맡길 때는 시스템 상태를 어떻게 확인하는지와 고객의 이용 흐름을 어떻게 점검하는지를 함께 물어보세요. 자동 점검이 포함된다면 어떤 기능을 어느 범위까지 실행하는지도 확인합니다.

테스트가 실제 주문이나 고객 알림으로 이어지지 않도록 계정과 데이터 처리 방식을 정하는 일도 빠뜨리지 않습니다. 점검을 위해 만든 신청 내역을 누가 정리하는지까지 합의해 두면 운영자가 실제 접수와 구분하는 데 도움이 됩니다.

2. ‘빠른 대응’을 구체적인 약속으로 바꿔야 합니다.

장애에 빠르게 대응한다는 말만으로는 서로의 기대를 맞추기 어렵습니다.

운영자는 곧 복구될 것으로 생각했는데 개발사는 접수 확인을 뜻했을 수 있습니다. 접수한 시점, 조사를 시작한 시점, 이용이 정상화된 시점을 구분해 적어두면 이런 오해를 줄일 수 있습니다.

그리고 각 시점에는 담당자와 완료 조건이 필요합니다. 접수할 때는 어떤 채널로 증상을 전달할지, 조사를 시작하면 누가 진행 상황을 알릴지 정합니다. 해결 예상 시간을 당장 알 수 없는 경우에도 다음 안내 시점을 정해두면 운영팀이 상황을 설명하기 쉽습니다.

처리 순서는 고객에게 미치는 영향을 보고 정해야 하는데요.

전체 결제가 중단된 상황과 일부 화면의 문구 오류를 같은 우선순위로 다루기는 어렵습니다. 영향을 받는 사용자 범위, 중단된 업무, 대신 이용할 방법이 있는지를 함께 보고 긴급도를 판단합니다. 이 기준을 장애가 난 뒤 처음 논의하지 않도록 미리 맞춰두는 편이 좋습니다.

원인을 모두 밝히기 전에 이용을 재개할 방법을 검토해야 할 수도 있습니다. 이전 배포로 되돌리거나 일부 기능을 잠시 멈추는 조치가 가능한지, 누가 승인할지 정합니다. 이후 원인을 조사할 수 있도록 필요한 로그도 보존합니다. 외부 결제·인증 서비스의 장애라면 그쪽 복구를 기다리는 동안 고객 안내를 맡을 사람도 있어야 합니다.

3. 문서를 받은 뒤 실제로 운영해 봅니다

똑똑한개발자팀은 인수인계의 완료 여부를 문서의 양보다 다음 담당자가 실제로 업무를 이어갈 수 있는지로 판단해야 한다고 보는데요.

새 담당자가 문서를 따라 접속했는데 권한이 없거나, 배포 방법이 현재 환경과 다를 수 있습니다. 클라우드, 도메인, 소스 저장소, 배포 도구의 소유자와 관리자를 확인하고 업무에 필요한 접근 권한이 있는지 살펴봅니다.

접근 수단은 조직이 관리하는 방식으로 전달합니다. 개인 계정에만 의존하는 부분은 없는지, 이전 담당자의 권한은 언제 회수할지도 확인하세요. 접근에 실패했을 때 누구에게 요청해야 하는지까지 문서에 연결돼 있어야 다음 담당자가 혼자서도 일을 이어가기 쉽습니다.

백업은 저장돼 있는지와 복원할 수 있는지를 나눠 봅니다. 무엇을 얼마나 자주 보관하는지 확인하고, 실제 복원 점검의 범위를 협의합니다. 복원된 데이터가 어느 시점의 것인지, 복원 환경에서 핵심 기능이 작동하는지도 기록합니다. 필요한 복구 수준은 서비스 중단의 영향과 비용을 함께 보고 정합니다.

그리고 운영 문서는 처음 보는 사람이 따라 읽으며 확인하는 편이 좋습니다. 자주 발생하는 증상, 확인할 로그 위치, 배포 순서, 연락할 담당자가 현재 상태와 맞는지 살펴보세요. 시스템이나 담당자가 바뀔 때 문서도 함께 수정할 사람을 정해두면 다음 인수인계 때 같은 내용을 다시 찾는 일을 줄일 수 있습니다.

우리 서비스에 필요한 지원 범위를 정합니다

유지보수 비용을 비교할 때는 월 수정 건수 옆에 점검 범위와 지원 시간대, 장애 시 맡는 역할을 함께 놓고 보세요. 같은 금액이어도 운영팀이 직접 해야 할 일은 달라질 수 있습니다. 모든 기능을 같은 수준으로 관리하기보다 고객에게 영향이 큰 업무부터 필요한 지원을 정하는 편이 현실적입니다.

똑똑한개발자는 웹·앱부터 관리자 시스템과 SaaS까지 프로덕트를 기획·디자인·개발·운영해온 경험이 있습니다. 고객의 이용 화면과 내부 담당자의 처리 과정을 함께 살펴보고 서비스 상태에 맞는 지원 범위를 협의합니다.

서비스에 맞는 유지보수 범위를 정하거나 운영 중 겪는 불편을 개선하고 싶다면, 아래 똑똑한개발자 링크로 이야기 나눠주세요! 감사합니다.