저는 특정 구성을 기반으로 제품에 대한 공식 SLA를 구성하라는 요청을 점점 더 많이 받고 있는 소규모 개발 회사에서 일하고 있습니다.
개발 측면에서 나는 이것이 편안하지만 하드웨어/플랫폼 관점에서 현실적이지 않다면 소프트웨어 관점에서 특정 목표를 달성할 것이라고 말하는 것은 의미가 없습니다. 클라이언트는 전반적인 것에 대해서만 관심을 갖습니다. 시스템 가용성.
플랫폼 관점에서 무엇을 보아야 합니까? 어떤 종류의 지표와 수준이 있나요?
또한 문제점은 무엇입니까(예를 들어 소프트웨어 관점에서 저는 수정 시간을 약속한 적이 없습니다. 문제를 수정하기 위해 전체 제품을 다시 작성하여 우리가 수정할 수 있도록 해야 할지 모르겠습니다. 5일은 잠재적으로 불가능합니다. 하드웨어/OS/플랫폼 관점에서 무엇을 약속하지 않아야 합니까?
답변1
나는 이 분야에서 광범위한 경험을 가지고 있습니다. 저는 호스팅 및 지원 서비스가 필요한 여러 회사 부서에 ISP처럼 데이터 센터를 운영하는 몇몇 Fortune-5 회사를 위해 많은 일을 하고 있습니다.
일반적으로 SLA(서비스 수준 계약)와 OLA(운영 수준 계약)라는 두 가지 측정 기준이 있습니다.
SLA는 사용 중인 하드웨어 유형을 통해 충족됩니다. SLA에 대해 이야기할 때 우리는 이를 설명하기 위해 수준을 사용합니다. SLA-1은 가동 중지 시간이 0이고, SLA-2는 최대 1시간의 가동 중지 시간, SLA-3은 8시간 등입니다. SLA는 중복 장비 사용을 통해 충족됩니다. 한 회사에서는 고가용성을 창출하기 위해 Cisco를 많이 사용합니다(Cisco CSM 및 GSS 장비). SLA 수준에 관해 이야기할 때 일반적으로 HA(고가용성) 및 DR(재해 복구)에 대해 이야기합니다. 회사에 여러 데이터 센터가 있는 경우 HA 구성 요소는 일반적으로 데이터 센터별 속성인 반면 DR은 데이터 센터 전체 속성입니다. 둘 다 RPO(복구 지점 목표) 및 RTO(복구 시간 목표) 측면에서 측정되었으며 이는 SLA 수준을 의미합니다.
OLA는 실제로 기본적으로 누군가(사람)가 수동 개입/수정 조치가 필요한 이벤트에 얼마나 빨리 응답하는지를 나타냅니다. OLA는 일반적으로 응답 시간 측면에서도 측정됩니다. 그들은 동일한 RTO/RPO 목표를 사용합니다. 제가 컨설팅하는 한 회사는 OLA 측정항목에 6가지 수준을 사용합니다. 여기의 처음 3개 수준은 이에 대한 예입니다.
OLA-1: RTO 0 < 2시간 OLA-2: RTO >= 2 & <= 4시간 OLA-3: RTO >= 24시간 & <= 30일(데이터 센터 오류가 아닌 경우), DC 오류가 > 30일인 경우.
OLA 및 SLA 측정항목을 구동하는 항목을 CIA 등급이라고 합니다. CIA = 기밀성, 무결성 및 가용성. 애플리케이션에 대한 데이터는 해당 애플리케이션에 대한 비용을 지불하는 사업 단위별로 분류되어야 합니다. CIA는 OLA와 SLA가 무엇인지 추진하는 데 도움을 줄 것입니다. CIA 수준의 각 부분에는 1부터 3까지의 숫자가 지정됩니다. 따라서 예를 들어 CIA 등급 1-1-1은 극비 수준, 최고 무결성 수준 및 최고 가용성 수준이 됩니다. 3-3-3의 CIA 등급은 당신이 갈 수 있는 가장 낮은 등급입니다. 따라서 CIA 등급 3-3-3은 일반적으로 SLA-6 및 OLA-6이 가장 낮은(가장 긴 응답 시간) 보장되는 SLA 및 OLA 수준 6에 매핑됩니다.
CIA 등급을 도출하는 방법은 일반적으로 데이터가 도난당하거나(기밀성) 손상되거나(무결성) 시스템이 다운될 경우(가용성) 기업이 손해를 보는 금액을 파악하는 것과 같습니다. 따라서 기밀 데이터가 도난당할 경우 1,000만 달러를 잃을 수 있는 회사의 C 등급은 1일 수 있습니다. 또는 데이터 손실이 심각하지 않고 회사에 1,000달러의 비용만 발생한다면 C 등급은 3일 수 있습니다. .
이것은 일반적으로 제가 컨설팅한 대기업이 그러한 일을 처리하는 방식입니다.
답변2
소프트웨어와 마찬가지로 하드웨어 문제에 대한 수정 시간을 약속하는 데 시간이 오래 걸립니다. 공급업체가 무언가의 중요한 버그를 수정하기를 언제 기다릴지 알 수 없습니다. SLA 수준의 측면에서 볼 때 "누군가가 X시간 내에 문제를 해결하게 될 것입니다"라는 형식을 취하는 경향이 있는 것으로 나타났습니다. X 물론 지불하는 금액에 따라 다르지만 내 경험상 1시간에서 8시간 사이가 정상으로 보입니다.
답변3
소프트웨어가 설치되는 하드웨어 문제의 복원을 위해 SLA를 제공하라는 요청을 받는 경우 대답은 "아니요"입니다. 응답 시간을 약속할 수 있지만 전체 하드웨어/OS/소프트웨어 스택을 제어하지 않으면 해결 시간을 약속할 수 없습니다.
고객이 귀하의 제품에 대해 호스팅 서비스가 정말로 필요하다고 어색한 방식으로 말하고 있는 것은 아닐까요? 그렇게 하면 그들이 걱정하는 내부 문제를 피할 수 있고 비용도 절감할 수 있습니다.
답변4
SLA 계약 시 고려해야 할 한 가지 사항은 SLA 자체는 전혀 의미가 없으며, SLA가 이행되지 않을 경우의 처벌과 함께 준수해야 한다는 것입니다.
예를 들어, ISP는 네트워크에서 100% SLA를 제공하지만, 우리가 돌려받을 수 있는 최대 금액은 월별 청구서입니다. 요즘에는 대역폭이 저렴하고 네트워크가 다운될 때 손실되는 금액에 가깝지 않기 때문에 매우 낮습니다. .
또한 일반적으로 계약서에 기록되는 내용은 누군가가 문제에 얼마나 빨리 대응할 것인지이지 문제를 해결하는 데 실제로 시간이 얼마나 걸리는지는 아닙니다. 따라서 짧은 응답 시간을 약속하는 경우 야간 근무에 인턴을 배치하여 깨어날 때까지 티켓을 섞으면 됩니다.
내 경험에 따르면 이 모든 SLA 비즈니스는 실질적으로 거의 의미가 없습니다.