관리형 애플리케이션 지원 및 유지보수
이미 운영 중인 소프트웨어가 귀사의 SLA와 티켓 큐 안에서 계속 작동하도록 관리합니다. 분류, 원인 수정, 패치 릴리스, 의존성 및 플랫폼 업그레이드, 보안 대응, 인시던트 처리를 포함합니다. 개발도 하는 엔지니어가 2차·3차 지원을 맡으므로, 반복되는 장애는 재시작하는 것이 아니라 고쳐집니다.
파트너에게 이것이 문제가 되는 이유
지원은 매니지드 서비스 중 팔기는 쉽지만 인력을 배치하기는 어려운 부분입니다. 수요가 고르지 않게 들어오고, 시간에 쫓기며 익숙하지 않은 코드를 읽을 수 있는 인력이 필요하며, 최고의 엔지니어를 투입하는 순간 그들은 더 높은 수익을 내는 업무에 쓸 수 없게 됩니다. 흔한 해법은 아무것도 고치지 않고 티켓만 닫는 별도의 저렴한 등급이며, 고객은 한 분기 안에 이를 알아차립니다.
당사의 답은 지원 인력이 엔지니어라는 것입니다. 시스템을 설명하는 데 그치지 않고 직접 변경할 수 있으며, 반복되는 인시던트를 끝내는 유일한 방법이 바로 이것입니다.
당사가 맡는 업무
분류 및 진단
1차 지원이 답할 수 없는 문의를 넘겨받아 재현하고, 재현 불가로 종결하는 대신 실제로 무엇이 문제인지 설명합니다.
재발하지 않는 수정
결함은 원인에서 수정하고, 티켓 하나가 아니라 해당 버그 유형 전체를 겨냥한 회귀 테스트를 작성하여 같은 인시던트가 다음 분기에 다시 발생하지 않도록 합니다.
릴리스 및 패치
패치 릴리스는 귀사의 변경 관리 프로세스에 따라 귀사의 파이프라인으로 배포하며, 의존성, 프레임워크 버전, 플랫폼 런타임을 최신으로 유지하여 업그레이드 위기로 번지지 않게 합니다.
보안 대응
의존하는 구성 요소에 보안 권고가 공개되면 백로그 항목이 아니라 무조건 업그레이드해야 할 이유입니다. 당사가 이를 추적하고 패치하며 노출 범위가 어땠는지 알려 드립니다.
모니터링 및 인시던트
이미 있는 알림을 모니터링하고, 필요한 알림을 추가하며, 인시던트를 처리한 뒤 무슨 일이 있었고 재발을 막으려면 무엇이 필요한지 서면으로 정리합니다.
소규모 변경
고객을 만족시키지만 별도 프로젝트로 만들 만큼은 아닌 소규모 개선이 꾸준히 이어집니다. 같은 용량 안에서 같은 조건으로 처리합니다.
귀사의 SLA에 대한 솔직한 평가
아무도 귀사의 시스템을 본 적이 없는 상태에서 만들어 낸 숫자는 귀사에도 귀사의 고객에도 아무 가치가 없으므로, 응답 및 해결 목표는 공개하지 않습니다. 대신 귀사가 이미 부담하고 있는 SLA를 읽고, 그중 어느 부분을 실제로 맡을 수 있는지와 그에 필요한 대응 범위를 알려 드린 뒤, 이를 서면으로 약속합니다.
근무 시간 외 대응도 마찬가지입니다. 프로젝트에 필요하고 사전에 합의한 경우, 누군가를 깨워 놓고 잘되기를 바라는 것이 아니라 해당 시간대를 위해 채용했거나 배정한 인력이 담당합니다. 당사는 이미 다른 프로젝트에서 유럽, 호주, 미국 태평양 시간대에 맞춰 운영하고 있으므로, 문제는 가능 여부가 아니라 어느 시간대가 필요한지입니다.
당사가 구축하지 않은 시스템 인수
이것이 일반적인 경우입니다. 지금까지 9건을 인수했으며 가장 오래된 것은 2008년에 작성되었습니다.
읽기 전용 검토 우선
책임을 지기 전에 코드, 인프라, 티켓 이력에 대한 접근 권한을 받고, 변경하지 않고 살펴봅니다.
서면 위험 목록
취약한 부분, 패치되지 않은 부분, 문서화되지 않은 부분, 밤에 누군가를 깨우게 될 부분을 운영 영향 순서로 정리합니다. 당사와 더 진행하든 아니든 귀사가 가져가실 수 있습니다.
대응 범위 협의
양측이 서명하기 전에 귀사가 고객에게 부담하는 SLA를 읽고, 어느 부분을 맡을 수 있는지, 필요한 시간대는 어떻게 되는지, 비용은 얼마인지 솔직하게 알려 드립니다.
인수인계 후 본격 운영
현재 지식을 보유한 담당자와 정해진 섀도잉 기간을 거친 뒤 큐를 넘겨받습니다. 더 이상 지식을 보유한 사람이 없다면 위험 검토부터 시작합니다.
그렇게 합의하면 귀사의 이름으로
지원은 보통 매니지드 서비스에서 가장 눈에 띄는 부분이므로, 화이트 라벨이 가장 중요한 부분이기도 합니다. 당사 엔지니어는 귀사가 발급한 메일함과 계정으로 일하고, 귀사의 티켓 시스템에서 답변하며, 귀사가 수정 없이 그대로 전달할 수 있는 인시던트 보고서를 작성합니다. 귀사의 고객은 끝까지 귀사와만 거래합니다. 구성 방식은 화이트 라벨 개발에서 설명하며, 지원에도 똑같이 적용됩니다.
지원 비용 책정 방식
인력 1인당 월 단위로 책정하므로, 귀사의 비용을 예측할 수 있고 이를 기준으로 고객에게 지원 계약 가격을 정할 수 있습니다. 모든 인력이 당사 포털에 근무 시간을 기록하고, 귀사는 한 달 내내 근무 시간을 확인하며, 같은 수치로 인보이스를 산출하므로 양측이 대조하는 단일한 기록이 있습니다.
지원이 신규 개발과 함께 있는 경우, 둘은 보통 두 개의 계약이 아니라 하나의 딜리버리 팟으로 구성하므로 한쪽의 한가한 주가 다른 쪽의 바쁜 주를 뒷받침합니다.
지원 계약 관련 질문
관리형 애플리케이션 지원에는 무엇이 포함됩니까?
이미 운영 중인 소프트웨어가 계속 정상 작동하도록 하는 일입니다. 접수되는 요청의 분류, 결함 재현과 수정, 1차 지원이 답할 수 없는 기술 문의 대응, 패치 릴리스 배포, 의존성과 플랫폼 버전 최신화 유지, 알림 모니터링, 장애 발생 시 인시던트 대응이 포함됩니다. 2차 및 3차 지원 업무이며, 1차 지원은 지금 있는 곳에 그대로 둡니다.
저희 SLA에 맞춰 작업하십니까?
예. 귀사의 시스템을 알기도 전에 정한 숫자는 아무 의미가 없으므로, 당사는 응답 및 해결 목표 시간을 미리 게시하지 않습니다. 귀사가 이미 고객에게 부담하는 SLA를 검토하고, 그중 당사가 감당할 수 있는 부분과 필요한 지원 범위를 솔직하게 알려 드린 다음 이를 서면으로 약속합니다.
근무 시간 외 지원이나 당직 대응도 가능합니까?
예. 근무 시간 외 지원과 당직 대응은 사전에 합의하여 지원 약관에 명시하고, 근무 시간이 이에 맞는 인력이 맡으므로 야간 장애도 잠에서 깬 사람이 아니라 근무 중인 담당자에게 전달됩니다.
당사가 만들지 않은 시스템도 지원할 수 있습니까?
그것이 일반적인 경우입니다. 지금까지 9건을 인수했으며 가장 오래된 시스템은 2008년에 작성된 것입니다. 인수한 시스템의 지원은 읽기 전용 검토와, 운영 영향도 순으로 정리한 서면 위험 목록에서 시작하므로, 처음 몇 주는 압박 속에서 추측하는 대신 실제로 무엇을 책임지게 되는지 파악하는 데 쓰입니다.
시스템을 지원하는 사람이 변경 작업도 같은 사람이 합니까?
예, 그것이 핵심입니다. 지원을 맡은 엔지니어는 티켓만 닫는 별도 계층이 아니라 엔지니어이므로, 반복되는 장애를 매주 월요일마다 재시작하는 대신 원인에서 해결할 수 있습니다. 개발과 지원을 모두 당사에 맡기시는 경우 두 팀은 코드 리뷰와 아키텍처 의사결정을 공유합니다.
지원 비용은 어떻게 책정됩니까?
인원당 월 단위로 책정하므로 귀사의 비용을 예측할 수 있고, 이를 기준으로 귀사의 고객에게 제시할 지원 계약 가격도 정할 수 있습니다. 근무 시간은 당사 포털에 기록되어 한 달 내내 확인하실 수 있으며, 같은 수치로 청구서를 발행하므로 양측이 하나의 출처를 공유합니다.
계속 운영해야 할 시스템이 있으십니까?
시스템이 무엇인지, SLA가 무엇을 약속하는지, 현재 지원에서 어려운 부분이 어디인지 알려 주십시오. 내용을 읽고 맡을 수 있는 부분과 맡을 수 없는 부분을 모두 알려 드리겠습니다.