모든 시스템 계약에는 도입과 운영계약이 있다.
그럼 SLA는 왜 해야 하는가?
기본적으로 계약서에 명시된 운영유지보수는 통상 2가지 관점이다.
1. 월1회 정기점검(예방점검)
2. 장애 발생시 3시간 또는 1일 이내의 원상 복구
하지만 2가지 외에 세부적으로 서비스의 수준을 요구할 필요가 발생한다. 솔루션이나 서버 도입이후, 위의 2가지 요구사항 외에 유지보수상 더 필요한 것을 요구하기는 어렵다. 정기점검은 논란의 대상이 없고, 장애 발생에 대해서는 사실 하드웨어 적인 파츠(parts, 부품)가 장애가 나서 부품 공수에 예상보다 오랜 시간이 걸릴 수 있고, OS나 또는 다른 솔루션과의 연계에 따른 예상치 못하는 장애에 대해 CASE 별로 요구사항을 정의할 수없다.
이것은 예상되는 문제를 나열하는 것도 한계가 있고, 예상되지 못한 문제에 대해 납품업체에 무한 책임을 요구하는 것도 어렵다.
그럼에도 불구하고 왜 우리는 SLA(Service Level Agreement)를 필요로 할까? 그건 무엇이고 언제 사용해야 할까?
SLA란?
서비스수준계약(Service-Level Agreement)이란 고객이 공급업체에게 기대하는 서비스 수준을 기술한 문서다. 이 문서에는 해당 서비스를 측정할 지표가 규정된다. 또 합의된 수준을 충족하지 못했을 때 해결책이나 불이익이 있으면 역시 명시된다. 통상적으로 SLA는 회사와 외부 공급업체 간에 체결되지만 한 회사에 속한 부서 사이에서도 체결될 수 있다.
예를 들어, 통신회사의 SLA는 99.999퍼센트의 네트워크 가용성을 약속한다. 즉, 1년에 발생하는 다운타임이 약 5.25분이라는 뜻이다. 이용하는 기업입장에서는 무중단 서비스를 해야 하는데 이것도 너무 긴 시간이다.
만일 이 약속을 지키지 못하면 고객의 결제 금액을 소정 비율 깎아준다. 통상적으로 할인 폭은 위반 정도에 따라 차등 적용된다.
SLA가 필요한 이유는?
SLA는 IT벤더 계약에서 필수적이다. 약정 서비스 일체와 그와 관련해 합의된 기대 신뢰도에 대한 정보를 하나의 문서에 정리하고 측정 지표, 책임, 기대치가 명시되어 있다. 따라서, 서비스에 문제가 발생했을 때 어느 측도 몰랐다는 변명을 할 수 없게 되어 있다. 양측이 요건을 똑같이 이해하도록 보장한다.
SLA이 없으면 고의적으로 또는 의도치 않게 계약을 편파적으로 해석할 수 있다. 따라서 SLA는 계약 쌍방을 보호하는 역할을 한다.
SLA는 업무의 기술 목표 또는 사업 목표와 일치되는 것이 이상적이다. 목표에 어긋나게 작성되면 계약 가격 책정과 서비스 제공 품질, 고객 경험 등에 부정적인 영향을 미칠 수 있다.
SLA는 누가 준비하는가?
대부분의 서비스 공급업체에는 표준 SLA가 구비되어 있다. 이러한 표준 SLA는 협상을 시작할 때 좋은 참고 자료가 된다. 그러나 공급업체에게 유리한 방향으로 작성된 경우가 대부분이기 때문에 고객사의 검토와 수정을 반드시 거쳐야 한다.
고객은 제안요구서(RFP)를 보낼 때 기대하는 서비스 수준을 명시해야 한다. 요구 수준에 따라 공급업체의 제공 내용과 가격이 달라지기 때문이다.
요구 서비스 수준이 너무 과하면 아예 응답이 없을 수도 있다. 예를 들어, 고객이 시스템 가용성 99.999 퍼센트를 요구했을 때 공급업체 측에서 고객이 지정한 설계로는 이 요건을 충족할 수 없다면 다른 솔루션을 제안하기도 한다.
SLA 내용은?
SLA의 내용 중에는 제공될 서비스와 기대 서비스 수준에 대한 설명이 있어야 한다. 아울러, 서비스 측정 지표, 각 당사자의 의무와 책임, 계약 위반 시 해결책 또는 불이익, 지표를 추가하거나 제거할 때 적용되는 규칙 등의 내용도 있어야 한다.
측정 지표는 각 당사자가 나쁜 행동을 했을 때 이득을 얻지 못하도록 해야 한다. 예를 들어, 고객이 정보를 제때 제공하지 않아서 서비스 수준이 충족되지 못했다면 공급업체가 불이익을 받아서는 안 되는 것이다.
SLA의 핵심 구성요소는?
SLA에는 서비스와 관리라는 두 가지 분야의 구성요소가 들어있어야 한다.
서비스 분야에 포함될 내용은 제공 서비스의 상세 내용, 서비스 가용성 조건, 각 서비스 수준에 대한 시간 창과 같은 기준(가령, 황금 시간대와 그 이외 시간대의 서비스 수준은 상이할 수 있음), 각 당사자의 책임, 단계적 문제 해결 절차, 비용/서비스 절충 내용 등이다.
관리 분야에 포함될 내용은 측정 표준 및 방식의 정의, 보고 절차, 내용 및 빈도, 분쟁 해결 절차, 서비스 수준 위반으로 인한 제3자 소송으로부터 고객을 보호하는 배상 조항(계약서에 이미 다뤘어야 할 부분이기는 하다), 필요에 따라 계약서를 업데이트할 방법 등이다.
이 마지막 항목이 중요하다. 서비스 요건과 벤더 역량은 변하기 때문에 SLA를 최신 상태로 유지할 방법이 있어야 한다.
배상 조항이란 무엇인가?
배상 조항은 서비스 공급업체가 보증 위반 시 고객 업체에게 배상하기로 합의하는 중요한 조항이다. 배상이란 공급업체가 약속 위반으로 인한 제3자 소송 비용 일체를 고객에게 지급해야 함을 의미한다.
서비스 공급업체에서 제공된 표준 SLA에는 이 조항이 없을 가능성이 높다. 이 내용이 포함된 간단한 조항 작성을 사내 변호사에게 요청해야 한다. 단, 서비스 공급업체는 이 부분에 대한 추가 협상을 원할 수 있다.
서비스 수준을 어떻게 확인 가능한가?
대부분의 서비스 공급업체는 온라인 포털을 통해 통계 자료를 공개하는 경우가 많다. 이를 통해 고객들은 SLA의 충족 여부와 SLA에 규정된 서비스 크레딧 등 불이익에 해당되는지 여부를 확인할 수 있다.
통상적으로 이러한 절차와 방법을 파악하는 것은 외주 회사의 몫이다. 해당 절차와 방법이 SLA 계약을 뒷받침할 수 있는지 확인해야 한다. 그러나 고객과 외주 회사는 관리 및 보고 방법뿐만 아니라 지원 절차 및 방법에 대한 오해가 없도록 SLA 계약 협상 중에 협력할 것을 권장한다.
그러나 중요한 서비스의 경우에는 고객은 SLA 이행 자료를 자동으로 캡처하는 타사 도구에 투자하는 것이 좋다. 이를 통해 이행 상황을 객관적으로 측정할 수 있다.
모니터링해야 할 측정 지표는?
SLA의 일부로 여러 항목을 감시할 수 있다. 단, 감시 방법은 가능한 한 간단하게 해야 양측에 과도한 비용과 오해를 방지할 수 있다.
측정 지표 선택 시에는 운영 상황을 점검하고 가장 중요한 것을 결정해야 한다. 감시 방식(그리고 그와 관련된 해결 방식)이 복잡하면 복잡할수록 효과는 떨어질 공산이 크다. 데이터를 제대로 분석할 여유가 없기 때문이다.
확신이 없을 때에는 데이터 수집이 쉬운 지표를 선택한다. 자동화 시스템이 가장 좋다. 힘들게 수동으로 수집한 지표는 신뢰하기 어렵다. 서비스에 따라 감시해야 할 측정 지표는 다음과 같다.
- 서비스 가용성: 사용 가능한 시간의 양. 타임 슬롯으로 측정한다. 예를 들면, 오전 8시에서 오후 6시 사이에는 99.5%의 가용성이 요구되고 다른 시간 중에는 이보다 더 높거나 낮은 가용성을 명시한다. 전자상거래 운영에 대한 SLA은 대단히 적극적인 요구를 하는 경우가 대부분이다. 한 시간에 수백만 달러를 벌어들이는 사이트의 경우 99.999% 업타임 요구도 드물지 않다.
아래와 같은 사업에 대해 SLA를 체결하는 것은 검토하시 바란다.
1. 인력 투입으로 받는 관제, 모니터링 등의 서비스는 성실함에 따라 서비스의 질이 차이 심할 경우
2. 통합 유지보수 입장에서 장애 대응 속도, 처리률 등 MMTR
3. 서비스 토탈 아웃 소싱 : 서비스 개선 건수, 서비스 개발 건수 등
SLA는 반드시 해야하는 것은 아니다. 하지만 사업의 특성을 보아 지급하는 보수에 대해 응당의 서비스를 받기 위해서라면 계약 체결시점에서 사전에 SLA 체결 요건을 넣고, 시작은 단순하고 모두가 목표달성 가능한 수준에서 시작하다가 월별 점검을 통해 수준을 맞춰 가는 것이 어떨까 싶다. 물론 지표를 합의할 수 있다면시작부터 상당수준으로 시작하는 것이 더 좋을 것 같다.
'반갑습니다. 신입님' 카테고리의 다른 글
[테스트방법] 시스템 검증하는 방법(BMT와 POC차이) (0) | 2021.10.13 |
---|---|
코인에 투자하기 전에 나는 누구인가? (0) | 2021.04.27 |
박진영이 말하는 '절대 인맥' 쌓으려 노력하지 마라. (0) | 2021.04.05 |
2020년 1회 이후 정보처리기사 필기 시험과목 변경 사항 안내 (0) | 2019.10.03 |
IT시스템 운영관리 매뉴얼2(NIA 제공) (0) | 2019.09.22 |