SLA(Service Level Agreement)란?

오늘은 서비스 수준 협약(SLA)에 대해서 공유해 드릴까 합니다.

제가 SLA에 대해서 처음 알게 된 것은 이전 회사에서 일할 때 였습니다. 해외에 IoT 솔루션(자동 검침 솔루션)을 판매했는 데 그때 고객사에서 SLA 기준 및 기능을 요청해서 이를 정리하면서 처음 알게 되었죠.

그리고 그때 사용했던 SLA의 주요 지표는 바로 검침률이었죠. IoT 디바이스가 얼마나 잘 데이터를 전송하느냐에 대한 지표였습니다.

그럼 SLA가 무엇인지에 대해서 먼저 공유해 드리겠습니다.

SLA란 공급업체에서 1. 고객이 기대하는 수준을 정의하고, 2. 해당 서비스를 측정하는 지표를 제시하며, 3. 합의된 서비스 수준의 충족 여부에 따라 보상 또는 패널티를 받게 되는 것입니다.

예를 들어 클라우드 제공 업체(CSP)의 경우는 서비스 가동률이라는 지표를 제공합니다. 이는 서비스가 중단되지 않고 지속되는 것을 말합니다.
AWS의 아래 문서를 보시면 SLA로 가동률을 제시한 것을 확인하실 수 있습니다.

 AWS Service Level Agreement

SLA가 필요한 이유는 공급업체와 고객 사이의 서비스에 대한 기대치를 명확히 하기 위한 것입니다. 그리고 이에 대한 즉정 기준, 책임 및 기대 수치를 명확히 함으로써 추후 발생하는 특정 상황에 대한 책임을 명확히 할 수 있죠.

그렇기에 SLA 문서에는 제공할 서비스, 예상 서비스 수준에 대한 설명, 서비스를 측정하는 기준, 각 당사자의 의무와 책임, 위반 시에 대한 해결 방법 및 패널티, 보상, 추가 프로세스(SLA 변경 상호 협의 등) 등이 포함되어야 합니다.

그럼 SLA에서 제공되는 지표에는 어떤 것들이 있는지 공유해 드리겠습니다.

SLA에서 제공되는 지표의 유형

SLA는 서비스마다 다르겠지만, 관련하여 다음과 같은 유형들이 있습니다.

서비스 가용률

서비스를 사용할 수 있는 시간을 말합니다. 예를 들어, 오전 8시에서 오후 6시 사이에 99.5%의 가용률이 필요하고 다른 시간에는 더 낮은 가용률이 되어도 되는 식으로 시간에 따라 지정할 수 있습니다.

일반적으로 전자 상거래 운영에서는 이 가용률이 아주 중요합니다. 서비스가 중단되면 판매를 할 수 없기에 바로 매출에 영향을 줄 수 있으니까요. 그렇기에 전자 상거래 서비스의 경우 99.999%와 같이 공격적인 가용률이 적용되기도 합니다.

불량률

주요 결과물의 오류 수 또는 백분율입니다. 불완전한 백업 및 복원, 코딩 오류/재작업, 일정 준수와 같은 것이 이 범주에 포함될 수 있습니다.

기술 품질

외주 애플리케이션 개발에서 프로그램의 크기 및 코딩 결함과 같은 요소를 검사하는 상용 분석 도구로 기술 품질을 측정하기도 합니다.

보안

최근처럼 규제가 엄격한 시대에 애플리케이션 및 네트워크의 보안 취약으로 인해 문제가 발생하면 많은 비용이 발생할 수 있습니다. 그렇기에 바이러스 백신 업데이트 및 패치와 같은 제어 가능한 보안 조치를 측정하는 것도 모든 합리적인 예방 조치가 취해졌음을 증명하는 데 중요한 지표가 될 수 있습니다.

지원 관련

문의 응대나 답변하기까지의 시간, 요청 업무 준수율 등을 지표로 정할 수도 있습니다.

