클라우드 SLA:2021년에 이미 무엇을 배웠습니까?

클라우드 SLA와 관련하여 악마는 세부 사항에 있습니다. 추적할 측정항목을 알고 이러한 측정항목이 수익에 미치는 금전적 영향을 평가하는 것이 중요합니다.

미 국회의사당에 대한 공격 이후, Amazon Web Services는 Twitter의 우익 마이크로블로깅 대안인 Parler 호스팅을 중단했습니다. Amazon에 따르면 Parler는 불법적이거나 유해하거나 공격적인 콘텐츠를 처리하기 위한 적절한 중재 시스템을 갖추지 않아 양방향 서비스 수준 계약(SLA)을 위반했습니다. AWS가 클라우드 서비스에서 Parler를 너무 빨리 제거할 수 있었다는 사실은 2021년에 클라우드 제공자가 호스팅하는 콘텐츠에 대해 휘두르는 엄청난 힘에 주목하게 되었습니다. 이 사례는 많은 서비스 제공자가 클라우드 SLA를 통해 보유하고 있는 힘을 드러낼 뿐만 아니라 , 그러나 세부 사항에 주의를 기울이고 클라우드 제공업체와 좋은 협력 관계를 유지해야 할 필요성도 강조합니다.

적절한 실사 없이 클라우드 SLA를 서두르지 마십시오.

Cloud SLA는 서비스 제공자가 제공되는 특정 서비스에 대해 책임을 지는 상황과 그렇지 않은 상황을 자세히 설명합니다. 이러한 계약은 다양한 조항이 포함된 살아있는 문서입니다. 중요하게도 SLA는 서비스 제공자 책임뿐만 아니라 고객 책임, 계약 위반에 대한 처벌, 응답 시간 및 해결 시간과 같은 성과 지표도 포함합니다. 조직의 법률 고문이 문서의 작은 글씨를 잘 알고 있어야 합니다. 고객이나 공급업체 모두 경계를 늦추어서는 안 됩니다. 먼저 SLA에 클라우드 공급자의 보안 표준이 자세히 나열되어 있는지 확인하십시오. 예를 들어, 클라우드 제공자가 법적으로 의무화되어 있지 않더라도 고객은 제공자가 HIPAA 표준을 준수하기를 원할 수 있습니다. 그렇다면 이러한 조건은 사전에 합의되어야 합니다. 또한 계약은 고객 조직이 스토리지에 있는 데이터의 소유권을 유지한다는 것을 확인해야 합니다. 마지막으로, 고객 조직이 향후 서비스 제공업체의 규정 준수를 감사할 수 있는 권한을 유지하도록 하는 것이 현명합니다.

참조: 멀티클라우드 계획이 코비드 안개로 인해 어려움을 겪음

양 당사자가 같은 페이지에 있는지 확인

Cloud SLA는 일반적으로 양방향입니다. 즉, 고객과 공급업체 모두에 대한 (명확한) 기대치가 있습니다. 각 당사자는 각자의 책임을 인식해야 합니다. 여기에는 최소한 허용 가능한 성능 매개변수와 위반 시 어떤 처벌, 구제책 및 서비스 크레딧이 부여되는지 파악하는 것이 포함됩니다. 성능 데이터 메트릭, 책임, 기대치, 황금 시간대 및 비황수 시간대의 예상 서비스 수준에 대해 양 당사자는 같은 입장을 취해야 합니다. 예방 정비의 정확한 일정이 있어야 하고, 일이 엉뚱한 경우 분쟁 해결 프로세스가 있어야 합니다.

다운타임, 지연 및 사고 대응에 대한 최대 허용 수준 결정

