SaaS 에서의 SLA 는 무엇일까요?

🐧 : 안녕하세요, 주간 SaaS 에서는 이번에는 조금은 색다른, 그러면서도 SaaS 서비스를 실제로 론칭하는 데에 필수적인 SLA 에 대해서 다루어 보고자 합니다. SLA 가 뭔지 모르셔도 괜찮습니다, SLA 가 무엇인지부터 시작해서 SLA 에 어떤 것들을 포함해야 하는지, 어떤 점을 유의해야 하는지를 오늘 다루어 보겠습니다. 오늘 읽어보실 내용은 기존 것에 비해서 길이가 짧습니다! 이따가 읽어보지 않으셔도 됩니다 :-) ! 금방 쑥 읽어보시지요.  원문은 여기에서 확인해 보실 수 있습니다.

오늘 내용을 보시기 전에, 저희 뉴스레터가 더 발전할 수 있도록 설문조사 꼭 부탁드립니다!

더 좋은 SaaS 뉴스레터를 받기 위해 설문조사 하러가기

SLA (Service Level Agreement, 서비스 수준 계약 )

서비스 수준 계약은 (1) 제품에 많은 비용을 지출하는 만큼 일정 수준의 품질을 기대한다는 점과 (2) 비즈니스 규모에 따라 예기치 않은 중단으로 인해 적지 않은 비용이 발생할 수 있다는 두 가지 전제에 기반한 기업 고객의 일반적인 요청입니다. 일반적으로 SLA는 최소 애플리케이션 가동 시간, 또는 지원 문제 해결을 위한 최대 대기 시간을 보장합니다.

가동 시간

일반적으로 엔터프라이즈 애플리케이션에 대한 SLA는 99.9% 이상(즉, 애플리케이션에 연간 8.76시간 이상의 예기치 않은 다운타임이 발생하지 않아야 함)이어야 하지만 99.99%(연간 최대 52.6분) 또는 심지어 99.999%(연간 5.26분)를 약속하는 곳도 많습니다. 이는 제품 기능이라기보다는 비즈니스 결정에 따른 것이지만, 가동 시간은 애플리케이션과 인프라 수준 모두에서 아키텍처 결정에 따라 크게 달라집니다. 또한 어느 정도의 과거 기록을 가지고 이를 보고하는 것이 중요하므로, 많은 SaaS 제공업체가 실시간 상태를 표시하고 가용성에 대한 과거 기록을 유지하는 상태 페이지를 제공합니다.

클라우드 서비스에 영향을 미치는 중단 또는 기타 문제가 발생하면 많은 회사에서 상태 페이지를 사용하여 문제를 진단하고 해결하면서 업데이트를 제공합니다. 고객은 무엇이 잘못되었는지, 언제 서비스를 다시 사용할 수 있는지 알고 싶어하며, 이러한 정보가 알려지지 않으면 악감정이 생길 수 있으므로 가능한 한 실시간에 가깝게 제공하는 것이 가장 좋은 방법입니다. 특히 장기간 또는 광범위하게 중단된 경우에는 상세한 사후 분석을 게시하는 것도 좋은 방법이며, 이를 통해 회사가 근본 원인을 해결하고 고객에게 이러한 이벤트를 진지하게 받아들이고 있음을 알릴 수 있습니다.

응답 시간

SLA에는 표준 지원 시간, 긴급 지원 및 최대 응답 시간을 제공하겠다는 약속도 포함될 수 있습니다. 응답은 자격을 갖춘 팀원이 문제를 인지하고 문제 진단을 시작하는 데 걸리는 시간으로 정의됩니다. 응답 시간은 제기되는 문제의 심각도에 따라 다릅니다.

심각도(Severity)는 보통 Sev 1, Sev 2, Sev 3으로 분류되며, 각 범주에 속하는 문제에 대한 명확한 정의가 있습니다. 해결 방법이 없는 애플리케이션 다운타임은 명백한 1단계 문제이며, 잠재적인 보안 취약점도 일반적으로 1단계로 격상됩니다. Sev1의 응답 시간은 3시간 미만일 가능성이 높습니다.

지원

고객 지원을 제공하는 방법에는 여러 가지가 있으며, 다양한 수준/수단을 제공하는 것은 다양한 요금제를 구분하기 위한 일반적인 기법입니다

기타 지원 관련 관행 및 제공 사항

계약 및 커뮤니티 지원 외에도 올바른 콘텐츠를 제작하여 고객을 교육하고 지원 업무를 일부 경감하는 데 큰 도움이 될 수 있습니다. 고품질의 문서는 특히 셀프 서비스 운영을 하는 SaaS 애플리케이션의 경우 절대적으로 필요합니다. 원하는 고객을 위해 비디오 튜토리얼, 웨비나, 유료 대면 교육까지 제공하는 것이 좋습니다.

기업 고객은 또한 제품 로드맵에 대한 가시성을 기대할 것입니다. 기업 고객은 변화하는 요구 사항을 지속적으로 충족하기 위해 추가될 기능에 영향을 미칠 수 있기를 원합니다. 그러나 일반적으로 이러한 논의에 앞서 safe-harbor 문구(🐧 : 프레젠테이션에 포함되는 경우를 의미하며,  예를 들면 오라클의 문서를 보실 수 있습니다.) 또는 기타 커뮤니케이션 수단을 통해 이것이 일반적인 방향이지만 특정 기간까지 특정 기능을 제공하겠다고 약속하지 않는다는 점을 알리는 것이 좋습니다. 일부 회사는 고객의 요청에 따라 기능을 구축하기도 하지만 이러한 유형의 거래는 계약서에 공식화해야 합니다.