그리고 실제로 다음과 같은 지표들을 사용하기도 합니다.

• 서비스 가용률: 가용성, 평균 복구시간, 평균 고장간격 등
• 서비스 장애: 예정된 장애시간, 평균 장애시간, 장애원인 규명률, 장애조치 최대 허용시간 초과 건수, 총 장애 건수 등
• 서비스 성능: 평균 응답시간, 최대 응답시간 초과 건수 등
• 데이터 관리: 백업 준수율, 데이터 복구 시간, 데이터 복구 성공률 등
• 보안: 보안침해사고 발생건수, 보안사항 위반건수, 침해사건 신속한 보고율, 침해사건 신속한 해결률, 침입탐지율, 정기예방점검률 등
• 서비스 지원: 평균 고객요청 처리시간, 고객요청 처리율, 서비스 요청 적기 처리율, 변경요청 적기 처리율, 변경 적용 시 오류 건수율, 자원할당 준수율, 서비스 만족도 등

이처럼 지표는 아주 많습니다. 하지만, 이런 지표를 모두 SLA에 적용할 필요는 없습니다. 오히려 많은 SLA 지표로 인해서 실제 서비스 제공에 의미 없는 작업이 발생할 수도 있으니까 말이죠. 그렇기에 공급업체과 고객 사이에서 SLA에 대한 협상을 하게 되는 것입니다.

그럼 SLA 지표 선택 시 어떤 사항을 고려해야 할까요?

SLA 지표 선택 시 고려 사항

올바른 행동에 동기를 부여하는 지표를 선택

지표의 첫 번째 목표는 올바른 행동에 동기를 부여하는 것입니다. 그리고 이런 동기를 통해 지표로 정의된 목표를 충족하기 위한 올바른 행동을 할 수 있게 되는 것입니다.

서비스 제공 업체가 통제할 수 있는 지표 선택

지표는 서비스 제공 업체가 통제할 수 있는 지표여야 합니다. 서비스 제공 업체가 통제할 수 없다면 지표 자체의 목표를 달성하는 데 서비스 제공 업체에서 할 수 있는 행동이 없기 때문에 의미가 없는 지표가 될 수 있습니다.

쉽게 수집할 수 있는 지표 선택

지표의 수집 용이성과 원하는 지표 항목의 균형이 필요합니다. 원하는 지표가 있다고 하더라도 수집하고 정리하는 데 너무 어렵다면 지표 정리에 많은 시간이 투입되기에 확인해야 하는 고객도 제공해야 하는 서비스 제공 업체도 부담이 될 수 있습니다.

지표 항목을 최소화

너무 많은 지표를 정의하게 되면 확인해야 하는 고객도 제공해야 하는 서비스 제공 업체도 모두 업무 부하가 걸릴 수 밖에 없습니다. 그렇기에 되도록 많은 지표를 선택하는 것은 지양하는 것이 좋습니다.

적절한 기준 설정

지표는 합리적이고 달성 가능한 수준으로 설정해야 합니다. 일반적으로 과거 데이터를 기반으로 기준을 설정할 수도 있지만, 과거 데이터가 없는 경우에는 상호 간에 적절하다고 생각하는 기준을 정하더라도 시간이 흐른 후 다시 조정하는 것도 필요합니다.

SLA에 대해서 정리를 하다 보니, 개인 KPI와 참 유사하다는 생각이 들었습니다. 둘 다 어떤 목표를 정하고 그 목표를 달성하는 것으로 서비스이든 개인이든 평가를 받는 것이니까요.

그리고 KPI를 목표 이상으로 달성하면 평가가 좋은 것처럼, 고객과 합리적인 SLA를 정하고 이를 달성하게 되면 당연히 고객에게 좋은 평가를 받게 되지 않을까 하는 생각도 듭니다.

저희에게는 클라우드에 대한 다양한 정보와 경험, 그리고 도구가 있습니다.

 OpsNow에 문의하기