99.9% 가동 시간 보장은 적절하게 들릴 수 있습니다. 그러나 이로 인해 연간 가동 중지 시간이 약 9시간에 이르며 이는 한 달에 43분으로 단축됩니다. 글로벌 전자 상거래 회사가 일반적으로 서비스 공급자에게 99.999% 가동 시간을 요구하는 것은 놀라운 일이 아닙니다. 지연 및 사고 대응도 중요한 지표입니다. 최소한 주어진 사건에 대응하는 데 걸리는 시간을 추적하는 것이 중요합니다. 또한 조직은 허용 가능한 대기 시간 수준을 알고 있어야 합니다. 일반적으로 밀리초 단위로 측정되는 대기 시간(네트워크 내 연결 품질)은 경과된 시간입니다. 대기 시간에는 정보를 처리하거나 요청을 처리하거나 주어진 작업 단위를 완료하는 데 걸리는 시간이 포함될 수 있습니다. 명확성을 높이기 위해 기업은 종종 대기 시간 메트릭을 백분위수로 그룹화합니다. 예를 들어 "중간 대기 시간" 또는 50번째 백분위수 대기 시간은 가장 빠른 50%의 요청에 대한 최대 대기 시간을 설명합니다. 또 다른 인기 있는 지표인 99번째 백분위수 대기 시간은 모든 요청의 가장 빠른 99%에 대한 최대 대기 시간을 나타냅니다. 가능하면 대기 시간이 비즈니스에 미치는 영향을 정량화해야 합니다. 조직은 다운타임, 대기 시간 및 데이터 손실의 영향을 측정하는 명확한 KPI를 항상 가지고 있어야 합니다.

측정항목을 신중하게 정의

조직에서 집중할 올바른 메트릭을 선택한 후에는 클라우드 SLA 내에서 이러한 메트릭을 적절하게 정의하는 것이 중요합니다. 가동 시간 백분율, MTTR(평균 해결 시간) 및 사고 대응 시간과 같은 메트릭은 신중하게 정의해야 합니다. 예를 들어, SLA의 문구에 따라 자동화된 이메일 응답은 잠재적으로 클라우드 서비스 제공업체의 사고 대응 시간 메트릭을 충족하는 것으로 간주될 수 있습니다. 아마도 이메일은 당면한 문제를 적절하게 해결하지 못할 것입니다. 따라서 세부 정보를 파고 메트릭이 어떻게 정의되는지 정확하게 평가하는 것이 중요합니다. 또한 가능하면 자동으로 모니터링하여 경고를 트리거할 수 있는 메트릭을 사용하십시오. 예를 들어 대기 시간 경고가 트리거되면 IT 담당자에게 경고를 보내 당면한 대기 시간을 유발하는 네트워크 문제를 해결할 수 있도록 해야 합니다. 일반적으로 자동화가 많을수록 좋습니다.

클라우드 제공업체와 좋은 관계를 유지하세요.

합의된 서비스 수준이 충족되지 않으면 고객은 고객 청구서에서 공제되는 재정적 크레딧인 서비스 크레딧뿐만 아니라 개선 서비스도 받게 될 것입니다. 클라우드 공급자를 정직하게 유지하려면 SLA에 서비스 패널티를 적용하는 것이 중요합니다. 그러나 많은 고객이 클라우드 서비스 공급자에게 좋은 서비스에 대한 보상으로 금전적 보너스를 제공하는 것을 고려합니다. 또한 환급 조항은 제공자로부터 일부 호의를 이끌어낼 수도 있습니다. 적립 환급은 서비스 제공자가 주어진 기간 동안 효과적으로 수행할 경우 서비스 수준 크레딧을 회복하는 SLA 조항입니다. 또한 앞서 언급했듯이 SLA는 살아있는 문서입니다. 특히 회사가 빠르게 성장하는 경우 정기적으로 재협상하는 것이 중요합니다. 그러나 그러한 협상은 소란스러울 수 있으므로 이러한 재협상을 1년에 1~2회로 제한하는 것이 현명합니다.

간단히 말해서, 클라우드 SLA와 관련하여 악마는 세부 사항에 있습니다. 추적할 메트릭(예:중간 지연 시간, 가동 시간 비율, 사고 대응 시간, MTTR)을 알고 이러한 메트릭이 수익에 미치는 금전적 영향을 정확히 평가하는 것이 중요합니다. 또한 클라우드 제공업체와 좋은 관계를 유지하는 것이 중요합니다. 결국 클라우드 SLA는 양 당사자에게 이익이 되는 공생 관계를 조성해야 합니다.