또한 많은 기업 고객은 결국 비즈니스 보험, 소스 코드 에스크로 (🐧 : 소스 코드 에스크로는 클라우드 애플리케이션이나 서비스형 소프트웨어(SaaS)를 판매하려는 회사가 고객에게 안심하고 제공할 수 있는 프로세스입니다. SaaS 제공업체는 소스 코드를 독립적인 제3자에게 에스크로에 보관하는 데 동의합니다. 파산, 파산, 법정관리 또는 기타 사전 결정된 비즈니스 상황이 발생할 경우 고객은 소스 코드에 대한 액세스를 요청하여 애플리케이션을 고객과 함께 사내로 가져와 비즈니스를 재개할 수 있습니다. 여기와 여기를 참고하시면 더 많은 정보를 얻을 수 있습니다.)  및 면책과 같은 것을 요구합니다. SLA와 마찬가지로 실제 제품 기능은 아니지만, 기업 계약 협상에서 다뤄질 수 있고 제품 구축 방식에 따라 어느 정도 해결될 수 있기 때문에 이해하는 것이 중요합니다.

이제 실제 사례를 살펴보겠습니다. HashiCorp 의 사례입니다. HashiCorp 에 대해서 모르시더라도, Terraform 에 대해서는 다들 아실 겁니다. 바로 그 서비스를 하는 회사입니다. 이 회사가 Sev 를 어떻게 정의하는 지에 대해서 살펴보겠습니다.

HashiCorp의 사례

해시코프는 제품 티어를 단순하게 유지하므로 각 티어에서 어떤 수준의 지원을 받을 수 있는지 쉽게 확인할 수 있습니다. 예를 들어, Terraform의 경우 무료 오픈 소스 버전은 커뮤니티와 문서 외에 해시코프가 제공하는 지원이 전혀 없지만, 프로와 프리미엄은 각각 실버와 골드 레벨의 지원을 제공합니다. 실버 지원은 하루 9시간, 주 5일(기본적으로 근무일 기준) 제공되며, 골드 지원은 하루 24시간, 주 7일 제공됩니다. ( 🐧 : 이 글은 2018 년도 기준으로, 현재에는 다른 기준으로 되어 있습니다. 여기 에서 최신 버젼을 볼 수 있습니다. )

해시코프는 애플리케이션 가동 시간과 관련된 SLA에 대한 공개 정보는 제공하지 않지만, 지원과 관련된 SLA는 제공합니다. 회사에 지원 페이지에는 이러한 수준의 의미와 사용자가 도움말 티켓을 제출할 때 포함해야 하는 유형의 정보가 명확하게 정의되어 있습니다. 잘못 정의된 기대치와 모호한 지원 티켓은 관련된 모든 사람에게 골칫거리가 될 수 있으므로 이러한 유형의 정보는 SaaS Provider가 사용자에게 명확하게 제공하는 것이 중요합니다. 다음은 해시코프가 엔터프라이즈 제품 전반에 걸쳐 SLA를 정의하는 방식입니다. ( 🐧 : 각 단계별로 하이라이트를 해놓았습니다. 그 부분에 유의해서 보시면 됩니다. )

Sev 1(긴급): 소프트웨어의 특정 부분에 대한 사용자 대다수가 영향을 받고, 오류의 가시성이 높으며, 해결 방법이 없고, 고객의 비즈니스 수행 능력에 영향을 미치는 고객이 보고한 모든 오류입니다.

Sev 2(높음): 소프트웨어의 특정 부분에 대한 대다수의 사용자가 영향을 받고, 오류의 가시성이 높으며, 해결 방법을 사용할 수 있지만, 성능이 저하되거나 기능이 제한되어 수익에 영향을 미치는 고객이 보고한 모든 오류입니다.

Sev 3(일반): 소프트웨어의 특정 부분에 대한 대다수의 사용자가 영향을 받고, 오류의 가시성이 높으며, 해결 방법을 사용할 수 있지만, 성능이 저하되거나 기능이 제한될 수 있으며, 수익에 영향을 미치지 않는 고객이 보고한 모든 오류입니다.

Sev 4(낮음): 단일 사용자가 심각한 영향을 받거나 완전히 작동하지 않거나 일부 사용자가 중간 정도의 영향을 받거나 부분적으로 작동하지 않으며 오류가 비즈니스에 미치는 영향이 제한적인 경우 고객이 보고한 모든 오류입니다.

또한 해시코프는 또 다른 모범 사례를 따르고 있는데, 이는 SaaS 호스팅 제품의 현재 사용 가능 여부와 최근 문제 및 해결 보고서를 보여주는 상태 페이지를 유지하는 것입니다. 서비스 성능에 대한 실시간 정보를 확인하는 것은 유용하지만, 이러한 페이지의 진정한 이점은 문제가 발생했을 때에만 실현됩니다. 사용자는 이 페이지에서 실제로 성능 저하의 원인이 무엇인지, 그리고 문제가 해결되고 있는지에 대한 자세한 정보를 얻을 수 있습니다.

주간 SaaS 에 대한 피드백(익명)을 남길 수 있어요